Betaflight 4.4: HD OSD, GPS RTH and More!

BetaFlight 4.4

Without any doubt, BetaFlight is the most popular open-source flight controller firmware. It is a mature software with a great community around it. It is permanently updated and improved. The latest BetaFlight 4.4 comes with seven significant improvements and many bug fixes. Most F4 and F7 flight controllers support this firmware. Firstly, I will install the v4.4 BF firmware on my SKYSTARS F722HD FC and all my FPV drones.

BetaFlight differs from Baseflight and Cleanflight in focusing on flight performance, leading-edge feature additions, and wide target support. With the Betaflight OSD, you can get all relevant flight metrics directly into your FPV video feed. An easy-to-use drag-and-drop configuration allows the placement of values like used mAh and LiPo Voltage readings. Additionally, you can change most firmware settings using stick commands without even removing your goggles.

#AD

Top 7 improvements in Betaflight 4.4 firmware

1. Cloud build

This is predominantly brought to you for convenience and to ensure we can keep the 512kb flash targets (STM32F411 and STM32F722) alive and well for years to come. The cloud build system will allow the flyer to select the features you want, and custom firmware will be created for you. Please check out the #cloud-build-issues Discord channel for any issues with the cloud-build process. Help us to help you, by taking advantage of the new Support button in the Command Line Interface (CLI) tab in Configurator 10.9.0 (RC4 onwards). This will give us valuable information in trying to diagnose your issue.

If you have something missing, we suggest flashing the core version. This will load all the hardware drivers (but not all features), and then you can submit a Support level of detail from the CLI tab. In addition, you can use the custom defines input box shown when “Expert Mode” is enabled.

For those missing a barometer: You can try any or all of BARO_MS5611 BARO_SPI_MS5611 BARO_BMP280 BARO_SPI_BMP280 BARO_BMP388 BARO_SPI_BMP388 BARO_LPS BARO_SPI_LPS BARO_QMP6988 BARO_SPI_QMP6988 BARO_DPS310 BARO_SPI_DPS310 BARO_BMP085 BARO_2SMBP_02B BARO_SPI_2SMBP_02B in the custom defines input box.

For those missing the flash chip: You can try any or all of FLASH_W25P16 FLASH_W25Q128FV FLASH_W25M02G FLASH_W25N01G FLASH_W25M in the custom defines input box.

Thank you all for your patience and assistance in working through what boards have what hardware. Unfortunately, we need our flyers to help crowd-source this information – as such diverse hardware is out there!

NOTE: If you have something missing from your cloud build that you would normally expect to be present, e.g., a flash chip or barometer, the reason is that the board configuration (in unified targets) has not been updated with this information (either by the community, or the manufacturer).

2. HD Digital OSD (DJI)

HD OSD is now supported and adds the following features. Not all HD Goggle/VTX combinations support all features but hopefully will do so in time.

If the OSD option alone or the OSD (HD) option is included in the build options, then HD support will be included.

To enable HD support, select VTX (MSP + Displayport) on the ports tab for the UART to which the VTX is connected. The MSP option will automatically be selected.

The OSD HD preview may be manually selected on the OSD tab alongside the PAL and NTSC options; however, this is not necessary as the first time the HD Goggle/VTX system is powered, the FC detects it and automatically applies the following settings, saves and reboots automatically. This only happens if the setting below is not already applied. This is a new feature and may not be supported by your HD system yet, so if the OSD tab does not automatically switch to HD, please enter the commands below manually.

set osd_displayport_device = MSP
set vcd_video_system = HD

The size of the canvas (visible number of columns/rows) defaults to 53×20 (compared to 30×16 for PAL and 30×13 for NTSC). The VTX can adjust this by sending an MSP command to adjust the canvas size. WTFOS will set this to 60×22, for example. This will be automatic, with no user interaction required. Should the goggles vendor decide to support alternate canvas sizes, then they would be selected in the goggles menus, and the new canvas size communicated to Betaflight, which would then adjust the usable number of OSD rows/columns accordingly.

Regardless of the canvas size, the boot logo, armed message, stats, CMS menu, etc. will be centered correctly.

