Alan Gonzalez wrote:
On Tue, 7 Dec 2004 15:37:33 -0500, Hiroto Shibuya <[EMAIL PROTECTED]> wrote:And, interestingly enough, is almost exactly the difference between the US Cable and US Cable HRC frequencies (they're actually 1.25MHz)... (Are you sure you're using the right frequency table?)
Dan Ferris writes: > Was this a trial and error method, and do you have the tuner type 50?
Yes, and yes (type=50). I have no clue what those numbers means. I just added trace codes where frequency setting was taking place, observed what was being set when I set the frequency 1Mhz off (which was painfully figured out by try and error)
Because the tuner driver sets the frequency using a 62.5kHz frequency step. 62.5kHz/step * 16steps = 1MHzand noticed that a particular data was off by 16.
And, I would have commented a long time ago, but I'm a bit behind on my newsgroups--232 IvyTV messages and 8620 MythTV messages to go... Work has been getting in the way of my fun!Michael Dean could comment further on this, since he worked on thatThat value in the table was being added to whatever calculation it was doing so it was a convenient place to make an adjustment. I'm hoping a developer can implement a right fix given this info.
Hiroto
config line from the actual Tuner Specifications Document.
The value for the IFPCoff (the last value of the tunertype struct) should be 732 for all NTSC-i (i.e. US) tuners. It is the picture intermediate frequency defined by the NTSC specification and is used in the calculation of the program divider bytes which are sent to the tuner to request a channel change.
The value 732 comes from the fact that we are using a step size of 62.5kHz in the Linux tuner driver:
45.75MHz * 1step/62.5kHz = 732 steps
or, since 1step/62.5kHz = 16steps/MHz,
45.75MHz * 16steps/MHz = 732 steps
That being said, I will admit that there is one place in the driver (not the tuner definition, though) where we may need a small modification. I haven't yet tested the change because--based on the other 48 tuner types defined before the ones I worked on--it's extremely unlikely to be required. If it is required, it almost definitely should have been implemented for many of the other tuners, but that's another project... The change may affect the oscillator--and, therefore, the tuning quality.
To find out for sure, I need some volunteers who are using RF modulated (i.e. cable or broadcast--not S-Video or Composite) input, are certain they are using the correct frequency table (i.e. broadcast, us-cable, or us-cable-hrc), and have already successfully compiled a patched tuner module--regardless of whether they are pleased with the quality of picture--to test a change for me. Volunteers using both tuner type 47 (LG TAPE) and 50 (TCL 2002N) are appreciated... Volunteers, please send me and e-mail (with ivtv in the subject) and give your kernel version and tuner type.
Thanks.
Mike
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
