Hello all,
(edit 1: additional details) I have our device connected to the Pixhawk6x (PX4 Pro V1.17.0) over telem1, and configured MAVLink for passthrough, using Qgroundcontrol to view the MAVLink traffic and battery status.
For context I am working on implementing MAVLink protocol for a custom battery management device. I have included the MAVLink C libraries into our STM32 Cube project GitHub - mavlink/c_library_v2: Official reference C / C++ library for the v2 protocol · GitHub
I believe I have discovered an issue with the PX4 firmware when interpreting the temperature value in the MAVLink battery status message.
The MAVLink message specification states that the temperature parameter of the battery status (147) message should be in centi-degrees Celsius. When I transmit this message in centi-degrees, the passthrough message sent directly to Qgroundcontrol will correctly interpret the value, for example 2600 sent over MAVLink will be displayed as 26 C on the Qgroundcontrol interface. While the same value when received by the Pixhawk will cause the PX4 firmware to broadcast its battery status with a invalid temperature value.
A simple test seems to indicate that the PX4 is failing to divide the value by 100 on receiving the message before being used internally, thus when it is multiplied by 100 on transmission it will cause a INT16 overflow.
Image 1: Qgroundcontrol battery status messages (120 = passthrough, 255 = PX4 Battery status message)
TEST: If I transmit 26 over MAVLink for temperature, the PX4 firmware will transmit a battery status temperature of 2600 viewed in Qgroundcontrol. If I send 327 I will receive 32700, and sending 328 produces the overflow and an invalid temperature value.
I was unable to find the exact line in PX4 firmware that this occurs, the MAVLINK receiver seems to have a division by 100 before passing to UORB. However the .md file fails to include a divide by 100 in the sample code.
Image 2: receiving_messages.md Does not indicate division by 100
Image 3: mavlink_receiver.cpp Does indicate division by 100
Has anyone else found a similar behavior?
Is there something that seems incorrect in my analysis?
Thanks,
bd