DJI O4 Low Power Mode Issue

[ivolanski]

I'm facing a recurring issue with my DJI O4 system where it remains stuck in low power mode even after arming the aircraft. This is causing limitations in range and performance. Here’s a detailed breakdown of my setup and troubleshooting steps:

Both INAV 8 RC3 and RC4 firmware

DJI Goggles 2, latest version

DJI O4 Air Unit

DJI O4 Pro Air Unit

MATEK F405 VTOL flight controller

All DJI hardware was updated today to the latest firmware versions to ensure compatibility and rule out software issues. To eliminate potential external causes, I conducted a series of controlled tests, focusing specifically on hardware behavior.

I started by plugging in a DJI O3 Air Unit. Upon arming the aircraft, the low power mode was disabled, and the system operated as expected. No further adjustments were needed.

Next, I:

Plugged in the DJI O4 Air Unit and armed the aircraft. The low power mode persisted.

Disconnected the O4 Air Unit and connected the DJI O4 Pro Air Unit instead. Upon arming, the low power mode still persisted.

Throughout these tests, I only connected the air unit plug on the air unit side and did not alter the flight controller cables, INAV settings, or any other configurations. The only software interaction involved switching the goggles to the correct device in the settings menu.

All air units were activated using the DJI Consumer Drones app, which I also downloaded and updated today for consistency. The firmware versions were double-checked to ensure no outdated components were present.

I am seeking assistance in resolving this persistent low power mode issue affecting the DJI O4 and DJI O4 Pro systems after arming the aircraft. If anyone has experienced similar problems or can provide troubleshooting suggestions, please share your insights.

Update: Official answer from DJI

