Gennar1

Finally yesterday night I managed to fix the PCTV 290e driver in order to make it working also in DVB-T mode (DVB-T2 was already working as discussed in the old thread).

I spent quite a bit of time comparing logs, inserting debug code and dumping registers everywhere in the em28xx and cxd2820r driver modules.

In the end, in DVB-T mode the 290e was not able to acquire the lock on the channel due to timing issues. In fact, increasing the wait time from 50 to 200ms in the tuning loop was enough to get the lock on any channel. But channel change was quite slow and sometimes, doing an automatic scan, a frequency was not scanned properly (again for timing issues). So instead of playing with the timings I changed the condition to exit the wait loop from "HAVE_SIGNAL" to "HAVE_LOCK". I think this was the original intention of the driver author (I've asked his feedback on this point).

With this modification, channel scan is 100% reliable and channel change is really fast.

But there was a further issue: a few weak channels were plagued by high BER and badly corrupted pictures. The same channels were working fine on the A867 stick, so I tried to improve the reception.

I noticed that the driver has an option to enable a "Low Noise Amplifier" (LNA) before the demodulator. This LNA is enabled by default for DVB-T2 and DVB-C, but it was disabled for DVB-T.
So I tried to enable it and the reception of weak channels improved a lot!

I collected some data:

LNA OFF:

MUX AGC BER picture

RAI mux 4 72% 32000 corrupted
TIMB 2 75% 14 OK
TVA Vicenza 68% 32000 corrupted
TV7 77% 0 OK
RETE CAPRI 69% 0 OK <------- QPSK modulation!
RAI mux 2 78% 14 OK

LNA ON:

MUX AGC BER picture

RAI mux 4 73% 1500 OK
TIMB 2 76% 0 OK
TVA Vicenza 69% 0 OK
TV7 78% 0 OK
RETE CAPRI 70% 0 OK <------- QPSK modulation!
RAI mux 2 79% 0 OK


So it's clear that the LNA is very useful also for DVB-T reception and should be enabled by default.

In attachment you can find 3 patches. The first one is a collection of all the changes in the em28xx/cxd2820r/tda18271 drivers from kernel 3.1.0 to the latest linux-media drivers available (due for integration in Linux 3.2.0).
This patch adds also support for the PCTV 460e DVB-S2 USB stick. In fact I was too lazy to cherry-pick only the changes relevant to the PCTV 290e, so I just took all changes related to em28xx and dependent drivers. I have no idea if the driver is working or not since I don't have that stick.
The other 2 patches apply the 2 modifications described above (fixed wait loop exit condition and LNA enabled by default).

I think it's better to keep the 2 extra patches separated for the time being, as I don't know if and when they will be integrated in the kernel. I will propose them to the driver author and on the linux-media mailing list.

I'm also including a zip package with the modified modules already compiled (for ET9000).

After yesterday's kernel module updates, all USB tuner drivers depending on dvb-usb (like Avermedia A867, A835 and many others) may not work any more, refusing to load.

The error is this:

modprobe dvb-usb

FATAL: Error inserting dvb_usb (/lib/modules/3.0.3/kernel/drivers/media/dvb/dvb-usb/dvb-usb.ko): Invalid module format

dmesg

dvb_usb: exports duplicate symbol dvb_usb_device_exit (owned by kernel)

The error is related to the fact that now dvb-usb is built into the kernel, while before it was a separate module:

SourceForge - openpli/openembedded/blobdiff - recipes/linux/linux-etxx00-3.0.3/et9x00_defconfig

For some reason, the automatic update procedure did not automatically remove the old module, so it was generating a conflict with the new embedded module.

To solve the problem it is sufficient to manually remove the old module:

opkg remove kernel-module-dvb-usb

I can confirm that eliminating the redirection to /dev/null in mdev-mount.sh solves the problem, and after a reboot /dev/null is OK, as well as ssh.

original code (in /etc/mdev/mdev-mount.sh):

			    # first allow fstab to determine the mountpoint
			    if ! mount /dev/$MDEV > /dev/null 2>&1
			    then
					    # no fstab entry, use automatic mountpoint

fixed:

			    # first allow fstab to determine the mountpoint
			    if ! mount /dev/$MDEV
			    then
					    # no fstab entry, use automatic mountpoint

MMhhhhh really, sorry, I'm not an expert about this but .... CT drivers are involved to an external USB DTT ?

Yes, they are for sat tuners. But also for USB DTT ? I think that E2 send data to kernel but for USB DTT CT driver are not involved.....

I'm not an expert too, but for example I suppose they could accidentally write some value in the wrong memory area.

A virtual frontend device is created, so yes the drivers are involved. And if that virtual frontend device would ignore -say- the bandwith parameter and always use '0' (=auto), this is what you would get if the usb tuner does not support auto bandwith.

Now I have a theory about the possible cause of the problem.

The dvb_frontend_parameters structure contains an union:

struct dvb_frontend_parameters {
__u32 frequency;	 /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
		/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
union {
  struct dvb_qpsk_parameters qpsk;
  struct dvb_qam_parameters  qam;
  struct dvb_ofdm_parameters ofdm;
  struct dvb_vsb_parameters vsb;
} u;
};

unions in C are just like normal structures, but all members in the union share the same memory area, so you can use only one member for every instance of the structure. If you try to write to another member, you are overwriting the memory area of all other members as well.

So probably there is loop in the ET drivers where they reset a parameter of the qpsk or the qam data structure (lets say, the symbol_rate), for all available frontends (3 in our case). Doing this, they are setting to zero the first 32 bit of the common memory area (because symbol_rate is an __u32) and hence the first 2 16 bit parameters of the ofdm data structure, which are bandwidth and code_rate_HP.

If I'm right, it will be trivial to fix it.

I wrote a post on the ClarkeTech forum, describing the problem and the progresses we made so far. Stay tuned...

I've finally been able to make the driver working. I had to hack the driver as discussed here:

http://openpli.org/f...d-with-usb-dtt/

Those are the world first screenshots of an Enigma2 box decoding a DVB-T2 channel.
Here in my area (north-east of Italy) there is only a single DVB-T2 multiplex from Europa7 HD:

http://www.europa7.it/





Europa7 HD is not yet fully operational, so it is not encrypting the programs: everything is FTA, if you have a DVB-T2 receiver.

The patch need some work, then I will release both the patch and the kernel module, so everybody will be able to test it.

Let me add a few more details.
This is the patch I apply to the A867 driver:

diff --git a/drivers/media/dvb/dvb-usb/a867_af903x-fe.c b/drivers/media/dvb/dvb-usb/a867_af903x-fe.c
index 65a498d..a9ed3bf 100644
--- a/drivers/media/dvb/dvb-usb/a867_af903x-fe.c
+++ b/drivers/media/dvb/dvb-usb/a867_af903x-fe.c
@@ -335,6 +335,23 @@ static int af903x_set_frontend(struct dvb_frontend* fe,
   return -EINVAL;
  }
 
+#if 1
+		printk(KERN_INFO "- %s: frequency %d Hz\n",__FUNCTION__, fep->frequency);
+		printk(KERN_INFO "- original bw value: %d\n", fep->u.ofdm.bandwidth);
+		printk(KERN_INFO "- original inversion value: %d expected %d\n", fep->inversion, INVERSION_AUTO);
+		printk(KERN_INFO "- original code_rate_HP value: %d expected %d\n", fep->u.ofdm.code_rate_HP, FEC_AUTO);
+		printk(KERN_INFO "- original code_rate_LP value: %d expected %d\n", fep->u.ofdm.code_rate_LP, FEC_AUTO);
+		printk(KERN_INFO "- original constellation value: %d expected %d\n", fep->u.ofdm.constellation, QAM_AUTO);	
+		printk(KERN_INFO "- original transmission_mode value: %d expected %d\n", fep->u.ofdm.transmission_mode, TRANSMISSION_MODE_AUTO);
+		printk(KERN_INFO "- original guard_interval value: %d expected %d\n", fep->u.ofdm.guard_interval, GUARD_INTERVAL_AUTO);
+		printk(KERN_INFO "- original hierarchy_information value: %d expected %d\n", fep->u.ofdm.hierarchy_information, HIERARCHY_AUTO);
+		/* dirty hack to set OFDM bandwidth to 7MHz in VHF band */
+		if( fep->frequency <= 230000000 && fep->u.ofdm.bandwidth != BANDWIDTH_7_MHZ ) {
+				printk(KERN_INFO "- %s original bw value: %d overridden to %d\n",__FUNCTION__, fep->u.ofdm.bandwidth, BANDWIDTH_7_MHZ);
+				fep->u.ofdm.bandwidth = BANDWIDTH_7_MHZ;
+		}
+#endif
+
  switch(fep->u.ofdm.bandwidth) {
  case BANDWIDTH_8_MHZ: bw=8; break;
  case BANDWIDTH_7_MHZ: bw=7; break;
--
1.7.0.4

I added a few printk to log some dvb_frontend_parameters.

When I select a VHF channel (MUX RAI VHF Ch 5) I get:

- af903x_set_frontend: frequency 177500000 Hz
- original bw value: 0
- original inversion value: 2 expected 2
- original code_rate_HP value: 0 expected 9
- original code_rate_LP value: 9 expected 9
- original constellation value: 6 expected 6
- original transmission_mode value: 2 expected 2
- original guard_interval value: 4 expected 4
- original hierarchy_information value: 4 expected 4
- af903x_set_frontend original bw value: 0 overridden to 1

while when I select a UHF channel (MUX Mediaset UHF Ch 49) I get:

- af903x_set_frontend: frequency 698000000 Hz
- original bw value: 0
- original inversion value: 2 expected 2
- original code_rate_HP value: 0 expected 9
- original code_rate_LP value: 9 expected 9
- original constellation value: 6 expected 6
- original transmission_mode value: 2 expected 2
- original guard_interval value: 4 expected 4
- original hierarchy_information value: 4 expected 4

The "expected" values are just the "auto" settings.
Basically, the OFDM bandwidth is always set to 0 (which means 8 MHz), as well as the code_rate_HP (in this case 0 means FEC is disabled).

Some DVB drivers are using just the frequency and the bandwidth to tune the channel. Examples are the A867 driver, the af9035, the WinTV Nova driver, the A835. Those drivers works on ET9000, but they can only tune UHF channels, while they can not tune any VHF channel with 7MHz bandwidth.

Other drivers are using all the DVB frontend parameters to tune the channel, and they can not work on ET9000 hardware, since the code_rate_HP parameter is always forced to 0, so FEC is disabled. Those drivers are loading properly, but they can not tune any channel, regardless of what you put in the terrestrial.xml or in the manual scan parameters. Examples are the em28xx-dvb drivers (I tested the PCTV 290e and the Terratec Cinergy Hybrid).

Those problems are specific of ET9000, and maybe also of ET5000. Unfortunately the only user with an ET5000 on SifTeam forum reported that his A867 and A835 sticks are working fine, but he never specifically stated that he was also able to tune VHF channels, so we need more input before ruling the ET5000 out of the equation.

Other boxes (like VU+ DUO) are not affected by the problem, so Enigma2 is probably not the cause of the problem, since the code is the same for all boxes (correct me if I'm wrong).

Nor the DVB API version neither the Linux kernel version can be the origin of the problem, since it is present in all images and all kernel versions (I reproduced it on 2.6.18, 2.6.31 and now on 3.0.3).

So the only probable cause of the problem that I can see are the closed source ET9000 drivers.

By the way, you don't need a VHF channel to reproduce the bug: you only need a working DVB-T stick and a single UHF frequency with channels. Open the manual scan interface and set the frequency of your channel and the bandwidth to 8MHz, leaving all other options on auto. The manual scan will give all the channel in the mux with this configuratio. Now set the bandwidth to 7 MHz or 6 MHz and repeat the scan. You will get all the channels regardeless of the bandwidth parameter, since it is always forced to 0. If the bug was not present you would get no channel with BW set to 7 or 6 MHz.

I ported the Avermedia A867 driver to the new kernel 3.0.3. In attachment you can find a zip file with the relevant files: the patch, the new kernel config and the modified recipe.

I also attached the new ipk file, in case someone wants to test it.

I started from the original Avermedia drivers for linux:

http://www.avermedia...aspx?FDFId=4591

and then I applied the patches for the newer kernel form Archlinux:

http://aur.archlinux...es.php?ID=45704

I renamed all files as "a867*" like in the old patch, and changed the #include directives accordingly.

Unlike the old patch, I installed the new files in drivers/media/dvb/dvb-usb/ instead of creating a new a867/ directory. Since the driver includes dvb-usb.h, I think they belong there.

Coherently, I modifed the Kconfig and Makefile in drivers/media/dvb/dvb-usb/ to build the new modules. The only dependency enforced is from dvb-usb.

The driver works fine, just like the old version. I can scan over 300 channels in my area.

A few extra information:

lsmod

Module				  Size  Used by
nfsd				  106907  8
dvb_a867			  196826  2
dvb_usb			    16349  1 dvb_a867
ipv6				  340993  10
ftdi_sio			   30022  1
usbserial			  30999  3 ftdi_sio
exportfs			    4010  1 nfsd
dvb				  4709970  15
modloader2			 33264  1 dvb
modloader			  22329  0
tpm					 7873  3 dvb,modloader2,modloader

dmesg

AVerMedia A867 driver module V1.0.27 loaded.
dvb-usb: found a 'AVerMedia A867 DVB-T Recevier' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (AVerMedia A867 DVB-T Recevier)
DVB: registering adapter 1 frontend 0 (A867 USB DVB-T)...
dvb-usb: AVerMedia A867 DVB-T Recevier successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_A867
DVB: registering adapter 0 frontend 2 (vtuner)...

cat /proc/bus/nim_sockets

NIM Socket 0:
Type: DVB-S2
Name: AVL2108
Has_Outputs: yes
Frontend_Device: 0
I2C_Device: 2
NIM Socket 1:
Type: DVB-S2
Name: AVL2108
Has_Outputs: yes
Frontend_Device: 1
I2C_Device: 3
NIM Socket 2:
Type: DVB-T
Name: A867
Has_Outputs: no
Frontend_Device: 2
I2C_Device: -1

Some modules that were supported in the old v4l-dvb source tree are not compiled by default in the new 3.0.3 kernel.

In particular, in the linux-etxx00-3.0.3/et9x00_defconfig (and also et5x00_defconfig and et6x00_defconfig) configuration file all the em28xx* modules are missing.

I suggest to add at least the following defines:

CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_EM28XX_DVB=m
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_RC=n
CONFIG_DVB_CXD2820R=m

The last one is the Sony DVB-T2 demodulator used in the PCTV 290e USB stick.
Since I own both an ET9000 and a PCTV 290e, I would be very happy to test how they work together.
DVB-T2 support would be a really nice feature of the new kernel :-)