mLRS Documentation: Additional Configuration for ArduPilot Systems

(back to main page)

This page contains additional detail on certain configuration options that are applicable only to ArduPilot systems. Initial configuration should follow the process described in the CRSF Telemetry and Yaapu Telemetry App page. If you are using a separate RC system and only want to have SiK functionality then you can refer to the SiK Telemetry Replacement page.

CRSF Receiver

Setting up ArduPilot for a CRSF receiver can be a bit tricky, as it depends on the flight controller board, and might need BRD_ALT_CONFIG to be set to a specific value. It is best to consult the ArduPilot wiki, or ask in the ArduPilot discussion channel.

CRSF works best on serial ports that have DMA enabled. This is only a concern on F4 and F7 flight controllers. The serial ports that have DMA enabled can be found by using the MAVProxy command 'ftp get @SYS/uarts.txt -', an '*' will denote serial ports that have DMA enabled (example for Matek F405 VTOL):

If you use a serial port without DMA, Mission Planner will show the message "CRSF: running on non-DMA serial port" in the 'Messages' section.

For a Matek H743 board the configuration is:

• BRD_ALT_CONFIG = 1
• RC_PROTOCOLS = 536 or 512
• RSSI_TYPE = 3 or 5
• SERIAL7_BAUD = irrelevant (baud rate is determined by ArduPilot)
• SERIAL7_OPTIONS = 0
• SERIAL7_PROTOCOL = 23

References:

• ArduPilot Docs for CRSF
• ArduPilot Docs for RC_PROTOCOLS
• ArduPilot Docs for RSSI_TYPE
• There are more RC options available in the RC_OPTIONS parameter. (ArduPilot Docs for RC_OPTIONS)

RSSI

RSSI is a relatively confusing topic with ArduPilot, since there are multiple values and sources.

First, a comment on how RSSI is represented by ArduPilot. ArduPilot converts any RSSI value into the range [0.0...1.0], where 0.0 represents the weakest and 1.0 the strongest signal. The equation which is used for this scaling depends on the source of the RSSI value. In the dataflash log this value is available as 'RSSI:RXRSSI'. For other uses, this internal RSSI value is then further converted into whatever the output format demands. For instance, the RSSI value that is displayed in the OSD uses the internal value multiplied by 100 which is displayed as 0% ... 100%. For MAVLink it is converted into the range [0...254] (0 = weakest signal, 254 = strongest signal, 255 = undefined). From here on we'll refer to this scaling as MAVLink units for RSSI.

The source of the RSSI value (and thus applied conversion formula) is determined by the ArduPilot parameter RSSI_TYPE. With mLRS these settings can be relevant:

• RSSI_TYPE = 3 (ReceiverProtocol): mLRS will send RSSI in dBm in the CRSF stream and ArduPilot will apply scaling using the following formula: RSSI = 1 - ((RSSI_dBM - 50) / 70). This means that -120 dBm is mapped to 0.0 and -50 dBm to 1.0.
  • Note: When using RSSI_TYPE = 3, it is possible to replace the RSSI with LQ using the RC_OPTIONS bitmask.
• RSSI_TYPE = 5 (TelemetryRadioRSSI): mLRS will send RSSI in the MAVLink stream to the ArduPilot via the RADIO_STATUS message, in MAVLink units. mLRS applies the scaling RSSI = (1 - ((RSSI_dBM - 50) / 70))*254 to convert to MAVLink units, i.e. -120 dBm is mapped to 0 and -50 dBm to 254. This is enabled in mLRS when the parameter "Rx Snd RadioStat" is not "off".
• RSSI_TYPE = 2 (RCChannelPwmValue): mLRS can be configured to send RSSI (and LQ) as a channel value to ArduPilot. This option is not recommended and not further described.

A ground control station (GCS) software such as MissionPlanner gets receiver RSSI data from ArduPilot via MAVLink messages (usually via the RC_CHANNELS message) in MAVLink units. This value is available in MissionPlanner as 'rxrssi'.

In addition to the above, a Tx module may send RADIO_STATUS MAVLink messages to the GCS, with RSSI in MAVLink units. The data from the Tx module is available in MissionPlanner as 'rssi' and 'remrssi' (also 'noise' and 'remnoise' are available).

This is enabled in mLRS when the parameter "Tx Snd RadioStat" is set to "1 Hz". The mLRS Tx module will use the following formula to convert from RSSI in dBm to MAVLink units: RSSI = (1 - ((RSSI_dBM - 50) / 70)) * 254.

Therefore in Mission Planner three RSSI metrics are available when using mLRS (all in MAVLink units):

1. rxrssi - the RSSI of the mLRS receiver, as seen by ArduPilot (and passed back to the ground via RC_CHANNELS messages)
2. rssi - the RSSI of the mLRS Tx module
3. remrssi - the RSSI of the mLRS receiver, as seen by the mLRS Tx module (passed back to the ground within the mLRS OTA packet)
   • Note: In theory, this value should match the 'rxrssi' value however due to scaling and timing this is not guaranteed.

References:

• ArduPilot Docs for RSSI_TYPE
• The link quality indicator in the HUD of MissionPlanner shows the percentage of lost data packets (as determined from the seq number in the MAVLink packets), see ArduPilot Docs for Flight Data Screen

RSSI Comparison Chart

It is often useful to know the exact RSSI dBm as opposed to RSSI as a percentage or in MAVLink units. The RSSI dBm allows one to understand exactly how much margin there is in the link budget. The table below provides conversions to RSSI dBm:

RSSI dBm	RSSI %	RSSI MAVLink units	Notes
-90	43	77
-100	29	73
-105	21	55	50 Hz Mode receiver sensitivity
-108	17	44	31 Hz Mode receiver sensitivity
-112	11	29	19 Hz Mode receiver sensitivity

Stream Rates

When configuring SRy/MAVy parameters, 'y' does usually not correspond to the number 'x' of the SERIALx port but to the count of serial ports using the MAVLink protocol. SERIAL0, and thus SR0, is nearly always reserved for the USB connection and set to use the MAVLink protocol (not possible in ArduPilot 4.7, has no MAV0). Therefore, as an example, in a setup where SERIAL1 and SERIAL2 are not set to MAVLink protocol and with the mLRS receiver connected to SERIAL3, then SR1/MAV1 configures the stream rates for the mLRS receiver.

To understand how stream rates affect the MAVLink data rate, you can use this calculator (requires Python).

mLRS Receiver

Flow Control

The mLRS receiver implements software flow control between itself and the flight controller, when configured as follows:

• "Rx Snd RadioStat" = "ardu_1": optimizes for ArduPilot usage
• "Rx Snd RadioStat" = meth_b: optimizes for PX4 usage

MAVLink RC

RC data and link quality data can be provided to ArduPilot in several ways, for instance via a CRSF connection. It is also possible to send these data via the MAVLink serial port, which can make the etxra RC wire unneccessary.

Two options are available, which can be enabled via the "Rx Snd RcChannel" parameter:

• "Rx Snd RcChannel" = "rc_channel_overrides": outputs MAVLink RC_CHANNELS_OVERRIDE messages
• "Rx Snd RcChannel" = "radio_rc_channels": outputs the newer MAVLink RADIO_RC_CHANNELS messages