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.


DIY Robocars via Twitter
RT @knightsautoteam: Hi @diyrobocars, we are Orlando's first Autonomous racing club and would love your support. We are hosting our first K…
Jan 20
DIY Robocars via Twitter
RT @Heavy02011: #VirtualRaceLeague: @DIYRobocars Race #14 - #ParkingLotNerds join us January 15th for #AutonomousRacing #RoboRace ⁦@DAVGtec…
Jan 16
DIY Robocars via Twitter
RT @chr1sa: And after that came our races, 50 in all. This battle between these two Russians was the best we've ever seen -- incredible fig…
Jan 16
DIY Robocars via Twitter
RT @chr1sa: Before our @DIYRobocars virtual race this weekend, we had a presentation from the team that won the Indy Autonomous Challenge i…
Jan 16
DIY Drones via Twitter
Dec 12, 2021
DIY Robocars via Twitter
Dec 12, 2021
DIY Robocars via Twitter
RT @chr1sa: Just a week to go before our next @DIYRobocars race at @circuitlaunch, complete with famous Brazilian BBQ. It's free, fun for k…
Dec 4, 2021
DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training
Nov 28, 2021
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Nov 26, 2021
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Nov 25, 2021
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23, 2021
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord:
Nov 23, 2021
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Nov 23, 2021
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20, 2021
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20, 2021
DIY Robocars via Twitter
Incredible training performance with Donkeycar
Nov 9, 2021