`

diff all

version

INAV/MATEKF405TE_SD 8.0.0 Dec 13 2024 / 11:19:58 (253cf74) dev

GCC-13.2.1 20231009

start the command batch

batch start

reset configuration to default settings

defaults noreboot

resources

Timer overrides

Outputs [servo]

servo 3 1150 1900 1550 100

safehome

Fixed Wing Approach

geozone

geozone vertices

features

feature -AIRMODE
feature REVERSIBLE_MOTORS
feature LED_STRIP
feature PWM_OUTPUT_ENABLE

beeper

blackbox

blackbox -NAV_ACC
blackbox NAV_POS
blackbox NAV_PID
blackbox MAG
blackbox ACC
blackbox ATTI
blackbox RC_DATA
blackbox RC_COMMAND
blackbox MOTORS
blackbox -GYRO_RAW
blackbox -PEAKS_R
blackbox -PEAKS_P
blackbox -PEAKS_Y
blackbox SERVOS

Receiver: Channel map

Ports

serial 2 2 115200 115200 0 115200
serial 3 33554432 115200 115200 0 115200

LEDs

led 0 0,5::CT:9
led 1 0,6::CT:9
led 2 0,7::CT:9
led 3 0,8::CT:9
led 4 0,9::CT:9
led 5 0,10::CT:9
led 6 0,11::CT:9
led 7 0,12::CT:9
led 8 5,1::C:1
led 9 6,1::C:1
led 10 7,1::C:1
led 11 8,1::C:1
led 12 9,1::C:1
led 13 10,1::C:1
led 14 11,1::C:1
led 15 12,1::C:1
led 16 5,2::C:1
led 17 6,2::C:1
led 18 7,2::C:1
led 19 8,2::C:1
led 20 9,2::C:1
led 21 10,2::C:1
led 22 11,2::C:1
led 23 12,2::C:1

LED color

LED mode_color

Modes [aux]

aux 0 0 0 1600 2100
aux 1 12 0 900 2100
aux 2 10 1 1700 2100
aux 3 15 2 1350 2100

Adjustments [adjrange]

Receiver rxrange

temp_sensor

Mission Control Waypoints [wp]

#wp 0 invalid

OSD [osd_layout]

osd_layout 0 0 18 0 V
osd_layout 0 1 12 0 H
osd_layout 0 7 26 19 H
osd_layout 0 9 32 2 H
osd_layout 0 11 18 19 H
osd_layout 0 12 1 4 H
osd_layout 0 13 24 12 V
osd_layout 0 14 9 0 V
osd_layout 0 15 9 8 H
osd_layout 0 22 26 1 V
osd_layout 0 23 24 0 V
osd_layout 0 28 23 11 H
osd_layout 0 30 11 18 V
osd_layout 0 32 32 19 V
osd_layout 0 40 32 0 V
osd_layout 0 85 31 1 H
osd_layout 0 125 14 19 V
osd_layout 0 145 39 0 V

Programming: logic

logic 0 0 -1 1 2 17 0 1 0
logic 1 0 -1 6 1 5 0 0 0
logic 2 1 -1 22 0 0 0 0 0
logic 3 1 -1 16 2 9 0 36 0
logic 4 1 -1 17 4 3 0 1000 0
logic 5 0 -1 15 0 100 4 4 0
logic 6 1 -1 2 4 4 0 30 0
logic 7 0 6 18 0 0 4 5 0
logic 8 0 -1 12 4 6 0 0 0
logic 9 0 8 18 0 0 0 100 0
logic 10 1 -1 2 4 4 0 50 0
logic 11 0 -1 52 0 9999 0 0 0

Programming: global variables

Programming: PID controllers

OSD: custom elements

master

set gyro_main_lpf_hz = 10
set gyro_zero_x = 9
set gyro_zero_z = -3
set ins_gravity_cmss = 989.917
set gyro_adaptive_filter_min_hz = 5
set acc_hardware = ICM42605
set acczero_x = -3
set acczero_y = -1
set acczero_z = 3
set accgain_x = 4099
set accgain_y = 4095
set accgain_z = 4117
set align_mag = CW270FLIP
set mag_hardware = NONE
set baro_hardware = SPL06
set rc_filter_auto = OFF
set rc_filter_smoothing_factor = 1
set serialrx_provider = SBUS
set blackbox_rate_denom = 2
set motor_pwm_protocol = STANDARD
set failsafe_procedure = NONE
set 3d_deadband_low = 1430
set 3d_deadband_high = 1500
set 3d_neutral = 1500
set small_angle = 180
set applied_defaults = 1
set gps_sbas_mode = AUTO
set gps_ublox_use_beidou = ON
set gps_ublox_use_glonass = ON
set nav_disarm_on_landing = OFF
set nav_wp_max_safe_distance = 500
set nav_rth_climb_first = OFF
set nav_rth_alt_mode = CURRENT
set nav_rth_altitude = 0
set nav_rth_trackback_mode = ON
set nav_fw_loiter_radius = 100
set nav_fw_yaw_deadband = 5
set osd_video_system = BFHDCOMPAT
set stats = ON
set stats_total_time = 48553
set stats_total_dist = 300707999
set stats_total_energy = 503500
set tz_offset = 480

control_profile

control_profile 1

set nav_fw_pos_hdg_p = 60
set manual_rc_expo = 70
set manual_rc_yaw_expo = 70

control_profile

control_profile 2

control_profile

control_profile 3

mixer_profile

mixer_profile 1

set platform_type = ROVER
set model_preview_type = 31
set motorstop_on_low = ON
set mixer_pid_profile_linking = ON

Mixer: motor mixer

mmix reset

mmix 0 1.000 0.000 0.000 0.000

Mixer: servo mixer

smix reset

smix 0 3 2 100 0 -1
smix 1 3 2 -40 0 6
smix 2 3 2 -40 0 10

mixer_profile

mixer_profile 2

Mixer: motor mixer

Mixer: servo mixer

battery_profile

battery_profile 1

set throttle_idle = 0.000
set nav_fw_cruise_thr = 1530
set nav_fw_min_thr = 1500
set nav_fw_max_thr = 1550
set nav_fw_pitch2thr = 0

battery_profile

battery_profile 2

battery_profile

battery_profile 3

restore original profile selection

control_profile 1
mixer_profile 1
battery_profile 1

save configuration

save

`

Update reason:
I just tried INAV RC4 but also with no luck.

[mmosca]

Check your wiring.
We don't have O4 hardware to check if anything changed with O4, but in O3 (and walksnail) this would happen when the rx on the fc is not connected to the tx on the air unit.
While OSD only needs the TX from FC to RX on the vtx, the VTX needs to be able to send MSP commands to the flight controller to figure out if it is armed or not.

If it still doesn't work after validating the connections, I also recommend contacting DJI, as it is likely something they changed between O3 and O4.

[ivolanski]

Check your wiring. We don't have O4 hardware to check if anything changed with O4, but in O3 (and walksnail) this would happen when the rx on the fc is not connected to the tx on the air unit. While OSD only needs the TX from FC to RX on the vtx, the VTX needs to be able to send MSP commands to the flight controller to figure out if it is armed or not.

If it still doesn't work after validating the connections, I also recommend contacting DJI, as it is likely something they changed between O3 and O4.

The wires on the DJI systems (O3, O4, and O4 Pro) are identical. The RX and TX connections are correctly set, as I previously mentioned not altering the flight controller connections. This same configuration works perfectly with the DJI O3 unit.

Contacting DJI support is unlikely to yield a solution, as their assistance is often limited. If this turns out to be a genuine issue, the only viable hope for resolution would come from the INAV development team. Notably, users on Betaflight have reported no such problems.

Thank you again for the prompt response. I am still seeking assistance and remain willing to support the INAV developers with troubleshooting, as I currently have both the DJI O4 and O4 Pro units on hand.

