Rockbox

Tasklist

FS#8151 - Signal strength meter for FM radio

Attached to Project: Rockbox
Opened by Przemysław Hołubowski (p.h.) - Tuesday, 13 November 2007, 20:28 GMT
Last edited by Bertrik Sikken (bertrik) - Thursday, 11 November 2010, 21:14 GMT
Task Type Patches
Category FM Tuner
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

The patch adds a line showing signal strength to a tuner's screen. The line looks like this: "Field strength: 54 dBu".

It's for players having TEA5767 or LV24020.

I've tested the patch on my H10. Unfortunately TEA5767 updates its field strength meter register only on station change. I don't know how LV24020 behaves.
This task depends upon

Closed by  Bertrik Sikken (bertrik)
Thursday, 11 November 2010, 21:14 GMT
Reason for closing:  Accepted
Additional comments about closing:  Committed as SVN r28559
Comment by Nikkhil (AceNik) - Tuesday, 04 December 2007, 17:27 GMT
synced to the rev15872
Comment by Przemysław Hołubowski (p.h.) - Tuesday, 04 December 2007, 23:32 GMT
The last version of the patch corrected a bit. Restored polish diacriticals and removed one unnecessary change (see polski.lang).
Comment by Lee Kang Hyuk (alwaysbluepop) - Friday, 14 December 2007, 04:54 GMT
interesting!
works fine on my x5,but poor TEA5767!
however this patch breaks the sim, so fix this.
Comment by Joel Garske (gibbon_) - Thursday, 20 March 2008, 09:12 GMT
I used this patch to create a "Mute weak stations" patch (FS#8764), for anyone who likes the feature.
Comment by Przemysław Hołubowski (p.h.) - Thursday, 20 March 2008, 10:26 GMT
Please note that TEA5767 doesn't update it signal meter when it is read. It is updated when frequency is changed or you mute off.
Comment by Przemysław Hołubowski (p.h.) - Tuesday, 06 May 2008, 13:55 GMT
I've fixed a bug in LV24020LP field strength decoding. Tested on Sansa C250.
Comment by Przemysław Hołubowski (p.h.) - Tuesday, 27 May 2008, 13:39 GMT
This version of the patch does not break the sim. Synced to revision 17636.
Comment by Nikkhil (AceNik) - Monday, 02 June 2008, 12:22 GMT
malformed patch at line 50
Comment by Nikkhil (AceNik) - Monday, 02 June 2008, 14:22 GMT
fixed silly mistake of malformed, error, you need to leave a line after each file is complete
Comment by Przemysław Hołubowski (p.h.) - Monday, 02 June 2008, 18:55 GMT
Restored polish diacritical characters and synced to revision 17677.
Comment by Bertrik Sikken (bertrik) - Friday, 19 February 2010, 14:27 GMT
Attached patch was synced to svn r24772, with the following changes:
* dropped the polish translation, it didn't sync properly anymore, and IMO we better do all translations at once
* fixed lv240x0 signal strength, I think the previous patch compared against the wrong values
Tested only on c200 which has a lv240x0 radio chip.

It looks like we're getting a "while-fm-screen" so this is a nice opportunity to revive this patch.
I'm thinking of having some kind of progressive icon that shows signal strength, similar to the volume icon (e.g. an antenna symbol with variable number of bars)

One thing I wonder about is in what unit the tuner driver should return the signal strength. Should we use dBuV like this patch, or maybe some kind of percentage?
Comment by Przemysław Hołubowski (p.h.) - Saturday, 20 February 2010, 09:53 GMT
TEA5767 does not refresh signal strength register when you read it. It is refreshed when you for example set frequency or mute/unmute.
What about LV240x0? Do you get a new value on a new signal strength register read?

As to the signal strength presentation form - if we would have antenna symbol with bars then it would be nice to display dBu value too. In the way two user groups would benefit. Those who aren't familiar with dBu units would be informed how strong is signal with easy to understand bars and those who are familiar with dBu would be given more detailed information about signal strength. Furthermore I think that unfamiliar ones would quickly learn correlation between dBu value and symbolic bar level.
Comment by Bertrik Sikken (bertrik) - Wednesday, 24 February 2010, 15:25 GMT
The LV240x0 shows continuous updates.

The reason I asked about the unit is because I can imagine that different radio chips have different dBuV levels where they have "good" reception. I did have a look at the Si470x range of tuners and they also use 70 dBuV as maximum strength (it enables stereo at around 32 dBuV as far as I can tell), pretty similar to the LV240x0. Knowing this now, I think reporting the raw dBuV is fine.

Attached patch add support for the si470x tuner chips.
Comment by Bertrik Sikken (bertrik) - Sunday, 18 April 2010, 15:09 GMT
Synchronised against svn r25670
Comment by Bertrik Sikken (bertrik) - Saturday, 05 June 2010, 14:39 GMT
This patch has gone out of sync because some of the radio code has recently been refactored in more reasonably sized chunks. I still do like to have this feature in rockbox sometimes though.

Attached patch syncs to current SVN, but still misses the updates to radio/radio.c to show the strength actually on the screen.
Comment by Bertrik Sikken (bertrik) - Sunday, 17 October 2010, 20:14 GMT
Driver support only, skin FMS support (to parse a tag and render it) to be added later.
Added support for rda5802 and tea5760 fm tuner chips.
Renamed field strength to RSSI (RSSI seems to be a more common name for this)
Comment by Jonathan Gordon (jdgordon) - Monday, 18 October 2010, 00:45 GMT
What sort of values does this give? for the skin support you probably want to do it the same as battery or volume levels (so it can be used to display the value, or a bar, or conditionals for images). That's pretty easy to add once the driver is all working.
Comment by Bertrik Sikken (bertrik) - Saturday, 23 October 2010, 14:21 GMT
I can't quiet make my mind up about the unit that should be returned. Unit dBuV (microvolts on a logarithmic scale) seems to be mentioned mostly in the data sheet, but the ranges appear to be different for the various tuner chips. Can we easily support a different range for each tuner? Do you need a single number that goes from (for example) 0 to 100?

Below an overview of the signal strength ranges for various tuner chips:
* TEA5760: 4 - 46 dBuV (16 steps of 2.8 dB)
* TEA5767: 9.5 - 54.5 dBuV (16 steps of 3.0 dB)
* LV24020: 5 - 75 dBuV (8 steps of 10 dB)
* SI470X: 0 - 70 dBuV (70 steps of 1 dB)
* RDA5802: unknown, 128 steps max, but probably the same as SI470X
* ipod_remote_tuner: supports RSSI, unit unknown, but various other settings suggests that the fm remote uses an SI470X too
* s1a0903x01: no RSSI support as far as I know

Maybe we could combine dBuV and relative RSSI in one property, where the low 16-bits contain dBuV and the high 16-bits contain the relative strength, for example.
Comment by Jonathan Gordon (jdgordon) - Saturday, 23 October 2010, 23:32 GMT
no problem, give the api a min/max/current value getter and the maths is easy to get a "percentage" for the drawn bars
Comment by Przemysław Hołubowski (p.h.) - Sunday, 24 October 2010, 11:16 GMT
Simple percentage conversion wouldn't be good here. Subjective quality is mainly SNR dependent and SNR is a nonlinear function of the signal strength in dBuV. Below certain signal strength value there's no reception at all. The value is tuner dependent. For example for TEA5767 weak reception starts from about 21dBuV, moderate from about 33dBuV, good from about 42dBuV and very good from about 51dBuV. Above 54dBuV there's no subjective quality difference, although signal strength can be much much higher.

There is absolutely no point in showing percentage:
- as in most cases you have up to 16 levels returned from RSSI registers (this value is reasonable)
- a few lowest and a few highest levels are hardly differentiable considering subjective quality
- signal strength in all tuners' cases can be a few times higher then maximum value RSSI register can hold, and 100% would suggest something else
- no matter which numerical RSSI value representation will be chosen user will have to learn it's relation to the subjective quality
- dBuV values are more informative and unfamiliar users will have to learn it's correlation to subjective quality just the same way as they would have to learn percentage values correlation

In my opinion (look at my comment from 20 February 2010 too):
- there should be an antenna symbol with a four bars (first would mean weak signal, two - moderate, 3 - good and 4 - very good)
- thresholds should be defined separately for each tuner
- dBuV values should be displayed next to the antenna symbol.
Comment by Jonathan Gordon (jdgordon) - Sunday, 24 October 2010, 11:20 GMT
well how it looks is entirely up to the themer, and showing 4 bars is as rediculous as a percentage value.
Comment by Przemysław Hołubowski (p.h.) - Sunday, 24 October 2010, 12:51 GMT
I think themer should be given current value, at least weak and very good threshold and max value. It would allow the themer to do anything.

There's no sense in converting it to anything as for theming purposes it would probably be converted once again - one time theme could show said antenna with a four bars and the other time signal meter may be represented in a similar to peak meter manner.
Comment by Bertrik Sikken (bertrik) - Sunday, 24 October 2010, 12:58 GMT
Sorry Przemysław, I don't really see the point in any of your objections and I agree with Jonathan about not limiting ourselves to how the level is represented graphically.
The idea is to return a value in dBuV that can be shown either as a number or as some progressive graphic in the FMS (like the volume).
I like to see subjective quality as a separate issue (very hard to define anyway).

For the graphic representation, we need to define which level corresponds to "no bars" and which level corresponds to "full bars" (assuming that bars are used, this is up to the theme designer).
Since the possible minimum and maximum dBuV level differs per tuner, we cannot have a single standard for the graphic for all tuners that would allow it to show all possible sub-images, so a minimum and maximum is defined for each tuner. A good initial value IMO for those is the possible minimum and maximum dBuV level it can report according to the datasheet, possibly to be "tuned" later.

Attached patch makes get_tuner(RADIO_RSSI) return the RSSI in dBuV and contains the min/max levels as #defines RADIO_RSSI_MIN and RADIO_RSSI_MAX accessible through #including tuner.h
Comment by Przemysław Hołubowski (p.h.) - Wednesday, 27 October 2010, 11:22 GMT
Attached patch:
- makes get_tuner(RADIO_RSSI_MIN) return defined RADIO_RSSI_MIN
- makes get_tuner(RADIO_RSSI_MAX) return defined RADIO_RSSI_MAX
- adds skin tokens: %tf - SKIN_TOKEN_TUNER_RSSI , %tl - SKIN_TOKEN_TUNER_RSSI_MIN, %th - SKIN_TOKEN_TUNER_RSSI_MAX and their processing
- adds field strength line to the default radio skin
- adds polish translation.

The patch seems to be complete and fully working now. Maybe it's time to commit it?
Comment by Jonathan Gordon (jdgordon) - Wednesday, 27 October 2010, 11:29 GMT
the skin changes will only allow themers to show the actual values, not use them with images or as a bar. have a look at how SKIN_TOKEN_BATTERY_PERCENT or SKIN_TOKEN_VOLUME is done
Comment by Bertrik Sikken (bertrik) - Wednesday, 27 October 2010, 16:19 GMT
p.h, I think your patch is fine except for the fact that we now have enums (to identify the radio property) and #defines (to define the min/max levels in dBuV) with the exact same names (RADIO_RSSI_MIN/MAX).
I propose to rename the min/max RSSI value (dBuV) to simply RSSI_MIN/MAX and move them from the tuner driver .h files to the tuner driver .c files.
I think it's fine to have separate properties to retrieve the min/max RSSI, instead of using a #define for the min/max. There are some targets that do not always use the same tuner chip (clip+ for example), so we have to get it from the tuner driver dynamically.

I think we can commit soon indeed, with just the numeric tag at first and implement the graphic later. Jonathan, what do you think?
Comment by Przemysław Hołubowski (p.h.) - Wednesday, 27 October 2010, 17:13 GMT
I've followed your suggestions Bertrik - RADIO_RSSI_MIN and MAX defines moved to .c files and renamed to RSSI_MIN and RSSI_MAX.

Loading...