All of lore.kernel.org
 help / color / mirror / Atom feed
* lgdt3304
@ 2013-06-27 18:38 Carl-Fredrik Sundstrom
  2013-06-27 18:58 ` lgdt3304 Steven Toth
  2013-06-27 18:59 ` lgdt3304 Devin Heitmueller
  0 siblings, 2 replies; 14+ messages in thread
From: Carl-Fredrik Sundstrom @ 2013-06-27 18:38 UTC (permalink / raw)
  To: linux-media


Has the driver for lgdt3304 been tested ? I am trying to get a new card
working 

AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1 Interface

It is using

1 x saa7160E
2 x LGDT3304
2 x TDA18271HD/C2

I get so far that I can load a basic driver by modifying the existing
saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the
LGDT3304 when attaching it using the 3305 driver.

I always fail at the first read from LGDT3305_GEN_CTRL_2, does this register
even exist in lgdt3304 or is it specific to lgdt3305?

        /* verify that we're talking to a lg dt3304/5 */
         ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, &val); 
         if ((lg_fail(ret)) | (val == 0))
        {
                printk("fail 1\n");
                goto fail;
        }

Since I do find the TDA18271HD/C2 I don't think there is something wrong
with the i2c buss. I also tried every possible i2c address without success.
The lgdt3305 has option between address 0x0e and 0x59, is it the same for
3304 ?

This is the first time I am trying to get a driver to work in Linux. Please
help me.

Thanks /// Carl-Fredrik


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lgdt3304
  2013-06-27 18:38 lgdt3304 Carl-Fredrik Sundstrom
@ 2013-06-27 18:58 ` Steven Toth
  2013-06-27 21:00   ` lgdt3304 Carl-Fredrik Sundstrom
  2013-06-27 18:59 ` lgdt3304 Devin Heitmueller
  1 sibling, 1 reply; 14+ messages in thread
From: Steven Toth @ 2013-06-27 18:58 UTC (permalink / raw)
  To: Carl-Fredrik Sundstrom; +Cc: linux-media

> I get so far that I can load a basic driver by modifying the existing
> saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the
> LGDT3304 when attaching it using the 3305 driver.

A GPIO holding the 3304 in reset?

--
Steven Toth - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lgdt3304
  2013-06-27 18:38 lgdt3304 Carl-Fredrik Sundstrom
  2013-06-27 18:58 ` lgdt3304 Steven Toth
@ 2013-06-27 18:59 ` Devin Heitmueller
  2013-06-27 20:45   ` lgdt3304 Carl-Fredrik Sundstrom
  2013-06-28  3:00   ` lgdt3304 Carl-Fredrik Sundstrom
  1 sibling, 2 replies; 14+ messages in thread
From: Devin Heitmueller @ 2013-06-27 18:59 UTC (permalink / raw)
  To: Carl-Fredrik Sundstrom; +Cc: linux-media

On Thu, Jun 27, 2013 at 2:38 PM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
>
> Has the driver for lgdt3304 been tested ? I am trying to get a new card
> working
>
> AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1 Interface
>
> It is using
>
> 1 x saa7160E
> 2 x LGDT3304
> 2 x TDA18271HD/C2
>
> I get so far that I can load a basic driver by modifying the existing
> saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect the
> LGDT3304 when attaching it using the 3305 driver.
>
> I always fail at the first read from LGDT3305_GEN_CTRL_2, does this register
> even exist in lgdt3304 or is it specific to lgdt3305?
>
>         /* verify that we're talking to a lg dt3304/5 */
>          ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, &val);
>          if ((lg_fail(ret)) | (val == 0))
>         {
>                 printk("fail 1\n");
>                 goto fail;
>         }
>
> Since I do find the TDA18271HD/C2 I don't think there is something wrong
> with the i2c buss. I also tried every possible i2c address without success.
> The lgdt3305 has option between address 0x0e and 0x59, is it the same for
> 3304 ?
>
> This is the first time I am trying to get a driver to work in Linux. Please
> help me.

Either the i2c is broken or the lgdt3304 is being held in reset by a GPIO.

Also, that device has multiple i2c busses, so you could be looking on
the wrong bus.

Do you see *any* i2c devices (such as an eeprom).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: lgdt3304
  2013-06-27 18:59 ` lgdt3304 Devin Heitmueller
@ 2013-06-27 20:45   ` Carl-Fredrik Sundstrom
  2013-06-28  3:00   ` lgdt3304 Carl-Fredrik Sundstrom
  1 sibling, 0 replies; 14+ messages in thread
From: Carl-Fredrik Sundstrom @ 2013-06-27 20:45 UTC (permalink / raw)
  To: 'Devin Heitmueller'; +Cc: linux-media


One of the TDA18271HD/C2 is detected on the secondary i2c bus at address
0x60. I haven't tried yet to find the second one.

The SAA7160E PCI-E interface has the following GPIO 

GPIO_[15:1]: interrupts from other external devices
GPIO_[23:16]: chip select to other external devices
GPIO_[29:26]: general purpose
BOOT_0 and BOOT_1: boot mode. The boot mode pins can be used as application
GPIO pins after 500 ms (after power-up). The boot mode has been latched.

All of them  are input and output with internal pull-up, so they should all
be set high.

Should I just try to change them all to outputs and then set them low one by
one until something answers at address 0x0e or 0x59? 

Thanks /// Carl

-----Original Message-----
From: Devin Heitmueller [mailto:dheitmueller@kernellabs.com] 
Sent: Thursday, June 27, 2013 1:59 PM
To: Carl-Fredrik Sundstrom
Cc: linux-media@vger.kernel.org
Subject: Re: lgdt3304

On Thu, Jun 27, 2013 at 2:38 PM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
>
> Has the driver for lgdt3304 been tested ? I am trying to get a new 
> card working
>
> AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1 
> Interface
>
> It is using
>
> 1 x saa7160E
> 2 x LGDT3304
> 2 x TDA18271HD/C2
>
> I get so far that I can load a basic driver by modifying the existing 
> saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect 
> the
> LGDT3304 when attaching it using the 3305 driver.
>
> I always fail at the first read from LGDT3305_GEN_CTRL_2, does this 
> register even exist in lgdt3304 or is it specific to lgdt3305?
>
>         /* verify that we're talking to a lg dt3304/5 */
>          ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, &val);
>          if ((lg_fail(ret)) | (val == 0))
>         {
>                 printk("fail 1\n");
>                 goto fail;
>         }
>
> Since I do find the TDA18271HD/C2 I don't think there is something 
> wrong with the i2c buss. I also tried every possible i2c address without
success.
> The lgdt3305 has option between address 0x0e and 0x59, is it the same 
> for
> 3304 ?
>
> This is the first time I am trying to get a driver to work in Linux. 
> Please help me.

