Reusing Betaflight OSD and modes

A practical guide to transferring CLI settings between builds

Copy your screen layout and switch assignments as small, reviewed modules. Keep the new build’s hardware configuration separate. This gives you a familiar cockpit and controls without replacing settings that belong to its flight controller, wiring, motors, or receiver.

This guide explains what to export, which lines to keep, how to apply them, and how to maintain a reusable library. It covers OSD and mode assignments; copying those settings does not transfer the aircraft’s tune or make a new aircraft ready to fly.

Start with these rules

Back up both aircraft before editing. Remove propellers for setup and all bench checks involving arming or motor operation.

Use the actual firmware version and CLI output from each aircraft. Command names, available features, and encoded values can vary by release and firmware build.

Use a full dump as the source for a complete module, then select only the lines you intend to transfer. A diff is useful for review and backup but omits values that match defaults.

Prepare the destination receiver and video system first. Matching switch behavior and display geometry are prerequisites for useful portability.

Paste modules without save, inspect the result, and save only after resolving errors. Never include defaults or a whole-board reset in an OSD or modes module.

What belongs together

Examples use familiar Betaflight 4.5-era syntax where identified. They are teaching examples, not a tested configuration for your aircraft. For a different release, create the equivalent settings in its compatible App or Configurator, then export a new module. [1–4]

1 Capture the source and destination

Export the old build

Connect the old aircraft, open the CLI, and run these read-only commands separately. Save their output as plain text with the aircraft name, exact firmware version, target and date. Keep screenshots of the OSD and Modes tabs beside the files.

version
status
diff all
dump all
aux
adjrange
get osd

Keep diff all as a compact record of changes and dump all as the complete source of values, including defaults. The aux output captures mode rows; adjrange captures adjustment rows, which can include OSD profile switching. get osd is useful for inspection, but its explanatory output is not a ready-to-paste script. Use the set lines from the dump. [1, 2]

Export the new build before changing it

Repeat the exports on the destination. Label them BEFORE. Record its working receiver channel map, Ports configuration and video system. Complete its normal hardware setup before importing your personal settings. Use its own backup for rollback; the old aircraft’s full dump is not its recovery file.

Check compatibility before extracting

Why a diff alone is incomplete

Suppose the old aircraft uses a default value for an OSD item and the new aircraft already has a different value. That item may be absent from the old diff. Pasting the diff leaves the destination’s value intact. A complete layout module must explicitly define both visible and hidden supported items, including source values that happen to match defaults.

For a firmware migration, reproduce the intended layout and switch behavior in the destination version’s interface, verify it, then export it. Avoid treating a successful paste as proof of equivalent behavior.

2 Choose the OSD settings to copy

Use this table as an extraction checklist. The asterisk means a family of setting names, not a CLI wildcard command. Keep only names actually exported and supported by the relevant firmware. [2–5]

Position values are encoded data

An OSD position number is not simply a pixel coordinate. Betaflight 4.5.2 packs position, profile visibility and type information into the value. Copy the exported number intact for a compatible layout. Do not calculate a new screen position by adding a guessed offset. Move the element in the OSD editor and export again. [5]

Keep appearance separate from measurements

Showing voltage, current or consumed mAh does not calibrate those readings. Keep voltage and current sensor calibration with each aircraft. Recheck capacity-related alarms for its battery. Likewise, showing link quality does not configure the receiver or establish a suitable warning threshold.

Do not blindly collect every line containing osd. The display device and canvas settings on the next page also contain that word. Review the complete candidate list before making it reusable.

3 Separate the display and profile dependencies

Configure the destination display first

Treat osd_displayport_device, displayport_* settings, vcd_video_system, osd_canvas_width and osd_canvas_height as a display adapter when present. UART serial configuration belongs here too. These describe how the screen is driven and what space it offers, not just your preferred arrangement.

For an MSP DisplayPort video system, configure the UART actually wired to that VTX using the destination version’s Ports interface. On supported releases this is the VTX MSP plus DisplayPort peripheral. Do not copy the old serial line merely because the old build also used digital video. [6]

