CLI Command Reference

The CLI provides direct, text-based access to the flight controller, available from the CLI tab in the Configurator, or over any serial terminal at the configured baud rate.

Common commands

Command	Description
help	List available commands
status	Show system status
version	Show firmware version info
dump	Print the full configuration (including defaults)
dump all	Print the full configuration for all profiles
diff	Print only settings that differ from defaults
diff all	Print changed settings across all profiles
save	Save changes and reboot
exit	Exit the CLI (without saving)
defaults	Reset to firmware defaults

Backup and restore

diff all is the preferred backup format for day-to-day use -- compact, and easy to review. Paste the saved output back into the CLI and run save to restore it. See Backup & Restore for the full workflow.

Serial port diagnostics

serialdebug helps when a device on a serial port (GPS, receiver, telemetry, ESC sensor) isn't working. It shows how each port is set up, what the function on a port reports, and the raw data a port receives.

Command	Description
serialdebug	Show every port
serialdebug <port>	One port in detail, with what its function reports
serialdebug monitor <port> [<baud>] [<seconds>] [inverted]	Print what a port receives
serialdebug scan <port> [inverted]	Try common baud rates and look for known protocols

<port> is the port number used by the serial command (UART1 is 0, UART7 is 6, UART10 is 9) or its name, such as UART7. serialdebug with no arguments lists the numbers, and serialdebug help prints the usage.

All ports

# serialdebug
port     id  rx   tx   functions         open  baud
VCP      20  -    -    MSP               yes
UART1     0  -    -    -                 no pins
...
UART3     2  D09  D08  RX_SERIAL         yes   460800 (irq rx)
UART7     6  E07  E08  GPS               yes   57600
UART10    9  E02  E03  -                 no
...

• rx / tx: the pins assigned with resource SERIAL_RX / SERIAL_TX.
• open: whether the port is running. NO (in capitals) means it has a function but did not open. no pins means no pins are assigned, so the port can't be used. PIN CONFLICT means one of its pins is also used by something else, such as a servo or LED; see resource show.
• (irq rx): the port's owner reads incoming bytes as they arrive (for example a serial receiver); monitor still works on it.

Lines starting with # point out setup problems: a port whose function did not open, a pin conflict, or a gps_provider with no matching port (for example UBLOX with no port set to GPS, so GPS is off).

One port

serialdebug 6 shows UART7 in detail: its pins and functions, the baud rates configured for each function type, and if it is open, the live baud rate, direction, inversion, half duplex and how many bytes are waiting to be read. Then each function on the port that can report its state adds a block. GPS reports:

GPS: provider UBLOX, active yes
GPS: state RECEIVING_DATA, last valid message 85ms ago, at 57600 baud
GPS: bytes 91230, packets 1520, errors 0, timeouts 0, sats 11, fix yes

• active: whether GPS was started at the last boot. GPS starts only when gps_provider matches a port (see the GPS tab). setup changed: save and reboot means the port or provider changed since the last boot.
• state: INITIALIZING or LOST_COMMUNICATION means no valid messages are arriving. RECEIVING_DATA means the module is talking.
• bytes / packets / errors / timeouts: everything received, valid messages, bad messages (wrong checksum, usually noise or a wrong baud rate) and times the module went silent.

The hints tell the cases apart: no bytes at all points at wiring or power, bytes without packets at the baud rate or protocol, and GPS set on more than one port means only the first one is used.

Watching a port

serialdebug monitor 6 prints what UART7 receives for 5 seconds. Readable text is shown as is, other bytes as <hex>. A working NMEA GPS shows lines like $GNGGA,..., a u-blox in binary mode shows <B5>b..., a CRSF receiver shows <C8><18><16>.... If nothing arrives, check that the device's TX goes to the flight controller's RX pin, and check power and ground.

The baud rate defaults to the port's current rate (or its GPS baud rate if the port is closed). Give one to try another, for example serialdebug monitor 6 9600 10 listens at 9600 baud for 10 seconds (up to 60). Add inverted for a signal that is inverted, such as S.Bus; a port that is already open keeps its own setting.

Finding the baud rate and protocol

