[linux-dvb] how to exactly tune a carrier
abraham.manu at gmail.com
Sat Oct 6 13:08:46 CEST 2007
Jeremy Hall wrote:
> the problem
> I have set inversion to auto, FEC to auto, and the frequency to the correct value for the carrier. I want the driver to scan the values I provide within a 1khz tolerence for all FEC choices and both spectral inversions. I don't know how long that takes but I'd like it for obvious reasons to go as quickly as possible. Since I don't know how long this takes, I decided to sleep for a few seconds then read status to determine if FE_HAS_LOCK so I can stop.
> To my horror, I discovered, by running dvbsnoop -s feinfo in another window, that not only were my symbol rates different than my suggested values, but the frequency was different as well. In fact, I noticed that if you wait long enough, you can lock onto a neighbouring signal that isn't even the one you wanted, and the frequency reported is something in the middle but closer to what you want, yet clearly it is the other signal, for example, two DSNG carriers are located at 12116 and 12121 respectively, with a symbol rate of 3979. At first I thought my LO was wrong, but try to lock the first one, wait about 8 seconds and then the second one magically locks even though I didn't want that one.
I have seen the similar problem. Although David Woodhouse <dwmw2 at infradead.org>
was the first person to point out a very similar issue (a little while back), except that he
was getting LOCK's on to the nearby transponders rather than the one he wanted to
LOCK, the only difference in your case and his case was that he was trying to LOCK to a
normal transponder (where no DSNG slot's were involved, i guess)
To make his life easier, i guess he chose another card (demodulator), which worked properly
which doesn't use the frontend zig-zag.
After quite some eyeballing, myself also came to the same conclusion. Because of this, for
the demods that i use, i decided not to use the dvb_frontend's swzigzag.
I had accidentally, tripped on this issue when i was working on a demod which didn't use the
step based method which is used normally be standard demods, but a ramp  method.
Both methods have their own advantages and disadvantages, though.
Although not much of a concern, it was argued by Johannes Stezenbach <js at linuxtv.org>
in another previous thread that the current frontend swzigzag is appropriate and probably
Anyone else having dvb_frontend swzigzag blues ?
More information about the linux-dvb