Power the video system as required, with its antenna installed and adequate cooling. Check the OSD preview against the actual goggles. Digital equipment can announce a canvas size to Betaflight; the negotiated grid may differ from the one you expected. [7]

Make one layout per verified screen geometry

Keep separate files such as osd-analog-pal.txt and osd-hd-verified-grid.txt. Record the actual columns and rows in each file. A layout designed for a larger screen can place elements outside a smaller one. Reposition edge elements in the destination OSD editor and export the adapted layout.

A CLI export also does not package the glyph artwork stored in an analog OSD chip or the font assets used by digital goggles. If symbols look wrong, check the appropriate font installation and vendor OSD support. Moving coordinates will not repair a font mismatch.

OSD pages and profile switching

Betaflight supports multiple OSD profiles on suitable builds. These control which elements are visible. In the documented profile implementation, an element shares one position across the profiles where it appears; profiles are not independent coordinate layouts. [4]

If your radio selects the OSD profile, retain the associated adjrange row as a separate optional module. This is an adjustment, not an ordinary aux mode assignment. Check its range channel, selector channel and adjustment function against the destination interface. Avoid borrowing a numeric function ID from an unrelated version. [8]

# Inspection only
get osd_profile
adjrange

OSD profiles, PID profiles and rate profiles are different systems. Do not include profile or rateprofile blocks from a full dump just to preserve an OSD page. After saving, test page selection outside the CLI. [4]

4 Copy and understand mode assignments

The aux command with no arguments lists mode assignments. Each row has a slot number; the slot is not the channel number. In Betaflight 4.5.2, the exported row includes the mode ID, zero-based AUX index, activation range, logic and linked mode. Preserve all fields when moving a verified row. [3, 9]

aux 0 0 0 1700 2100 0 0

In this 4.5.2 example: slot 0 assigns ARM, whose permanent mode ID is 0, to AUX1, whose CLI index is 0. Its range is 1700–2100. The final fields select OR logic and no linked mode. Check the destination Modes tab rather than inferring safety from those numbers alone. [9]

That channel mapping assumes the usual first four control channels. Verify the bars in the Receiver tab. The transmitter’s switch name is not stored in an aux row, so the same row can act on a different physical switch in another radio model. [3]

A small example to read before adapting

# Illustrative 4.5.2 rows, not a complete mode table
# ARM on AUX1 high
aux 0 0 0 1700 2100 0 0
# ANGLE on AUX2 high
aux 1 1 1 1700 2100 0 0
# BEEPER on AUX3 high
aux 2 13 2 1700 2100 0 0

Acro is the normal rate mode when no auto-level mode is selected; it does not need a dedicated Acro row. ANGLE requires a functioning accelerometer. Assigning GPS Rescue or another feature to a switch does not complete that feature’s setup. [3]

Prevent leftover and conflicting rows

Pasting slots 0–2 does not erase slots 3 onward. Choose deliberately: merge selected rows into unused destination slots, or replace the complete mode table. For replacement, remove unwanted ranges in the Modes tab and save, then apply the reviewed table. Inspect every destination slot afterward.

For a repeatable complete module, export the finalized destination aux table, including its disabled rows. Do not assume every release has the same number of slots or invent an aux clear command. Also review existing adjrange rows: they can still change settings even after modes are replaced.

5 Build a modular configuration library

The following file structure is a recommended workflow. Plain text modules are easy to inspect and compare. They become portable through explicit compatibility notes and dependencies; the filenames do not make Betaflight automatically load them.

betaflight-library/
  bf-<exact-version>/
    10-osd-preferences.txt
    20-osd-<verified-grid>.txt
    30-modes-<radio-channel-plan>.txt
    40-osd-profile-switch.txt
  builds/
    <craft>/
      hardware-and-display-notes.txt
      90-build-overrides.txt
      before-dump.txt
      after-dump.txt
      README.txt

Give each module one responsibility

Preferences owns units, timers and reviewed warning or statistics selections. Layout owns the complete supported position list and initial OSD profile. Modes owns either the complete aux table or a documented set of slots. Profile switching owns only the necessary adjrange rows. Build overrides owns intentional exceptions, such as battery-specific alarms and craft identity.