Either the i2c is broken or the lgdt3304 is being held in reset by a GPIO.

Also, that device has multiple i2c busses, so you could be looking on the
wrong bus.

Do you see *any* i2c devices (such as an eeprom).

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: lgdt3304
  2013-06-27 18:58 ` lgdt3304 Steven Toth
@ 2013-06-27 21:00   ` Carl-Fredrik Sundstrom
  0 siblings, 0 replies; 14+ messages in thread
From: Carl-Fredrik Sundstrom @ 2013-06-27 21:00 UTC (permalink / raw)
  To: 'Steven Toth'; +Cc: linux-media


I found a datasheet for lgdt3305 it does indeed have a reset pin at pin 37
active low with internal pull up.
I will try to attach a probe to that pin and walk through all of the GPIO
until I find the right one.

I hope that lgdt3304 and lgdt3305 are pin compatible otherwise I might not
have much success.



-----Original Message-----
From: linux-media-owner@vger.kernel.org
[mailto:linux-media-owner@vger.kernel.org] On Behalf Of Steven Toth
Sent: Thursday, June 27, 2013 1:59 PM
To: Carl-Fredrik Sundstrom
Cc: linux-media@vger.kernel.org
Subject: Re: lgdt3304

> I get so far that I can load a basic driver by modifying the existing 
> saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect 
> the
> LGDT3304 when attaching it using the 3305 driver.

A GPIO holding the 3304 in reset?

--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: lgdt3304
  2013-06-27 18:59 ` lgdt3304 Devin Heitmueller
  2013-06-27 20:45   ` lgdt3304 Carl-Fredrik Sundstrom
@ 2013-06-28  3:00   ` Carl-Fredrik Sundstrom
  2013-06-28 15:23     ` lgdt3304 Steven Toth
  1 sibling, 1 reply; 14+ messages in thread
From: Carl-Fredrik Sundstrom @ 2013-06-28  3:00 UTC (permalink / raw)
  To: 'Devin Heitmueller'; +Cc: linux-media


I am able to detect two lgdt3304 one on each i2c bus now. As you suspected I
had to set GPIO pin 17 for them to come alive.

Now to my next question, how do I attach two front ends I have two lgdt3304
and two TDA18271HD/C2 
Is there a good driver I can look at where they do that ?

Thanks /// Carl

-----Original Message-----
From: Devin Heitmueller [mailto:dheitmueller@kernellabs.com] 
Sent: Thursday, June 27, 2013 1:59 PM
To: Carl-Fredrik Sundstrom
Cc: linux-media@vger.kernel.org
Subject: Re: lgdt3304

On Thu, Jun 27, 2013 at 2:38 PM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
>
> Has the driver for lgdt3304 been tested ? I am trying to get a new 
> card working
>
> AVerMedia AVerTVHD Duet PCTV tuner (A188) A188-AF PCI-Express x1 
> Interface
>
> It is using
>
> 1 x saa7160E
> 2 x LGDT3304
> 2 x TDA18271HD/C2
>
> I get so far that I can load a basic driver by modifying the existing 
> saa716x driver, I can detect the TDA18271HD/C2, but I fail to detect 
> the
> LGDT3304 when attaching it using the 3305 driver.
>
> I always fail at the first read from LGDT3305_GEN_CTRL_2, does this 
> register even exist in lgdt3304 or is it specific to lgdt3305?
>
>         /* verify that we're talking to a lg dt3304/5 */
>          ret = lgdt3305_read_reg(state, LGDT3305_GEN_CTRL_2, &val);
>          if ((lg_fail(ret)) | (val == 0))
>         {
>                 printk("fail 1\n");
>                 goto fail;
>         }
>
> Since I do find the TDA18271HD/C2 I don't think there is something 
> wrong with the i2c buss. I also tried every possible i2c address without
success.
> The lgdt3305 has option between address 0x0e and 0x59, is it the same 
> for
> 3304 ?
>
> This is the first time I am trying to get a driver to work in Linux. 
> Please help me.

Either the i2c is broken or the lgdt3304 is being held in reset by a GPIO.

Also, that device has multiple i2c busses, so you could be looking on the
wrong bus.

Do you see *any* i2c devices (such as an eeprom).

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lgdt3304
  2013-06-28  3:00   ` lgdt3304 Carl-Fredrik Sundstrom
@ 2013-06-28 15:23     ` Steven Toth
  2013-07-09  4:18       ` lgdt3304 Carl-Fredrik Sundstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Steven Toth @ 2013-06-28 15:23 UTC (permalink / raw)
  To: Carl-Fredrik Sundstrom; +Cc: Devin Heitmueller, linux-media

On Thu, Jun 27, 2013 at 11:00 PM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
>
> I am able to detect two lgdt3304 one on each i2c bus now. As you suspected I
> had to set GPIO pin 17 for them to come alive.
>
> Now to my next question, how do I attach two front ends I have two lgdt3304
> and two TDA18271HD/C2
> Is there a good driver I can look at where they do that ?

The SAA7164 driver (amongst others) demonstrates how to expose
multiple tuners on a single card via multiple adapters,
/dev/dvb/adapterX.

The cx88 driver demonstrates how to expose multiple tuners/demods via
a single transport bus, via a single dvb adapter.
/dev/dvb/adapter0/frontendX

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: lgdt3304
  2013-06-28 15:23     ` lgdt3304 Steven Toth
@ 2013-07-09  4:18       ` Carl-Fredrik Sundstrom
  2013-07-09 14:53         ` lgdt3304 Steven Toth
  0 siblings, 1 reply; 14+ messages in thread
From: Carl-Fredrik Sundstrom @ 2013-07-09  4:18 UTC (permalink / raw)
  To: 'Steven Toth'; +Cc: 'Devin Heitmueller', linux-media

Need some advice and pointers.
I have gotten both adapters/frontends of the VerMedia AVerTVHD Duet PCTV
tuner (A188) A188-AF card to register.

[ 6251.073357] DVB: registering new adapter (SAA716x dvb adapter)
[ 6251.217817] tda18271 1-0060: creating new instance
[ 6251.219671] TDA18271HD/C2 detected @ 1-0060
[ 6251.484794] SAA716x Budget 0000:04:00.0: DVB: registering adapter 0
frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)...
[ 6251.485084] DVB: registering new adapter (SAA716x dvb adapter)
[ 6251.601649] tda18271 0-0060: creating new instance
[ 6251.603615] TDA18271HD/C2 detected @ 0-0060
[ 6251.868787] SAA716x Budget 0000:04:00.0: DVB: registering adapter 1
frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)...


