[mythtv] [mythtv-commits] Ticket #2060: US cable frequency tables incorrect

Daniel Kristjansson danielk at cuymedia.net
Thu Jul 20 11:48:55 UTC 2006


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. 
> During this I noticed that T-7 through T-14 are incorrect according to 
> http://www.jneuhaus.com/fccindex/cablech.html, which agrees with the 
> listing provided by the bug reporter ( 
> http://www.atxnetworks.com/qrf/catvfrq1.htm ) (although my URL provides 
> a value for T-14, and the reporter's URL skips it).

Ok, if you make a patch I'll apply it. Please include a couple sources
for any changes if you can. I've noticed a lot of inconsistency in what
google turns up. (Or reference an official ANSI/ISO standard).

> If we do make changes, I recommend we:
>     - fix the T band frequencies in ntsc_cable (standard)
Yep

>     - fix the HRC and IRC lists to remove the T-band channels (HRC and 
> IRC standards don't define a T band)
Hmm, yes I didn't add these to the digital HRC/IRC, but feared changing
the analog tables. But we should just nix them.

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

>     - 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. Perhaps we could just fix the
channels referencing the tables? Again how far of are these? The bttv
driver/hardware does not appear to use the PLL much to automatically
fix the frequency. 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.

> 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.
These small tweaks will probably do nothing except maybe speed up
tuning by an imperceptible amount.

-- Daniel




More information about the mythtv-dev mailing list