serialdebug scan 6 listens for 1.5 seconds at each of 9600, 19200, 38400, 57600, 100000, 115200, 230400, 400000, 416666, 420000 and 460800 baud, and counts the NMEA, UBX, CRSF and FBUS frames it recognises at each:

   9600:   960 bytes, 100% text, 16 NMEA
  19200:   480 bytes,  41% text
...
# looks like NMEA at 9600 baud

Set the port's baud rate (or for GPS, turn on gps_auto_baud) to match. S.Bus is not recognised; use monitor with inverted for it.

Note

While monitor or scan runs the flight controller does nothing else, so only use them on the bench. Press any key to stop early. A port already in use (such as the GPS port) is borrowed and set back afterwards.

Settings added in recent snapshots

These settings are per-profile (set them after selecting the profile you want to change):

Setting	Range	Default	Description
angle_level_damping	0-100	25	Angle mode damping: percent of measured roll/pitch rate taken off the leveling command; 0 = off
atthold_gain	0-250	40	Attitude Hold correction strength
atthold_deadband	0-100	5	Per-axis stick percent below which that axis is held
atthold_max_rate	0-1800	300	Correction rate clamp, deg/s
fw_spa_gain	25-200	100	GPS speed attenuation baseline, percent
fw_spa_curve	0-8	0	Gain curve evaluated on GPS speed; 0 = GPS speed attenuation off
fw_spa_speed_max	10-600	150	GPS speed at the curve's right edge, km/h
snap_relax_strength	0-100	100	Snap Relax: percent of opposing roll/pitch/yaw feedback removed during a pop top, pinwheel or snap; 0 = off
snap_relax_threshold	20-100	60	Stick percent that roll, pitch and yaw must all reach
snap_relax_window	0-1000	400	All three sticks must pass the threshold within this many ms of each other
snap_relax_hold	0-1000	350	Fade-out back to full feedback, ms
prop_hang_strength	0-100	100	Prop-Hang Relax: percent of the roll I-term held back in a prop hang; 0 = off
prop_hang_angle	5-45	20	Degrees from straight up that still count as a hang
prop_hang_fade	0-2000	500	Fade-out back to full roll I-term after the hang, ms

The autohover_* settings were removed with the AUTO HOVER mode in MSP API 22.11. Restoring a diff from older firmware reports them as unknown settings; those lines can be ignored.

The fw_spa_* settings need firmware with MSP API 22.10 or later, and are not present on targets built without GPS.

Stick deadbands are global (not per-profile). roll_deadband and pitch_deadband replace the old shared deadband setting, which a diff from older firmware will now reject as an invalid name:

Setting	Range	Default	Description
roll_deadband	0-100	5	Roll stick deadband around center, µs
pitch_deadband	0-100	5	Pitch stick deadband around center, µs
yaw_deadband	0-100	5	Yaw stick deadband around center, µs

Altitude estimation

Altitude and vario (used by telemetry, Blackbox and GPS RTH/Loiter altitude hold) come from the accelerometer fused with a measured altitude. The measurement is the barometer, or GPS altitude on boards without one. The accelerometer gives a vario that responds straight away; the measurement keeps the altitude from drifting and corrects the accelerometer's own error over a few seconds. If the measurement drops out, the estimate carries on from the accelerometer for 5 seconds, then reports no altitude. Without an accelerometer, altitude is the filtered measurement on its own.

Setting	Range	Default	Description
position_fusion_baro_tc	5-100	20	How long the accelerometer is trusted over the barometer, in 0.1 s. Higher is smoother but slower to correct
position_fusion_gps_tc	5-200	40	The same over GPS altitude, in 0.1 s. GPS altitude is noisier than a barometer, so the default is longer
position_gps_min_sats	0-50	6	Satellites needed before GPS altitude is used. The default was 12, which left most boards without a barometer with no altitude at all; saved configs keep their value, so set it to 6 on those

A board without a barometer gets its altitude from GPS with the default position_alt_source. Before this, it had none unless the source was set to GPS only.

Debug modes

debug_mode modes that no longer record anything are named UNUSED_<n>, where <n> is the mode's number. The numbers are unchanged, so older logs still decode, but a diff from older firmware that sets one of the old names is rejected as an invalid value. Set debug_mode = NONE instead.