The card only has one RF input hence I believe the two TDA18271 tuners are
setup in master/slave configuration.
When I try to set them up as master slave the slave fails to detect as seen
in below log. If I configure both as master 
both are detected 

[ 5410.137358] DVB: registering new adapter (SAA716x dvb adapter)
[ 5410.281839] tda18271 1-0060: creating new instance
[ 5410.283694] TDA18271HD/C2 detected @ 1-0060
[ 5410.548784] SAA716x Budget 0000:04:00.0: DVB: registering adapter 0
frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)...
[ 5410.549081] DVB: registering new adapter (SAA716x dvb adapter)
[ 5410.665649] tda18271 0-0060: creating new instance
[ 5410.669264] Unknown device (0) detected @ 0-0060, device not supported.
[ 5410.669269] tda18271_attach: [0-0060|S] error -22 on line 1285
[ 5410.669272] tda18271 0-0060: destroying instance
[ 5410.704784] SAA716x Budget 0000:04:00.0: DVB: registering adapter 1
frontend 0 (LG Electronics LGDT3304 VSB/QAM Frontend)...

When I try to tune I get the following on all stations.

using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>>> tune to: 57028615:8VSB
WARNING: >>> tuning failed!!!
>>> tune to: 57028615:8VSB (tuning failed)

Sometimes I also get 
WARNING: filter timeout pid
This happens mostly on frequencies I know have stations in my dfw area.

Any pointers would be much appreciated, especially how to find out which
tda18271 is master and how to setup 
the configuration struct's for ATSC , master, slave . 

Thanks /// Carl

/*when both tda18271 are configured with below struct they are both found */

/*if I remove .gate and .role comments it fails to detect the tda18271 on
the first i2c bus */
static struct tda18271_config averduet_tda_config_master = {
        .std_map           = &averduet_std_map,
        //.gate              = TDA18271_GATE_DIGITAL,
        //.role              = TDA18271_MASTER,
};

static struct tda18271_config averduet_tda_config_slave = {
        .std_map           = &averduet_std_map,
        .gate              = TDA18271_GATE_DIGITAL,
        .role              = TDA18271_SLAVE,
        .output_opt        = TDA18271_OUTPUT_LT_OFF,
        .rf_cal_on_startup = 1,
};

static struct lgdt3305_config averduet_lgdt3304_dev = {
        .i2c_addr           = 0x0e, /*0x0e, 0x59 these are the only two
possible values*/
        .demod_chip         = LGDT3304,
        .spectral_inversion = 1,
        .deny_i2c_rptr      = 0, /*1,*/
        .mpeg_mode          = LGDT3305_MPEG_PARALLEL,
        .tpclk_edge         = LGDT3305_TPCLK_FALLING_EDGE,
        .tpvalid_polarity   = LGDT3305_TP_VALID_HIGH,
        .vsb_if_khz         = 3250,
        .qam_if_khz         = 4000,
};




tridentsx@tridentsx-P5K-E:~/media_build/media$ lsmod
Module                  Size  Used by
tda18271               40860  2
lgdt3305               22788  2
saa716x_budget         18162  0
mb86a16                27023  1 saa716x_budget
saa716x_core           68492  1 saa716x_budget
stv090x                57159  1 saa716x_budget
dvb_core               90348  3 saa716x_core,saa716x_budget,lgdt3305
vesafb                 13500  1
snd_hda_codec_analog    75266  1
parport_pc             27504  0
ppdev                  12817  0
bnep                   17669  2
rfcomm                 37420  0
bluetooth             202069  10 bnep,rfcomm
snd_hda_intel          38307  2
coretemp               13131  0
binfmt_misc            17260  1
kvm_intel             126842  0
snd_hda_codec         117580  2 snd_hda_intel,snd_hda_codec_analog
snd_hwdep              13272  1 snd_hda_codec
kvm                   376505  1 kvm_intel
snd_pcm                80890  2 snd_hda_codec,snd_hda_intel
snd_page_alloc         14230  2 snd_pcm,snd_hda_intel
gpio_ich               13236  0
snd_seq_midi           13132  0
snd_seq_midi_event     14475  1 snd_seq_midi
snd_rawmidi            25114  1 snd_seq_midi
snd_seq                51280  2 snd_seq_midi_event,snd_seq_midi
nvidia               7108000  24
snd_seq_device         14137  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              24411  2 snd_pcm,snd_seq
microcode              18286  0
lpc_ich                16925  0
serio_raw              13031  0
snd                    56485  13
snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,
snd_seq_device,snd_hda_codec_analog
asus_atk0110           17390  0
mac_hid                13037  0
soundcore              12600  1 snd
lp                     13299  0
parport                40753  3 lp,ppdev,parport_pc
pata_acpi              12886  0
firewire_ohci          35292  0
firewire_core          61718  1 firewire_ohci
crc_itu_t              12627  1 firewire_core
usb_storage            47684  0
pata_jmicron           12662  0
floppy                 55441  0
sky2                   52846  0
ahci                   25507  0
libahci                26108  1 ahci



-----Original Message-----
From: linux-media-owner@vger.kernel.org
[mailto:linux-media-owner@vger.kernel.org] On Behalf Of Steven Toth
Sent: Friday, June 28, 2013 10:23 AM
To: Carl-Fredrik Sundstrom
Cc: Devin Heitmueller; linux-media@vger.kernel.org
Subject: Re: lgdt3304

On Thu, Jun 27, 2013 at 11:00 PM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
>
> I am able to detect two lgdt3304 one on each i2c bus now. As you 
> suspected I had to set GPIO pin 17 for them to come alive.
>
> Now to my next question, how do I attach two front ends I have two 
> lgdt3304 and two TDA18271HD/C2 Is there a good driver I can look at 
> where they do that ?

The SAA7164 driver (amongst others) demonstrates how to expose multiple
tuners on a single card via multiple adapters, /dev/dvb/adapterX.

The cx88 driver demonstrates how to expose multiple tuners/demods via a
single transport bus, via a single dvb adapter.
/dev/dvb/adapter0/frontendX

- Steve

