> > From: Manu Abraham <abraham.manu@xxxxxxxxx> > Date: 2007/10/25 Thu AM 04:53:28 BST > To: garlicdevel@xxxxxxxxxxxx > CC: linux-dvb@xxxxxxxxxxx > Subject: Re: Pinnacle PCTV Sat HDTV Pro USB (PCTV452e) > > garlicdevel@xxxxxxxxxxxx wrote: > >>> but I think the older driver could be better at the moment as with the newer > >> driver the device doesn't appear to initialize for the stb0899 > >> hmm, i have checked both and they don't differ. > > > > there seems to be some more checks in the newer driver to make sure the device is in the right state > > also looking at one of the newer budget devices that's using it, there seems to be a whole bunch of defines added into the config structure > > I'm not sure if these are being used just yet (or if so what for) > > but I'm keeping my options open by trying things against both for now just to be sure > > > > > >> you are "initialising" STB0899_DISFIFO in line 51 with 0x00. > >> this byte will be sent out after frontend_init() on the first diseqc command. > > > > sorry about that > > the win driver appears to fill in a default set of values when the device is plugged in > > this is what I've used in the data structure > > although if the stb driver doesn't change these again afterwards in the same way the win driver does, then this won't work right > > I'll need to take a closer look at the values that are being set after the initial plugin of the device > > looking at the logs for this one, it seems to be going mostly from 00 to e2, with 10, 38, f0 near the end of the log > > You are right. In fact this is a FIFO, but initially it is initialized to 0x00 to avoid > garbage in the output. You are right as well that the FIFO is modified later on > at run time, which you can see it in the driver. The FIFO is transferred only > when the precharge is discharged, till then whatever you have in the FIFO is > of no concern. > > You can see the FIFO being modified at runtime here (contrary to your claim > that the stb0899 driver doesn't modify the FIFO, well if it wouldn't have, then > there wouldn't have been any diseqc commands sent) > > http://jusst.de/hg/multiproto/file/2c1aa7b57779/linux/drivers/media/dvb/frontends/stb0899_drv.c > line #687 before the discharge > > Manu > I'm afraid I don't know much about how FIFO's tie in with the tuning of the LNB / diseqc commands at this point, everything I'm seeing is just based on observation of the win driver I know diseqc is used to to send commands to move the motor and can be used to send / recieve data from the LNB but I'm wondering if diseqc would have been used in the windows log, as I left the setting empty for the A/B/C/D diseqc switch when selecting the channel does diseqc have to be used to tune the LNB? Also I've just reliased some of the changes to the register I've mentioned above will be incorrect anyway I remembered afterwards that the perl script isn't taking account of the offsets when looking at the log to work out the register name At the moment the default values match the initial values loaded by the win driver on hardware plugin But I think I need to be looking at the values set later on during the actual tuning instead I'm going to update the perl script to take account of the register names with offsets then I'll add something in to create the structure set (contents of the priv header) based on the latest values instead of the earliest ones this might also help identify how the different settings on a per channel basis in the win driver as there seems to be a lot of drop down boxes / number settings that can be altered on a per channel basis (like circular polarisation for example) ----------------------------------------- Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
