QGC Shows Wrong Battery Percentage

This aircraft has been flying with v1.8.0 dev which was setup in the same process as described below with no known issues at that time. I upgraded to v1.9.0 stable for some added functionalities and now have run into this issue.

Setup details:

PX4 v1.9.0 stable QGC uploaded px4_fmu-v3_default.px4
Pixhawk1 2.4.8
FX-79 Buffalo Flying Wing
3S 8000 mAh LiPo
Windows 10 Pro & QGC v3.5.2
Windows 7 Pro & QGC v3.4.4 (just to see if the same thing happens)
Telem1 connected to Teensy 3.4 for Tx telemetry
Telem2 connected to MinimOSD.

  • Connected Pixhawk via USB to QGC.
  • For a fresh setup, I installed ArduRover first to overwrite previous PX4 1.8.0dev.
  • Then installed PX4 v1.9.0 Stable via QGC. It uploaded px4_fmu-v3_default.px4
  • Calibrated all sensors, radio and setup flight modes, etc.
  • When setup steps are completed, unplugged USB and powered up by LiPo battery.
  • (Issue 1)Tx telemetry shows correct LiPo voltage but flight controller voltage only show 4.07v but actual voltage from servo rail is 5.45v.
  • (Issue 2) Plugged in USB cable but won’t connect to QGC even though the correct port shows in Device Manager. It appears but doesn’t do its normal process when the USB is plugged in, it appears for a second then disappears for a second then re-appears.


  • Unplugged USB and LiPo battery.
  • Plug in USB only and it connected to QGC then plugged in LiPo battery
  • (Issue 3) Battery percentage is wrong on icon bar, but if you click on the icon, the popup window shows the correct voltage.
  • (Issue 4) MinimOSD overlay is no longer showing up. Since SYS_COMPANION has been deprecated, per instructions, set MAV_1_CONFIG to TELEM 2 and Mav_1_MODE to OSD.

@dagar @JulianOes @DonLakeFlyer Any guidance to resolve these issues is highly appreciated.

@bkueng Can you advise on debugging “Issue 4” above - the setting sounds correct.

With respect to Issue 3, the percentage is calculated from the voltage. Exactly how this is done depends on your battery config. Checkout https://docs.px4.io/v1.9.0/en/config/battery.html for an explanation of the options - it may then be obvious from your settings why this value is so far off.

I should’ve specified that prior to the upgrade, I was able to power up with the battery first, connected USB to QGC and percentage displayed was correct. But now, I can’t do this (Issue 2) because it won’t connect to QGC after battery is plugged in. I have to plug USB first to QGC then plugin the battery. At that point, the sensed percentage doesn’t change from USB power to battery’s actual condition.

Thank you very much for the assistance.

For issue 4: did you set the baudrate (param SER_TEL2_BAUD)? I think it should be 57600.

Yes, I set it at 57600 8N1

USB connection problems sounds like Windows Driver problems. If you install Windows Daily you’ll get latest drivers.

@DonLakeFlyer It has nothing to do with the driver. As I pointed out, it works fine when USB is plugged in first. But when powered up with battery first then connect the USB, even when the driver shows up in Device Manager, it won’t connect to QGC. By the way, it won’t connect to Mission Planner either.

Ah, sorry. Missed that part. That would seem like a possible firmware problem then.

@DonLakeFlyer Doesn’t QGC calculate the percentage from the voltage? The voltage after battery is plugged in is correct, which indicates that it is QGC that is not updating.

No, the percentage comes from mavlink telemetry.

@bkueng @hamishwillee @DonLakeFlyer FYI… Eric Stockenstrom and Alex Apostoli are collaborating on the PX4 MavlinkToPassthru FrSky Telemetry Scripts and I’ve been assisting in testing it. I reported some battery and GPS display issues and Eric had this voltage debug that may be related here. He indicated some kind of corruption then somehow normalizes?

Hope it helps.


Sounds interesting, but probably worth opening another topic for that. The last link (https://discuss.ardupilot.org/t/px4-mavlink-decoding/43232/5) does not work.

Aaahh… maybe because you have to be logged in. Anyway, here’s what Eric said, in part, if others are not signed up with discuss.ardupilot.org:

" the SYS_STATUS: #1 and BATTERY_STATUS ( #147 ) records come through corrupt for about a minute and a half, then suddenly come right. I can’t say without further investigation if other record types are corrupt during that period. The voltage of 65nnn appears because the ms bit is “1”.

My voltage debug text is attached here.

If you look through it you will see that the quality of data suddenly reverts to normal, but moving averages take a few moments before they recover."


Wanted to share what’s been discovered by Eric Stockenstrom

"I streamed the TLog into MP, and the voltage is show as 65.xx volts for a while and then later improves.


After some more diagnosis I found that the telemetry is Mavlink 2, and it is being treated by the (latest) APM library as Mavlink 1. This can be seen on the image of the latest MP hud above.

So, I have a theory :thinking:

My understanding of the Mavlink version handshaking protocol here is that communication should start off with Mavlink 1, and a negotiation takes place to determine if Mavlink 2 is supported by both (all) parties.


But the TLog starts off immediately with Mavlink 2, and since no negotiation has been successfully concluded, the receiving station (MP or the Teensy) assumes Mavlink 1, and of course the fields are badly misaligned. Later, some Mavlink 1 telemetry arrives, the negotiation succeeds, and all is well.

So perhaps the TLog starts part-way into the session, or there is some other problem on the PX4 side."

MAV_PROTO_VER = Default (0).

Hope this helps point the dev team to look in the right place.


quote=“rollys, post:15, topic:11259”]
But the TLog starts off immediately with Mavlink 2, and since no negotiation has been successfully concluded, the receiving station (MP or the Teensy) assumes Mavlink 1, and of course the fields are badly misaligned.

That would seem to be a Mission Planner bug. You can’t negotiate a mavlink protocol with a telemetry log playback. You need to use whatever is in the file.

Understood, I think. I’m not familiar at all with Mavilink but this tlog was from QGC so my question would be why QGC started with v2 when it connected with the Pixhawk when its params were set for v1 first before v2. I’m just trying to be a mediator here so forgive what might be a noob stupid question.


QGC started with 2 because the first traffic from the vehicle was 2.

Just following up to see if there’s been any progress on figuring this out.


Not sure who you are looking for progress from. I’m not doing anything here.