Keep receiver protocol, UARTs, resources, motor outputs, board alignment, PID and filter tuning, failsafe settings and sensor calibration out of the shared OSD and modes files. Configure those for the aircraft. Treat permanent AIRMODE versus switch-controlled AIRMODE as an explicit behavioral decision rather than copying every feature line.

Document the module contract

# Module: pilot layout
# Firmware: exact tested version and build
# Display: system plus verified columns and rows
# Requires: working destination OSD
# Owns: complete supported osd position list
# Apply after: destination display setup
# Save: manually after reviewing all modules

For a modes module, add a readable channel plan: AUX1 arm, AUX2 flight mode, AUX3 beeper, and any prearm or crash-flip switch. Record switch positions and expected behavior. For optional rows, state the required sensor or feature.

Extract narrowly and review conflicts

In a text editor, search the full dump for aux rows and set osd_ lines. A regular expression such as ^set osd_.*_pos\s*= selects candidate position lines. It does not validate firmware compatibility or screen fit. Copy reviewed timer, unit and other preference lines separately; do not paste the entire search result blindly.

Remove reset commands, unrelated sections and embedded save commands. When two modules set the same variable or row, the later one wins. Document intentional overrides and remove accidental duplicates. A complete module should give the same owned settings when applied again. This does not imply it resets settings it does not own.

6 Create your own Betaflight presets

Use personal presets to standardize the parts of each build that you want to feel familiar: screen information, switch roles and optional OSD page selection. Start with the reviewed modules from section 5. Keep one OSD preset per verified display geometry and one modes preset per radio channel plan.

Package a small preset first

A Presets-tab file combines CLI commands with metadata. TITLE, FIRMWARE_VERSION, CATEGORY and STATUS are required. OSD and MODES are valid categories. Start with EXPERIMENTAL status and describe the settings and prerequisites. The firmware tag controls compatibility filtering; it does not convert commands or prove that they work. [11]

This deliberately small example sets only metric units. Save it as presets/4.5/osd/pilot_metric_v1.txt in your preset repository. The 4.5 tag is illustrative: use a supported version identifier and verify on the exact firmware you intend to use.

#$ TITLE: Pilot metric units v1
#$ FIRMWARE_VERSION: 4.5
#$ CATEGORY: OSD
#$ STATUS: EXPERIMENTAL
#$ AUTHOR: YourPilotName
#$ DESCRIPTION: Sets OSD units to metric.

set osd_units = METRIC

Expand this file only after the small example works. Add your verified timer and presentation lines, then create a separate layout preset from the complete position list. For modes, use a separate MODES file containing your reviewed aux table. Describe whether it replaces the whole table or changes selected slots.

Add it as a custom source

Fork the official firmware-presets repository to your GitHub account, clone it, and create a personal branch. Add your files, rebuild and check the index, then commit and push the files and generated index. In Presets > Preset Sources, add your repository URL and branch. Official submission is optional for personal use. [11]

# Run in the preset repository on your computer
node indexer/indexer.js
node indexer/check.js

The indexer creates index.json and index_hash.txt when validation succeeds. check.js runs validation without saving the index. Resolve errors before pushing; regenerate after changing preset files or paths. These commands check repository structure, not aircraft behavior. [12, 13]

Use the repository URL, such as https://github.com/YourAccount/firmware-presets, rather than a raw text-file URL. Select your source and compatible firmware filter, then search for the preset title. Treat a publicly accessible fork as public: keep binding secrets and private information out of its files.

7 Keep presets consistent across builds

Design a small personal preset collection

Define your channel plan before creating the modes preset. For example, use the same AUX channel for arming on each transmitter model and document the expected physical switch. If a new build needs an exception, give it a distinct preset or a recorded override. Avoid silently changing the common preset to fit one aircraft.

Use includes and options deliberately

INCLUDE can share payload files; OPTION blocks expose selectable command groups. Mutually exclusive option groups can separate alternatives. [11]

