[linux-dvb] Terratec Cinergy 1200 DVB-C - Unknown Device

Tomi Orava tomimo+linux-dvb at ncircle.nullnet.fi
Fri Feb 2 06:58:27 CET 2007


>> It seems that Reelbox
>> (http://www.reel-multimedia.co.uk/reelbox-software.html) does indeed
>> contain some sort of GPL-driver for TDA10023. I checked out the ReelBox
> <...>
> Some sort? It's GPL. The reason why it is stil based on the DVB-API of
> 2.6.12 is that there were too many API changes in the last time
> (especially

Uh, I did not mean to imply anything about your drivers license. I more or
less meant that the driver in ReelBox-repo is for an unknown card using
the TDA10023 frontend which might not be 1:1 compatible with Terratec
and/or Satelco etc.

> the PLL stuff) and with the upcomming S2 I currently don't see any
> stabilisation in the near future. As the drivers works fine for the RB,
> there's no need to waste time in continuously porting to the current API
> ;-)

Anyway, it's great to see that your driver has been licensed in GPL and I
thank you for doing it :)

>> #>scan -a 2 fi-elisa
>> scanning fi-elisa
>> using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
>> initial transponder 154000000 6900000 0 4
>> initial transponder 370000000 6900000 0 4
>> >>> tune to: 154000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_128
> First try with czap that you're actually getting a lock.

I neglected to mention that getting a lock seems to work without problems.

#>czap -a 2 MTV3
using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
  1 MTV3:154000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_128:305:561:49
  1 MTV3: f 154000000, s 6900000, i 2, fec 0, qam 4, v 0x131, a 0x231
status 00 | signal aeae | snr a3a3 | ber 000fffff | unc 00000034 |
status 1f | signal eaea | snr f4f4 | ber 000005e8 | unc 000001c5 |
status 1f | signal eaea | snr f4f4 | ber 00000000 | unc 00000000 |
status 1f | signal eaea | snr f4f4 | ber 00000000 | unc 00000000 |
status 1f | signal eaea | snr f5f5 | ber 00000000 | unc 00000000 |
status 1f | signal eaea | snr f5f5 | ber 00000000 | unc 00000000 |

>> WARNING: filter timeout pid 0x0011
> Maybe the parallel data output configuration is wrong and the data is
> latched at the wrong edge. The value is in the inittab, adress 0x12. The
> clock polarity is bit 0, so a change to 0xa1 would be worth a try.

I changed the inittab line:

0x12,0xff,0xa0,  // INTP1 POCLKP=1 FEL=1 MFS=0
0x12,0xff,0xa1,  // INTP1 POCLKP=1 FEL=1 MFS=0

but without success. It might of course be that the I've made an obvious
mistake in merging the driver with the 2.6.20-rc7 kernel version.

I did enable some debug printk's in the driver and got the following
interesting printouts:

Feb  2 07:49:40 valen kernel: Symbolrate 6900000, BDR 2001431 BDRI 134,
Feb  2 07:49:40 valen kernel: DVB: TDA10023(2): AFC (-1) 6738Hz

I compared the AFC-values to another Hauppauge/Technotrend DVB-C 1.0 card
and it gives the following AFC-values (in case that give's you some hints
about the problem):

Feb  2 01:29:38 valen kernel: DVB: registering frontend 1 (VLSI VES1820
Feb  2 01:30:57 valen kernel: ves1820: AFC (3) -20215Hz
Feb  2 01:30:58 valen kernel: ves1820: AFC (3) -20215Hz
Feb  2 01:31:21 valen kernel: ves1820: AFC (4) -26954Hz
Feb  2 01:31:23 valen kernel: ves1820: AFC (5) -33692Hz

>> PS. It would be so much easier with proper programming docs ... :(
> I have the data sheet, but I don't know the current status of it. As NXP
> still doesn't have it on their webpage, I assume it's on purpose.

I did ask for the programming specs for the TDA10023 from nxp.com but got
an email saying that document is not available for public. They suggested
asking from card manufacturer ...

Tomi Orava

PS. Attached is the merged driver diff I've tried to get working.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tda.diff
Type: text/x-patch
Size: 27067 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20070202/973cbfa2/tda-0001.bin

More information about the linux-dvb mailing list