--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lgdt3304
  2013-07-09  4:18       ` lgdt3304 Carl-Fredrik Sundstrom
@ 2013-07-09 14:53         ` Steven Toth
  2013-07-10  1:40           ` lgdt3304 Carl-Fredrik Sundstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Steven Toth @ 2013-07-09 14:53 UTC (permalink / raw)
  To: Carl-Fredrik Sundstrom; +Cc: Devin Heitmueller, linux-media

> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>>>> tune to: 57028615:8VSB
> WARNING: >>> tuning failed!!!
>>>> tune to: 57028615:8VSB (tuning failed)

I don't have a box in front of me but that's usually a sign that the
frequency details you are passing in are bogus, so the tuner driver is
rejecting it.

Check your command line tuning tools and args.

Here's a one line channels.conf for azap (US digital cable) that works
fine, and the azap console output:

ch86:597000000:QAM_256:0:0:101

stoth@mythbackend:~/.azap$ azap ch86
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 597000000 Hz
video pid 0x0000, audio pid 0x0000
status 00 | signal 0000 | snr b770 | ber 00000000 | unc 00000000 |
status 1f | signal 0154 | snr 0154 | ber 000000ad | unc 000000ad | FE_HAS_LOCK
status 1f | signal 0156 | snr 0156 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

--
Steven Toth - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: lgdt3304
  2013-07-09 14:53         ` lgdt3304 Steven Toth
@ 2013-07-10  1:40           ` Carl-Fredrik Sundstrom
  2013-07-10 13:51             ` lgdt3304 Steven Toth
  0 siblings, 1 reply; 14+ messages in thread
From: Carl-Fredrik Sundstrom @ 2013-07-10  1:40 UTC (permalink / raw)
  To: 'Steven Toth'; +Cc: 'Devin Heitmueller', linux-media


I don't have digital cable only over the air ATSC. No one else on this list
has this card ?

Thanks /// Carl

-----Original Message-----
From: linux-media-owner@vger.kernel.org
[mailto:linux-media-owner@vger.kernel.org] On Behalf Of Steven Toth
Sent: Tuesday, July 09, 2013 9:54 AM
To: Carl-Fredrik Sundstrom
Cc: Devin Heitmueller; linux-media@vger.kernel.org
Subject: Re: lgdt3304

> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>>>> tune to: 57028615:8VSB
> WARNING: >>> tuning failed!!!
>>>> tune to: 57028615:8VSB (tuning failed)

I don't have a box in front of me but that's usually a sign that the
frequency details you are passing in are bogus, so the tuner driver is
rejecting it.

Check your command line tuning tools and args.

Here's a one line channels.conf for azap (US digital cable) that works fine,
and the azap console output:

ch86:597000000:QAM_256:0:0:101

stoth@mythbackend:~/.azap$ azap ch86
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 597000000 Hz
video pid 0x0000, audio pid 0x0000
status 00 | signal 0000 | snr b770 | ber 00000000 | unc 00000000 | status 1f
| signal 0154 | snr 0154 | ber 000000ad | unc 000000ad | FE_HAS_LOCK status
1f | signal 0156 | snr 0156 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lgdt3304
  2013-07-10  1:40           ` lgdt3304 Carl-Fredrik Sundstrom
@ 2013-07-10 13:51             ` Steven Toth
  2013-07-11  3:51               ` lgdt3304 Carl-Fredrik Sundstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Steven Toth @ 2013-07-10 13:51 UTC (permalink / raw)
  To: Carl-Fredrik Sundstrom; +Cc: Devin Heitmueller, linux-media

On Tue, Jul 9, 2013 at 9:40 PM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
>
> I don't have digital cable only over the air ATSC. No one else on this list
> has this card ?

You are very welcome, thank you.

We generally recommend Linux users purchase cards that are already
supported (or semi supported), such as the HVR2250. If you're keen
enough to tackle adding support for a new board then that's great
news, but very few people usually have experience with hardware not
yet supported.

The channels.conf is capable of support digital cable and ATSC, simply
change the modulation scheme and your target frequency and try again.

A quick google for an equivalent ATSC channels.conf provides a lot of
useful information.

Create your channels.conf to match your target frequencies in Hz and
use azap to debug.

Eg.

KPAX-CW:177028615:8VSB:65:68:2

>
> Thanks /// Carl
>
> -----Original Message-----
> From: linux-media-owner@vger.kernel.org
> [mailto:linux-media-owner@vger.kernel.org] On Behalf Of Steven Toth
> Sent: Tuesday, July 09, 2013 9:54 AM
> To: Carl-Fredrik Sundstrom
> Cc: Devin Heitmueller; linux-media@vger.kernel.org
> Subject: Re: lgdt3304
>
>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>>>>> tune to: 57028615:8VSB
>> WARNING: >>> tuning failed!!!
>>>>> tune to: 57028615:8VSB (tuning failed)
>
> I don't have a box in front of me but that's usually a sign that the
> frequency details you are passing in are bogus, so the tuner driver is
> rejecting it.
>
> Check your command line tuning tools and args.
>
> Here's a one line channels.conf for azap (US digital cable) that works fine,
> and the azap console output:
>
> ch86:597000000:QAM_256:0:0:101
>
> stoth@mythbackend:~/.azap$ azap ch86
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 597000000 Hz
> video pid 0x0000, audio pid 0x0000
> status 00 | signal 0000 | snr b770 | ber 00000000 | unc 00000000 | status 1f
> | signal 0154 | snr 0154 | ber 000000ad | unc 000000ad | FE_HAS_LOCK status
> 1f | signal 0156 | snr 0156 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: lgdt3304
  2013-07-10 13:51             ` lgdt3304 Steven Toth
