Rockbox

Tasklist

FS#9196 - Fine-tuning some FM tuner constants

Attached to Project: Rockbox
Opened by Christopher Williams (christop) - Tuesday, 15 July 2008, 18:51 GMT
Last edited by Michael Sevakis (MikeS) - Tuesday, 22 June 2010, 07:38 GMT
Task Type Patches
Category FM Tuner
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

In 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.
This task depends upon

Closed by  Michael Sevakis (MikeS)
Tuesday, 22 June 2010, 07:38 GMT
Reason for closing:  Fixed
Additional comments about closing:  As of r27042, considering it fixed.
Comment by Bertrik Sikken (bertrik) - Tuesday, 15 July 2008, 22:17 GMT
Hmmm, if the application note says to use 38.3 kHz instead of 38 kHz, I think we better just do it. Probably the chip designers found out about some peculiarity or bug that requires this.

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.
Comment by Michael Sevakis (MikeS) - Wednesday, 16 July 2008, 00:29 GMT
Hello Christopher,

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.
Comment by Christopher Williams (christop) - Wednesday, 16 July 2008, 17:48 GMT
Bertrik, Michael: Thanks for the responses. I suppose you're both right about the 38.3 kHz stereo decoder clock; it is probably due to some minor inaccuracy in the IC that they changed it to 38.3 (perhaps the Sanyo engineers measured the actual frequency and found it to be closer to 38 kHz when it is _set_ to 38.3 kHz by the software, so they put that in the application notes). Either way, it doesn't seem to affect clarity of the stereo signal. I just thought it was a strange value, and I was being pedantic about it. Besides, I thought that a receiver was not supposed to depend on an internal clock source for the 38 kHz carrier frequency but instead rely on the 19 kHz pilot tone in the signal and simply double the frequency of that to derive the 38 kHz stereo signal. I guess this shows my inexperience with real-world FM radio receiver design.

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...
Comment by Michael Sevakis (MikeS) - Thursday, 17 July 2008, 18:28 GMT
Christopher,

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 :).
Comment by Bertrik Sikken (bertrik) - Monday, 28 July 2008, 21:27 GMT
I tried to measure if any external clock is present (using the radio chip's counters) but found nothing (f=0). Amazing really how all of the FM tuning is basically calibrated by this one delay statement.

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.
Comment by Jonas Häggqvist (rasher) - Saturday, 08 August 2009, 16:05 GMT
I just noticed this while testing  FS#9824  on my e280 - my ears tell me that tuning to +0.05MHz sounds better than the actual frequency.

Loading...