[ANNOUNCE EXPERIMENTAL] PCTV 80e driver

[ANNOUNCE EXPERIMENTAL] PCTV 80e driver

[Mauro Carvalho Chehab]

Years ago, there were some efforts to merge the Devin's drx-j driver port.

For those that followed the discussions, there were several issues with drx-j
that were preventing its merge, even at the staging dir.

One of the major issues is that the drx-j firmware were enclosed inside the
source code, with is forbidden inside the Linux Kernel, as some lawyers believe
that such aggregation would require to also release the firmware source code
as GPL.

I tried to help on that time, but I couldn't do much, as I didn't have any
PCTV 80e board here, nor I had any ATSC signal on my region.

Well, the situation changed, as last year, Samsung bought me an universal
terrestrial and cable generator, and this year I finally got one PCTV 80e
device.

So, three days ago, I resurrected my work from this branch:
	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j

Rebasing it to the upstream version, and doing the required work for the
drx-j to minimally follow the required upstream rules.

The result is at:
	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-new

Even with all changes, this driver is a way more complex that it would need,
as there are 3 abstraction layers between the Linux DVB subsystem and the
hardware:
	drx3xyj.c - talks with the subsystem;
	drx_driver.c - is a "generic" driver for drx-j;
	drxj.c - actually implements the functions that talk with the
		 hardware.

Such complexity makes it hard to debug and to fix, but it should work.

For those with such device that wants to give it a try:

The DRX-J firmware files should be downloaded from:
	http://linuxtv.org/downloads/firmware/#8

and added at /lib/firmware. Only dvb-fe-drxj-mc-1.0.8.fw firmware is
needed. The other two firmware files there aren't currently used, but I
decided to store them, as their usage might be needed later.

As already mentioned, the driver is at my experimental tree, at:
	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-new

In order to test it, I recommend you to get the ATSC frequency tables from:
	http://git.linuxtv.org/dtv-scan-tables.git

and the newest version of the v4l-utils from:
	http://git.linuxtv.org/v4l-utils.git

In order to compile v4l-utils, use:
	autoreconf -vfi && ./configure && make && sudo make install 

The command to scan for the existing ATSC channels is:

	$ dvbv5-scan -I channel /usr/share/dvb/atsc/us-NTSC-center-frequencies-8VSB

Please notice that us-NTSC-center-frequencies-8VSB file is for the
terrestrial frequencies. There are other ATSC frequencies provided there,
used by cable operators.

In order to zap into a channel and see the program IDs:

	$ dvbv5-zap -I channel -c ~/atsc-test -m 473000000 

(assuming that atsc-test is a file with the existing frequencies,
and that 473 MHz is the frequency of some channel).

It should write, at the screen:

tuning to 473000000 Hz
       (0x00) Signal= 0.00% C/N= 0.03% UCB= 20 postBER= 0
Lock   (0x1f) Signal= 76.00% C/N= 0.45% UCB= 295 postBER= 0
  dvb_set_pesfilter to 0x2000

And, after a while:

 PID          FREQ         SPEED       TOTAL
0000      8.39 p/s     12.3 Kbps      539 KB
0f75    419.96 p/s    616.8 Kbps    26985 KB
0fff      8.78 p/s     12.9 Kbps      564 KB
1000      8.33 p/s     12.2 Kbps      535 KB
1683    420.27 p/s    617.3 Kbps    27005 KB
1ae4    419.68 p/s    616.4 Kbps    26967 KB
1fff      8.33 p/s     12.2 Kbps      535 KB
TOT    1334.12 p/s   1959.5 Kbps    85728 KB

Of course, other DVB applications should equally work.

PS.: at least here on my tests with dvbv5 apps at v4l-utils, there are some
instability at the driver: sometimes, it shows the full PID table, sometimes 
it shows only a subset of the existing PIDs, and sometimes, it doesn't show
anything.

That seems to be some sort of bug at PID filtering.

At this stage, I'm not sure where is the bug, as I just make the driver
to work.

Ah, I didn't work at the remote controller yet. I'll handle it after
doing more tests with the DVB functionality.

Those with PCTV 80e: please test, and provide some feedback.

Thanks!
Mauro

Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver

[Mauro Carvalho Chehab]

Em Sun, 19 Jan 2014 02:23:28 -0200
Mauro Carvalho Chehab <m.chehab@samsung.com> escreveu:

