[mythtv] [mythtv-commits] Ticket #2060: US cable frequency tables incorrect
danielk at cuymedia.net
Fri Jul 21 18:06:50 UTC 2006
On Fri, 2006-07-21 at 13:22 -0400, Michael T. Dean wrote:
> On 07/20/2006 07:48 AM, Daniel Kristjansson wrote:
> >On Wed, 2006-07-19 at 12:49 -0400, Michael T. Dean wrote:
> >>On 07/18/2006 03:08 PM, MythTV wrote:
> >How far off are these?
> Not far (12.5kHz or 25kHz). Since the kernel tuner module has a
> resolution of 62.5kHz (1MHz/16) when specifying frequency, it all falls
> within "rounding error".
Actually, V4L2 allows you to specify the frequency within 62.5 Hz.
But, most cards only allow you to specify the frequency in 62.5kHz
increments with the V4L2 drivers. I believe our tables were originally
built for V4L1 which always used 62.5Khz increments. I think truncating
the frequencies is wrong, we should really round. But in practice
these values in the table work out after the 62.5Khz conversion.
> Specifically, the FCC requires that the frequency of all carrier signals
> for cable channels operating on frequencies used in the aeronautical
> radiocommunications/radionavigation bands must be offset as described
> below. The FCC doesn't specify any direction for the offset, but a
> positive offset is more common; however, some cable companies may have
> chosen to use a negative offset.
Ah, this is interesting. So theoretically we should have two tables
for regular cable at least. One positive offset, and one negative
offset.. But I think the PLL is good enough for this since most drivers
use a 62.5kHz stepping.
> (The T-band channels are off by 1250kHz (1.25MHz), however, which is
> definitely worth fixing--even though I don't know of anyone who has an
> T-band channels.)
Yup we should fix this before 0.20. The small offsets on the regular
channels I want to have a longer testing period for. Most people
don't get content on T-band channels since they are now mostly used
for out-of-band data; cable modems, guide data, etc. I've never owned
a TV that could tune the T-band channels... But, I'm sure there is
a MythTV user somewhere wondering why he can't get channel T-3...
> >Hmm, I'm not sure about this. I fixed the off by 100 kHz IRC channels
> >in the digital tables when I found them.
> The largest difference I see is in HRC and is only about 40kHz (and I
> just re-checked every channel in ntsc_bcast, ntsc_cable, ntsc_hrc, and
> ntsc_irc). In IRC, it looks to me like every channel is off by either
> 12.5kHz or 25kHz. I'm basing these statements on the frequencies at
> http://www.jneuhaus.com/fccindex/cablech.html , so if you saw a 100kHz
> difference in IRC, our information sources must have different values.
Here's my source: http://www.ipass.net/teara/atv1-frm.html
> Note, also, that even if we modify the HRC and IRC frequencies in Myth,
> the kernel tuner module tunes using the integer number of "tuner steps"
> to represent the frequency. A "tuner step" is 1MHz/16 = 62.5kHz
See my note about 62.5Hz tuner steps..
> if we modifiy the frequencies by these amounts. If, in fact, we are
> ever off by 62.5kHz (1 tuner step) or more (such as the 100kHz you
> mentioned), it's worth fixing the frequencies.
There is also rounding/truncation error. We only need to be a little
off to jump to the next tuner step in either direction.
> Hmmm. I'm starting to wonder if these values were chosen (by whomever
> created the frequency tables) specifically because they provide an
> integer number of tuner steps...
Yup, see my note on this table being originally specific to the bttv
V4L driver which only had 62.5 Hz steps.
> Since most cable companies use a positive offset, it's quite possible
> that users whose cable companies use a negative offset have needed to
> specify a negative finetune for the offset channels (14-16, 25-53, 98,
> and 99) to reliably tune those channels. I would be very interested to
> see what channels users have offset and by what amounts. I'd be happy
> to start a thread on the -users list asking for info (since no one who
> doesn't have to will have read this far in my message :). And, if it
> turns out that negative finetune values consistently appear for the
> affected range of channels, I'll create a patch to add a positive and
> negative version of the frequency table.
I would be good to get some feedback from users actually using finetune..
> > Perhaps we could just fix the channels referencing the tables?
> I'm not sure what you mean by this.
If we change the channel frequency by 25 kHz, maybe we should make the
reverse change to any pre-existing the finetuneing in the DB...
> > The bttv
> >driver/hardware does not appear to use the PLL much to automatically
> >fix the frequency.
> AIUI (IANAEE), the kernel tuner module only seems to /explicitly/ use
> the PLL for the MT2032 universal tuner (type 33). However, I'm pretty
> certain (all?) other tuner module hardware uses a digital programmable
> PLL IC that's controlled through the control data for the tuner module
> hardware (as represented by the tunertype struct in the kernel tuner
> module), and requires an application to explicitly disable the PLL using
> the control data. TTBOMK, none of the tunertypes disable the PLL.
> Therefore, the control data is transmitted to the tuner module when the
> config data is sent via i2c. Then, the tuner module hardware
> automatically uses the PLL IC to lock-in on the appropriate center
> frequency without any application control. I would guess (since I don't
> know how close the frequency has to be for a lock but would assume it
> has to be closer than 62.5kHz), this is why the kernel tuner module can
> get away with using a 62.5kHz step-size for frequencies (i.e.
> 16steps/MHz) and why users have to specify a relatively-large (positive)
> finetune value in Myth to see a real (as opposed to a placebo :) difference.
I think it may just be the step I used. The PLL probably does adjust
within the 62.5 kHz range. When I've put a 100kHz finetune in I've
seen distortion with a WinTV card using a Bt878 (2 steps?). I expected
the PLL to sync to the signal with such a small offset but it didn't.
> Most tuner hardware (all the ones I've seen) allows tuning with a
> programmable step-size of either 31.25kHz, 50kHz, or 62.5kHz. I'm
> pretty certain that the kernel's bttv tuner module only supports 62.5kHz
> steps. See the comment above set_tv_freq() in tuner.c (and the code
> supports the comment's validity). I'm guessing most card drivers,
> however, allow specifying frequencies in other units (such as kHz or
> MHz), so if you only looked at the bttv or ivtv modules, this wouldn't
> necessarily appear to be the case.
AFAIK only 62.5kHz and 62.5Hz is supported by the V4L2 API, actual initial
tuning accuracy could be anywhere in this range (or worse). I believe
the analog tables were constructed with bttv in mind though.
> >We should commit any small tweaking separately from the T-? fixes.
> Definitely. I'll do any of these as separate patches.
> >These small tweaks will probably do nothing except maybe speed up
> >tuning by an imperceptible amount.
> Yeah. As described above, I don't think it will change anything
> (thereby making an imperceptible difference :), but I guess there's no
> real harm in fixing things (as long as someone reports back with a
> thumbs up/down before the release--I have no RF-modulated sources, so it
> won't be me ;). (Or, we can hold off on the fine-tune patches until
> after 0.20.)
I think we should hold off until after 0.20 for these. They are probably
harmless, but I don't want to risk breaking things for this. I'm more
interested in having it correct to avoid problems with future hardware
and to avoid people needing to setup finetune values, and this can
wait until after the release.
> At least changing the frequencies would prevent bugs/comments/posts like
> http://www.gossamer-threads.com/lists/mythtv/commits/164527#164527 .
> (BTW, anonymous did his math wrong. The frequencies are off by 12.5kHz
> in IRC.)
The variability in published tables on this is absolutely maddening.
The FCC offsets you explained probably explains some of it and the
bttv 62.5kHz limitation explains some of it (at least in the software
I've looked at), but the rest of the variability seems unexplainable..
More information about the mythtv-dev