@ 2013-07-11  3:51               ` Carl-Fredrik Sundstrom
  2013-07-11 12:46                 ` lgdt3304 Antti Palosaari
       [not found]                 ` <01ab01ce7df1$e92cc9e0$bb865da0$@blueflowamericas.com>
  0 siblings, 2 replies; 14+ messages in thread
From: Carl-Fredrik Sundstrom @ 2013-07-11  3:51 UTC (permalink / raw)
  To: 'Steven Toth'; +Cc: 'Devin Heitmueller', linux-media


Thanks Steven for all the support,

Now I got the master slave to work and I can scan the local FOX channel with
azap

tridentsx@tridentsx-P5K-E:~/.kde/share/apps/kaffeine$ azap FOX
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 599028615 Hz
video pid 0x0031, audio pid 0x0034
status 01 | signal 0000 | snr 0000 | ber 00000000 | unc 0000ca8b | 
status 1f | signal 8e53 | snr 00c4 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 907a | snr 00c5 | ber 00000000 | unc 00000165 |
FE_HAS_LOCK
status 1f | signal 8dc8 | snr 00c4 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 8d3f | snr 00c1 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK

However when I try to view or scan channels in mplayer or kaffeine it can't
find them and there 
are some timeouts Similar to the ones I got in scan utility. 

kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section;
type = 3 pid = 8187 
kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section;
type = 0 pid = 0 
kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section;
type = 3 pid = 8187 

Playing dvb://.
dvb_tune Freq: 599028615
dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 2048 bytes
dvb_streaming_read, return 0 bytes
Failed to recognize file format.

When I use the scan tool I get the following for every channel that I can
get a lock on in azap

>>> tune to: 473028615:8VSB
WARNING: filter timeout pid 0x0000
WARNING: filter timeout pid 0x1ffb


Below is a kernel  trace at the same time. It seems the tuning is successful
still no channels are output at the end of scan.


[ 4800.196989] tda18271_tune: [1-0060|M] freq = 473028615, ifc = 3250, bw =
6000000, agc_mode = 3, std = 4
[ 4800.196992] tda18271_agc: [1-0060|M] no agc configuration provided
[ 4800.196996] tda18271_set_standby_mode: [1-0060|M] sm = 0, sm_lt = 0,
sm_xt = 0
[ 4800.199133] tda18271_dump_regs: [1-0060|M] === TDA18271 REG DUMP ===
[ 4800.199136] tda18271_dump_regs: [1-0060|M] ID_BYTE            = 0x84
[ 4800.199140] tda18271_dump_regs: [1-0060|M] THERMO_BYTE        = 0x48
[ 4800.199143] tda18271_dump_regs: [1-0060|M] POWER_LEVEL_BYTE   = 0x80
[ 4800.199146] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_1   = 0xde
[ 4800.199149] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_2   = 0xb4
[ 4800.199152] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_3   = 0x1c
[ 4800.199155] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_4   = 0x64
[ 4800.199157] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_5   = 0x86
[ 4800.199160] tda18271_dump_regs: [1-0060|M] CAL_POST_DIV_BYTE  = 0x98
[ 4800.199163] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_1     = 0x69
[ 4800.199166] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_2     = 0x40
[ 4800.199169] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_3     = 0x00
[ 4800.199172] tda18271_dump_regs: [1-0060|M] MAIN_POST_DIV_BYTE = 0xb1
[ 4800.199175] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_1    = 0x79
[ 4800.199178] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_2    = 0xa8
[ 4800.199181] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_3    = 0x08
[ 4800.199184] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_1    = 0xfc
[ 4800.199187] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_2    = 0x01
[ 4800.199190] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_3    = 0x84
[ 4800.199192] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_4    = 0x41
[ 4800.199195] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_5    = 0x01
[ 4800.199198] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_6    = 0x84
[ 4800.199201] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_7    = 0x41
[ 4800.199204] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_8    = 0x07
[ 4800.199207] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_9  W = 0x00
[ 4800.199210] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_10   = 0x29
[ 4800.199213] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_11   = 0x96
[ 4800.199216] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_12   = 0x13
[ 4800.199219] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_13   = 0xbd
[ 4800.199222] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_14   = 0x11
[ 4800.199224] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_15   = 0x85
[ 4800.199227] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_16 W = 0x00
[ 4800.199230] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_17 W = 0x4c
[ 4800.199233] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_18   = 0x0c
[ 4800.199236] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_19 W = 0x00
[ 4800.199239] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_20 W = 0x20
[ 4800.199242] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_21   = 0xb3
[ 4800.199245] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_22   = 0x37
[ 4800.199248] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_23   = 0xb0
[ 4800.199251] tda18271_set_standby_mode: [1-0060|M] sm = 0, sm_lt = 0,
sm_xt = 0
[ 4800.201715] tda18271_dump_regs: [1-0060|M] === TDA18271 REG DUMP ===
[ 4800.201718] tda18271_dump_regs: [1-0060|M] ID_BYTE            = 0x84
[ 4800.201721] tda18271_dump_regs: [1-0060|M] THERMO_BYTE        = 0x50
[ 4800.201725] tda18271_dump_regs: [1-0060|M] POWER_LEVEL_BYTE   = 0x80
[ 4800.201728] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_1   = 0xde
[ 4800.201731] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_2   = 0xb4
[ 4800.201734] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_3   = 0x1c
[ 4800.201737] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_4   = 0x64
[ 4800.201740] tda18271_dump_regs: [1-0060|M] EASY_PROG_BYTE_5   = 0x86
[ 4800.201743] tda18271_dump_regs: [1-0060|M] CAL_POST_DIV_BYTE  = 0x98
[ 4800.201746] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_1     = 0x69
[ 4800.201749] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_2     = 0x40
[ 4800.201752] tda18271_dump_regs: [1-0060|M] CAL_DIV_BYTE_3     = 0x00
[ 4800.201755] tda18271_dump_regs: [1-0060|M] MAIN_POST_DIV_BYTE = 0xb1
[ 4800.201758] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_1    = 0x79
[ 4800.201761] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_2    = 0xa8
[ 4800.201764] tda18271_dump_regs: [1-0060|M] MAIN_DIV_BYTE_3    = 0x08
[ 4800.201766] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_1    = 0xfc
[ 4800.201769] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_2    = 0x01
[ 4800.201772] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_3    = 0x84
[ 4800.201775] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_4    = 0x41
[ 4800.201778] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_5    = 0x01
[ 4800.201781] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_6    = 0x84
[ 4800.201784] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_7    = 0x41
[ 4800.201787] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_8    = 0x07
[ 4800.201790] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_9  W = 0x00
[ 4800.201793] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_10   = 0x29
[ 4800.201796] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_11   = 0x96
[ 4800.201799] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_12   = 0x13
[ 4800.201802] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_13   = 0xbd
[ 4800.201805] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_14   = 0x11
[ 4800.201808] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_15   = 0x85
[ 4800.201811] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_16 W = 0x00
[ 4800.201814] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_17 W = 0x4c
[ 4800.201817] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_18   = 0x0c
[ 4800.201820] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_19 W = 0x00
[ 4800.201823] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_20 W = 0x20
[ 4800.201826] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_21   = 0xb3
[ 4800.201829] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_22   = 0x37
[ 4800.201832] tda18271_dump_regs: [1-0060|M] EXTENDED_BYTE_23   = 0xb0
[ 4800.201835] tda18271_lookup_thermometer: [1-0060|M] (0) tm = 60
[ 4800.202320] tda18271_lookup_map: [1-0060|M] (281) rf_cal: 0x15
[ 4800.202326] tda18271_lookup_rf_band: [1-0060|M] (0) rfmax = 47900000 <
freq = 473028615, rf1_def = 46000, rf2_def = 0, rf3_def = 0, rf1 = 46000,
rf2 = 0, rf3 = 0, rf_a1 = 0, rf_a2 = 0, rf_b1 = -18, rf_b2 = 0
[ 4800.202332] tda18271_lookup_rf_band: [1-0060|M] (1) rfmax = 61100000 <
freq = 473028615, rf1_def = 52200, rf2_def = 0, rf3_def = 0, rf1 = 52200,
rf2 = 0, rf3 = 0, rf_a1 = 0, rf_a2 = 0, rf_b1 = -7, rf_b2 = 0
[ 4800.202338] tda18271_lookup_rf_band: [1-0060|M] (2) rfmax = 152600000 <
freq = 473028615, rf1_def = 70100, rf2_def = 136800, rf3_def = 0, rf1 =
70100, rf2 = 136800, rf3 = 0, rf_a1 = 0, rf_a2 = 0, rf_b1 = 1, rf_b2 = 0
[ 4800.202344] tda18271_lookup_rf_band: [1-0060|M] (3) rfmax = 164700000 <
freq = 473028615, rf1_def = 156700, rf2_def = 0, rf3_def = 0, rf1 = 156700,
rf2 = 0, rf3 = 0, rf_a1 = 0, rf_a2 = 0, rf_b1 = -7, rf_b2 = 0
[ 4800.202349] tda18271_lookup_rf_band: [1-0060|M] (4) rfmax = 203500000 <
freq = 473028615, rf1_def = 186250, rf2_def = 0, rf3_def = 0, rf1 = 186250,
rf2 = 0, rf3 = 0, rf_a1 = 0, rf_a2 = 0, rf_b1 = -4, rf_b2 = 0
[ 4800.202355] tda18271_lookup_rf_band: [1-0060|M] (5) rfmax = 457800000 <
freq = 473028615, rf1_def = 230000, rf2_def = 345000, rf3_def = 426000, rf1
= 230000, rf2 = 345000, rf3 = 426000, rf_a1 = 0, rf_a2 = 0, rf_b1 = 0, rf_b2
= 1
[ 4800.202358] tda18271_lookup_rf_band: [1-0060|M] (6) rf_band = 06
[ 4800.202362] tda18271_lookup_map: [1-0060|M] (54) rf_cal_dc_over_dt: 0x12
[ 4800.202893] tda18271_lookup_map: [1-0060|M] (2) ir_measure: 0x06
[ 4800.202897] tda18271_lookup_map: [1-0060|M] (6) bp_filter: 0x06
[ 4800.202900] tda18271_lookup_map: [1-0060|M] (6) rf_band: 0x06
[ 4800.202904] tda18271_lookup_map: [1-0060|M] (63) gain_taper: 0x19
[ 4800.203180] tda18271_lookup_pll_map: [1-0060|M] (31) main_pll: post div =
0x20, div = 0x10
[ 4800.236205] lgdt3305_set_modulation: 
[ 4800.236211] lgdt3305_read_reg: reg: 0x0000
[ 4800.236761] lgdt3305_write_reg: reg: 0x0000, val: 0x03
[ 4800.237057] lgdt3305_passband_digital_agc: agc ref: 0x32c4
[ 4800.237060] lgdt3305_write_reg: reg: 0x0012, val: 0x32
[ 4800.237433] lgdt3305_write_reg: reg: 0x0013, val: 0xc4
[ 4800.237810] lgdt3305_agc_setup: lockdten = 0, acqen = 0
[ 4800.237812] lgdt3305_write_reg: reg: 0x0314, val: 0xe1
[ 4800.238186] lgdt3305_set_reg_bit: reg: 0x030e, bit: 2, level: 0
[ 4800.238188] lgdt3305_read_reg: reg: 0x030e
[ 4800.238745] lgdt3305_write_reg: reg: 0x030e, val: 0x18
[ 4800.239041] lgdt3305_rfagc_loop: ifbw: 0x8000
[ 4800.239044] lgdt3305_write_reg: reg: 0x0308, val: 0x80
[ 4800.239416] lgdt3305_write_reg: reg: 0x0309, val: 0x00
[ 4800.239793] lgdt3305_write_reg: reg: 0x030d, val: 0x00
[ 4800.240176] lgdt3305_write_reg: reg: 0x0106, val: 0x4f
[ 4800.240552] lgdt3305_write_reg: reg: 0x0107, val: 0x0c
[ 4800.240927] lgdt3305_write_reg: reg: 0x0108, val: 0xac
[ 4800.241304] lgdt3305_write_reg: reg: 0x0109, val: 0xba
[ 4800.241680] lgdt3305_spectral_inversion: (1)
[ 4800.241683] lgdt3305_write_reg: reg: 0x0126, val: 0xf9
[ 4800.242057] lgdt3305_mpeg_mode: (1)
[ 4800.242060] lgdt3305_set_reg_bit: reg: 0x050e, bit: 5, level: 1
[ 4800.242062] lgdt3305_read_reg: reg: 0x050e
[ 4800.242616] lgdt3305_write_reg: reg: 0x050e, val: 0x7b
[ 4800.242911] lgdt3305_mpeg_mode_polarity: edge = 1, valid = 1
[ 4800.242913] lgdt3305_read_reg: reg: 0x050e
[ 4800.243471] lgdt3305_write_reg: reg: 0x050e, val: 0x7b
[ 4800.243767] lgdt3305_soft_reset: 
[ 4800.243770] lgdt3305_set_reg_bit: reg: 0x0002, bit: 0, level: 0
[ 4800.243772] lgdt3305_read_reg: reg: 0x0002
[ 4800.244333] lgdt3305_write_reg: reg: 0x0002, val: 0x9a
[ 4800.268013] lgdt3305_set_reg_bit: reg: 0x0002, bit: 0, level: 1
[ 4800.268017] lgdt3305_read_reg: reg: 0x0002
[ 4800.268479] lgdt3305_write_reg: reg: 0x0002, val: 0x9b
[ 4800.397037] lgdt3305_read_reg: reg: 0x0003
[ 4800.397499] lgdt3305_read_status: SIGNALEXIST INLOCK 
[ 4800.397502] lgdt3305_read_reg: reg: 0x011d
[ 4800.397979] lgdt3305_read_cr_lock_status: (1) CLOCKVSB
[ 4800.397998] function : dvb_dmxdev_filter_set, PID=0x1ffb, flags=05,
timeout=0
[ 4800.436025] function : dvb_dmxdev_filter_set, PID=0x0000, flags=05,
timeout=0
[ 4800.768016] lgdt3305_read_reg: reg: 0x0003
[ 4800.768479] lgdt3305_read_status: SIGNALEXIST INLOCK SYNCLOCK NOFECERR
SNRGOOD 
[ 4800.768482] lgdt3305_read_reg: reg: 0x011d
[ 4800.768959] lgdt3305_read_cr_lock_status: (1) CLOCKVSB
[ 4800.768961] lgdt3305_get_frontend: 
[ 4802.132014] lgdt3305_read_reg: reg: 0x0003
[ 4802.132477] lgdt3305_read_status: SIGNALEXIST INLOCK SYNCLOCK NOFECERR
SNRGOOD 
[ 4802.132480] lgdt3305_read_reg: reg: 0x011d
[ 4802.132955] lgdt3305_read_cr_lock_status: (1) CLOCKVSB
[ 4803.508016] lgdt3305_read_reg: reg: 0x0003
[ 4803.508479] lgdt3305_read_status: SIGNALEXIST INLOCK SYNCLOCK NOFECERR
SNRGOOD 
[ 4803.508482] lgdt3305_read_reg: reg: 0x011d
[ 4803.508957] lgdt3305_read_cr_lock_status: (1) CLOCKVSB
[ 4804.900042] lgdt3305_read_reg: reg: 0x0003
[ 4804.900506] lgdt3305_read_status: SIGNALEXIST INLOCK SYNCLOCK NOFECERR
SNRGOOD 
[ 4804.900508] lgdt3305_read_reg: reg: 0x011d
[ 4804.900984] lgdt3305_read_cr_lock_status: (1) CLOCKVSB
[ 4806.292015] lgdt3305_read_reg: reg: 0x0003
[ 4806.292479] lgdt3305_read_status: SIGNALEXIST INLOCK SYNCLOCK NOFECERR
SNRGOOD 
[ 4806.292481] lgdt3305_read_reg: reg: 0x011d
[ 4806.292957] lgdt3305_read_cr_lock_status: (1) CLOCKVSB
[ 4807.448098] lgdt3305_get_tune_settings: 
[ 4807.448120] lgdt3304_set_parameters: (479028615, 7)
[ 4807.448129] tda18271_tune: [1-0060|M] freq = 479028615, ifc = 3250, bw =
6000000, agc_mode = 3, std = 4
[ 4807.448133] tda18271_agc: [1-0060|M] no agc configuration provided







-----Original Message-----
From: linux-media-owner@vger.kernel.org
[mailto:linux-media-owner@vger.kernel.org] On Behalf Of Steven Toth
Sent: Wednesday, July 10, 2013 8:51 AM
To: Carl-Fredrik Sundstrom
Cc: Devin Heitmueller; linux-media@vger.kernel.org
Subject: Re: lgdt3304

On Tue, Jul 9, 2013 at 9:40 PM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
>
> I don't have digital cable only over the air ATSC. No one else on this 
> list has this card ?

You are very welcome, thank you.

We generally recommend Linux users purchase cards that are already supported
(or semi supported), such as the HVR2250. If you're keen enough to tackle
adding support for a new board then that's great news, but very few people
usually have experience with hardware not yet supported.

The channels.conf is capable of support digital cable and ATSC, simply
change the modulation scheme and your target frequency and try again.

A quick google for an equivalent ATSC channels.conf provides a lot of useful
information.

Create your channels.conf to match your target frequencies in Hz and use
azap to debug.

Eg.

KPAX-CW:177028615:8VSB:65:68:2

>
> Thanks /// Carl
>
> -----Original Message-----
> From: linux-media-owner@vger.kernel.org 
> [mailto:linux-media-owner@vger.kernel.org] On Behalf Of Steven Toth
> Sent: Tuesday, July 09, 2013 9:54 AM
> To: Carl-Fredrik Sundstrom
> Cc: Devin Heitmueller; linux-media@vger.kernel.org
> Subject: Re: lgdt3304
>
>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>>>>> tune to: 57028615:8VSB
>> WARNING: >>> tuning failed!!!
>>>>> tune to: 57028615:8VSB (tuning failed)
>
> I don't have a box in front of me but that's usually a sign that the 
> frequency details you are passing in are bogus, so the tuner driver is 
> rejecting it.
>
> Check your command line tuning tools and args.
>
> Here's a one line channels.conf for azap (US digital cable) that works 
> fine, and the azap console output:
>
> ch86:597000000:QAM_256:0:0:101
>
> stoth@mythbackend:~/.azap$ azap ch86
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 597000000 Hz
> video pid 0x0000, audio pid 0x0000
> status 00 | signal 0000 | snr b770 | ber 00000000 | unc 00000000 | 
> status 1f
> | signal 0154 | snr 0154 | ber 000000ad | unc 000000ad | FE_HAS_LOCK 
> | status
> 1f | signal 0156 | snr 0156 | ber 00000000 | unc 00000000 | 
> FE_HAS_LOCK
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com

--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: lgdt3304
  2013-07-11  3:51               ` lgdt3304 Carl-Fredrik Sundstrom