If the canvas size is reduced, either by selecting the PAL/NTSC options or by the VTX sending a different canvas size, all OSD elements will be moved onto the available canvas so they can be repositioned using the configurator.

In addition to the usual OSD elements, it is now possible, where supported by the FPVGoggles/VTX vendor, to enable/disable and reposition the following OSD elements. If none are explicitly enabled, all those supported will be displayed at their default locations.

  • Goggle battery voltage
  • VTX voltage
  • Bit-rate
  • Delay
  • Distance
  • Video link quality
  • Goggle DVR icon
  • VTX DVR icon
  • VTX warnings
  • VTX temperature
  • Goggle fan speed

To make better use of the colour OSD capabilities of the HD systems, four fonts are now supported. The intent is that these be used to display text and other icons in white, green, amber and red corresponding to normal, good, marginal, and critical conditions, respectively. This will allow the link quality text and icon to be displayed in red when critical, amber when marginal, and green when good, for example.

To enable this feature set the displayport_msp_fonts array to select the font number (0-4) to use for each of normal, good, marginal, and critical conditions, respectively.

To enable all four fonts: set displayport_msp_fonts = 0,1,2,3

To only use the default (predominantly white) font: set displayport_msp_fonts = 0,0,0,0

To display critical warnings in red, select the first font for normal, good, and marginal OSD elements, and for critical OSD elements, select the third font: set displayport_msp_fonts = 0,0,0,3

3. Preset Favourites

This feature reduces the amount of searching the users have to do in the presets tab. The BetaFligh configurator will remember the presets you are using, automatically marking them with the “star”. Favorite presets will always appear first in the initial list and the search results. Combined with the fix that preselects the current firmware from the plugged-in FC, users can avoid altogether searching of the commonly used presets and pick them right away. The UI “stars” are clickable, so users can manually add/remove favorite presets. 

4. GPS Return to Home enhancements

GPS “Rescue” has been extensively revised and greatly improved. The quad should reliably return at the set speed, descend at an angle, land within a few meters of the home point, and disarm automatically on touch-down. There are separate PID control elements for altitude and return velocity t home; the defaults work very well for ‘typical’ quads. The system should initially be tested with a switch at a reasonably close range and low altitude. Setting up and testing GPS Rescue to provide a reliable return in case of a RxLoss failsafe is a non-trivial task but well worth the trouble.

The BetaFlight team strongly recommends reading the wiki entry and following the instructions.

Remember that in any true failsafe, the quad will always enter Failsafe Stage 1 phase for 1s (user-configurable) before initiating the Rescue. You MUST set the Stage 1 behavior NOT to DROP, or it will disarm and drop in Stage 1 and never enter GPS Rescue. The safest option for Stage 1 is to configure Angle Mode on an aux switch and set Stage 1 Failsafe to enable Angle Mode at a fixed hover/light climb throttle value with all other sticks forced to center. When you get a signal loss of more than 300ms, you’ll enter Angle Mode, and it will start to level out. That will clearly warn you that you are getting a signal breakup. Alternatively, you can set Failsafe Stage 1 to hold all current values; the quad will then continue on the same path until Stage 1 Failsafe expires and the Rescue starts.

Please disable the compass/magnetometer unless:

  • it has been fully calibrated, and
  • You have confirmed, by logging, that the magnetometer heading values are noise-free and reflect the true attitude of the quad.

In most short flights, using the Baro significantly improves altitude control. Baro data is updated more frequently than GPS data and often varies less. The user can control how much trust they place on the Baro vs GPS altitude data. Over long flights and with some particular Baro units or installations, Baro drift can be more of a problem, and the GPS data should be trusted more.

There are three new and handy GPS Rescue debugging modes. One shows how accurately the quad tracks the requested altitude and the requested velocity. The other two are used for tuning the GPS Rescue PIDs. If Mag is enabled, Mag information is automatically recorded.

Data acquisition from GPS hardware now uses the UBlox protocol, at 10hz, by default. NMEA mode has been improved and, in some cases, will run at 10hz. We can now log the Dilution Of Precision values for future improvements.

There are extensive changes to sanity checks, and in most cases, the quad will attempt to land itself rather than disarm, if necessary, using only the Baro signal.

