[mythtv] Ticket #1049: DVBSignalMonitor needs to be able to monitor NIT/SDT
yeasah at schwide.com
Wed Jun 7 03:55:12 UTC 2006
Daniel Kristjansson wrote:
>On Tue, 2006-06-06 at 22:44 -0400, Mark Buechler wrote:
>>I would agree with you. From my experience, either the Linux DVB
>>drivers or the hardware itself attempts to tune in increments + or -
>>the requested frequency in order to get a lock, many times going too
>>far and hitting adjacent frequencies.
>You need to report this to the DVB mailing list. The DVB drivers'
>auto-de-tuning "feature" is a serious bug which needs to be fixed.
>The hardware does a little PLL on the signal, which is fine, but
>some of the drivers try to one up this by doing their own frequency
>walk, this is a very bad idea because it leads to the type of
>problem you are describing.
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
Actually, many cards do much more than a little PLL, and there's a good
reason -- LOF error on LNBs can be significant (easily greater than your
tp spacing -- remember, it's some consumer quality ~10GHz oscillator
powered by some dodgy PCI card's power supply connected by a long piece
of coax in conditions which are alternately hot and cold, dry and wet),
so a zigzag frequency walk sometimes needs to happen.
Some cards do this automatically (usually playing rotator tricks in the
demodulator instead of actually moving the tuner), but for those that
don't, the dvb-core implements it in software ("swzigzag"). Ordinarily
this is fine (if annoying, but there's not much one can do about
drifting RF oscillators), but when you combine the search with a moving
dish, that's when things go wrong. I think the answer is just to tune
after the dish has stopped.
I don't think very many frontend drivers disable swzigzag by default,
but for cards with adequate acquisition capability software zigzag can
be effectively disabled with module parameters. The functionality is not
part of the drivers, but rather part of the dvb core (though its
behavior can be modified by the various drivers), so it's actually
issuing retuning commands by proxy, just as if the application was doing it.
Basically swzigzag doesn't start until a timer has expired. This timer
is painfully short by default, but can be set by giving the dvb-core
module a dvb_override_tune_delay parameter (which is in milliseconds)
For example, I have in my modprobe.conf:
options dvb-core dvb_override_tune_delay=30000
which essentially disables it, since it won't start the swzigzag
nonsense for 30 seconds.
While I was patching the heck out of the cx24123 frontend driver to get
tuning and diseqc to work, I asked some questions on the dvb list about
swzigzag (it was *really* shafting the cx24123, because it would retune
faster than the card could lock, thus preventing any lock from happening
until much later when swzigzag kicked into slow mode), but nobody had
anything to say about it. The cx24123 demod does do its own search, so I
set the cx24123 registers to search in a conservative range, and then
disabled swzigzag with the module parameters.
And then there's the dst frontend cards, which are totally different
again -- the tuning there is one-shot, takes a few seconds to time out
while the card itself madly scans frequencies for the signal, and then
fails completely, never to lock again until another tuning request is
made by the app. I have one of those too. It has other cute "quirks",
like not being able to change the LNB voltage without issuing a tuning
request (which of course may cause a multi-second delay while the card
does its searching business)
More information about the mythtv-dev