@ 2013-07-11 12:46                 ` Antti Palosaari
       [not found]                 ` <01ab01ce7df1$e92cc9e0$bb865da0$@blueflowamericas.com>
  1 sibling, 0 replies; 14+ messages in thread
From: Antti Palosaari @ 2013-07-11 12:46 UTC (permalink / raw)
  To: Carl-Fredrik Sundstrom
  Cc: 'Steven Toth', 'Devin Heitmueller', linux-media

Carl-Fredrik,

On 07/11/2013 06:51 AM, Carl-Fredrik Sundstrom wrote:
>
> Thanks Steven for all the support,
>
> Now I got the master slave to work and I can scan the local FOX channel with
> azap
>
> tridentsx@tridentsx-P5K-E:~/.kde/share/apps/kaffeine$ azap FOX
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 599028615 Hz
> video pid 0x0031, audio pid 0x0034
> status 01 | signal 0000 | snr 0000 | ber 00000000 | unc 0000ca8b |
> status 1f | signal 8e53 | snr 00c4 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 907a | snr 00c5 | ber 00000000 | unc 00000165 |
> FE_HAS_LOCK
> status 1f | signal 8dc8 | snr 00c4 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 8d3f | snr 00c1 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
>
> However when I try to view or scan channels in mplayer or kaffeine it can't
> find them and there
> are some timeouts Similar to the ones I got in scan utility.
>
> kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section;
> type = 3 pid = 8187
> kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section;
> type = 0 pid = 0
> kaffeine(5476) DvbScanFilter::timerEvent: timeout while reading section;
> type = 3 pid = 8187
>
> Playing dvb://.
> dvb_tune Freq: 599028615
> dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 2048 bytes
> dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 2048 bytes
> dvb_streaming_read, attempt N. 4 failed with errno 0 when reading 2048 bytes
> dvb_streaming_read, attempt N. 3 failed with errno 0 when reading 2048 bytes
> dvb_streaming_read, attempt N. 2 failed with errno 0 when reading 2048 bytes
> dvb_streaming_read, attempt N. 1 failed with errno 0 when reading 2048 bytes
> dvb_streaming_read, return 0 bytes
> Failed to recognize file format.
>
> When I use the scan tool I get the following for every channel that I can
> get a lock on in azap
>
>>>> tune to: 473028615:8VSB
> WARNING: filter timeout pid 0x0000
> WARNING: filter timeout pid 0x1ffb
>
>
> Below is a kernel  trace at the same time. It seems the tuning is successful
> still no channels are output at the end of scan.

