[mythtv] Ticket #1049: DVBSignalMonitor needs to be able to monitor NIT/SDT
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