[linux-dvb] Latest CVS - tuning changes/problems

[Ralph Metzler <rjkm@convergence.de>]

Dave Chapman writes:
 > Hi,
 > 
 > I checked out the latest CVS code yesterday morning (23rd April), and am 
 > finding some strange behaviour with the tuning code.  I understand from the 
 > changelog that the tuning code has changed.
 > 
 > Firstly, the driver wouldn't compile because of the unknown symbols 
 > FE_COMPLETION_EVENT etc.  I changed this to QPSK_COMPLETION_EVENT - I hope 
 > that made sense.

Yes, sorry.
I checked in the missing file yesterday afternoon.

 
 > However, I am experiencing very different behaviour (with my old Hauppauge 
 > card) than earlier CVS versions.  I should mention that I am testing the 
 > driver on the satellite at 31W - this is a "feeds" satellite with most 
 > transponders transmitting close together in the range of 10954-11019 
 > vertical, SR 5632.  These transponders also only occasionally transmit a 
 > signal.
 > 
 > If I tune to an active transponder, then it seems to work  But then, if I 
 > tune to another, inactive frequency, then quite often, the tuner will stay 
 > locked at the current transponder.  Is this now the desired behaviour when 
 > tuning fails?

No.
But the driver now does a zigzag-scan around the frequency. So, it
might lock onto the old transponder if it was very close.
Maybe I should make the range of the scan smaller.

Does this also happen (jumping back to old transponder) if it was
further away, or does it then jump to a close by one?

 
 > In addition, if, for example, I tune to an active transponder at 10959v, and 
 > then try to tune to an active transponder at 10966v, then the tuner refuses 
 > to move from 10959v.  Is this due to a kind of auto fine-tuning in the driver?
 > 
 > Also, it is now taking longer for the QPSK_COMPLETION_EVENT to arrive, which 
 > slows down frequency scanning.  I understand that this is how it should be, 
 > but can anyone suggest a way to perform a fast channel scan with the latest 
 > driver?  Can I just ignore those events whilst scanning and use a short 
 > usleep instead?

Yes, if you re-tune when the old tuning process did not finish yet
(i.e. did not send a message yet) this aborts the process and starts
a new one.

I expected that this kinds of problems would show up.
Some read the API in such a way that the driver should handle the
zigzag scan and fine tuning (which I now implemented), others want
direct control because it is much better for scans.
In the old API I had a flag for that (AFC flag). The new API provides
a call which should return the recommended step size for a scan. The
frequency range around the step size should then be searched by the
driver or the hardware. Since every DVB demodulator has its own way of
frequency correction and search I think this should be handled in
the driver. It is just not so easy to figure out and control the right
step size since it can depend on symbol rate, frequency and used hardware.



Ralph




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