For your first collection, prefer separate, clearly named presets. If you later add a combined pilot preset, use plain shared payloads without their own options, and put the selectable choices in the parent. Review the generated CLI for every combination. Never allow two selected layouts to overwrite each other unintentionally.

Do not paste a preset source file containing options directly into the CLI. Its metadata lines are comments to the flight controller, so commands inside unchecked options would still execute if pasted. Apply through the Presets interface, or manually extract only the intended plain CLI payload.

Test the preset and record its revision

1. Back up a configured destination, apply the preset through the Presets tab, and review the proposed changes and any options. Save only after the command review is clean.

2. Perform the checks in section 8. Also try the preset against a backed-up setup with different OSD values or extra mode rows; confirm that its documented replacement or merge behavior holds.

3. Apply the same revision again and compare its owned settings. Reapplication should not introduce a different result.

4. Record each build’s exact firmware, preset revision or Git commit, chosen options, display grid, radio plan and final overrides. Preserve the AFTER dump with this record.

Keep a tested stable branch for everyday use and a development branch for changes. Name meaningful revisions v1, v2 and so on, with a short change log. Revalidate before moving a change to stable. Updating the repository does not update aircraft that already used a preset; schedule and verify each reapplication yourself.

Consistency means matching the intended pilot experience. Battery alarms, receiver transport, calibration, motor settings and tuning still belong to each aircraft. A personal preset should make repeated choices predictable without making unrelated hardware settings identical.

8 Apply and verify the transfer

Apply in a controlled order

1. Finish the destination hardware, receiver and video setup. Export the BEFORE backup and confirm that propellers are removed.

2. Confirm the radio model and each AUX channel. If replacing modes, remove unwanted destination ranges first; also inspect adjustment rows.

3. Paste preferences, the matching layout, modes, optional profile switching and finally build overrides. Use small blocks without save.

4. Read every response. Stop on unknown settings, invalid values, parse errors or unexpected row output. Recheck values with get and list aux and adjrange.

5. If an error leaves the in-memory configuration uncertain, use exit without saving to discard that session’s unsaved edits. Correct the files before retrying. This does not undo anything saved earlier. [1]

6. Once the CLI review is clean, enter save. Reconnect and verify the OSD, Modes and Adjustments tabs, then the actual goggles and switches.

Bench checks before flight

Modes: verify every switch position, including startup with the arm switch already high, intended prearm behavior and disarming. USB or an open CLI can prevent arming; inspect status flags rather than disabling safeguards to force it.

OSD: check every intended profile, warnings visibility, timers, units and all screen edges. Compare displayed measurements with plausible readings. Test switch selection after leaving the CLI.

Dependencies: confirm accelerometer behavior for leveling modes, the receiver link and the configured failsafe response. Validate GPS-related features separately using the procedure for that firmware.

Complete the new aircraft’s normal motor order, motor direction and failsafe checks with propellers removed. An OSD and modes import does not replace these checks.

Save the result you actually verified

Export fresh diff all, dump all, aux and adjrange output as AFTER files. Compare BEFORE and AFTER: only the intended module settings and documented prerequisite changes should differ. Record firmware, radio model, display grid and the checks performed. Export revised modules from this verified state.

Rollback

Before save, abandon unsaved edits with exit. After save, restore the destination’s previous values for every changed setting and row, including rows you removed. A full recovery should follow the restore procedure for that destination’s exact firmware and target. Recheck behavior after recovery; never use the source aircraft’s whole dump as a shortcut.

9 Troubleshooting

Official sources

Reviewed October 1, 2026. Consult the reference for your installed release. The 4.5.2 source links below establish the syntax and encoding of the examples; they are not a claim that newer releases behave identically.

1 Command Line Interface

2 Betaflight 2025 12 CLI reference

3 Modes and AUX configuration

4 OSD Profiles

5 Betaflight 4 5 2 OSD encoding source

6 Betaflight 4 4 release notes and HD OSD setup

7 DisplayPort MSP canvas protocol

8 In Flight Adjustments

9 Betaflight 4 5 2 CLI implementation

10 OSD Tab

11 Firmware Presets specification and custom sources

12 Preset index generator

13 Preset checker