Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Dave Chapman writes:
 > On Tuesday 24 April 2001 10:45 am, Ralph Metzler wrote:
 > >  > 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.
 > >
 > 
 > The channels on my test satellite (31W) can be as close as 7 (MHz?) (e.g. 
 > 10959v and 10966v), and I rarely get a signal lock +- 1 from the actual 
 > frequency (with older CVS drivers).  This is probably the exception and 
 > "mainstream" satellites would work fine with your current code.
 > 
 > > Does this also happen (jumping back to old transponder) if it was
 > > further away, or does it then jump to a close by one?
 > 
 > Yes, it seems to.  When I was testing it this morning, only one transponder 
 > was active on the satellite, and any frequency (e.g. +-200) seemed to leave 
 > the tuner locked on the old transponder.  What is your current "zig-zag" 
 > range?

+/- (10/16)*Symbolrate which is about 3.52 MHz at the symbol rate 
of 5632 you mentioned. So this should not happen.
I'll have another look at the code.

 
 > > 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.
 > 
 > I agree with that - the driver should try to make all the hardware look the 
 > same.  I'll help all I can on various satellites.  For now, would it cause 
 > any problems if I set the AFC flag to 0 in dvb.c ?

No, but it does not do anything right now ...

You can change the "(i==20)" to "(i==1)" in mon_zigzag() in dvb.c to get the 
old behavior.

 
 > On a related topic, do you have any suggestions about searching for 
 > transponders with unknown symbol rates?  Are some tuner chips (e.g. old/new 
 > Hauppauge) better than others when it comes to locking onto a signal with the 
 > wrong symbol rate?  Can you suggest a (hopefully small) list of symbol rates 
 > that I could try to identify if there is a signal on a particular frequency?


I did not really do much testing with scanning recently. On the
mainstream satellites you can get almost everything with 27500 and
22000 but I have seen many odd symbol rates on other sats. 


Ralph



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



Home | Main Index | Thread Index