[mmosca]

Check your wiring. We don't have O4 hardware to check if anything changed with O4, but in O3 (and walksnail) this would happen when the rx on the fc is not connected to the tx on the air unit. While OSD only needs the TX from FC to RX on the vtx, the VTX needs to be able to send MSP commands to the flight controller to figure out if it is armed or not.
If it still doesn't work after validating the connections, I also recommend contacting DJI, as it is likely something they changed between O3 and O4.

The wires on the DJI systems (O3, O4, and O4 Pro) are identical. The RX and TX connections are correctly set, as I previously mentioned not altering the flight controller connections. This same configuration works perfectly with the DJI O3 unit.

Contacting DJI support is unlikely to yield a solution, as their assistance is often limited. If this turns out to be a genuine issue, the only viable hope for resolution would come from the INAV development team. Notably, users on Betaflight have reported no such problems.

Thank you again for the prompt response. I am still seeking assistance and remain willing to support the INAV developers with troubleshooting, as I currently have both the DJI O4 and O4 Pro units on hand.

The INAV team does not have O4 hardware to test. We did not get any from DJI before release, and the one I bought with my own money has not been delivered either. So, there is nothing we can do about it at the moment. If the wiring is correct, ti is likely a bug on the DJI side, or at very least, something they changed from vistas and O3.

Debugging this will likely be tricky and require some custom firmware and back and forth with betaflight, so not really pratical to do asynchronously.

[ivolanski]

Check your wiring. We don't have O4 hardware to check if anything changed with O4, but in O3 (and walksnail) this would happen when the rx on the fc is not connected to the tx on the air unit. While OSD only needs the TX from FC to RX on the vtx, the VTX needs to be able to send MSP commands to the flight controller to figure out if it is armed or not.
If it still doesn't work after validating the connections, I also recommend contacting DJI, as it is likely something they changed between O3 and O4.

The wires on the DJI systems (O3, O4, and O4 Pro) are identical. The RX and TX connections are correctly set, as I previously mentioned not altering the flight controller connections. This same configuration works perfectly with the DJI O3 unit.
Contacting DJI support is unlikely to yield a solution, as their assistance is often limited. If this turns out to be a genuine issue, the only viable hope for resolution would come from the INAV development team. Notably, users on Betaflight have reported no such problems.
Thank you again for the prompt response. I am still seeking assistance and remain willing to support the INAV developers with troubleshooting, as I currently have both the DJI O4 and O4 Pro units on hand.

The INAV team does not have O4 hardware to test. We did not get any from DJI before release, and the one I bought with my own money has not been delivered either. So, there is nothing we can do about it at the moment. If the wiring is correct, ti is likely a bug on the DJI side, or at very least, something they changed from vistas and O3.

I totally understand your point, and I have no words to express my gratitude. I am extremely thankful to the INAV developers for investing both time and money to bring this amazing system that brings so much happiness to so many people.

I also want to reinforce that I have the O4 unit in my hands and am more than willing to help if possible. Regarding the wirings, please check the images below from the O4 user manual and compare them with the O3. As far as I can see, they follow exactly the same standard.

[ivolanski]

this part of the user manual caught my attention, I tried MSP but wwith no lucky

[mmosca]

Those are betaflight instructions and do not apply to INAV.

https://www.youtube.com/watch?v=elq6AF5gdXE

[ivolanski]

Those are betaflight instructions and do not apply to INAV.

https://www.youtube.com/watch?v=elq6AF5gdXE

I am totally aware of it. The point is that it is working with Betaflight but not with INAV. Why? Who knows?
This video is not helpful as my setup is working with O3, so I guess I am not doing anything other than the normal setup.
You can also see my diff all, I guess it is aligned with INAV instruction for O3

[ivolanski]

Check your wiring. We don't have O4 hardware to check if anything changed with O4, but in O3 (and walksnail) this would happen when the rx on the fc is not connected to the tx on the air unit. While OSD only needs the TX from FC to RX on the vtx, the VTX needs to be able to send MSP commands to the flight controller to figure out if it is armed or not.

If it still doesn't work after validating the connections, I also recommend contacting DJI, as it is likely something they changed between O3 and O4.

I did as you suggested and contacted DJI; please check the answer below:

They are so cute; they also sent me a cow holding a heart, maybe to show how lovely they are also when they are Fu***g the community. hahahaha

[mmosca]

We need more info on this. Does it work for anyone?

[jaroszmm]

Seems somebody on Facebook got it working.
Also the reply is shit - O3 works with INAV, or at least partially but works. I guess they need to figure out what "works" means for them.

[ivolanski]

