ap page rssi

[jlpoltrack]

Title

[olliw42]

very good start I think it needs to mention however a bit more of the complexity with ardupilot

if I'm not mistaken this conversion is so only if the CRSF protocol is used. Moreover I think one needs to get some ArduPilot parameters correct, if I'm not mistaken one needs to set RSSI_TYPE = 3. And when there is also the option RC_OPTION "Use LQ for RSSI with CSRF".

to make it more confusing, if one has also mavlink and flow control enabled (which most will), then the mLRS receiver is also sending the RADIO_STATUS message, which also contains a rssi value (in fact tow, rssi and remrssi). This value is taken if RSSI_TYPE = 5. Here mLRS applies the same scaling from dbm to rssi value as used by ArduPilot with CRSF

to make it even more confusing, if the mLRS tx module is also emitting a RADIO_STATUS message, when in e.g. MissionPlanner you will see also the values coming from this message. In the radio you yet will see another value. So, what you see on and OSD (showing data on the fc side) or in e.g MissionPlanner (showing data on ground side) or on the radio (also showing data on ground side but different "units") can all be different.

and this is just what I pull out of memory, might be incomplete opr partially incorrect.

[jlpoltrack]

As you say, RSSI is a complex topic :) so here are a few thoughts back:

if I'm not mistaken this conversion is so only if the CRSF protocol is used. Moreover I think one needs to get some ArduPilot parameters correct, if I'm not mistaken one needs to set RSSI_TYPE = 3. And when there is also the option RC_OPTION "Use LQ for RSSI with CSRF".

This is a good callout and I will add some bullets that detail what is going on when using RSSI_TYPE = 3 or 5. IMO we don't want to mention this RC_OPTION as AP now supports LQ in addition to RSSI, so you can have both LQ and RSSI. I believe this option was only for when LQ wasn't available in AP. Enabling this option today wouldn't provide any benefit.

to make it more confusing, if one has also mavlink and flow control enabled (which most will), then the mLRS receiver is also sending the RADIO_STATUS message, which also contains a rssi value (in fact tow, rssi and remrssi). This value is taken if RSSI_TYPE = 5. Here mLRS applies the same scaling from dbm to rssi value as used by ArduPilot with CRSF

Do you know if choosing RSSI_TYPE = 5 will populate rxrssi with the value that it receives for rssi from the RADIO_STATUS message? I did a quick check and when using RSSI_TYPE=5 I don't see rssi or remrssi in Mission Planner but only rxrssi. It seems that the remrssi values the receiver sends in the RADIO_STATUS message would only be available in the FC log.

to make it even more confusing, if the mLRS tx module is also emitting a RADIO_STATUS message, when in e.g. MissionPlanner you will see also the values coming from this message. In the radio you yet will see another value. So, what you see on and OSD (showing data on the fc side) or in e.g MissionPlanner (showing data on ground side) or on the radio (also showing data on ground side but different "units") can all be different.

I always have this enabled so I can get the RSSI on the Tx side in Mission Planner using the rssi field, knowing that the remrssi may not match what I see for rxrssi. Note: for me the rxrssi, rssi and remrssi return the unsigned 8 bit values in the MP HUD.

Do we want to include some general suggestions? To me it sounds like:

• For the Rx side, if using CRSF for output, use RSSI_TYPE = 3 otherwise use RSSI_TYPE=5
• For the Tx side, enable RADIO_STATUS if you want to the see the RSSI of the Tx module (not sure why this wouldn't be the default)

[olliw42]

AP now supports LQ in addition to RSSI, so you can have both LQ and RSSI. I believe this option was only for when LQ wasn't available in AP. Enabling this option today wouldn't provide any benefit.

really, didn't knew that. How would I see LQ e.g. in MissionPlanner, or get it via MAVLink?

Do you know if choosing RSSI_TYPE = 5 will populate rxrssi with the value that it receives for rssi from the RADIO_STATUS message? I did a quick check and when using RSSI_TYPE=5 I don't see rssi or remrssi in Mission Planner but only rxrssi. It seems that the remrssi values the receiver sends in the RADIO_STATUS message would only be available in the FC log.

if i'm not mistaken:

• rssi&remrssi are populated from RADIO_STATUS messages which arrive at MissionPlanner, i.e., coming from the mLRS tx mdule.
• rxrssi is what the flight controller thinks rssi is, and I think it is delivered to MissionPlanner via the RC_CHANNELS message.
• This rxrssi value depends on the settings in ArduPilot. For 5 it is taken from the RADIO_STATUS message arriving at the flightcontroller, i.e., comming from the mLRS receiver. For 3 it is taken from the rc data, i.e. e.g. CRSF. Here RC_OPTION comes into play.

Do we want to include some general suggestions

I'm frankly not sure what of that all I would include. The minimum to include to the current text is IMHO to clearly specify the conditions for which it is as the text describes

[jlpoltrack]

really, didn't knew that. How would I see LQ e.g. in MissionPlanner, or get it via MAVLink?

My mistake here, Rx LQ is only available as an OSD element, so this only applies for folks flying with video.

Have done a rework to stick to the facts and also updated the table for the unsigned 8-bit values that one gets for 'rssi' and 'remrssi' in Mission Planner.

[olliw42]

I'm not sure about the "RSSI %" percentage it refers to, the rssi is internally stored as float from 0.0 .. 1.0, but then converted in output to 0 .. 255. So, if I'm not mistaken, e.g., rxrssi is also in unit (1 - (dBm - 50)/70) * 255

[jlpoltrack]

I'm not sure about the "RSSI %" percentage it refers to, the rssi is internally stored as float from 0.0 .. 1.0, but then converted in output to 0 .. 255. So, if I'm not mistaken, e.g., rxrssi is also in unit (1 - (dBm - 50)/70) * 255

Attempted to address this with some more explanation.

[olliw42]

sorry for having abandoned this a bit

and I'm sorry to also have few more comments.

• I guess instead of "unsigned 8bit" one could directly say 0..255.
• rxrssi: I think this is getting a bit too much nested. Maybe the Notes do not need an extra bullet.
• In that bullet I guess it could be usefull to say also that therefore 100 means >= 50 dB rssi and 0 <= 120 dBm rssi.
• I think one should mention that rssi is actually negative, but in many places given as positive value. Like in the CRSF telemetry items and here in the MAVLink fields. This goes also somewhat along with claryfing what Rx RSSI dBM/Tx RSSI dBM are.
• The note that in theory remrssi should match the rxrssi value is imprecise. It is equal to the value in the mavlink message, but not how it is displayed by MissionPlanner. May need more precise language
• I think the values in the table are not all correct. :)
• Instead of e.g. "50 Hz Mode Limit" I would suggest e.g. "50 Hz Mode receiver sensitivity". LoRa has the potential to ge below that so it's not a limit really.

Besides what is delivered to the gcs by mavlink, rssi data is also stored in the data flash log. I think this should also be adressed since it can be an important source of info for teh analysis after the flight. E.g., one may want to create rssi vs distance plots. I have not yet fully disected all possible scenarios. However, in the "default" mLRS setting with CRSF and Rx Snd RadioStat enabled the data from the RADIO_STATUS message are logged (the CRSF data is not logged).

puh ... this rssi thing is really a beast ...

[jlpoltrack]

Stale, so closing. Can revisit if needed.