Radio's should report RSSI in dBm

[bergzand]

When receiving a frame, all radio's report the RSSI as the raw register value in the netdev_radio_rx_info struct. This way it is impossible to use this value in any higher level layer. This value should be converted to dBm by the radio drivers, to have any use.

I would propose to refactor the type of the rssi variable to int8_t. The practical range of most radio's is between -10 and -100 dBm. The reason for keeping it as a negative value instead of an absolute value is mainly for ease of programming and clarity. I don't think anyone is ever going to hit positive dBm values, but to me it makes sense to keep it negative.

I've done most of the work for all radio drivers, but I only own the mrf24j40 so I can't test everything.

[adjih]

You should consider that the sensitivity of most modern low-range low power radios is below -128 dBm (almost by definition; that's what makes them long range). I've seen figures of -141 dBm for NB-IoT, -134 dBm for LoRa, -129 dBm for SigFox, -142 dBm for RPMA, etc.

[bergzand]

I completly missed that class of devices, thanks. In that case it makes more sense to have absolute values.

[adjih]

Your initial issue is still very valid: the reported RSSI value has no meaning per say, and would be driver/hardware dependent. With just a dump of the radio register values, the application would have to do the conversion (which can be complex this is why for instance #6797 does it in the driver).

I just have no opinion on how one would best solve the issue.

[bergzand]

@adjih I might have been a bit short sighted with this. It seems that ieee802.15.4 is quite strict with how the RSSI should be reported, but that might be one of the few classes of devices that actually have a RSSI that can be converted to dBm. It's not called an indication for nothing :)

This issue will probably become a best effort kind of thing, depending on the radio type and the manufacturers goodwill.

[jnohlgard]

I think it is a good idea to let the drivers do the conversion on a best effort basis. At least for most 802.15.4 radios it will be possible to get dBm readings. As for the value range, why not just increase the width to int16_t? It's only one byte more for a single variable, the application is likely not going to keep thousands of RSSI values around, even the spectrum scanner in https://github.com/RIOT-OS/applications/pull/30 doesn't use more than one value per channel and interface.

[bergzand]

@gebart You're probably right with that assumption. The only reason I have to define it as a uint8_t is because it (should) fit.

[bergzand]

Closing this one as it is fixed for a while now