Seems somebody on Facebook got it working. Also the reply is shit - O3 works with INAV, or at least partially but works. I guess they need to figure out what "works" means for them.

Hi mate, Yes, as I mentioned before in this post, talking to DJI is totally useless.
How about "someone from Facebook"? Could you please share something else about this?

[mmosca]

I also see some reports about similar issues with Betaflight, so it may be an issue on the DJI side.

[jaroszmm]

Seems somebody on Facebook got it working. Also the reply is shit - O3 works with INAV, or at least partially but works. I guess they need to figure out what "works" means for them.

Hi mate, Yes, as I mentioned before in this post, talking to DJI is totally useless. How about "someone from Facebook"? Could you please share something else about this?

Sorry. That FB guy did not mention he started recording manually.

[ivolanski]

We need more info on this. Does it work for anyone?

I created the same post on REDDIT and just got an answer from another user with similar situation as me.

[mmosca]

Bough one to test this week:

https://youtu.be/Ppp-W5AwJKc

I can confirm I get the issue with latest INAV nightly build. Haven't tested with BF or older INAV versions yet, but there shouldn't be significant changes in INAV's code to justify it not working.

[ivolanski]

You may want to check it #10598 fixes it for you.

You will need to set enable_broken_o4_workaround = ON on the cli.

How to test it, just use the cli? Should I keep RC4 or install another version?

Thanks

[mmosca]

Not merged yet. You have to download the artifacts from the PR and flash it manually.

[jaroszmm]

Okay, I can tell it worked.
RC4 "stock" did not trigger disabling low power and recording.
flashed the newest HEX
After arming I get recording in both AU and Goggles 2

[kdshaw1984]

Not merged yet. You have to download the artifacts from the PR and flash it manually.

Can someone help me learn how to download artifacts and flash them manually? Struggling to get this low power mode workaround to work. Thank you.

[MrD-RC]

No need to. Just use INAV 8.0.0 stable release.

[kdshaw1984]

Thank you Darren. Can you please tell me what boneheaded newbie thing I’m doing - keep getting an "### ERROR: Invalid name” message when I input the "set enable_broken_o4_workaround = ON” command in the CLI. Screenshot attached. Still stuck in low power mode when I arm and launch. Kevin 

…

On Feb 6, 2025, at 10:54 PM, Darren Lines ***@***.***> wrote: No need to. Just use INAV 8.0.0 stable release. — Reply to this email directly, view it on GitHub <#10590 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPHXQ2GO7PZNXKVVE5NTXLD2ORKCPAVCNFSM6AAAAABVDDXQCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBSGA4DGOJWGI>. You are receiving this because you commented.

[MrD-RC]

I can't see a screenshot.

If you are using Configurator 8.0.0 and firmware 8.0.0 it should work.

[kdshaw1984]

[kdshaw1984]

I can't see a screenshot.

If you are using Configurator 8.0.0 and firmware 8.0.0 it should work.

Sorry, I'd replied via email and the screenshot did not make it through. I have been getting this error when I paste the CLI command. I've tried on 8.0 RC4 and well as the most recent stable release. Tried on 2 different boards (HAKRC 4530D). Thanks again for any insight.

[MrD-RC]

set enable_broken_o4_workaround = on should work. It is in the release. Are you flashing the flight controller with full chip erase enabled?

[kdshaw1984]

You must be some kind of sorcerer. During prior firmware installations, I had downloaded the .hex file and installed locally. This time I did the "load firmware online" option and the workaround was accepted! I don't know if that was a coincidence or not, but I will take it. Thank you so much for your assistance. You are very kind to help.

[ivolanski]

Hi, I am using version 8.0 for both configurator and firmaware. I set set enable_broken_o4_workaround = on but o4 remains in low power mode. I have OSD, with GPS info and everything else, but arming is raising the power. Of course if I disable the auto low power, it will always be in full power, but this is not what I am seraching for.

Thanks

[mmosca]

Hi, I am using version 8.0 for both configurator and firmaware. I set set enable_broken_o4_workaround = on but o4 remains in low power mode. I have OSD, with GPS info and everything else, but arming is raising the power. Of course if I disable the auto low power, it will always be in full power, but this is not what I am seraching for.

Thanks

Double check your wiring. Osd only needs tx from fc to vtx. Arming detection needs both tx and rx from fc to vtx to work.

A good way to double check this issue is to see if the battery voltage is reported correctly in dji's own osd elements at the bottom of the screen. If voltage shows as 0, you have a wiring issue.

Working example:

[ivolanski]

Battery voltage is normal, o3 can be armed using the same plug, everything looks fine besides full power. The only thing that I can imagine is that I am using force arm or arm bypass, something like this. Maybe a unplanned behavior?

[mmosca]

Did you save after changing the value of enable_broken_o4_workaround on the cli?