Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Progess on VP-1020




	Hi:

> 
> I have been working on getting my FTA satellite receiver card
> working under Linux.

	I've been working on a VP-1030 (CI Version).

> The card is marketed under different labels, mine is a VVmer TV@Sat
> card, but I believe it to be the same as a VisionPlus VP-1020
> and a Twinhan. The BTTV card list has it as:

	I think Twinhan and VisionPlus are the same company. Twinhan
makes the hardware and VisionPlus the software.

>    DST Card/DST-IP (bt878, twinhan asic) VP-1020
>     Sold as:
>      KWorld DVBS Satellite TV-Card
>      Powercolor DSTV Satellite Tuner Card
>      Prolink Pixelview DTV2000
>      Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ?
>    DST-CI Card (DVB Satellite) VP-1030
>    DCT Card (DVB cable)

	MSI makes also a DST card. 

	DST-CI Compatibles are the new Pinnacle PCTVSat CI an Hercules Cards.

> The card consists of a BT848 (or connexant equiv), an alps_b2srv tuner

	Bt878A. The tuner is made by LG Innotek, but it is not directly
accesable from the bt878a. The asic is a 8051 compatible microcontroller.
The VP-1030 includes a CIMAX for CI control, i think.

> 1. bttv driver.
> The normal bttv driver hangs and the whole system locks up on detecting
> the bt848 chip. Most unLinuxy :(
> The PCI id is all zeroes. On tracking down where the hangs occur, it
> is in most areas to do with video capture initialisation.
> The BT chip is not used for video capture on this card.
> In order to prevent lockups, I changed my version of the bttv
> driver to have the unknown device have zero video inputs, and
> changed the core driver not to do any capture / video initialisation
> if video inputs count is zero.

	I haven't been capable of prevent this lockups with bttv, 
so i've written a modified bttv driver with only gpio and i2c. This driver
works well with a Pinnacle PCTV Sat, and does not hang my computer with
the twinhan, so i've been working on analyzing the communications 
between the asic and the bt878.

> 2. i2c level
 
> The i2c is also slightly different in that gpio pin 0 has to be
> driven low for i2c signals to go out. After I2c transfer,

	How did you realize this? I've been monitoring GPIOEN, and 
this is allways 0. GPIO seems used to monitor asic state.

> this pin is left not output enabled. I2c is not done to the tuner
> but to the asic at addresses aa and ab. Data is sent in small packets,

	If they belongs to the tuner, yes. If they are for the CI, can
 be bigger.

> comprising part of the alps tuner dividers and part qpsk codes,
> and part bits for 13/18 V and 22Khz tone. At this stage
> I presume the asic sends this data out to relevant parts of the board.

> This means there may be more important info in the user level 
> driver. Or not ...

	I don't think that the asicprocesses the output of the
stv0299, but who knows...

> 4. The packets to the asic.
> 
> The asic is determined to be new or old.
> The packet
> 
>    6 | 0 | 0 | 0 | 0 | 0 | 0xfa
> 
> is sent to the asic (aa).
> 
> If a certain reply (yet to be determined) comes back it is 'new'.

	I have the reply to this for my card, (new protocol, VP-1030).

> For old devices, packets seem to be fixed length along the lines of
> 
>    alps-freq-div1 | alps-freq-div2 | alps-freq-div3 |
>                symbol-rate1 | symbol-rate2 | symbol-rate3 |
>                 bits | checksum
> 
> where bits:
>      0..2  = 1 for 22Khz, 0 off
>      5  = 1 for symbol rate > 8000
>      6  = 1 for 13 / 18 V
>      7  = 1 some meaning
> 
> For new devices, the first byte appears to be a length indicator
> then following bytes the same as old.

	I think this byte is sent as i2c subaddres in the first
 transaction.

> The method works by sending the packet to aa, (actually in the code
> the address is put in the first byte of the buffer and handled
> as an address by the sending routine)

	I think the address for CI is different. I'll check at home.

> Then the address ab is read a single byte as response with
> i2c settings BT848_I2C_SDA|BT848_I2C_SCL.
> 
> To read the current tuner packet, eight bytes are read from ab
> with BT848_I2C_SDA|BT848_I2C_SCL|BT848_I2C_W3B, then the
> final byte with BT848_I2C_SDA|BT848_I2C_SCL.
> 
> There may also be an 8820 device, which I suspect is some kind of
> ca device.
> 
> It is reset in error conditions by pulling GPIO bit 2
> low, waiting, then releasing back to high.
> 
> That's it for now.

	By the way, the twinhan driver misdetects my Pinnacle PCTVSat
as a DST card??







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



Home | Main Index | Thread Index