Dennis Noordsij wrote:
Hi,Ok, I'll postpone applying this patch. You can't simply disable frequency bending when you have multiple cards in the same box. When both try to tune on the same frequency I had in some setups the effect that both frontends loose lock due to RF interferences.
After some months of not much time, I've now been playing with the new firmware / drivers and VDR. As you know Jaakko we have the same cards and the same cable network :-)
- Disables zigzag for everything except DVB-s. This is from Metzler driver. Maybe someone with DVB-t needs it? In that case change the "!= FE_QPSK" to "== FE_QAM".
Disabled zigzag. For QAM_64, if I hit the exact frequency, it locks immediately. Picture is perfect, etc. But I have 2 cards, and if I let the frequency bending step in (i.e. offset the frequency by one stepsize, 62.5kHz) locking for that card becomes more unreliable, it does better if it doesn't bend the frequency at all. So it's very touchy, if I step 62.5kHz away from the "right" frequency the results get much worse.
You should use INVERSION_AUTO if you don't know for sure your providers inversion settings.- Has anyone ever tested this auto inversion thing? DVB-c is far too slow to tune and lock for this auto inversion code to work. Therefore you need to manually set it.
I had inversion turned off with the reg0 |= 0x20 code in ves1820.c
(Your HTV channels.conf specifies inversion off for all channels, hope that was right :)
That's automatically done by the zigzag scan, another reason not to disable it. Here in the Berlin cable network we have similiar offsets from the announced frequency in NITs for some transponders.- QAM registers have been tweaked to non-specification values. I do not know if someone has counterexamples, but this works for a lot of people.
Tried both your "100" for Reg1 but also "106", noticed not much difference.
For QAM_128 channels (or maybe it's the signal rate of 5900, or maybe the frequency, 283MHz and up compared to 162MHz for the working channels) I can't seem to get reliable lock-ons at all. Scanning down from advertised_frequency + 10*stepsize to advertised_frequency - 10*stepsize, it does better closer to the advertised_frequency but never hits the sweet spot.