> And, after a while:
> 
>  PID          FREQ         SPEED       TOTAL
> 0000      8.39 p/s     12.3 Kbps      539 KB
> 0f75    419.96 p/s    616.8 Kbps    26985 KB
> 0fff      8.78 p/s     12.9 Kbps      564 KB
> 1000      8.33 p/s     12.2 Kbps      535 KB
> 1683    420.27 p/s    617.3 Kbps    27005 KB
> 1ae4    419.68 p/s    616.4 Kbps    26967 KB
> 1fff      8.33 p/s     12.2 Kbps      535 KB
> TOT    1334.12 p/s   1959.5 Kbps    85728 KB
> 
> Of course, other DVB applications should equally work.
> 
> PS.: at least here on my tests with dvbv5 apps at v4l-utils, there are some
> instability at the driver: sometimes, it shows the full PID table, sometimes 
> it shows only a subset of the existing PIDs, and sometimes, it doesn't show
> anything.
> 
> That seems to be some sort of bug at PID filtering.
> 
> At this stage, I'm not sure where is the bug, as I just make the driver
> to work.

It seems that subsequent tuning makes the device worse, reducing the
maximum effective packet bandwidth. Btw, this happens with both xHCI
and EHCI drivers, so, it is not related to any USB 3.0 issue.

Enabling some demux logs, it is possible to see that there are too many
FEC errors:

[73514.186880] dvb_dmx_swfilter_packet: 4546 callbacks suppressed
[73514.186933] TEI detected. PID=0x17f data1=0xc1
[73514.186965] TEI detected. PID=0x1c68 data1=0xbc
[73514.186993] TEI detected. PID=0x17f data1=0xc1
[73514.187022] TEI detected. PID=0x1c68 data1=0xbc
[73514.187049] TEI detected. PID=0x17f data1=0xc1
[73514.187080] TEI detected. PID=0x1c68 data1=0xbc
[73514.187105] TEI detected. PID=0x17f data1=0xc1
[73514.194878] TEI detected. PID=0x1c68 data1=0xbc
[73514.194906] TEI detected. PID=0x17f data1=0xc1
[73514.194927] TEI detected. PID=0x1c68 data1=0xbc
[73521.569205] TS speed 402 Kbits/sec 

I'm starting to suspect that this could be a hardware issue.

It would be good to see if others can use it and tune to several
channels.

> Ah, I didn't work at the remote controller yet. I'll handle it after
> doing more tests with the DVB functionality.

Remote controller support was added.

Regards,
Mauro

Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver

[Steven Toth]

> The result is at:
>         http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-new

That's excellent news.

Well done.

- Steve

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

Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver

[Devin Heitmueller]

On Sun, Jan 19, 2014 at 8:39 AM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> It seems that subsequent tuning makes the device worse, reducing the
> maximum effective packet bandwidth. Btw, this happens with both xHCI
> and EHCI drivers, so, it is not related to any USB 3.0 issue.

I'm pretty sure I saw this and had a patch.  I don't recall the exact
circumstances under which it happened, but I believe it had to do with
stopping and then restarting the streaming on the em28xx too quickly.
The state machine inside the em28xx gets confused and you end up
getting a misaligned stream (which is why you see hundreds of
different PIDs in output from tools such as dvbtraffic).

> Enabling some demux logs, it is possible to see that there are too many
> FEC errors:
>
> [73514.186880] dvb_dmx_swfilter_packet: 4546 callbacks suppressed
> [73514.186933] TEI detected. PID=0x17f data1=0xc1
> [73514.186965] TEI detected. PID=0x1c68 data1=0xbc
> [73514.186993] TEI detected. PID=0x17f data1=0xc1
> [73514.187022] TEI detected. PID=0x1c68 data1=0xbc
> [73514.187049] TEI detected. PID=0x17f data1=0xc1
> [73514.187080] TEI detected. PID=0x1c68 data1=0xbc
> [73514.187105] TEI detected. PID=0x17f data1=0xc1
> [73514.194878] TEI detected. PID=0x1c68 data1=0xbc
> [73514.194906] TEI detected. PID=0x17f data1=0xc1
> [73514.194927] TEI detected. PID=0x1c68 data1=0xbc
> [73521.569205] TS speed 402 Kbits/sec

Are these actually valid PIDs you're expecting data on?  If not, then
it could just be the issue I described above.  Does the TEI check
occur after it has found the SYNC byte?

> I'm starting to suspect that this could be a hardware issue.
>
> It would be good to see if others can use it and tune to several
> channels.
>
>> Ah, I didn't work at the remote controller yet. I'll handle it after
>> doing more tests with the DVB functionality.
>
> Remote controller support was added.

