[mythtv] [mythtv-commits] Ticket #2060: US cable frequency tables incorrect
Michael T. Dean
mtdean at thirdcontact.com
Fri Jul 21 17:22:24 UTC 2006
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:
>>>#2060: US cable frequency tables incorrect
>>>Comment (by danielk):
>>>I mostly used the frequencies in frequencies.c to build the table.
>>>The T-# channels did disagree with the ones in the URL you referenced. One
>>>of them has to be wrong...
>>Yeah, Daniel, I think the ones defined in Myth's frequency tables are
>> - (no matter what we decide about "fixing" frequencies in HRC and
>>IRC) leave ntsc_cable frequencies (other than T band) unmodified (since
>>we've chosen the value from which cable companies are required to offset
>>and since some companies use a positive and others use a negative
>>offset, we can't make it academically-correct without making two
>>frequency tables for standard)
>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".
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.
- Channels in the radiocommunications bands, those between
118-137MHz (14-16), 225-328.6 MHz (25-41), and 335.4-400MHz (43-53),
must be offset by 12.5kHz from 25kHz-spaced channels (47CFR76.612(a))
- Channels in the radionavigation bands, those between 108-118MHz
(98-99), and 328.6-335.4MHz (42), must be offset by 25kHz from
50kHz-spaced channels (47CFR76.612(b))
Therefore, channels 14-16, 25-41, and 43-53 are off by 12.5kHz; and
channels 42, 98, and 99 are off by 25kHz. The only problem is that we
don't know in which direction they're off. Creating two frequency
tables for ntsc_cable (i.e. ntsc_cable_positive and ntsc_cable_negative)
forces the user to know the difference to choose the right one.
However, even if they choose the wrong one (thereby getting a 50MHz
difference on 42, 98, and 99), the tuner module hardware might find the
appropriate center frequency, anyway (see below for hardware fine-tune
discussion). There is one possibility (that I'll mention below) that
may make doing both frequency tables worthwhile.
(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
>> - ignore all the frequency "fine-tuning" in HRC and IRC. (Modifying
>>these values would--if nothing else--make the finetune values some users
>>have specified in the database "incorrect" since they'd be applied to
>>different frequencies, and in the worst case could cause tuning issues
>>for some users who have specified finetune values.) Since the
>>hardware's fine-tuning algorithm should take care of all the
>>discrepancies we have, it's not, IMHO, worth the risk of breaking things
>>(which is why I didn't make the IRC values academically correct when
>>updating a 0.18.1 patch to work SVN--the values were tested by the guy
>>who did the first patch and I couldn't test the modified ones, so it was
>>better to leave them).
>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.
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
Currently, all our (NTSC-M) frequencies (Myth represents them in kHz)
divided by 1000 (to get MHz) and multiplied by 16 (to get "tuner steps")
(or, divided by 62.5kHz/step) give integer values with no remainder (all
NTSC-M frequencies in Myth are multiples of 250kHz), and our values
correspond to the frequency step below the "academically-correct"
frequency. Therefore, since 25kHz is 0.025MHz and 0.025 * 16 = 0 (after
truncating) and even 40kHz = 0.040MHz and 0.040 * 16 = 0, if the largest
offset truly is 40kHz, we're not changing the tuning process at all even
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.
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...
However, depending on how frequencies are handled by the drivers, there
may actually be a difference between the NTSC standard cable with a
positive offset and with a negative offset. Since the "middle"
frequency is an exact kernel module tuner step, if we subtract some
amount (12kHz or 25kHz), then divide by 62.5, then truncate, we'll end
up with one tuner step less than if we don't subtract. However, a
frequency table with a positive offset is identical to the current
frequency table from the kernel tuner module's perspective.
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.
> Perhaps we could just fix the
>channels referencing the tables?
I'm not sure what you mean by this.
> Again how far of are these?
> 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.
>But the bttv tuner is only accurate to within about
>16.5kHz, which explains any +/- 8.25 kHz discrepancy in this table
>which was designed for this driver/hardware.
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.
>>correct, though, we could also do the frequency fine-tuning. Note,
>>though, that I've never actually had someone willing to test the new
>>frequency tables (giving them the option to use them has always been
>>enough to convince them it's not the frequency tables ;). Finding
>>someone to test the corrected frequency tables will likely be the
>>biggest challenge (unless we commit first and revert if necessary :).
>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
At least changing the frequencies would prevent bugs/comments/posts like
(BTW, anonymous did his math wrong. The frequencies are off by 12.5kHz
Sorry about the verbosity...
More information about the mythtv-dev