[linux-dvb] Re: New card: Lorenzen DVB-T PCI (TT budget)

[Alex Woods <linux-dvb@giblets.org>]

On Tuesday 15 Apr 2003 1:16 am, Holger Waechtler wrote:
> Alex Woods wrote:
> > On Monday 14 Apr 2003 11:29 am, Holger Waechtler wrote:
> >>Ingolf Haberer wrote:
> >>>Hello ML,
> >>>There is a new kid on the block - the Lorenzen DVB-T PCI. It's a
> >>> TT-DVB-T budget with CI soldering pads but not present.
> >>>The PCB is called "B2T1110 Rev. 1.1".
> >>>The PHILIPS frontend (tuner) is labled "TDM1316L/IHP" and the
> >>> demodulator "TDA10045H".
> >>
> >>The PCI bridge part (all the SAA7146 related stuff) should work out of
> >>the box, the frontend is not yet supported on a PCI card.
> >>
> >>However, a driver is included in Alex Wood's DEC2000-t driver in the
> >>DVB-kernel tree.
> >>
> >>If you own such a beast please peel the frontend code out of the
> >>dec-driver and generalize it so that it can be used with all types of
> >>cards...
> >
> > Calling it a driver is glorifying it a bit ;)
> >
> > Whilst the DEC2000-t also has a TDA10045H for the frontend, everything
> > gets passed to it down a USB cable, so I can only guess at what the chip
> > itself might be after.  Also, the only bit implemented is tuning to a
> > frequency, so it's rather skeletal right now.
> >
> > If you do have a go at writing a generic TDA10045H frontend don't be
> > afraid to completely disregard the stuff in the dec driver, because it's
> > likely to be very very very specific to the dec driver.
> >
> > I couldn't find any documentation on the TDA10045H's registers, so if you
> > find any, please let me know.  It could possibly be useful for
> > reverse-engineering the usb transmissions for the dec.
>
> at the end you might want to take a look on the actual i2c communication
> to the demodulator and tuner chip, here is a nice tool:
> http://warmcat.com/milksop/cheapi2c.html
>
> Alex: maybe you can post the logs for your DEC2000?
>
> Holger

Of course...  I was kind of enjoying trying to figure them out, but I could 
use some expert eyes looking at some of the bits ;)

The packets for the commands and results consist of a header and then any 
parameters/data.  All command packets are sent in this way, whether they're 
to the frontend or the demux, or whatever.

The header looks like this, numbers before colons are byte number:

{
	1: type (0xaa for a command, 0x55 for a result, and I think 0x5a for a failed 
result)
	2: id (an incrementing counter.  id's match for matching commands and 
results)
	3: command id (in my kludged i2c stuff, I pass this in the i2c addr)
	4: Length of data (in bytes, 0x3c max) (in my kludge, this gets passed as the 
i2c len)
}

In my kludge I pass the packet payload in the i2c buf.
This is the tune to frequency command and result:

aa0c711400000003000ac5d000000001000000ff000000ff
550c710400000000

I have the command data worked out as:

{
	1-4: unknown
	5-8: frequency (KHz)
	9-12: unknown
	13-16: unknown
	17-20: unknown
}

Okay, so maybe 'worked out' wasn't the best phrase to use ;)
For multi-byte values, the data seems to be sent most in network byte order 
(most significant first).

Unfortunately, as there is no way to distinguish between frontend commands and 
other ones, I'm going to list packets I've seen from a tuning session, which 
will hopefully be mostly frontend stuff.  Also, I haven't had much luck 
finding packets that aren't mostly 0x00's.

/* Perhaps zapping to the pids that contain channel data? I see these when 
getting teletext too.  Think I've found service pids in there somewhere */
aa10601d00120001084e66c0000000000000000000ffffff000000000000000000
551060020000
aa11601d0014000101730000000000000000000000ff0000000000000000000000
551160020001
aa3b601d123f00010802123f000000000000000000ffffff000000000000000000
553b60020001

/* Signal status enquiry maybe? */
aa1373080000000100000000
5513730c00000000000000ff00000000
aa6673080000000100000000
5566730c00000000000000ff00000000
/* Good grief, wouldn't 8 bit ints suffice for these?!? */
aa8573080000000100000001
5585733000000000000000ff000000000000000b00000000000000000000000000000000000000f0000000530000000300000002

/* I have no clue what these are */
aa3962020000
553962020000
aa3c62020001
553c62020001

The sequence seems to be, set to a frequency, then the command 73, then 60, 
then 62 once or twice, then repeat 60 and 62 stuff for a bit before switching 
frequency.

Cheers,
Alex


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.