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

[Mark Buechler]

It was actually the dst based Twinhan cards I had the most trouble with. In
correction, the Genpix 8psk module behaves like the Nexus in that it works
well with rotors and tuning.

Once the new DiSEqC stuff goes in, within the new tuning process after the
rotor is estimated to be at its desired location, and the tuing code
retunes, I think we should retune every few seconds until a lock is gotten.
Given how the dst based cards behave, if we don't retune several times then
we're very highly dependant on rotor movement speed estimates.

- Mark.

On 6/7/06, Yeasah Pell <yeasah at schwide.com> 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
> >shift and you can do this cheaply (<$5) with a quartz crystal, a
> >clock multiplier and some analog electronics. The voltage doesn't
> >matter much as long as you get something like +5 Volts and the quartz
> >is stable +/- 60 degrees Centigrade. If you are really cheap (<$2)
> >the crystal will have a constant error which could be easily compensated
> >for. With the $5 electronics the shift will be < 100 kHz, with the $2
> >electronics you will need to compensate in the card or software, but
> >we're talking <1 Mhz, not 3+ Mhz... I realize some of the LNB designers
> >might be uneducated cut-n-paste hacks, but still I can't see anyone
> >trying to get this circuit to work in an open loop; the only way you
> >could really screw it up enough would be to cut-n-paste a 50K
> >terrestrial transmitter circuit diagram into your LNB design.
> >
> >
> Heh, never underestimate the cornercutting of cost reduced electronics
> -- economies are such that saving pennies or sometimes even a fraction
> of a cent is the "right thing" to do even if it significantly
> compromises some aspect of the product. I've seen designs come out of
> cost reduction with what looks like random parts missing, and it really
> seems like part of the process is often "keep removing parts until it no
> longer passes these tests." Ridiculous.
>
> I'm not sure what oscillators modern/cheap LNBs use -- they used to
> generally use DROs I think. But some manufacturers spec their drift --
> Invacom, for example, specs a +/- 3MHz drift at temperature extremes for
> many of their LNBs. Mine is better than that, +/-1MHz. But you can bet
> there are worse LNBs out there, especially the mass produced integrated
> units.
>
> Nevertheless, I think you're right that the swzigzag stuff probably goes
> way too far in its searching, and in any case it is just totally
> inappropriate when you have a card whose tuning range is already wide
> enough to handle LNB drift (or if you have a well made LNB that doesn't
> drift much for that matter)
>
> >
> >
> >>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 can see that, if you think it is wise I'll reapply the hack until
> >your stuff is done...
> >
> >
> I don't have any particular desire for it to be reapplied, but if you
> have some time at some point to consider how the signal monitor, et. al.
> will interact with the new device tree stuff to accomplish retuning (as
> well as OSD status for rotor position information), that'd probably be a
> good conversation to have sometime soon before I make any bogus
> assumptions.
>
> >
> >>For example, I have in my modprobe.conf:
> >>options dvb-core dvb_override_tune_delay0000
> >>
> >>
> >Ugh, I was hoping for an override in the API.
> >
> >
> Actually, now that you mention it, I think Andrew did get something like
> that in -- SET_FRONTEND_TUNE_MODE or something like that, which allows
> you to totally disable the software retune stuff. That would basically
> make all cards behave like the dst -- so you'd have to watch your signal
> and manually retune if you lost lock, etc. But at least it'd be
> consistent, and no monkey business going on.
>
> It's probably not especially common for people to have a DVB API with
> that option yet, though.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060607/0055cb9e/attachment.htm