Hi Georg, On Sun, 10 Jul 2005, Georg Sassen wrote: > You'll find it on http://sams.sassen.de/usbsnoop.log.bz2 > > But it's quite huge: > -rwxr-xr-x 1 georg georg 19158324 Jul 10 21:01 usbsnoop.log.bz2 It is not huge. ;) > Meanwhile (while compressing the huge logfile...) I did another experiment: I > entered the USB IDs of my firmware into the umt-010 driver so that it would > accept it and tried "tzap -r RTL": > georg@piccolo:~$ tzap -r RTL > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > tuning to 538000000 Hz > video pid 0x01b1, audio pid 0x01b2 > status 00 | signal ff24 | snr 0000 | ber 00000000 | unc 00000000 | > status 1e | signal ff56 | snr 4848 | ber 00000000 | unc 0000165b | > FE_HAS_LOCK > status 1e | signal ff78 | snr 5c5c | ber 00000000 | unc 0000045f | > FE_HAS_LOCK > status 1e | signal ff73 | snr 5656 | ber 0000ab8c | unc 00000072 | > FE_HAS_LOCK > status 1e | signal ff5d | snr 4848 | ber 00005783 | unc 00000203 | > FE_HAS_LOCK > status 1e | signal ff78 | snr 4848 | ber 00005783 | unc 00000ced | > FE_HAS_LOCK > status 1e | signal ff69 | snr 4848 | ber 0001de2c | unc 0000026a | > FE_HAS_LOCK > status 1e | signal ff44 | snr 5050 | ber 0001de2c | unc 000015b8 | > FE_HAS_LOCK > status 1e | signal ff39 | snr 4848 | ber 00016954 | unc 00001e36 | > FE_HAS_LOCK > status 1e | signal ff4c | snr 4848 | ber 00005479 | unc 0000227e | > FE_HAS_LOCK > > This seems to look better than with the hanftek firmware. This is not correct. In this case the firmware is just for programming the FX2 to make it vendor-specific. The programming of the tuner and frontend is completely done in the driver. I think your result is an accident. Either the tuner-programming survived the reboot from windows and the tuner-programming with the umt-010-driver wrote to the wrong address or the tuner-programming of the umt-010-driver was wrong, but still makes the tuner to get a (bad) signal. > mplayer /dev/dvb/adapter0/dvr0 doesn't show anything, though, neither does > cat /dev/dvb/adapter0/dvr0. Yes, UNC and BER are indicating that almost everything is trash -> wrong tuner-programming. Can you try to tune to a good channel in windows, then do a reboot to linux and run scan again. If my assumption is right it will find the same channel on each frequency. > Bus 005 Device 003: ID 15f4:0001 HanfTek HanfTek UMT-010 USB2.0 DVB-T (cold) > [..] It is identical to the hanftek-device I have here. What I saw on the usblog you created, is that the tuner in your box is on i2c-addr 0x60 (the hanftek one is on 0x61). (This confirms my theory about the tuner-left-over from windows). It is connected to the slave-i2c-port of the mt352. Which makes it impossible to read the address? Is there a way of figuring out if a write to the slave-i2c-port of the mt352 failed? (this would be a way to distinguish the tuners) Another solution would be to simply program both tuners each on its address... Please try to open the box to figure out which tuner is inside. This is important to know. The box has apparently good reception quality, so need for returning it because of quality issues. regards, Patrick. -- Mail: patrick.boettcher@xxxxxxx WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
