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

[Yeasah Pell]

Allan Stirling wrote:

> Yeasah Pell wrote:
>
>> Allan Stirling wrote:
>>
>>> Daniel Kristjansson wrote:
>>>  
>>>
>>>> I doubt this is as much of a problem as the DVB devs seem to think.
>>>> I actually asked Kenneth Aafloy to chart the LNB drift and get back
>>>> to me, he never did. My EE background is in radio engineering, the
>>>> job of the downconverter portion of the LNB is just to frequency
>>>>   
>>>
>>> ...
>>> I had a spare tuner, so here you go:
>>
> >>...
>
>>> Total swing for this test is 45kHz (0.003%) which is probably not 
>>> significant. Obviously, longer cable runs, worse power supplies, 
>>> cheaper LNBs may give worse figures.
>>
>
>> Interesting figures, thanks for the experiment!
>>
>> For the acquisition search, the rate of change of the LOF is pretty 
>> much irrelevant though, since acquisition happens over a brief period 
>> of time -- it's the total error from the LOF's "correct" frequency 
>> that acquisition has to deal with, since that determines how far you 
>> have to search just to find the signal that you are looking for. 
>
>
> These aren't showing deltas at all - It's just a count of *all* of the 
> frequencies that occurred over a fairly hot day / cool night period.
>
>> 12.226GHz. If you were on that tp:
>>
>> 1.626GHz - 1626758GHz = 758kHz
>>
> Ahem. Apologies. For some reason, I didn't check the actual frequency 
> I was zapping to, preferring to look it up on lyngsat. Indeed, you are 
> correct.
>
>> Which definitely sounds more like it.
>>
>> The long-term LOF drift that you show in the chart is something that 
>> most cards deal with automatically by tracking, but swzigzag isn't in 
>> the picture for that (it only kicks in after acquisition if signal 
>> lock is lost for some period), and the tracking capabilities of cards 
>> presumably are designed only to deal with slow incremental changes in 
>> frequency, so I think it'd be unlikely that tracking would cause 
>> significant detuning.
>>
> Sure - But it shows the absolute frequency that the card believes at 
> the time is the center frequency and also that it does move - But not 
> really significantly, which is what I hoped (And Daniel predicted) 
> would happen.
>
>
> I seem to remember that the 'actual' frequency tuned-to used to be 
> stored on a scan. I'm not too sure if that is present any more from 
> Daniel / Stuarta's -commits list comments. If people are indeed seeing 
> extreme drift, it would possibly tend to be only in one direction. 
> Maybe this is throwing some people's ex-working setups off?

Ah, interesting. I hadn't considered that.

Let's assume that the greatest term in the LNB oscillator error is 
constant and specific to the LNB (that seems likely and your data does 
seem to indicate that the greatest error term is constant, anyway). 
Let's further assume that the LNB offset error is the only significant 
source of frequency error in the system.

By storing the actual frequency reported by the card in the 
dtv_multiplex table, you're basically applying a pre-correction for the 
observed LNB error. So in theory, if you have a card with a demodulator 
that has the capability to detect the frequency offset from the tuner 
frequency and the driver uses that to report the actual frequency, you 
can use this to pre-correct for LNB error, at least for the gross part 
of the error. And if you do that, it's presumably 100% ok to disable 
swzigzag without losing any potential benefit for people with crap 
setups, since any further LOF drift (probably hundreds of kHz at the 
most) will assuredly be within the demodulator's capability to tune 
without external help.

There's some complications, though.

1) Reporting of current frequency is quite uneven in the drivers. Some 
cards simply can't report it, and the drivers just generally report the 
last set frequency. In order to determine whether you can disable 
swzigzag, you need to be able to determine if the frequency you have 
stored is 'actual' or not. But IIRC there's no DVB capability flag to 
test for this. You could (at scan time) turn off swzigzag, attempt a 
tune, and see if the frequency is exactly the same as what you set -- 
that's not 100%, since it could be that the frequency didn't need any 
adjustment, but that's the best I can think of. Of course, there's the 
possibility that the tune would fail altogether without swzigzag on...

2) It would be annoying to have to rescan if you change LNBs just to get 
new frequency values, and worse users probably wouldn't realize they 
needed to do this. Ideally it would have supernatural knowledge of the 
LNB change and disable the code that turns off swzigzag since the 
pre-corrected offsets are no longer valid.