[mythtv] [mythtv-commits] Ticket #2060: US cable frequency tables incorrect
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
> 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)
> - 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.
More information about the mythtv-dev