[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 
>>incorrect. 
>>
...

>>    - (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))

See 
http://frwebgate.access.gpo.gov/cgi-bin/get-cfr.cgi?TITLE=47&PART=76&SECTION=612&TYPE=TEXT 
for 47CFR76.612.

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 
T-band channels.)

>>    - 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?
>

(see above)

> 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 
after 0.20.)

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.)

Sorry about the verbosity...

Mike


More information about the mythtv-dev mailing list