Should be trivial - I added the support for the em2874's RC using that
device - the RC support went upstream years ago but not the actual
board profile.

Probably worth mentioning that while I got signal lock on ATSC, I
didn't any significant analysis into the quality of the SNR. It's
possible that additional optimization of the frontend is required in
order to achieve optimal performance.  Also, I didn't do the ClearQAM
support yet, although that should be a fairly straightforward exercise
(should just be another block in the set_frontend() call which sets
the modulation appropriately).

Devin

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

Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver

[Mauro Carvalho Chehab]

Em Sun, 19 Jan 2014 11:50:55 -0500
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> On Sun, Jan 19, 2014 at 8:39 AM, Mauro Carvalho Chehab
> <m.chehab@samsung.com> wrote:
> > It seems that subsequent tuning makes the device worse, reducing the
> > maximum effective packet bandwidth. Btw, this happens with both xHCI
> > and EHCI drivers, so, it is not related to any USB 3.0 issue.
> 
> I'm pretty sure I saw this and had a patch.  I don't recall the exact
> circumstances under which it happened, but I believe it had to do with
> stopping and then restarting the streaming on the em28xx too quickly.
> The state machine inside the em28xx gets confused and you end up
> getting a misaligned stream (which is why you see hundreds of
> different PIDs in output from tools such as dvbtraffic).

Do you still has your old tree? I'm not seeing it anymore at kernellabs.

> 
> > Enabling some demux logs, it is possible to see that there are too many
> > FEC errors:
> >
> > [73514.186880] dvb_dmx_swfilter_packet: 4546 callbacks suppressed
> > [73514.186933] TEI detected. PID=0x17f data1=0xc1
> > [73514.186965] TEI detected. PID=0x1c68 data1=0xbc
> > [73514.186993] TEI detected. PID=0x17f data1=0xc1
> > [73514.187022] TEI detected. PID=0x1c68 data1=0xbc
> > [73514.187049] TEI detected. PID=0x17f data1=0xc1
> > [73514.187080] TEI detected. PID=0x1c68 data1=0xbc
> > [73514.187105] TEI detected. PID=0x17f data1=0xc1
> > [73514.194878] TEI detected. PID=0x1c68 data1=0xbc
> > [73514.194906] TEI detected. PID=0x17f data1=0xc1
> > [73514.194927] TEI detected. PID=0x1c68 data1=0xbc
> > [73521.569205] TS speed 402 Kbits/sec
> 
> Are these actually valid PIDs you're expecting data on?  If not, then
> it could just be the issue I described above.  Does the TEI check
> occur after it has found the SYNC byte?

Yes. it keeps repeating several times, even after finding the SYNC.

This patch makes the behavior stable:
	http://git.linuxtv.org/mchehab/experimental.git/commitdiff/88c9318cbea60d189a9b10cbc4c5a73f8b002336

Even so, the bitstream of my test signal is 19Mbps, while the measured
speed with the valid packets is being about 3Mbps.

I'm now playing with the em28xx code that allocates URBs, as it might
be related (yet, it works properly with HVR-950).

> > I'm starting to suspect that this could be a hardware issue.
> >
> > It would be good to see if others can use it and tune to several
> > channels.
> >
> >> Ah, I didn't work at the remote controller yet. I'll handle it after
> >> doing more tests with the DVB functionality.
> >
> > Remote controller support was added.
> 
> Should be trivial - I added the support for the em2874's RC using that
> device - the RC support went upstream years ago but not the actual
> board profile.

Yes, the patch was a single line one:
	http://git.linuxtv.org/mchehab/experimental.git/commitdiff/69473d44d1daf434f1e567f40a8247bb8056cfc3
> 
> Probably worth mentioning that while I got signal lock on ATSC, I
> didn't any significant analysis into the quality of the SNR. It's
> possible that additional optimization of the frontend is required in
> order to achieve optimal performance. 

It is unlikely to be due to some optimization, as I'm not injecting
any errors via the RF generator.

> Also, I didn't do the ClearQAM
> support yet, although that should be a fairly straightforward exercise
> (should just be another block in the set_frontend() call which sets
> the modulation appropriately).

Ok. I'll handle it after being sure that VSB is working properly.

Btw, I noticed that there are two "extra" firmwares, that aren't currently
used, defined, on your driver, at drxj_mc_vsb.h and drxj_mc_vsbqam.h.

