STM32/ESP32/ESP8285-based High-Performance Radio Link for RC applications
GPL-3.0 License
Bot releases are hidden (Show)
Getting Started 3.0 Documentation
This is a feature release version (meaning it contains new features, targets and bug-fixes) and is compatible with all V3.X versions.
Our STM32 users. This includes the Happymodel ES915 TX/RX, Happymodel PP, NamimnoRC V1 Flash/Voyager TX/RX, FM30, Ghost and FrSky R9 hardware.
More detail on the below features will be added with coming RCs and the final release.
#2176
#2242
#2309
#2370
#2400
This allows the dev team to add new targets as soon as they have been tested/passed, if they don't require firmware changes to support them
#2408 Support Graupner HoTT telemetry sensors
#2631 HoTT Telemetry: robustness measure
#2410 Support for ESP32-S3 targets
#2463 Get thermal info from S3 if no LM75A
#2472 Fix esp32s3 and backpack passthrough flashing settings
#2494 Allow flashing of the backpack on S3 via USB
#2346 DShot output for PWM receivers
#2425 Configurable I2C pins for PWM capable (ESP32) receivers
#2535 PWM failsafe modes, like no-pulse, hold, and custom set position
#2624 WebUI: prevent multiple I2C SCL/SDA selections
#2322 Configurable OLED/TFT startup splash screen
#2432 Added switch-mode and Gemini settings
#2444 Adds a Joystick that sends data via UDP/WIFI
#2515 VTX SPI output calibration routine and initial PWM value config
#2583 Fixed VTX PWM array initialization for unified ESP32 targets
#2542 Allow all binding methods on RX
#2523 Support CRSF bind command from betaflight
#2528 PPM handset support
#2612 Fix TX module PPM input seeing spurious channels
#2540 Gemini Xrossband (GemX) - LR1121 Driver
#2616 Adds LR1121 image calibration
#2617 Fix LR1121 binding (adds 2.4GHz binding)
#2618 Allow choosing the domain for LR1121 modules
#2643 LBT - Change TX modules to use RX mode with timeout
#2480 Add BMP280/BME280 I2C barometer support
With the separation of the targets from the main firmware repository we will list only those targets that are only supported from this release onwards.
Any new targets that have been added that can be supported by older firmware will just show up in Configurator.
Published by pkendall64 10 months ago
Getting Started 3.0 Documentation
This is a patch version release bug-fixes only (mostly) and is compatible with V3.X.
Published by pkendall64 12 months ago
BETAFPV Lite Radio 3
to BETAFPV Lite Radio 3 Pro
#2319Radiomaster Zorro
to Radiomaster Zorro Internal
#2319stock
bootloader flashing option for STM32 targets #2354fuzzy_snr
using integer arithmetic #2378 #2379Getting Started 3.0 Documentation
This is a patch version release bug-fixes only (mostly) and is compatible with V3.X.
Published by JyeSmith over 1 year ago
Getting Started 3.0 Documentation
This is a minor version release (new features, targets and bug-fixes only) and is compatible with V3.X.
“ELRS is great, but the first-time setup was a PITA!”
This is one of the main complaints we see across the groups about ExpressLRS.
We understand the challenges faced during the initial setup process of ExpressLRS, with many users expressing their frustration. In version 3.3, we are doing something to improve this, starting with the introduction of pre-compiled builds.
While our "just-in-time" firmware compilation approach has served us well in the past, it has also caused inconvenience and frustration. Various factors, some of which were completely out of our control (e.g. updates to the Platformio framework), have resulted in failed configurator builds, leading to user dissatisfaction.
To overcome these challenges, we have made a significant change in v3.3. Instead of relying on local compilation for release versions, the configurator will now seamlessly retrieve pre-built firmware from the cloud and flash it onto your device. This shift not only drastically reduces firmware update times from minutes to seconds but also eliminates many annoying build issues, where users are faced with the dreaded red "failed build" error message in the Configurator.
Make sure you have updated to version 1.6.0 the Configurator to take advantage of this awesome new feature: https://github.com/ExpressLRS/ExpressLRS-Configurator/releases
#1904
In the hobby and commercial UAV industry, securing a dependable telemetry downlink alongside RC control often presents challenges in terms of cost, availability, and reliability. While Dragonlink has been the go-to option for a reliable long-range RC + telemetry link, it can be difficult to find in stock and tends to be expensive. Other alternatives, such as the RFD900 modems, are typically limited to 900MHz and also suffer from availability and cost issues.
This is where AirPort comes to the rescue.
AirPort offers a firmware option that transforms a standard ExpressLRS transmitter and receiver pair into a bidirectional transparent serial data link over the air. This enables seamless serial data communication between the connected devices, supporting any protocol of your choice, including MAVLINK (Ardupilot), MSP (Betaflight and INAV), or any other telemetry protocol that can be transmitted serially. This feature may also be useful for interfacing wirelessly with other ground devices, such as antenna trackers or similar.
Thanks to the increasing availability of ExpressLRS hardware, AirPort makes it effortless and cost-effective to incorporate an inexpensive telemetry uplink/downlink into your UAV models.
In previous versions, the only receiver protocol available for connecting ELRS to your FC was CRSF. While CRSF performs admirably in most scenarios and remains the preferred option if your hardware is compatible, what if your hardware doesn't support it? Typically, this would require the use of an additional protocol converter, such as the CRSF to SBUS converter.
In this release, we are delighted to introduce not just one, but THREE new receiver protocols, along with inverted options tailored for specific hardware requirements. This expanded protocol support ensures greater flexibility and compatibility, empowering you to seamlessly integrate ELRS with a wider range of hardware options.
#2094
That’s right, you read that correctly… after all that bitching and whining from us in the past, ELRS finally added SBUS as a receiver protocol! This is particularly useful for those closed-source FCs & flight stabilizers that only allow SBUS as an input. We’ve also added an inverted version of SBUS (which is normally inverted, so technically it’s un-inverting it - insert Xzibit meme) for hardware that doesn’t have the inverter on the UART.
PWM receivers can also be configured to output serial on some pins and select serial protocol, so now you can have CRSF/SBUS etc and PWM simultaneously!
#2137
Graupner HoTT SUMD joins SBUS as another user selectable receiver protocol, which can be found in many open source flight control firmwares (BF, INAV, ARDU) as well as a variety of flybarless controllers (helis).
#2140
The DJI RS Pro series, including the RS2 Pro and RS3 Pro gimbals, are renowned professional camera stabilizers often utilized on cinelifters for active stabilization of high-end cinema-grade cameras. While these gimbals can be controlled via an SBUS interface, DJI’s janky implementation of the protocol demands precise channel endpoints to trigger various functions, such as recentering.
To spare you the frustration of manually adjusting mixer settings as you attempt to discover the exact (and poorly documented) values expected by DJI for channel outputs, the ELRS team has introduced a dedicated version of SBUS, specifically tailored to these gimbals. This special version is preconfigured to seamlessly integrate with your RS2 Pro or RS3 Pro. For more detailed information regarding installation, please refer to the associated pull request: https://github.com/ExpressLRS/ExpressLRS/pull/2140 or check out a quick demo here: https://youtube.com/shorts/OPZykP-bP4k
#1993
Dry those eyes #Team900, ELRS now has True Diversity 900MHz receivers. A much sought after piece of gear that was frequently requested is now a reality. Check the new targets list for BETAFPVs Super-D, and I'm sure there will be more to follow!
But that's not all… with diversity also comes Gemini! Need a 900 Gemini Tx? Be sure to go and pester your favorite FPV manufacturer.
#2089
Exciting news! #Team900 is now part of the DVDA family! With the latest release, we introduce the new D50 packet mode, leveraging the 200Hz OTA modulation parameters to transmit 4 repeat packets across 3 frequencies. This approach is identical to the functionality of D250 for the 2.4GHz frequency range.
The primary goal of the D50 packet mode is to significantly enhance Link Quality (LQ) in RF-congested environments, particularly when flying alongside other pilots operating on the same frequency domain. By providing 4 transmission attempts for each packet, distributed across multiple frequency hops, you can enjoy improved reliability and stability during flights.
#2060
Support has been added into VRx & TX backpack as well as the main firmware to allow head tracking information to be sent wirelessly from the goggles to the TX module and then mixed into the channel output. At present, this functionality is exclusively supported by HDZero goggles, however we are optimistic that other goggle manufacturers will follow suit and incorporate compatibility with this exciting feature.
Target support has been added for 16 channel PWM receivers in both 2.4G and 900M flavors. Not only that, they are true diversity!
Any PWM channel can be set to a combination of the available PWM modes e.g. 400Hz, 10kHz PWM, On/Off switch. A single PWM channel can also be reassigned to a serial protocol (CRSF, Sbus etc). You want a FC connected plus native PWM output, you got it.
#2054
We understand that not everyone requires or utilizes the TX backpack feature in their transmitter setup. While enjoying a few cold ones at the ELRS headquarters, we asked ourselves: “If you’re not using the backpack, why have it sitting there chewing power?”, so we’ve introduced a convenient option to disable the TX backpack functionality. This can save a little juice (~0.3W) on the transmitter. Zorro users rejoice!
#2007
Proprietary VTX control protocols SUCK! That's right Smartaudio and Tramp… you guys suck. These protocols are owned by commercial manufacturers who never seem to do a good job at properly documenting the protocol specs, and have low motivation to extend their protocols for features that don’t directly interest them and their bottom lines.
MSP control for VTXs is a breath of fresh air that alleviates many of these pains, and now it’s supported in ELRS for hardware where the VTX is controlled by the same MCU as the receiver.
#2002
Allows you to run a Gemini TX in different antenna configurations:
#1968
If you have a receiver with analog VBAT and use a CRSF based VBAT sensor, then the receiver will favor the CRSF based sensor automatically.
Vitroid
, Senk0
, King David
, and FlyingBaguette
, whose diligent testing played a part in shaping this RC release. Your assistance has been truly appreciated.Published by JyeSmith over 1 year ago
Getting Started 3.0 Documentation
This is a minor version release (new features, targets and bug-fixes only) and is compatible with V3.X.
“ELRS is great, but the first-time setup was a PITA!”
This is one of the main complaints we see across the groups about ExpressLRS.
We understand the challenges faced during the initial setup process of ExpressLRS, with many users expressing their frustration. In version 3.3, we are doing something to improve this, starting with the introduction of pre-compiled builds.
While our "just-in-time" firmware compilation approach has served us well in the past, it has also caused inconvenience and frustration. Various factors, some of which were completely out of our control (e.g. updates to the platformio framework), have resulted in failed configurator builds, leading to user dissatisfaction.
To overcome these challenges, we have made a significant change in v3.3. Instead of relying on local compilation for release versions, the configurator will now seamlessly retrieve pre-built firmware from the cloud and flash it onto your device. This shift not only drastically reduces firmware update times from minutes to seconds but also eliminates many annoying build issues, where users are faced with the dreaded red "failed build" error message in the Configurator.
Make sure you have updated to version 1.6.0-rc1 of the Configurator to take advantage of this awesome new feature: https://github.com/ExpressLRS/ExpressLRS-Configurator/releases
#1904
In the hobby and commercial UAV industry, securing a dependable telemetry downlink alongside RC control often presents challenges in terms of cost, availability, and reliability. While Dragonlink has been the go-to option for a reliable long-range RC + telemetry link, it can be difficult to find in stock and tends to be expensive. Other alternatives, such as the RFD900 modems, are typically limited to 900MHz and also suffer from availability and cost issues.
This is where AirPort comes to the rescue.
AirPort offers a firmware option that transforms a standard ExpressLRS transmitter and receiver pair into a bidirectional transparent serial data link over the air. This enables seamless serial data communication between the connected devices, supporting any protocol of your choice, including MAVLINK (Ardupilot), MSP (Betaflight and INAV), or any other telemetry protocol that can be transmitted serially. This feature may also be useful for interfacing wirelessly with other ground devices, such as antenna trackers or similar.
Thanks to the increasing availability of ExpressLRS hardware, AirPort makes it effortless and cost-effective to incorporate an inexpensive telemetry uplink/downlink into your UAV models.
In previous versions, the only receiver protocol available for connecting ELRS to your FC was CRSF. While CRSF performs admirably in most scenarios and remains the preferred option if your hardware is compatible, what if your hardware doesn't support it? Typically, this would require the use of an additional protocol converter, such as the CRSF to SBUS converter.
In this release, we are delighted to introduce not just one, but THREE new receiver protocols, along with inverted options tailored for specific hardware requirements. This expanded protocol support ensures greater flexibility and compatibility, empowering you to seamlessly integrate ELRS with a wider range of hardware options.
#2094
That’s right, you read that correctly… after all that bitching and whining from us in the past, ELRS finally added SBUS as a receiver protocol! This is particularly useful for those closed-source FCs & flight stabilizers that only allow SBUS as an input. We’ve also added an inverted version of SBUS (which is normally inverted, so technically it’s un-inverting it - insert Xzibit meme) for hardware that doesn’t have the inverter on the UART.
PWM receivers can also be configured to output serial on some pins and select serial protocol, so now you can have CRSF/SBUS etc and PWM simultaneously!
#2137
Graupner HoTT SUMD joins SBUS as another user selectable receiver protocol, which can be found in many open source flight control firmwares (BF, INAV, ARDU) as well as a variety of flybarless controllers (helis).
#2140
The DJI RS Pro series, including the RS2 Pro and RS3 Pro gimbals, are renowned professional camera stabilizers often utilized on cinelifters for active stabilization of high-end cinema-grade cameras. While these gimbals can be controlled via an SBUS interface, DJI’s janky implementation of the protocol demands precise channel endpoints to trigger various functions, such as recentering.
To spare you the frustration of manually adjusting mixer settings as you attempt to discover the exact (and poorly documented) values expected by DJI for channel outputs, the ELRS team has introduced a dedicated version of SBUS, specifically tailored to these gimbals. This special version is preconfigured to seamlessly integrate with your RS2 Pro or RS3 Pro. For more detailed information regarding installation, please refer to the associated pull request: https://github.com/ExpressLRS/ExpressLRS/pull/2140 or check out a quick demo here: https://youtube.com/shorts/OPZykP-bP4k
#1993
Dry those eyes #Team900, ELRS now has True Diversity 900MHz receivers. A much sought after piece of gear that was frequently requested is now a reality. Check the new targets list for BETAFPVs Super-D, and I'm sure there will be more to follow!
But that's not all… with diversity also comes Gemini! Need a 900 Gemini Tx? Be sure to go and pester your favorite FPV manufacturer.
#2089
Exciting news! #Team900 is now part of the DVDA family! With the latest release, we introduce the new D50 packet mode, leveraging the 200Hz OTA modulation parameters to transmit 4 repeat packets across 3 frequencies. This approach is identical to the functionality of D250 for the 2.4GHz frequency range.
The primary goal of the D50 packet mode is to significantly enhance Link Quality (LQ) in RF-congested environments, particularly when flying alongside other pilots operating on the same frequency domain. By providing 4 transmission attempts for each packet, distributed across multiple frequency hops, you can enjoy improved reliability and stability during flights.
#2060
Support has been added into VRx & TX backpack as well as the main firmware to allow head tracking information to be sent wirelessly from the goggles to the TX module and then mixed into the channel output. At present, this functionality is exclusively supported by HDZero goggles, however we are optimistic that other goggle manufacturers will follow suit and incorporate compatibility with this exciting feature.
Target support has been added for 16 channel PWM receivers in both 2.4G and 900M flavors. Not only that, they are true diversity!
Any PWM channel can be set to a combination of the available PWM modes e.g. 400Hz, 10kHz PWM, On/Off switch. A single PWM channel can also be reassigned to a serial protocol (CRSF, Sbus etc). You want a FC connected plus native PWM output, you got it.
#2054
We understand that not everyone requires or utilizes the TX backpack feature in their transmitter setup. While enjoying a few cold ones at the ELRS headquarters, we asked ourselves: “If you’re not using the backpack, why have it sitting there chewing power?”, so we’ve introduced a convenient option to disable the TX backpack functionality. This can save a little juice (~0.3W) on the transmitter. Zorro users rejoice!
#2007
Proprietary VTX control protocols SUCK! That's right Smartaudio and Tramp… you guys suck. These protocols are owned by commercial manufacturers who never seem to do a good job at properly documenting the protocol specs, and have low motivation to extend their protocols for features that don’t directly interest them and their bottom lines.
MSP control for VTXs is a breath of fresh air that alleviates many of these pains, and now it’s supported in ELRS for hardware where the VTX is controlled by the same MCU as the receiver.
#2002
Allows you to run a Gemini TX in different antenna configurations:
#1968
If you have a receiver with analog VBAT and use a CRSF based VBAT sensor, then the receiver will favor the CRSF based sensor automatically.
Vitroid
, Senk0
, King David
, and FlyingBaguette
, whose diligent testing played a part in shaping this RC release. Your assistance has been truly appreciated.Published by pkendall64 over 1 year ago
Getting Started 3.0 Documentation
This is a minor version release (new features, targets and bug-fixes only) and is compatible with V3.X.
“ELRS is great, but the first-time setup was a PITA!”
This is one of the main complaints we see across the groups about ExpressLRS.
We understand the challenges faced during the initial setup process of ExpressLRS, with many users expressing their frustration. In version 3.3, we are doing something to improve this, starting with the introduction of pre-compiled builds.
While our "just-in-time" firmware compilation approach has served us well in the past, it has also caused inconvenience and frustration. Various factors, some of which were completely out of our control (e.g. updates to the platformio framework), have resulted in failed configurator builds, leading to user dissatisfaction.
To overcome these challenges, we have made a significant change in v3.3. Instead of relying on local compilation for release versions, the configurator will now seamlessly retrieve pre-built firmware from the cloud and flash it onto your device. This shift not only drastically reduces firmware update times from minutes to seconds but also eliminates many annoying build issues, where users are faced with the dreaded red "failed build" error message in the Configurator.
Make sure you have updated to version 1.6.0-rc1 of the Configurator to take advantage of this awesome new feature: https://github.com/ExpressLRS/ExpressLRS-Configurator/releases
#1904
In the hobby and commercial UAV industry, securing a dependable telemetry downlink alongside RC control often presents challenges in terms of cost, availability, and reliability. While Dragonlink has been the go-to option for a reliable long-range RC + telemetry link, it can be difficult to find in stock and tends to be expensive. Other alternatives, such as the RFD900 modems, are typically limited to 900MHz and also suffer from availability and cost issues.
This is where AirPort comes to the rescue.
AirPort offers a firmware option that transforms a standard ExpressLRS transmitter and receiver pair into a bidirectional transparent serial data link over the air. This enables seamless serial data communication between the connected devices, supporting any protocol of your choice, including MAVLINK (Ardupilot), MSP (Betaflight and INAV), or any other telemetry protocol that can be transmitted serially. This feature may also be useful for interfacing wirelessly with other ground devices, such as antenna trackers or similar.
Thanks to the increasing availability of ExpressLRS hardware, AirPort makes it effortless and cost-effective to incorporate an inexpensive telemetry uplink/downlink into your UAV models.
In previous versions, the only receiver protocol available for connecting ELRS to your FC was CRSF. While CRSF performs admirably in most scenarios and remains the preferred option if your hardware is compatible, what if your hardware doesn't support it? Typically, this would require the use of an additional protocol converter, such as the CRSF to SBUS converter.
In this release, we are delighted to introduce not just one, but THREE new receiver protocols, along with inverted options tailored for specific hardware requirements. This expanded protocol support ensures greater flexibility and compatibility, empowering you to seamlessly integrate ELRS with a wider range of hardware options.
#2094
That’s right, you read that correctly… after all that bitching and whining from us in the past, ELRS finally added SBUS as a receiver protocol! This is particularly useful for those closed-source FCs & flight stabilizers that only allow SBUS as an input. We’ve also added an inverted version of SBUS (which is normally inverted, so technically it’s un-inverting it - insert Xzibit meme) for hardware that doesn’t have the inverter on the UART.
PWM receivers can also be configured to output serial on some pins and select serial protocol, so now you can have CRSF/SBUS etc and PWM simultaneously!
#2137
Graupner HoTT SUMD joins SBUS as another user selectable receiver protocol, which can be found in many open source flight control firmwares (BF, INAV, ARDU) as well as a variety of flybarless controllers (helis).
#2140
The DJI RS Pro series, including the RS2 Pro and RS3 Pro gimbals, are renowned professional camera stabilizers often utilized on cinelifters for active stabilization of high-end cinema-grade cameras. While these gimbals can be controlled via an SBUS interface, DJI’s janky implementation of the protocol demands precise channel endpoints to trigger various functions, such as recentering.
To spare you the frustration of manually adjusting mixer settings as you attempt to discover the exact (and poorly documented) values expected by DJI for channel outputs, the ELRS team has introduced a dedicated version of SBUS, specifically tailored to these gimbals. This special version is preconfigured to seamlessly integrate with your RS2 Pro or RS3 Pro. For more detailed information regarding installation, please refer to the associated pull request: https://github.com/ExpressLRS/ExpressLRS/pull/2140 or check out a quick demo here: https://youtube.com/shorts/OPZykP-bP4k
#1993
Dry those eyes #Team900, ELRS now has True Diversity 900MHz receivers. A much sought after piece of gear that was frequently requested is now a reality. Check the new targets list for BETAFPVs Super-D, and I'm sure there will be more to follow!
But that's not all… with diversity also comes Gemini! Need a 900 Gemini Tx? Be sure to go and pester your favorite FPV manufacturer.
#2089
Exciting news! #Team900 is now part of the DVDA family! With the latest release, we introduce the new D50 packet mode, leveraging the 200Hz OTA modulation parameters to transmit 4 repeat packets across 3 frequencies. This approach is identical to the functionality of D250 for the 2.4GHz frequency range.
The primary goal of the D50 packet mode is to significantly enhance Link Quality (LQ) in RF-congested environments, particularly when flying alongside other pilots operating on the same frequency domain. By providing 4 transmission attempts for each packet, distributed across multiple frequency hops, you can enjoy improved reliability and stability during flights.
#2060
Support has been added into VRx & TX backpack as well as the main firmware to allow head tracking information to be sent wirelessly from the goggles to the TX module and then mixed into the channel output. At present, this functionality is exclusively supported by HDZero goggles, however we are optimistic that other goggle manufacturers will follow suit and incorporate compatibility with this exciting feature.
Target support has been added for 16 channel PWM receivers in both 2.4G and 900M flavors. Not only that, they are true diversity!
Any PWM channel can be set to a combination of the available PWM modes e.g. 400Hz, 10kHz PWM, On/Off switch. A single PWM channel can also be reassigned to a serial protocol (CRSF, Sbus etc). You want a FC connected plus native PWM output, you got it.
#2054
We understand that not everyone requires or utilizes the TX backpack feature in their transmitter setup. While enjoying a few cold ones at the ELRS headquarters, we asked ourselves: “If you’re not using the backpack, why have it sitting there chewing power?”, so we’ve introduced a convenient option to disable the TX backpack functionality. This can save a little juice (~0.3W) on the transmitter. Zorro users rejoice!
#2007
Proprietary VTX control protocols SUCK! That's right Smartaudio and Tramp… you guys suck. These protocols are owned by commercial manufacturers who never seem to do a good job at properly documenting the protocol specs, and have low motivation to extend their protocols for features that don’t directly interest them and their bottom lines.
MSP control for VTXs is a breath of fresh air that alleviates many of these pains, and now it’s supported in ELRS for hardware where the VTX is controlled by the same MCU as the receiver.
#2002
Allows you to run a Gemini TX in different antenna configurations:
#1968
If you have a receiver with analog VBAT and use a CRSF based VBAT sensor, then the receiver will favor the CRSF based sensor automatically.
Vitroid
, Senk0
, King David
, and FlyingBaguette
, whose diligent testing played a part in shaping this RC release. Your assistance has been truly appreciated.Published by wvarty over 1 year ago
Getting Started 3.0 Documentation
This is a bugfix release (bug-fixes only, no new targets or features) and is compatible with V3.X.
Published by CapnBry over 1 year ago
Getting Started 2.0 Documentation
The versioning scheme chosen by the ExpressLRS devs is based on the semantic versioning scheme.
Where a version is defined as “major.minor.patch”
major = major new feature and/or incompatible changes
minor = minor features or enhancements and/or new targets
patch = bug-fixes
Published by JyeSmith over 1 year ago
Getting Started 3.0 Documentation
This is a minor version release (new features, targets and bug-fixes only) and is compatible with V3.X.
Published by JyeSmith almost 2 years ago
Getting Started 3.0 Documentation
All PWM receivers.
Published by pkendall64 almost 2 years ago
Getting Started 3.0 Documentation
V3.1.0 was pulled as there was a serious upgrade issue for some users on Windows systems. Their TX module or ESP32-based receivers appeared soft-bricked, as they would enter wifi hardware-configuration mode because of an obscure bug in the platformio ESP32 base system which left the flash chip unable to be read by the firmware.
There were also a couple of other bugs found during testing that we really wanted to get fixed.
This is a minor version release (new features, targets and bug-fixes only) and is compatible with V3.X.
All users that require LBT (i.e. the EU/CE regulatory domain for 2.4GHz)
Published by JyeSmith almost 2 years ago
Getting Started 3.0 Documentation
This is a fix release and compatible with V3.0.0.
All receivers based on the STM32 MCU, and the SIYI FM30 2.4GHz TX.
Published by wvarty about 2 years ago
Getting Started 3.0 Documentation
This is a new major version, 3.x, and like previous major versions the software is incompatible with the previous major versions, ExpressLRS 1.x and 2.x. TXes running 3.x software only work with RXes running 3.x software-- both sides must be upgraded. SPI RXes all currently run 2.x and will not work with a 3.x TX.
Users of SPI receivers (AIO boards) maintain compatibility with currently available V2 RF modes. Flight controllers can be updated from PR https://github.com/betaflight/betaflight/pull/11783 or wait until merged into BF master.
FLRC - The F is for Fast (modulation) and lower latency, but a shorter range than our normal modes. Our version can still easily do +10km and comes in 500Hz and 1000Hz flavors https://github.com/ExpressLRS/ExpressLRS/pull/1277
Déjà Vu Diversity Aid (DVDA) - On top of FLRC, these modes use multiple sends to create more reliable connection when faced with interference such as at FPV races with many transmitters. 250Hz and 500Hz versions, which do quad and double sends respectively, and across multiple frequencies. https://github.com/ExpressLRS/ExpressLRS/pull/1527
More Full Resolution channels (Full) - Instead of just 4ch + 8x switches, support for 10-bit 8ch/12ch/16ch modes in 100Hz and 333Hz rates, using LoRa modulation. https://github.com/ExpressLRS/ExpressLRS/pull/1572
LBT - For compliance, listen-before-talk has been added to allow certification of our TX modules in the EU up to 100mW. https://github.com/ExpressLRS/ExpressLRS/pull/1243
Increased precision over 2.x modes - 25% better stick precision in the 988us to 2012us range, except for fullres modes. 1 "bit" over-the-air used to represent 1.2us of stick, now 1 bit = 1us. https://github.com/ExpressLRS/ExpressLRS/pull/1572
Video: ExpressLRS 3.0 Packet Modes Explained https://youtu.be/ymv9OJFWgJ4
Published by JyeSmith about 2 years ago
This is a new major version, 3.x, and like previous major versions the software is incompatible with the previous major versions, ExpressLRS 1.x and 2.x. TXes running 3.x software only work with RXes running 3.x software-- both sides must be upgraded. SPI RXes all currently run 2.x and will not work with a 3.x TX.
Published by JyeSmith over 2 years ago
This is a new major version, 3.x, and like previous major versions the software is incompatible with the previous major versions, ExpressLRS 1.x and 2.x. TXes running 3.x software only work with RXes running 3.x software-- both sides must be upgraded. SPI RXes all currently run 2.x and will not work with a 3.x TX.
Published by FOG-Yamato over 2 years ago
Getting Started 2.0 Documentation
The versioning scheme chosen by the ExpressLRS devs is based on the semantic versioning scheme.
Where a version is defined as “major.minor.patch”
major = major new feature and/or incompatible changes
minor = minor features or enhancements and/or new targets
patch = bug-fixes
Published by wvarty over 2 years ago
Getting Started 2.0 Documentation
streamexpect
library that is used to support ETX passthrough had ones of it's dependencies updated in an incompatible way, so we've included this library directly into the build chain code (#1564)The versioning scheme chosen by the ExpressLRS devs is based on the semantic versioning scheme.
Where a version is defined as “major.minor.patch”
major = major new feature and/or incompatible changes
minor = minor features or enhancements and/or new targets
patch = bug-fixes
Published by JyeSmith over 2 years ago
Getting Started 2.0 Documentation
The ExpressLRS team would like to thank RadioMaster and EdgeTX for their collaboration on integrating ExpressLRS into the TX16S.
The versioning scheme chosen by the ExpressLRS devs is based on the semantic versioning scheme.
Where a version is defined as “major.minor.patch”
major = major new feature and/or incompatible changes
minor = minor features or enhancements and/or new targets
patch = bug-fixes
Published by wvarty over 2 years ago
Getting Started 2.0 Documentation
The ExpressLRS team would like to thank Divimath / HDZero for their support and collaboration on an integration between ExpressLRS, and the HDZero Video Receiver (VRX).
Currently, the high level feature set allows a user to:
There may be more features introduced in future to further extend this integration.
For more information, see the Manual for the HDZero Backpack here: https://docs.google.com/document/d/1L4U4uEqYhuwCww_RxSpavNetltbHMvLAknhM0HjRnwE/edit?usp=sharing
NOTE: This integration uses the Backpack functionality (See https://github.com/ExpressLRS/Backpack), and requires that a backpack receiver, running v1.0 or later be added to your VRX
The versioning scheme chosen by the ExpressLRS devs is based on the semantic versioning scheme.
Where a version is defined as “major.minor.patch”
major = major new feature and/or incompatible changes
minor = minor features or enhancements and/or new targets
patch = bug-fixes
Published by JyeSmith over 2 years ago
Getting Started 2.0 Documentation
The ExpressLRS team would like to thank RadioMaster and the EdgeTX team for their support and collaboration on an internal ExpressLRS module. RadioMasters contribution of numerous prototypes and final product hardware for testing has resulted in the first fully featured and supported handset... the RadioMaster Zorro!
https://www.radiomasterrc.com/products/zorro-radio-controller
https://github.com/EdgeTX
The versioning scheme chosen by the ExpressLRS devs is based on the semantic versioning scheme.
Where a version is defined as “major.minor.patch”
major = major new feature and/or incompatible changes
minor = minor features or enhancements and/or new targets
patch = bug-fixes