On Sun, Dec 28, 2003 at 01:54:24PM +0100, Holger Waechtler wrote:
> Robert Schlabbach wrote:
> >From: "Holger Waechtler" <[EMAIL PROTECTED]>
> >
> >>Some of the VES1820 based cards have the I/Q wires between
> >>PLL/Synthesizer and Demodulator swapped, so you don't know in advance
> >>whether INVER
Andreas Oberritter schrieb:
> seems like auto inversion fails. please try ves1820.c from dvb-kernel or
> try increasing the mdelays until it works reliably. current cvs version
> uses 50ms delay while the patches you used have 30ms.
I can't test that at the moment. I switched back to 2.4.23 becaus
Robert Schlabbach schrieb:
> Instead of modifying the sources, you could simply have edited the
> channels.conf file and change the "INVERSION_AUTO" setting to either
> "INVERSION_ON" or "INVERSION_OFF".
I found that out shortly after my source code editing. But how should
I have known that befor
Robert Schlabbach wrote:
From: "Holger Waechtler" <[EMAIL PROTECTED]>
Some of the VES1820 based cards have the I/Q wires between
PLL/Synthesizer and Demodulator swapped, so you don't know in advance
whether INVERSION_OFF is really INVERSION_OFF or not.
Then the driver should detect the hardware
From: "Holger Waechtler" <[EMAIL PROTECTED]>
> Some of the VES1820 based cards have the I/Q wires between
> PLL/Synthesizer and Demodulator swapped, so you don't know in advance
> whether INVERSION_OFF is really INVERSION_OFF or not.
Then the driver should detect the hardware type and makre sure t
Robert Schlabbach wrote:
From: "Holger Waechtler" <[EMAIL PROTECTED]>
From: "Andreas Oberritter" <[EMAIL PROTECTED]>
seems like auto inversion fails. please try ves1820.c from dvb-kernel
Can you please report which delay values work reliably so that we can
take them over into the driver source?
From: "Holger Waechtler" <[EMAIL PROTECTED]>
> > From: "Andreas Oberritter" <[EMAIL PROTECTED]>
> >>seems like auto inversion fails. please try ves1820.c from dvb-kernel
>
> Can you please report which delay values work reliably so that we can
> take them over into the driver source?
How about jus
Robert Schlabbach wrote:
From: "Andreas Oberritter" <[EMAIL PROTECTED]>
seems like auto inversion fails. please try ves1820.c from dvb-kernel
or try increasing the mdelays until it works reliably. current cvs
version uses 50ms delay while the patches you used have 30ms.
Might still not be enough
From: "Andreas Oberritter" <[EMAIL PROTECTED]>
> seems like auto inversion fails. please try ves1820.c from dvb-kernel
> or try increasing the mdelays until it works reliably. current cvs
> version uses 50ms delay while the patches you used have 30ms.
Might still not be enough. I've measured the s
ou edited) appears not to work reliably...
Regards,
--
Robert Schlabbach
e-mail: [EMAIL PROTECTED]
Berlin, Germany
- Original Message -
From: "Andreas 'powARman' Regel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 23, 2003 2:02 PM
Subj
On Tue, 2003-12-23 at 14:02, Andreas 'powARman' Regel wrote:
> I tracked this down to function ves1820_setup_reg0 in ves1820.c. Value
> of reg0 at the beginning of this function changes from value 0x48 to
> 0x68 or from 0x68 to 0x48 with every call. If reg0 is 0x48 tuning will
> work, if reg0 is 0x
Hi, me again :-)
> I did some further investigations using czap. I discovered that tuning
> works exactly every second try, the next try always doesn't work
I tracked this down to function ves1820_setup_reg0 in ves1820.c. Value
of reg0 at the beginning of this function changes from value 0x48 to
Hi,
I did some further investigations using czap. I discovered that tuning
works exactly every second try, the next try always doesn't work:
outputs of czap tuning on channel ZDF (also tested other channels):
/usr/local/src/DVB/apps/szap # ./czap -c channels.conf -n 1
using '/dev/dvb/adapter0/fr
13 matches
Mail list logo
