Hello, I recently obtained one of the dreaded Artec T1 usb-dvb tuners. Sadly, I only discovered the problems that this device causes in Linux since purchasing it. So far I have managed to get the system to recognise the card by making use of the faulty USB ID facility in the Kernel configuration (it is indeed one that identifies itself by the default code stored in the Cypress chip). The system correctly installs the firmware file that I got from the Windows drivers using Patrick's utility. That's where the success ends though. I cannot get the card to tune to any station. Whichever program is used, the result is always the same - tuning failure. Reading through the archives for this forum, I noticed that there have been several messages that seem to match my problem, but couldn't find any direct solution. If I have missed it, I apologise for bringing it up again here and would be grateful if someone could point me towards the answer. Assuming that this isn't the case, here are a few more details on my device. It is an Artec T1 with a DibCom 3000M-B and a Thomson DAT7022 tuner. I removed the lid of the tuner and can see that it does indeed have the Infineon TUA6010XS PLL that the driver file reckons it should. My latest efforts have been directed towards comparing the USB activity when attempting to scan for channels using the dvbscan utility and the equivalent operation using the program that came with the Windows application. The data was obtained from Windows using the usbsnoop application and from Linux by enabling the debugging option in the Kernel and specifying debug level 2 to the dvb-usb module. Without knowing the addresses/control commands for the various components in the tuner, most of the traffic is pretty meaningless to me. However, I do notice that the first transaction on the bus seems to differ between the operating systems. Windows sends out a fairly long frame of data: 00000000: 07 00 01 ef 00 6c 2b ef 00 1c 00 00 00 86 a0 c2 00000010: 37 f3 24 d2 4e 85 01 a1 cd 7e 50 bb 08 01 00 00 00000020: 00 38 Whereas the Linux equivalent starts the same but is a much shorter packet: 07 00 01 The subsequent packets sent to the tuner in the Windows operation are: 00000000: 03 10 04 04 00 00 00000000: 02 11 84 01 00 02 00000000: 03 10 00 00 00 04 00000000: 03 10 04 00 81 2c 00000000: 03 10 04 00 00 00 etc. and in Linux: 03 10 04 04 00 00 03 10 00 00 00 08 03 10 04 00 81 2c 03 10 04 00 00 00 03 10 04 03 90 00 03 10 04 05 00 01 03 10 00 06 00 b2 etc. I assume that the first transaction is supposed to configure the device and the remainder are concerned with the tuning/scanning operations; but am just guessing at this point. The discrepancy stands out as a possible reason for the tuning problem in Linux. If anyone is in a better position than me to interpret these results or can offer any other suggestions, I would appreciate their help. Many thanks, Steve. ___________________________________________________________ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
