Hello,
I was wondering if anyone can confirm that the LabVIEW code for calculating checksums at this link is still valid for the newest form of MAVLINK:
I have been able to monitor the serial communications from qgroundcontrol and RealTERM and verify the message contents but have not been able to confirm the checksum.
If this is not correct, could someone please explain to me how the checksum is calculated or if LabVIEW code has been updated to reflect the newest checksums that would be great as well.
Thanks,
Replies
I am generating the correct checksum for MavLink packets using the CRC16CCIT 8408 polynomial in VBA. The 1021 polynomial DOES NOT WORK for me. I don't care what the documentation says, the checksum is NOT the CRC16CCIT X.25 standard. The header misleads.
I know the C library header says "1021" but the actual output is different.
Hey Ellis
Is it correct noticed, that this VI only works for the heartbeat message, and that I have to fill out the seed array with the right values, before it supports all messages..?
BTW Great job.. :)
/Allan
I'm working on this very same thing. I got the 0x94 and 0x88 to come out as seen here.
we are now implementing crc extra. My code looks quiet a bit different compared to the previous VI.
Hi Everyone,
I was the one who added the 'seed' in MAVLink 1.0, so maybe I should explain how it works and why it was added.
While we were using MAVLink 0.9 we had a couple of incidents where the XML describing a message that was in active use changed. The change was such that the length of the message didn't change, but the fields did. This meant that when a MAV using the old code was talking to a ground station using updated code that the fields were badly corrupted. The MAVLink 0.9 protocol completely relied on everyone being careful not to change the meaning or format of any existing message. With so many people working on MAVLink this was hard to enforce.
So for MAVLink 1.0 we decided to solve this problem by adding a 1 byte 'seed' to the checksum based on the XML for the message. When the mavlink code generator runs, it takes a checksum of the XML structure for each message and creates an array define MAVLINK_MESSAGE_CRCS. This is used to initialise the mavlink_message_crcs[] array in the C/C++ implementation, and is similarly used in the python implementation.
When the checksum for a message is calculated, this extra byte is added on the end of the data that that the checksum is calculated over. The result is that if the XML changes then the message will be rejected by the recipient as having an incorrect checksum. This ensures that only messages where the sender and recipient are using the same XML structure will get through (or at least it makes a mistake much more unlikely).
If you are doing your own implementation of MAVLink 1.0 you can get this checksum in one of two ways:
This is the python code that calculates the seed:
def message_checksum(msg):
'''calculate a 8-bit checksum of the key fields of a message, so we
can detect incompatible XML changes'''
crc = mavutil.x25crc(msg.name + ' ')
for f in msg.ordered_fields:
crc.accumulate(f.type + ' ')
crc.accumulate(f.name + ' ')
if f.array_length:
crc.accumulate(chr(f.array_length))
return (crc.crc&0xFF) ^ (crc.crc>>8)
Notice that it uses the same x25 chcksum that is used at runtime. It calculates a CRC over the message name (such as "RAW_IMU") followed by the type and name of each field, space separated. The order of the fields is the order they are sent over the wire. For arrays, the array length is also added.
My apologies if this seed has caused any confusion. Hopefully the above will explain the reason it was added.
Cheers, Tridge
here is the code the planner uses for crc
https://code.google.com/p/ardupilot-mega/source/browse/Tools/Ardupi...
in mavlink 1.0 you need to use the seed value also. all packet types have one.
https://code.google.com/p/ardupilot-mega/source/browse/Tools/Ardupi...
and
https://code.google.com/p/ardupilot-mega/source/browse/Tools/Ardupi...