WARNING: ALWAYS CHECK that the Home Arrow points directly back towards home after takeoff! Sometimes, if you take off and spin around during arming or immediately on takeoff, the quad’s attitude information can become corrupted, and the Home Arrow can point the wrong way. It’s best to arm cleanly and fly away from Home in a straight line at a reasonable speed immediately after takeoff. Watch the Home Arrow carefully to ensure it quickly points back to Home. If the Home Arrow points the wrong way when a failsafe occurs, the GPS Rescue will initially fly off in the wrong direction, and in some cases, you may lose the quad.

5. Other OSD improvements

Option to show ‘READY’ in the OSD with a mode switch. This is a niche improvement for racing situations where all pilot video feeds are on one central screen. The pilot can flick a switch to indicate that they are ready to fly, and the word READY appears on their OSD. The race director can then tell if all pilots are ready by looking at the central screen. On arming, the READY text disappears.

6. Support for extended DShot Telemetry

If the ESC supports it, we can get per-motor temp, current, and voltage via DSHot Telemetry.

7. Flight improvements

BetaFlight 4.4: Antigravity

AntiGravity has been tweaked, resulting in greater stability during rapid throttle changes, by:

  • Not applying AntiGravity P boost to yaw, preventing additional yaw wobbles during rapid throttle changes
  • Reducing the overall AntiGravity P boost to reduce the chance of unwanted P wobbles
  • Allows the relative P gain during AntiGravity to be set independently of the I boost, with anti_gravity_p_gain. The default is 100, meaning ‘normal’. A lower number will give proportionally less P boost than the default for machines that get P wobbles readily during throttle boost, and vice versa.
  • Further optimizations of the timing of the boost effect. A PT2 filter is used at 6Hz by default. The value can be tweaked to focus the boost when needed most by changing the anti_gravity_cutoff value. Higher values will make the boost a bit stronger but of a shorter duration. Lower values may work better for less responsive builds or for a more prolonged boost.
  • Applying iTerm windup constraints to antigravity-induced iTerm increases 
  • Removing the old ‘step’ mode, which wasn’t working as intended, the AntiGravity value is now directly related to the amount of iTerm boost. The default is 80, meaning 8x iTerm boost on fast throttle cuts. Do not increase AntiGravity unless you’ve made a log and confirmed that there is no P wobble.

7. ELRS 3.x support for ELRS SPI boards

Unfortunately, ELRS 2. x transmitters will not be able to bind to ELRS SPI Boards flashed with Betaflight 4.x.

Other changes

  • Four PID profiles (was 6), and 4 rate profiles (was 3) – thanks @haslinghuis
  • TPA settings inside the PID profile – thanks @haslinghuis
  • improved barometer smoothing and calibration, attitude calculation fixes, filter fixes – thanks @karatebrot
  • HD OSD support – thanks @SteveCEvans
  • VTX device over MSP PR11705 – thanks @phobos
  • parse and log GPS degree of precision (DOP) values PR11912 – thanks @karatebrot
  • hardware support for newer gyro chips, improved filtering for BMI160/270, etc – thanks @SteveCEvans and others
  • lower minimum of 20Hz for dynamic notch, useful for low RPM setups with very large props
  • increased dynamic idle minimum RPM from 100 (10k RPM) to 200 (20k rpm) for quads with very small props
  • support for 64 discrete LEDs via cloud build option – PR12064 – thanks @Limonspb
  • Fixes to NMEA at 10hz and UBlox comms – thanks @Karatebrot, @krzysztofkuczek
  • Winbond W25q80 flash support – thanks @David-OConnor
  • Many bugfixes, target updates, driver updates, and fixes – thanks to too many people to mention individually

5 COMMENTS

  1. It is only release candidate five, final version is coming soon.
    Betaflight 4.4.0 RC5 – 17th January 2023
    Betaflight 4.4.0 RC4 – 14th January 2023
    Betaflight 4.4.0 RC3 – 2nd January 2023
    Betaflight 4.4.0 RC2 – 27th December 2022

  2. I just flashed BF 4.4.0 RC5 on my Foxeer Reaper AIO V3 F745 board, and the previous configuration was lost :(. I tried to CLI load it but gives lots of errors..

LEAVE A REPLY

Please enter your comment!
Please enter your name here