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