This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9196 - Fine-tuning some FM tuner constants
Attached to Project:
Rockbox
Opened by Christopher Williams (christop) - Tuesday, 15 July 2008, 20:51 GMT+1
Opened by Christopher Williams (christop) - Tuesday, 15 July 2008, 20:51 GMT+1
|
DetailsIn Rockbox on my Sansa e280, in the US, all FM radio stations come in clearer when I tune to about 0.05 MHz higher than the station is "supposed" to be. For example, the station 94.5 comes in clearer at about 94.56 MHz. In the OF, the station comes in clearly at the correct frequency.
I dug through the FM tuner driver for the lv24020lp and discovered a constant "magic" value of 16 subtracted from duration*1000 as the argument to udelay(), but this constant is not explained. It appears to me to be there to offset any overhead incurred (I'm probably wrong about this). I changed the constant to different values and realized that it changes what Rockbox reports the FM frequency to be. After some experimenting, I found that the value 24 or so results in the frequencies being closest to what they should be for almost every station. (In reality the reported frequency dithers around this frequency but generally stays within 32 kHz on either side of it). A couple of stations still come in clearest about 0.02 MHz higher, but I'll just assume that those stations really are broadcast at slightly higher frequencies. Also, I changed the stereo decoder (SD) frequency from 38.3 kHz to 38.0 kHz, as this is the frequency I think it's "supposed" to be. I have no idea why it should be 38.3 in the first place (besides the AN2400S04 application note mentioning that frequency). I'd like someone smarter than me to tell me why. :) Disclaimer: this patch is of the "it works for me" variety, and it might affect the other reported frequencies, such as the IF and SD frequencies. Also, there's probably a better and "cleaner" way to fine-tune the frequencies reported by the driver without the use of magic values, but I am not familiar enough with the driver to make such changes. You Have Been Warned. 
lv24020lp.c.diff
(1.3 KiB)
|
This task depends upon
Regarding the magic value of 16, I think that is indeed compensation for overhead, but I can imagine that the overhead is not a simple fixed number because the processor frequency can change.
The application note mentions another, probably more accurate, method of measuring the frequencies with the use of counter 2. This does require an external clock into the external_clock_in pin though. I think it is interesting to find out if anything is connected here. Maybe I'll try that out this week.
The magic value _is_ just an guesstimate of the overhead time of communicating with the chip. We're aiming for tuning to +/-16kHz; being more precise just slows it down too much because of huge delays. AFC will finish the rest and can adjust it by several-hundred kilohertz. The fact that AFC can lock a signal and adjust the tuning by a huge margin (tested and confirmed) so I can't see why the minor error would affect final tuning to a noticeable extent since it's automatic. I might expect more effect on scanning reliability.
I did some figuring and a delay offset of 8uS does give a measurement error of about the magnitude you report. I'd like to using the internal measurement counter but a 32kHz clock doesn't seem to be present on the pin (??) - it just hanged waiting for the ready signal. It would be more accurate and could yield during measurement. Maybe I just messed up.
The stereo decoder clock is supposed to be _set_ to 38.3kHz. The specification was changed in REVISION HISTORY V0.4 (p. 3) and was unexplained by Sanyo. They're the one's that did the tuner design afterall and I felt it best to follow what was layed out.
I'll test this out anyways when I get a chance.
Regarding the magic value, I also kind of figured that my new magic value is also a guesstimate and that the overhead can vary depending on CPU clock speed. That's the reason for the disclaimer. I made this patch partly to scratch my own itch and partly to bring this to the attention of the developers of the tuner driver. Of course I now realize that the second part is redundant because you guys are already aware of the timing issues.
Now I'll go work on fixing more (actual) bugs...
There seems to be a few seconds where RB is a little off and AFC drifts it to the correct frequency. The main difference in retailos that makes reception better though is that it seems to either idle the processor at a lower frequency or shuts something off that rockbox doesn't. I have noticed similar reception quality between OF and RB until the backlight goes off with OF where noise in the signal will suddenly disappear. This device isn't really a champion of clear reception with either firmware (very noisy design).
One thing that needs proper implementation is the station scanning and it should be noted in the file with a "TODO" iirc. Right now it's using signal level but that isn't really the proper way. I didn't really feel like doing that after being a big part of the initial work of getting the tuner working(lazy I guess :).
One thing I can imagine to improve accuracy is to actually measure the length of the delay period (if possible). Apparently on PP, there is a microsecond counter (which already gives a pretty accurate delay), we could read that just after changing the NRW line to get an even better idea how long the delay lasted.