On Sun, 23 Apr 2017 15:19:21 +0300 Antti Palosaari <crope@xxxxxx> wrote: > On 03/16/2017 12:22 AM, Andreas Kemnade wrote: > > If the si2157 is behind a e.g. si2168, the si2157 will > > at least in some situations not be readable after the si268 > > got the command 0101. It still accepts commands but the answer > > is just ffffff. So read the chip id before that so the > > information is not lost. > > > > The following line in kernel output is a symptome > > of that problem: > > si2157 7-0063: unknown chip version Si21255-\xffffffff\xffffffff\xffffffff > That is hackish solution :( Somehow I2C reads should be get working > rather than making this kind of work-around. Returning 0xff to i2c reads > means that signal strength also shows some wrong static value? > dvb-fe-tool -m is like this: Lock (0x1f) Signal= -1.00dBm C/N= 19.25dB UCB= 6061140 postBER= 40.0x10^-6 Signal strength is static. Yes, I do not like my solution, too. Also i2c reads from the windows driver from the si2157 after that 0101 command give such problems. I have checked my usb logs again. So the question is where a better solution can come from. I do not find a proper datasheet of the si2157 or the si2168. Just for reference: the stick is labeled VG0022a. The usb strings are like that: idVendor 0x1d19 Dexatek Technology Ltd. idProduct 0x0100 bcdDevice 1.00 iManufacturer 1 ITE Tech., Inc. iProduct 2 TS Aggregator iSerial 3 AF0102020700001 if that may lead to some information. Regards, Andreas
Attachment:
pgpnWUKM02JN7.pgp
Description: OpenPGP digital signature