This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#8151 - Signal strength meter for FM radio
Attached to Project:
Rockbox
Opened by Przemysław Hołubowski (p.h.) - Tuesday, 13 November 2007, 21:28 GMT+2
Last edited by Bertrik Sikken (bertrik) - Thursday, 11 November 2010, 22:14 GMT+2
Opened by Przemysław Hołubowski (p.h.) - Tuesday, 13 November 2007, 21:28 GMT+2
Last edited by Bertrik Sikken (bertrik) - Thursday, 11 November 2010, 22:14 GMT+2
|
DetailsThe 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. 
tuner_field_strength.patch
(4.8 KiB)
apps/lang/english.lang | 17 +++++++++++++++++ apps/lang/polski.lang | 19 ++++++++++++++++++- apps/recorder/radio.c | 16 ++++++++++++++++ firmware/drivers/tuner/lv24020lp.c | 4 ++++ firmware/drivers/tuner/tea5767.c | 4 ++++ firmware/export/lv24020lp.h | 1 + firmware/export/tea5767.h | 1 + firmware/export/tuner.h | 2 +- 8 files changed, 62 insertions(+), 2 deletions(-) |
This task depends upon
Closed by Bertrik Sikken (bertrik)
Thursday, 11 November 2010, 22:14 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as SVN r28559
Thursday, 11 November 2010, 22:14 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as SVN r28559
works fine on my x5,but poor TEA5767!
however this patch breaks the sim, so fix this.
* 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?
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 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.
Attached patch syncs to current SVN, but still misses the updates to radio/radio.c to show the strength actually on the screen.
Added support for rda5802 and tea5760 fm tuner chips.
Renamed field strength to RSSI (RSSI seems to be a more common name for this)
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.
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.
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.
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
- 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?
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?