Number	Old name
8	RC_SETPOINT
25-27	RANGEFINDER, RANGEFINDER_QUALITY, LIDAR_TF
29	GOVERNOR
30	SDIO
33	SMARTAUDIO
46	TTA
56-57	FEEDFORWARD_LIMIT, FEEDFORWARD
61-62	D_LPF, VTX_TRAMP
69-77	PITCH_PRECOMP, YAW_PRECOMP, RESCUE, RESCUE_ALTHOLD, CROSS_COUPLING, ERROR_DECAY, HS_OFFSET, HS_BLEED, GOV_MOTOR
79	AUTOHOVER (removed with the mode in API 22.11)

For Wingflight's own diagnostics use ATTHOLD, TVHOLD, AIRBORNE, ALTITUDE, GAIN_ATTEN, SNAP_RELAX or PROP_HANG. The first two log one axis at a time, picked with debug_axis.

GAIN_ATTEN shows the throttle (TPA) and GPS speed (SPA) gain attenuation that scales P, D, F and B (their product is floored at 25%):

Field	Value
0	Throttle attenuation, x1000 (1000 = 100%)
1	GPS speed attenuation, x1000
2	Filtered GPS speed used by the curve, 0.1 km/h
3	Raw GPS speed, cm/s
4	GPS fix (1 = fix)

SNAP_RELAX shows Snap Relax detection:

Field	Value
0	Relax amount, x1000 (1000 = 100%)
1	Snap active (1 = all three sticks past the threshold)
2	Time between the first and last stick crossing the threshold, ms
3-5	Roll, pitch and yaw stick deflection, x1000

PROP_HANG shows Prop-Hang Relax detection:

Field	Value
0	Roll I-term relax, x1000 (1000 = 100%)
1	Nose-up component, x1000 (1000 = pointing straight up)
2	Vertical speed, cm/s
3	Time the hang conditions have held, ms (detected at 500)
4	Altitude estimate available (1 = yes)
5	Plain rate flight (1 = no leveling or hold mode active)

ALTITUDE shows the altitude estimate next to its sources, to check the fusion against the raw readings:

Field	Value
0	Altitude, cm (what telemetry and navigation use)
1	Vario, cm/s
2	Measured altitude before fusion, cm
3	Measured vario (derivative of the measured altitude), cm/s
4	Barometer altitude, cm
5	GPS altitude, cm
6	Vertical acceleration, gravity removed, cm/s²
7	Learned accelerometer error, cm/s²

Bus servo output

Setting	Values	Default	Description
fbus_master_channels	8, 12, 16, 24	24	Channels F.Bus output sends. 8 uses the 8-channel frame, 12 and 16 the 16-channel frame, 24 the 24-channel frame
fbus_master_baud_fast	OFF, ON	ON	F.Bus output speed. ON runs at 460800 baud, OFF at 115200 for receivers set to F.Port2 speed; at 115200 the frame rate is capped at 150 Hz. CLI only
sbus_out_channels	8, 12, 16	16	Channels SBUS output sends, always in the 16-channel frame

Channels past the count are sent at center. Also on the Servos tab; see Servos → Bus output channel count.

Mixer rules

The mixer rule command takes an optional last argument, the rule's role: 0 for none (the default when omitted), 1 for Flap Compensation, 2 for Differential Thrust Yaw. The full argument order is:

mixer rule <index> <operator> <input> <output> <weight> <offset> <weight-neg> <speed> <curve> <condition> <role>

Everything after <offset> is optional: <weight-neg> defaults to the symmetric value, and the rest default to off. dump and diff print rules in this form.

<output> is a number. Motors stay at 27-30, so bus servos 19-24 come after them:

Output	Meaning
0	None
1-8	PWM servos 1-8 (S1-S8)
9-26	Bus servos 1-18 (S9-S26)
27-30	Motors 1-4 (M1-M4)
31-36	Bus servos 19-24 (S27-S32)

<input> is a number too. RC channels 19-24 were added after the thrust-vector inputs, so they are 30-35 rather than following CH18 (26):

Input	Meaning
13-26	RC channels 5-18
27-29	Thrust-vector roll, pitch, yaw
30-35	RC channels 19-24

Note

This page covers general CLI usage. A full per-command and per-setting reference is planned as the project stabilizes -- contributions welcome, see Contributing.