Do you remember when those should be used? Or are them just two variants
of the main firmware, with support for just VSB and just ClearQAM?

Regards,
Mauro

Re: [ANNOUNCE EXPERIMENTAL] PCTV 80e driver

[Devin Heitmueller]

On Sun, Jan 19, 2014 at 12:32 PM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> Em Sun, 19 Jan 2014 11:50:55 -0500
> Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:
>
>> On Sun, Jan 19, 2014 at 8:39 AM, Mauro Carvalho Chehab
>> <m.chehab@samsung.com> wrote:
>> > It seems that subsequent tuning makes the device worse, reducing the
>> > maximum effective packet bandwidth. Btw, this happens with both xHCI
>> > and EHCI drivers, so, it is not related to any USB 3.0 issue.
>>
>> I'm pretty sure I saw this and had a patch.  I don't recall the exact
>> circumstances under which it happened, but I believe it had to do with
>> stopping and then restarting the streaming on the em28xx too quickly.
>> The state machine inside the em28xx gets confused and you end up
>> getting a misaligned stream (which is why you see hundreds of
>> different PIDs in output from tools such as dvbtraffic).
>
> Do you still has your old tree? I'm not seeing it anymore at kernellabs.

Yeah, I still have the tree.  It's not the HG tree that you saw a
couple of years ago - it's on one of my private git trees because it
was part of a commercial project.  I'll have to dig around and see if
I can find it.

>>
>> > Enabling some demux logs, it is possible to see that there are too many
>> > FEC errors:
>> >
>> > [73514.186880] dvb_dmx_swfilter_packet: 4546 callbacks suppressed
>> > [73514.186933] TEI detected. PID=0x17f data1=0xc1
>> > [73514.186965] TEI detected. PID=0x1c68 data1=0xbc
>> > [73514.186993] TEI detected. PID=0x17f data1=0xc1
>> > [73514.187022] TEI detected. PID=0x1c68 data1=0xbc
>> > [73514.187049] TEI detected. PID=0x17f data1=0xc1
>> > [73514.187080] TEI detected. PID=0x1c68 data1=0xbc
>> > [73514.187105] TEI detected. PID=0x17f data1=0xc1
>> > [73514.194878] TEI detected. PID=0x1c68 data1=0xbc
>> > [73514.194906] TEI detected. PID=0x17f data1=0xc1
>> > [73514.194927] TEI detected. PID=0x1c68 data1=0xbc
>> > [73521.569205] TS speed 402 Kbits/sec
>>
>> Are these actually valid PIDs you're expecting data on?  If not, then
>> it could just be the issue I described above.  Does the TEI check
>> occur after it has found the SYNC byte?
>
> Yes. it keeps repeating several times, even after finding the SYNC.
>
> This patch makes the behavior stable:
>         http://git.linuxtv.org/mchehab/experimental.git/commitdiff/88c9318cbea60d189a9b10cbc4c5a73f8b002336
>
> Even so, the bitstream of my test signal is 19Mbps, while the measured
> speed with the valid packets is being about 3Mbps.

Something is seriously wrong then - I had it delivering all 19 Mbps.

>> Probably worth mentioning that while I got signal lock on ATSC, I
>> didn't any significant analysis into the quality of the SNR. It's
>> possible that additional optimization of the frontend is required in
>> order to achieve optimal performance.
>
> It is unlikely to be due to some optimization, as I'm not injecting
> any errors via the RF generator.

Sorry, I wasn't clear.  I didn't intend to suggest any RF optimization
is causing the issue you're seeing.  I was just saying that I didn't
do any optimization of the RF path so while it works under ideal
signal conditions it may not work as well under more adverse signal
conditions.  In other words, I did what most of the other LinuxTV
developers do - I got a successful signal lock and said "good enough".
 ;-)

On that note, it's probably worth mentioning that particular design
has an LNA controlled by one of the GPIOs on the DRX-J.  So if you're
consistently having poor RF performance (especially with a generator),
try sticking an attenuator in-line, and/or make sure that the LNA is
actually being properly disabled.

> Btw, I noticed that there are two "extra" firmwares, that aren't currently
> used, defined, on your driver, at drxj_mc_vsb.h and drxj_mc_vsbqam.h.
>
> Do you remember when those should be used? Or are them just two variants
> of the main firmware, with support for just VSB and just ClearQAM?

I would have to look at the source again to be sure, but if I recall
it was just so you could reduce the size of the firmware if you didn't
care about the other modulation scheme.

Devin

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