mLRS is a LoRa radio link for RC vehicles that keeps the data rate up

The name encodes the design trade

mLRS is described as an open source 2.4 GHz and 915/868 MHz and 433 MHz/70 cm LoRa based high performance long range radio link, providing a bidirectional serial connection combined with full remote control.

The README explains the name at length, and the explanation is the most useful paragraph in the document. The m alludes to MAVLink, since the project includes features that optimize performance for MAVLink systems, and may also allude to MSP for the same reason. The LR alludes to long range, and here the project is careful. It should not be understood in terms of an absolute range such as 100 km, but as achieving the best possible range under given conditions, because physical laws dictate that higher data rates result in shorter range.

That sentence is the whole design brief. mLRS cannot compete purely on range with systems that achieve range by reducing data rates to a minimum, at the cost of the associated compromises. The stated goal is to achieve a high range while maintaining a relatively high data rate.

The typical specifications given are plenty of full resolution RC channels with a 50 Hz update rate, and serial data rates of about 3 to 5 kBytes per second at 2.4 GHz. In a hobby where the usual complaint about long range links is that they crawl, that is a reasonable place to aim.

Six radio chip families, three frequency bands

The supported hardware is what separates this from a single design. mLRS supports the SX1280/1, SX1276, SX1262, LLCC68, LR1121 and LR2021 Semtech chips, and through them the 2.4 GHz, 915/868 MHz and 433 MHz/70 cm bands.

That list spans two quite different radio architectures. The SX128x parts are the 2.4 GHz LoRa and FLRC capable parts, and the SX126x and LLCC68 parts are the sub GHz LoRa parts. The SX1276 is the older 900 MHz part, which the documentation associates with the 19 Hz 7x mode, and the LR1121 and LR2021 are the newer multi band parts that appear across most of the modes.

For a builder, this means the choice of radio module is a design decision rather than a constraint imposed by the software. The same firmware serves an ESP32 based wireless bridge and an STM32 based flight controller radio, and the repository layout reflects that spread, with a firmware directory, an esp directory, a lua directory, an ardupilot_tools directory, a tools directory, a platformio.ini, a run_setup.py script and a docs directory.

The platformio.ini at the repository root is the sign that this is a firmware project rather than a hardware design, and the README does not spell out a build procedure: it points readers to the separate mLRS documentation repository for parameter details and build and configuration guidance. The firmware is built for multiple target platforms, and the README lists support for ESP32 and ESP8266 modules used as a wireless connection to a ground control station, and for a range of STM32 targets including STM32F103, STM32G4 and STM32L.

Six operation modes trade rate against sensitivity

The operation mode table is where the trade in the design becomes concrete, and it is the most decision relevant part of the documentation for anyone choosing hardware.

There are six modes. The 50 Hz mode is 2.4 GHz only, with a downlink serial rate of 4100 bytes per second, an uplink of 3200 bytes per second and a receiver sensitivity of -105 dBm. The 31 Hz and 19 Hz modes cover all three band families and trade rate for sensitivity, with sensitivities of -108 dBm and -112 dBm respectively and downlink rates of 2562 and 1547 bytes per second. The 19 Hz 7x mode is 915/868 MHz only, and the FLRC mode at 111 Hz is 2.4 GHz only with the highest rates in the table at 9111 bytes per second downlink. The FSK mode at 50 Hz covers the sub GHz bands and matches the 50 Hz rates of 4100 and 3200 bytes per second.

Two entries in the sensitivity row are worth reading twice. FLRC is marked not for LR, and FSK is marked not for LR. Those two modes are the high rate options and they are not the long range ones, which is exactly the physics the README describes.

The chip set row also shows where each mode is practical. The 19 Hz 7x mode is the only one that requires an SX1276, and the FSK mode does not use the SX128x parts at all, using the SX126x, LLCC68, LR1121 and LR2021 instead. Selecting a mode therefore constrains your radio module, not just your link budget.

RC channels come in a 16 and a 32 channel layout

mLRS supports two RC channel configurations, and the layouts are given precisely because channel resolution and reliability are the practical concern for a pilot.

The 16 channel configuration is non-interlaced throughout. CH1 to CH8 have 11 bit resolution, with CH1 to CH4 having a higher reception probability. CH9 to CH12 have 8 bit resolution. CH13 to CH16 have three position values, with CH13 and CH14 having a higher reception probability.

The 32 channel configuration uses interlacing to fit more channels into the same link budget. CH1 to CH8 keep 11 bit resolution and the higher reception probability, still non-interlaced. CH9 to CH16 drop to 8 bit and are interlaced 1:2. CH17 to CH20 have 9 position values interlaced 1:4, and CH21 to CH32 have three position values also interlaced 1:4.

The design logic is consistent. The channels most likely to be used for control surfaces keep full resolution and are not shared, while the auxiliary channels take a degraded step, since three position values are enough for a switch and a low rate channel for an analog function.

The interlacing also means that the number of channels is not free. A pilot moving from 16 to 32 channels is trading update rate and resolution on the lower channels, and the choice of radio and mode has to be made with that in mind.

Two LoRa chips give full diversity and dual band operation

Two of the more distinctive features come from using more than one radio in a single unit.

Full diversity applies to mLRS transmitters and receivers which feature two Semtech LoRa chips, and it works for both receiving and transmitting. The documentation says this really improves link quality in the far range, and that it allows advanced dual antenna setups on the transmitter side. In practice this is the difference between a link that holds at the edge of its range and one that drops out, and it is a hardware decision that costs money and board area.

