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

Manu Abraham abraham.manu at gmail.com
Fri Jun 9 01:01:28 UTC 2006

Daniel Kristjansson wrote:
> On Thu, 2006-06-08 at 21:57 +0400, Manu Abraham wrote:
>> Are you saying that you loose a FE_LOCK due to LNB LO drift ?
>> AFAIK, swzigzag is used only once for acquiring a LOCK, once acquisition 
>> is complete, it does the tracking by itself. Newer devices, don't do 
>> swzigzag too..
> The swzigzag problem was encountered by Yeasah. As he described it
> swzigzag kicks in before the rotor has finished pointing the dish
> and gets hopelessly lost. We were pondering disabling swzigzag,

The problem with disabling swzigzag is that, ATM you will face tuning 
problems, as the devices won't tune properly.

> but the worry was that if we did LNB drift would mean that we
> would need to re-implement swzigzag. My belief was that LNB drift
> would be small enough that the PLL could adjust for it. Allan's
> data backs this up, but Yeasah pointed out an LNB that has a 
> +/- 3 Mhz temperature drift according to the data sheet.

Well, for normal LNB's the oscillator is stabilized by a TCXO 
(Temperature Compensated Crystal Oscillator). It is a 4 pin crystal that 
has an oven (the voltage to the oven controls the temperature, and the 
voltage in normal cases will be inversely proportional to the ambient 
temperature, thereby it try to makes the ambient temperature for the 
quartz bead more or less constant, within a certain range), compared to 
a 2 pin quartz crystal, and LO stability is rated at a typical +/- 1MHz. 
There can possibly exist hopeless LNB's that i am not aware of though. 
Most of them are stabilized at a certain temperature. The TCXO takes 
care to a certain temperature range.

These drift values are quite small compared to the VCO 's frequency 
range and thus it can track these changes quite easily and they are even 
rated with quite a good FOS (Factor Of Safety)

Most of the simple PLL's are supplied with a clock of 4MHz, and for 
these that could be the maximum variation that which it can lock on to. 
As an example , for the STV0299, The VCO’s loop filter is optimized for 
a reference frequency between 4 and 8 MHz.

> Fixed LNB frequency error should not be a problem since MythTV
> saves the tuned frequency during the scan for drivers/hardware
> that support it.

For some new devices, the frequency that which it will lock will not be 
the same as the frequency that which you would have asked it to lock. 
These are handle by new devices in their algorithms such as carrier 
width calculation and carrier centering etc.

Anyway, i can't see anyway in which this can affect any userspace 
application, because of the same reasons explained.

> A further thing to add is that Yeasah found out that his device
> supports hardware zigzag and he has some patches to the driver
> that will avoid the problematic swzigzag altogether. But other
> devices which do use swzigzag could still be a problem.
In fact, there are 3 types of drivers

(1) dumb devices (no intelligence)
(2) device that are hardware assisted
(3) completely hardware driven

(1) To make it quite easy there are no real dumb devices that i know 
(maybe some devices do exist, i don't know). The dumb devices that are 
out there are bad drivers that which have been there due to insufficient 
information etc from the vendor or due to other technical reasons.

(2) Most devices support some sort of hardware assistance in some way or 
the other. if you disable zigzag on these, they won't tune properly, as 
they are a part of the tuning algorithm recomended internally.

(3) On these devices, you cannot disable the tuning algorithms at all, 
as these are done in hardware and there will be no possible way of 
disabling them. The only way it can be disabled is to make it a dumb 
device, but no sensible person would follow that idea to throw away all 
those features. But again making it dumb, you will have a lot of 
problems in tuning as you will have to tell the device the "exact 
frequency" that which you need to tune.

Additionally, we will be implementing advanced algorithms to the devices 
(at driver level) that which do not belong in (1) but they belong to (1) 
because of insufficient data, but there are enough ideas/efforts to make 
them into category (2) make them better. But these routines are meant 
for use only at the driver level (since these are device specific each 
of them) and "not meant for consumption by userspace applications".

So a while later, in the longer run many devices might not support 
swzigzag, but only (2).


More information about the mythtv-dev mailing list