I’m writing custom software for interpreting mavlink endpoint data and I’m seeing some large discrepancy between the common BATTERY_STATUS message and what I’m interpreting from the endpoint (attached) the battery voltages do not seem to match and there is 41bytes of payload vs. the 36 that the message definition states.
Was a custom message defined instead of this common message structure?
packet.txt (159 Bytes)
Any pointers would be greatly appreciated.
fd 29 00 00 a8 01 01 93 00 00 c1 00 00 00 5f 00 00 00 ff 7f 8a 35 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 4a 00 00 00 00 ff 00 00 00 00 01 0f f2
Just by guessing and checking figured out what I needed:
8a 35 was my voltage : 13706 mv / 13.7 volts
4a 00 was my current : 74ca / 0.74 amps
But still curious as to why the message structure seemed different, and if it is, is it described somewhere?
Hi @wagonhelm 
You haven’t specified which firmware type or version you’re using, so I can’t go looking for the relevant message generation code, but from the message definition you linked to you don’t seem to have allowed for the extension fields in your bytes count, so perhaps your firmware is including time_remaining and charge_state estimates in the message?
| Field | Type | Bytes | Cumulative Sum |
|---|---|---|---|
| id | uint8_t |
1 | 1 |
| battery_function | uint8_t |
1 | 2 |
| type | uint8_t |
1 | 3 |
| temperature | int16_t |
2 | 5 |
| voltages | uint16_t[10] |
2 (x10) | 25 |
| current_battery | int16_t |
2 | 27 |
| current_consumed | int32_t |
4 | 31 |
| energy_consumed | int32_t |
4 | 35 |
| battery_remaining | int8_t |
1 | 36 |
| time_remaining ++ | int32_t |
4 | 40 |
| charge_state ++ | uint8_t |
1 | 41 |
| voltages_ext ++ | uint16_t[4] |
4 (x4) | 57 |
| mode ++ | uint8_t |
1 | 58 |
| fault_bitmask ++ | uint32_t |
4 | 62 |
If you’re writing your own parser, you might not be accounting for the way MAVLink serialises its data?
Hi @EliotBR thanks for the reply.
Using BlueOS 1.25 with BlueROV2 / Navigator board with ardusub.
If I understand correctly extensions should come after the payload and the payload should be
c1 00 00 00 5f 00 00 00 ff 7f 8a 35 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 4a 00 00 00 00 ff
With the extensions being
00 00 00 00 01
This would have my battery voltage starting at index 10 (voltage index 0 with all other voltages reading as FF ff) where the message definition should have it at index 5. I’m either not understanding how the payload / extensions are generated , or I would say the message definition is radically different the the common definition. Or maybe both.
In regards to my parser it seems to be parsing the attitude and pressure messages just fine, just this message was the only one where I didn’t follow common message definition exactly.
What seems to make the most sense is that
c1 00 00 00 5f
Is the extension