MAVLINK 1.0 Checksum Protocol


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.


You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • 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.. :)



    • 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.


  • Developer

    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:

    • you can just use the generated headers, and use MAVLINK_MESSAGE_CRCS to get the right seed for each message type
    • or you can re-implement the code that calculates the seed.

    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( + ' ')
        for f in msg.ordered_fields:
            crc.accumulate(f.type + ' ')
            crc.accumulate( + ' ')
            if 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

This reply was deleted.


Chris Anderson liked Zara Mae Pickering's profile
May 21
Azjeg liked Azjeg's profile
Apr 27
DIY Robocars via Twitter
RT @chr1sa: Donkeycar 4.4 released with tons of new features, including path learning (useful with GPS outdoors), better Web and Lidar supp…
Nov 27, 2022
DIY Robocars via Twitter
RT @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
Nov 24, 2022
DIY Robocars via Twitter
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer
Nov 24, 2022
DIY Robocars via Twitter
UC Berkeley's DIY robocar program
Nov 24, 2022
DIY Robocars via Twitter
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
Nov 24, 2022
DIY Robocars via Twitter
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup
Nov 20, 2022
DIY Robocars via Twitter
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.…
Nov 20, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs
Nov 8, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.
Nov 8, 2022
DIY Robocars via Twitter
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
Oct 23, 2022
DIY Robocars via Twitter
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
Oct 23, 2022
DIY Robocars via Twitter
Oct 23, 2022
DIY Robocars via Twitter
Oct 19, 2022
DIY Robocars via Twitter
Oct 18, 2022