I'm parsing MAVLINK 1.0 for my ground station.

From MAVLINK documentation, I understand that the protocol uses little-endian encoding on the wire. This assumption produces meaningful data for a lot of packets. However some packets make no sense in LE but produce meaningful data in BE, for example RC_CHANNELS_RAW message seems to encode channel values in BE uint16_t. I wonder if some fields (messages?) indeed use different endianness, and if they do, I wonder if there exists a canonical list of which messages are BE and which LE.

Ari.

Views: 1395

Reply to This

Replies to This Discussion

Hi,

Which MAVLink implementation did you use when you saw that (tx and rx)? Did you look at the raw binary data?

I am not aware of inconsistencies..

Regards

Soren

I'm running the git version of Ardupilot; I'm writing my own ground station RX. I'm traveling now and so am away from my hardware. I can post the raw binary when I return next week.

Ari.

Hi,

OK.

The easiest thing for you to do might be to look at the MAVLink library yourself in the APM code and see if there is a difference in endianness.

You do know the Python generator of that MAVLink, right? APM uses its generated C code, other projects too, and AP Mission Planner apparently not.

Regards

Soren

Here's the hex and what my code parses it into. As I'm looking at it, another possibility occurs to me. I notice that the value of "port" fluctuates between (decimal) 210 and 213, while chan8_raw stays in the single digits.

I wonder if it's possible that the AVR code skips the port byte? If it's true, the endianness is fine but I'm reading the high byte from one field and the low byte from the next field, and this makes it look like the bytes are backwards.

The XML I'm using is from http://code.google.com/p/ardupilot-mega/source/browse/libraries/GCS...

Here's a sample message (attachment has a number of different instances):

<Buffer 16 52 01 01 23 80 46 00 00 d5 05 e3 05 76 04 79 05 df 05 df 05 df 05 c5 06 00 00 35 24 00 00 6b 3a 03 08 3d 2d 0c 9b 7c bf fd ff fc ff 00 00 42 e2 00 00 ...>
{ payloadLength: 22,
  packetSequence: 82,
  systemID: 1,
  componentID: 1,
  messageID: 35,
  messageName: [ 35, 'RC_CHANNELS_RAW' ],
  time_boot_ms: 18048,
  port: 213,
  chan1_raw: 58117,
  chan2_raw: 30213,
  chan3_raw: 30980,
  chan4_raw: 57093,
  chan5_raw: 57093,
  chan6_raw: 57093,
  chan7_raw: 50437,
  chan8_raw: 6,
  rssi: 0 }

Attachments:

Hm. This XML https://github.com/mavlink/mavlink/blob/master/message_definitions/... has no port field. It looks like an addition between 0.9 and 1.0. I wonder if Ardupilot simply forgot to add this field?

Ari.

Another possibility is that APM puts the "port" field at the end of message rather than at the front.

I notice that the payload length matches the longer 1.0 message definition, and that the last two bytes before the checksum are always 0x00. One of them is the RSSI (which, to my understanding, APM always reports as 0) and other one may well be the port.

If I understand the "extra CRC" mechanism correctly, just swapping the order of fields in a message would not trigger a change in "extra CRC" byte, two message definitions, one with "port" at the head and another with "port" at the end would produce the same "extra CRC" and consequently the same CRC on the message.

Ari.

I notice the same with SERVO_OUTPUT_RAW message: no port field, and consequent 8-bit offsets for 16-bit fields.

So here's my problem. In an offline communication, Lorenz Meier set me straight on field reordering. I was parsing fields from the stream in the order that they appear in XML. This is inconsistent with the wire encoding. The wire encoding reorders fields according to their width, wider fields first. So even though the XML lists "port" before "chan1_raw", on the wire the (8-bit) "port" field appears after all the (16-bit) "chan*_raw" fields. This explains the 8-bit offset in my original parsing code.

Ari.

Hi,

Hehe ;)

So the byte ordering was little endian after all, but you had the word boundaries in the wrong places?

Yeah there was that change from 0.9 to 1.0 with field vs, byte order. And there is a magic number derived from all fields (and their order) that gets included in checksums. Still haven't found out how to calculate that number..

Regards

Soren

I haven't figured it out either. I'm just taking pre-generated numbers from e.g. http://code.google.com/p/ardupilot-mega/source/browse/libraries/GCS...

Ari.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service