• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category FM Tuner
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Rockbox
Opened by p.h. - 2007-11-13
Last edited by bertrik - 2010-11-11

FS#8151 - Signal strength meter for FM radio

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.

Closed by  bertrik
2010-11-11 21:14
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Committed as SVN r28559

synced to the rev15872

p.h. commented on 2007-12-04 23:32

The last version of the patch corrected a bit. Restored polish diacriticals and removed one unnecessary change (see polski.lang).

works fine on my x5,but poor TEA5767!
however this patch breaks the sim, so fix this.

I used this patch to create a “Mute weak stations” patch (FS#8764), for anyone who likes the feature.

p.h. commented on 2008-03-20 10:26

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.

p.h. commented on 2008-05-06 13:55

I’ve fixed a bug in LV24020LP field strength decoding. Tested on Sansa C250.

p.h. commented on 2008-05-27 13:39

This version of the patch does not break the sim. Synced to revision 17636.

malformed patch at line 50

fixed silly mistake of malformed, error, you need to leave a line after each file is complete

p.h. commented on 2008-06-02 18:55

Restored polish diacritical characters and synced to revision 17677.

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?

p.h. commented on 2010-02-20 09:53

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.

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.

Synchronised against svn r25670

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.

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)

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.

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.

no problem, give the api a min/max/current value getter and the maths is easy to get a “percentage” for the drawn bars

p.h. commented on 2010-10-24 11:16

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.

well how it looks is entirely up to the themer, and showing 4 bars is as rediculous as a percentage value.

p.h. commented on 2010-10-24 12:51

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.

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

p.h. commented on 2010-10-27 11:22

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?

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

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?

p.h. commented on 2010-10-27 17:13

I’ve followed your suggestions Bertrik - RADIO_RSSI_MIN and MAX defines moved to .c files and renamed to RSSI_MIN and RSSI_MAX.


Available keyboard shortcuts


Task Details

Task Editing