Rockbox

The FM Radio is very buggy.

Processor activity can interfere with stations even in the OF. Something it does when idling in it's radio screen strenghthens the receptions on some stations but I've no idea atm what it's doing exactly. I've tried the idle frequency in rockbox with no change. The biggest problem really with FM is that scanning isn't implemented properly yet but the sensitivity when tuned to a particular frequency is never reduced. It's always whatever the radio chip is able to receive.

So the issue is scanning, and not sensitivity.

Is it something to do with the Sanyo Radio chip being more software-based?

I definitely appreciate your efforts, Michael, for investigating this for me. Thank you very much.

You're welcome.

When I did finish up work on the radio driver it was quite involved and I was satisfied enough that it could tune quickly and generally behave with Rockbox. Getting scanning perfect would be another whole project in itself so I just did a quick implementation that checks signal level (one that worked well enough for me in US/Canada) and left it at that for the time being with a TODO: to actually do a good implementation. None of the radio drivers really implement the scanning in any sophisticated manner and why? Because it's quite a bugger and even all the OF I've checked can barely get it right. There's also the fact on the Philips chip that what works absolutely perfectly in my region is completely ineffective in the Europe region. I doubt the situation is exactly the same with the Sanyo chip but yeah, it's quite a bit more software-driven than other ICs and the readings of the IF Sanyo suggests seem to never be quite stable nor in the tolerances given. A good deal of the code in SVN based off their suggested algorthms but modified to actually function. Nothing they said to do worked as given-- just to give an impression of what lies in wait. :)

Thanks for the full explanation. But sophisticated scanning implementation sounds like a lot of work to do alone. Especially with the IF values. How can I help?

You can implement it :). The chip datasheet is around here somewhere.

If noone gets to it, when I'm in the mood to go back to that (and this stuff takes a mood for alot of messing around) I'll ask for testing for sure.

What FM region are you in?

Lol... well that's the funny thing. Even though I live in the Caribbean, hence I should use the Americas FM Region, I find myself using the European FM setting because my country (Trinidad and Tobago) requires the 0.05 MHz values.

But I find what you say very interesting: If the OF of some DAPs can't even get it right, but you come along and do get it right, that would be a major achievement.

From observing the IF values, I think the trick is to get them to lock on to a stable frequency.

I won't mind testing when you get into the mood.

"e200/c200: Take advantage of mutex recursion for the tuner driver and dump the awkward *_nolock stuff"

Good work

:D :o :?

It's just a using a newer capability of the threading and the things being done to avoid double-locking by the thread that already owned a lock were just making messy hacks like having two version of a function or using multiple locks when one will suffice. Nothing fancy. :)

I looked at the application note, and it recommends muting the audio while tuning. I have attached a patch for this. I have also enabled the tuner logging, which should probably be turned off if this works.

Tuner muting is already done at the top level for all tuners before changing frequencies (see apps/recorder/radio.c). With or without it, it never made any difference nor would I expect it to do so.

Edit: I'll provide evidence that it makes no difference because next_present doesn't mute it but scanning and free-tuning do and I get no different a result.

I believe you! I was just wondering cause the app note said to do so, and we are doing it anyways. I'll look around for other interesting tasks to finish.

(I think this can be achieved from the tuner logging functions. I will do the same, and we can probably compare results. Maybe the behavior is location based)

These are some interesting developments!!

Recently FM frequency measurement has been improved for this chip (SVN r27042), I propose to close this task.