Rockbox

Tasklist

FS#7562 - FM Radio Quality

Attached to Project: Rockbox
Opened by Terrence (terrence1019) - Wednesday, 08 August 2007, 21:58 GMT
Last edited by Bertrik Sikken (bertrik) - Sunday, 17 April 2011, 10:34 GMT
Task Type Bugs
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 1
Private No

Details

Is there any way to increase the quality of the FM Radio tuner for the e200? My unit continually is unable to lock unto some stations, that have even strong frequencies.
This task depends upon

Closed by  Bertrik Sikken (bertrik)
Sunday, 17 April 2011, 10:34 GMT
Reason for closing:  Remind
Additional comments about closing:  Probably has been fixed by now. Please let us know if it continues to be a problem.
Comment by Terrence (terrence1019) - Wednesday, 08 August 2007, 22:01 GMT
The FM Radio is very buggy.
Comment by Michael Sevakis (MikeS) - Wednesday, 05 September 2007, 08:41 GMT
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.
Comment by Terrence (terrence1019) - Thursday, 06 September 2007, 02:41 GMT
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.

Comment by Michael Sevakis (MikeS) - Thursday, 06 September 2007, 13:05 GMT
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. :)
Comment by Terrence (terrence1019) - Friday, 07 September 2007, 03:48 GMT
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?
Comment by Michael Sevakis (MikeS) - Sunday, 09 September 2007, 06:01 GMT
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?
Comment by Terrence (terrence1019) - Monday, 10 September 2007, 04:42 GMT
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.
Comment by Terrence (terrence1019) - Monday, 10 September 2007, 04:43 GMT
I won't mind testing when you get into the mood.
Comment by Terrence (terrence1019) - Tuesday, 06 November 2007, 09:12 GMT
"e200/c200: Take advantage of mutex recursion for the tuner driver and dump the awkward *_nolock stuff"

Good work
Comment by Michael Sevakis (MikeS) - Wednesday, 07 November 2007, 04:17 GMT
: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. :)
Comment by Venkat Raghavan (robotgeek) - Saturday, 13 September 2008, 07:43 GMT
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.
Comment by Michael Sevakis (MikeS) - Saturday, 13 September 2008, 20:30 GMT
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.
Comment by Venkat Raghavan (robotgeek) - Sunday, 14 September 2008, 03:17 GMT
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)
Comment by Terrence (terrence1019) - Sunday, 14 September 2008, 03:23 GMT
These are some interesting developments!!
Comment by Bertrik Sikken (bertrik) - Friday, 16 July 2010, 23:05 GMT
Recently FM frequency measurement has been improved for this chip (SVN r27042), I propose to close this task.

Loading...