--On Saturday, August 16, 2003 05:46:02 PM +0200 Robert Schlabbach <[EMAIL PROTECTED]> wrote:
I'm not sure about your comment that frequencies in cable systems are usually correct. Earlier versions display AFC information somewhere and I saw a not very small difference.
Aha! Your card may be mis-tuned. The Siemens cards have a TDA9819 IF amplifier on them, with a VCO-controlled output frequency. That frequency is modified by using the infamous "PWM" output, which is supposedly measured INDIVIDUALLY for each card after manufacturing and then written to the EEPROM on the card.
The PWM value for your card may be incorrect, or maybe your card's characteristics changed due to aging.
As to why you are no longer seeing the AFC displayed, the CVS comment says:
- printk() -> dprintk() for AFC in ves1820.c
So you could just change it back to get the AFC displayed again (or somehow enable dprintk output...)
Then take a look at read_pwm() in VES1820.C. Also enable the dprintk output there (e.g. by changing it to printk as well). What PWM value is displayed? If it's 0xFF, your EEPROM is damaged.
Either way, try inserting a line to override the PWM value and try a few values and see if you can minimize the AFC output. What optimum value do you come up with?
Ok, I've extend the ves1820 driver for module options capability for CARCONF, CLKCONF and PWM (at the moment private patch, but if per-card config is working, I will submit them).
I found that the PWM on my first card is really not the proper one. EEPROM: 0x52 Best: 0x38
AFC is now between 0 and -1/1
After you have found an optimal PWM value, try changing the CARCONF register back to 0x12 again. Does it work now?
Yes, after adjusted PWM, newer default CARCONF (0x12) will work proper. I get already on the first czap line "FE_HAS_LOCK"
Because of this parameters (especially PWM) need to be set per card, I ran into a problem: how to get the card number in following functions:
int ves1820_attach (struct dvb_i2c_bus *i2c)
int ves1820_init (struct dvb_frontend *fe)
Hopefully anyone can help me here.
i2c->adapter>num is the card number and i2c->id the number of the frontend on your card (usually 0, the index of the first one).
But what do you thing about reprogramming the EEPROM? A simple pseudo-frontend driver that just rewrites the EEPROM is trivial to implement and avoids complicated per-card module parameters (think of the case that you're moving your cards, then you would have to rewrite your start scripts completely).
Even if the EEPROM on your card is write-protected it's pretty simple to unlock it, you just have to cut one wire of the 24lc16 (the WP pin) on your card. See the 24lcXX datasheet for details. Other EEPROMs of the 24lcXX family behave similiar.
Holger
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