Your problem is somewhere between demod and bus interface. Tuner and 
demod are working as demod is able to gain lock. Interface between demod 
and bus interface - bridge - (USB, PCI) is transport stream (aka mpeg 
TS). There is two main wiring used, serial ts and parallel ts. Check 
that first. Both demod and bridge should be configured properly.

If TS interface it is correct then bug is somewhere in bridge settings.

regards
Antti


-- 
http://palosaari.fi/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FW: lgdt3304
       [not found]                 ` <01ab01ce7df1$e92cc9e0$bb865da0$@blueflowamericas.com>
@ 2013-07-11 12:52                   ` Steven Toth
  0 siblings, 0 replies; 14+ messages in thread
From: Steven Toth @ 2013-07-11 12:52 UTC (permalink / raw)
  To: Carl-Fredrik Sundstrom; +Cc: Linux-Media

Carl,

Thanks for writing. Please CC the mailing list at all times.

Comments below.

On Thu, Jul 11, 2013 at 12:48 AM, Carl-Fredrik Sundstrom
<cf@blueflowamericas.com> wrote:
> I don't know what happened to the dmeg log formatting when I pasted it I
> cleaned it up below.
> I can't see anything obvious that fail when scanning, it just starts on the
> next frequency after getting a lock

Ignore scan for now, use the azap tools with the -r arg and dvbtraffic
tools in two different terminal sessions.

