I have studied some things somewhat further and opened up the tuner modules in my possession. This revealed the following:

DVB-S(2): AVL2108 demodulator and STV6306 tuner (works)
DVB-T: S5H1432 demodulator and MXL5007T tuner (old, DVB-T only, tuner module number DNOD44QSH102A,work on factory firmware, not on E2, no driver available)
DVB-T(2): CXD2820R demodulator and TDA18212 tuner (new, tuner module number DNOQ44QCH106A, works on factory software, not on E2)
DVB-C: TDA10024 demodulator and MXL201 tuner (tuner module number DNQS44CPP101A, not tested by me)

If you have look at the driver code things match up regarding DVB-S(2) and DVB-C. The drivers are indeed for the chips mentioned.

With DVB-T(2) it is a completely different story. As mentioned before the DVB-T only module (...102A) is not supported, due to the missing driver. With the DVB-T2 module, there is a surprise. The driver is for the combination CDX2820R plus TDA18272, not the TDA18212 I found in my module. I looked three times with a magnifying glass, and I did not misread the number, as a 1 and a 7 can be mixed up easily in small print. The TDA18212 also exists and seems to be an earlier member of the NXP DVB-T2 compatible tuner chips of which the TDA18272, TDA18273 and the TDA18292 also are members. A quick hunt on the net did yield a brief product description, but no detailed data sheets. Most promising was the site of Antti Palosaari who has drivers for most of them

This is quite revealing, assuming that the TDA18212 and TDA18272 are not compatible with each other. Frontends are made around the demodulator, the part that is actually visible in hardware. The tuner is controlled through the demodulator, in many cases through a so called I2C gate. This explains that the CDX2820R/TDA18212 module is recognized as a frontend, because the TDA2820R is detected (and reported) correctly. The tuner however is different from that assumed by the current driver and hence: no reception and the lock errors found in the logs.

This leads to two possibilities. The first is that the chip number TDA18212 was misread as TDA18272, and the driver was built for the latter. If so, this driver could never have worked on the module I have (...106A). The second possiblity is that there are modules around with the TDA18212, but also with the TDA18272. Technically it is possible this can work if you drive the TDA18272 as a TDA18212 in case the '7' is a superset of the '1'; both ICs have the same housing and are mechanically compatible.

The fix? I have to study a driver for the TDA18212 and figure out the differences with the TDA18212 and intgrate that in the current driver. This however is time consuming and I am very busy with two other projects. To pull this off one would also need the full datasheets (not the 10 page product briefs) of the two devices.

Also see Samsung-S5H1432-demodulator-help-wanted

Regards,

Audioniek.

- - - Aktualisiert - - -

The 12V tuner bug...

is not a bug. For reasons that are beyond my comprehension, somebody mixed the LNB voltages up with the 12V output that can be found on only one SH4 receiver I know of: the ABcom IPbox 9900HD. The two (12V out and LNB power) have nothing to do with each other, but there are STV090X tuner drivers around that do strange and unjust things with the LNB power driver and the 12V output (which does not exist on almost all models), the latter can be controlled through procfs.

A long time ago I removed all 12V output related stuff from the frontend drivers, so this "bug" does not exist in my images.

In addition, in my images the entry /proc/stb/misc/12V_output is missing as the corresponding hardware is simply not there (I do not offer an image for the IPbox 9900HD as I do not have one and therefore cannot test things). E2 tests for this entry and reports that something is missing if it is not found (which is not true, the message is wrong). Regarding the previous, on SH4 this is all normal, and you should not bother about this "bug".

Regards,

Audioniek.