[linux-dvb] Artec T1 Tuning Problem

Steven Cleary steven_c_gbr at yahoo.com
Tue Jan 23 19:24:26 CET 2007


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

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

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

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

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,


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. 

More information about the linux-dvb mailing list