PCTV 80e driver

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

Em Sun, 19 Jan 2014 02:23:28 -0200
Mauro Carvalho Chehab <[email protected]> escreveu:

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.

Remote controller support was added.

Regards,
Mauro

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).

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?

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

Em Sun, 19 Jan 2014 11:50:55 -0500
Devin Heitmueller <[email protected]> escreveu:

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

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).

Yes, the patch was a single line one:

	http://git.linuxtv.org/mchehab/experimental.git/commitdiff/69473d44d1daf434f1e567f40a8247bb8056cfc3

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

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

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.

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

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.

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

That's excellent news.

Well done.

- Steve

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