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.
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.
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.
@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.
@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.
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”.
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 …
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.
[/quote]
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.
…