[mythtv] Ticket #1049: DVBSignalMonitor needs to be able to monitor NIT/SDT

[Yeasah Pell]

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.
>
>-- Daniel
>
>_______________________________________________
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>  
>
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)

Ugh.