azap -r FOX, will tune fox reliably for you, as your log messages
below indicate tuner and demodulator lock. This is good. This implies
the tuner and demodulator are most likely configured for RF reception,
this is a big part of the problem solved.

dvbtraffic will show all/any transmitter data coming from the
demodulator and entering the kernel. The display is a breakdown pid by
pid on how much data 'per pid' is being received by the kernel (from
the card). In your case the answer will be zero, or occasional junk.
Normal conditions shows 10-25 lines of stable text, show Mbp/s per
pid. (Goal being 19.2) for stable reception.

>
> Probably will give up un this and get that other card.

You're close, don't give up.

Better yet, finish the work, publish it _THEN_ buy the other card,
it's a little better in my opinion ;)

>
> Thanks /// Carl
>
> [ 4806.292479] lgdt3305_read_status: SIGNALEXIST INLOCK SYNCLOCK NOFECERR
> SNRGOOD
> [ 4806.292481] lgdt3305_read_reg: reg: 0x011d
> [ 4806.292957] lgdt3305_read_cr_lock_status: (1) CLOCKVSB
> [ 4807.448098] lgdt3305_get_tune_settings:
>
>
> tridentsx@tridentsx-P5K-E:~/.kde/share/apps/kaffeine$ azap FOX using
> '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 599028615 Hz
> video pid 0x0031, audio pid 0x0034
> status 01 | signal 0000 | snr 0000 | ber 00000000 | unc 0000ca8b |
> status 1f | signal 8e53 | snr 00c4 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 907a | snr 00c5 | ber 00000000 | unc 00000165 |
> FE_HAS_LOCK
> status 1f | signal 8dc8 | snr 00c4 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 8d3f | snr 00c1 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK

This is very good. The tuner and demodulator are locked to FOX and
your error counts are well within acceptable ranges. Congratulations.

>
> However when I try to view or scan channels in mplayer or kaffeine it can't
> find them and there are some timeouts Similar to the ones I got in scan
> utility.

This is invariably because the electrical interface between the LG
demod and the host controller (PCIe or USB - whatever your card is)
has been incorrectly configured, or not configured at all. I don't
know the specifics of that card so I need to talk generally here.

1. Demodulators and host controllers usually transmit data over either
a serial or parallel data bus. Each bus has slightly different control
lines to indicate such things as CLOCK, START_OF_PACKET, TSVAL, TSERR,
along with the data lines. The control lines help the demod tell the
host controller about the state of the data on the bus.

2. The demod and the host controller need to be configured identically
else the host controller won't receive any data from the demod, or
best case will receive garbage. Linux drivers can vary in respect to
windows drivers here in terms of how the bus is configured, somewhat,
but some hard and fast rules still apply.

a) Assuming both the host controller and the LG support both serial
and parallel (I haven't checked) you'll need to configure that option
correctly to match the card. You can't just 'pick one and hope', you
have to pick the right mode. Visual inspection of the PCB helps, or
knowing their either end of the bus can only be serial due to the
nature of the silicon implementation also helps. Or simply, try all
combinations.

b) Control lines such as TSVALID, TSERR, START_OF_PACKET usually have
polarities HIGH or LOW. These can vary between Windows and Linux, it
doesn't matter if they do, as long as each end matches correctly. I
personally like to match windows by probing the bus visually with
either a logic analyzer or a scope on pads in/around the demodulator.
Trial and error changing these configuration settings at one end
(usually the demodulator) should very quickly start to show garbage or
real data in dvbtraffic. In my experience both ends have their own
defaults and they never match. Leave the host controller alone and
adjust the demodulator unless the demodulator in questions simply
cannot be controlled (highly unusual).

Don't look at scan until dvbtraffic shows real and stable pid data
that doesn't jump about the screen and look like junk. Expect
dvbtraffic to show you between 10-25 lines of stable data, constantly
updating at roughly 19.2Mbps total throughput.

Review the card, determine whether its a serial or parallel bus (or
guess), then review the control line polarities.

This should help.

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2013-07-11 12:52 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-27 18:38 lgdt3304 Carl-Fredrik Sundstrom
2013-06-27 18:58 ` lgdt3304 Steven Toth
2013-06-27 21:00   ` lgdt3304 Carl-Fredrik Sundstrom
2013-06-27 18:59 ` lgdt3304 Devin Heitmueller
2013-06-27 20:45   ` lgdt3304 Carl-Fredrik Sundstrom
2013-06-28  3:00   ` lgdt3304 Carl-Fredrik Sundstrom
2013-06-28 15:23     ` lgdt3304 Steven Toth
2013-07-09  4:18       ` lgdt3304 Carl-Fredrik Sundstrom
2013-07-09 14:53         ` lgdt3304 Steven Toth
2013-07-10  1:40           ` lgdt3304 Carl-Fredrik Sundstrom
2013-07-10 13:51             ` lgdt3304 Steven Toth
2013-07-11  3:51               ` lgdt3304 Carl-Fredrik Sundstrom
2013-07-11 12:46                 ` lgdt3304 Antti Palosaari
     [not found]                 ` <01ab01ce7df1$e92cc9e0$bb865da0$@blueflowamericas.com>
2013-07-11 12:52                   ` FW: lgdt3304 Steven Toth

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.