Dual band is the related case, where the two chips work in different RF bands, for example 2.4 GHz and 915/868 MHz. These provide full diversity, with simultaneous transmission on both RF bands in addition.

Both features fall out of the same underlying design decision, which is to support the Semtech chip families broadly rather than to design around one of them. The cost is that the dual chip variants are more complex boards with more power draw, and they are not the configuration a first time builder should start with.

The other link level feature in the list is adaptive ARQ and retransmission, which handles the case where a packet is lost rather than simply dropping it.

Everything is configured from the transmitter, not the receiver

The usability story of mLRS is that you almost never touch the receiver hardware.

The receiver parameters can be set from the mLRS transmitter or radio, with no need to mess with the receiver for configuration in any way. The transmitter and receiver parameters can be set via a Lua script, a CLI, or an OLED display, and there is no need to recompile or reflash the firmware in order to change an option or parameter setting.

That is a substantial practical improvement over the usual embedded radio workflow, where changing a frequency or a power setting means connecting a USB cable to the receiver, or reconfiguring it in a separate tool. Here, everything is done from the radio in your hand.

The rest of the usability layer follows the same shape. There is a bind mode for binding unknown receivers to a transmitter, ten model configurations stored in the transmitter and selected by receiver number in OpenTx or EdgeTx radios, and support for an OLED display and a five way button along with a second serial port.

For the ground station side, the project supports CRSF and ArduPilot passthrough protocol, which enables using the Yaapu Telemetry app on standard radios out of the box with no extra dongles, and support for ESP32 and ESP8266 modules for a wireless connection to a ground control station. The mLRS system also integrates with the mTXe project, MAVLink for EdgeTx, and the README mentions wireless connection to ground control stations like MissionPlanner or QGC.

MAVLink and MSP get their own optimisations

The project is not simply a transparent serial pipe, and the differences are the point of the m in the name.

For MAVLink, the README lists technologies introduced by mLRS as an innovative flow control for MAVLink for smoother and more reliable data flow, and MavlinkX for reduced packet loss and data compression. There are also optimizations for ArduPilot and PX4 autopilot systems.

For the other protocol, there is support of MSP and optimizations for INAV autopilot systems, which enables the INAV telemetry widget, in flight connection to the INAV configurator or MWP ground control, support for MSP-RC, and MspX for reduced packet loss.

The INAV side deserves a note, because INAV ground stations are a common pairing for FPV flying and the telemetry link is exactly where a lossy radio hurts. A protocol extension that reduces packet loss on the same link is worth more than a modest improvement in raw range.

There are also two features the README names only as except and ortho features, without describing what they do. That is a documentation gap, and anyone who wants to understand the difference would need to consult the separate mLRS documentation repository rather than the README.

Where a radio link is the wrong tool

The project states its own limits plainly, and they are worth repeating before anyone buys hardware.

The first limit is range versus data rate. The README says mLRS cannot compete purely on range with systems that achieve the range by reducing data rates to a minimum, at the cost of the associated compromises. If your mission is to fly as far as possible and you do not care about telemetry throughput, a system designed the other way round is the better choice, and the project names several of them, including SiK radios, OpenLRS, ExpressLRS, OpenHD, Ruby, UltimateLRS, QczekLRS, DragonLink, RFD900 and TBS Crossfire.

The second limit is the hardware commitment. mLRS is firmware and hardware designs, not a product. The receiver and transmitter are built or sourced by you, the parameters are set from the transmitter, and the radio modules are specific parts. A commercial system such as a DragonLink or an RFD900 arrives as a working pair with support behind it.

The third is project maturity. The Project Status section says there is still plenty of room for ideas and improvement, and that in this sense the project is work in progress, while also saying it is fair to call it stable and to perform quite well. Both statements are true at once, and the practical reading is that the core link works and the surrounding feature set keeps moving. The last push was on 2026-10-19 and the most recent tagged release is v1.4 from 2026-03-20, so development continues between releases.

On licensing, the project is GPL-3.0, and the repository includes an ardupilot_tools directory and a lua directory for the radio scripting, so the licensing terms reach the scripts you run on your transmitter as well as the firmware. For a hobbyist that is a non issue. For anyone embedding the firmware in a product, the copyleft terms are a different conversation, and the LICENSE file governs.

The alternative worth naming is ExpressLRS or OpenLRS, both open source and both far more widely deployed, with ExpressLRS in particular having a larger hardware ecosystem and a broader community. They achieve a similar goal with a different radio approach, using 2.4 GHz at higher data rates rather than LoRa across multiple bands, so the choice between them and mLRS is really a choice about which band, which chip and which data rate your flying needs.

Editorial conclusion

mLRS fits a hobbyist or team flying long range RC vehicles, or running MAVLink over a radio link, who wants an open firmware, a wide choice of frequency bands and chip sets, and who can accept a moderate data rate in exchange for range. It is the wrong choice for a pilot who needs the maximum possible link budget at any cost, since the project itself says it cannot compete on range with systems that reduce the data rate to a minimum, and it is the wrong choice for a plug and play setup since the receiver parameters are set from the transmitter or radio and the hardware is a build. Before you commit, check three things: that the operation mode you need exists for your band and chip set, since FLRC and FSK are not available for long range and the sensitivity figures differ by mode, that the RC channel configuration you need is one of the two supported layouts, and that you are comfortable with a project the documentation describes as work in progress, with the last push on 2026-10-19 and the most recent tagged release v1.4 from 2026-03-20.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. olliw42/mLRS on GitHub
4. README
5. Releases