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

[Holger Waechtler <holger@convergence.de>]

Alex Woods wrote:
> 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:
I'm not talking about the USB level but the i2c level communication. 
Nobody guarantees you that all i2c transfers are intiated by the host 
PC, right?

Holger



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