I have two AMP 2.0 units. One is running MAVLink 0.9 and
the other is running MAVLink 1.0. My telemetry receiver
code successfully checks the CRC16 checksum for MAVLink 0.9,
but it gets errors on MAVLink 1.0 frames.
Has anything changed in the CRC16 calculation
for MAVLink 1.0?
I know that MAVLink 0.9 transfers in Big Endian order
and MAVLink 1.0 transfers in Little Endian order.
This should not change the CRC16 calculation results.
Thanks in advance for any information on this matter,
There is also a new start character in Mavlink 1.0 perhaps that is a prob?
Why they did that I don't know - but it's not the only issue the framing protocol in Mavlink has. You just have to deal with these quirks some times.
According the the MAVLink on-line spec ( qgroundcontrol.org/mavlink/start) the CRC does not
include the sync (start character). I don't mind changing my code, but I would like to know what to change.
In MAVLink 1.0 there is an extra CRC process step.
For every XML message in MAVLink and additional CRC value is calculated, once at the time of generating the MAVLink C code and Python. Let's call the the XML message CRC. Then when a message is created the normal (MAVlink 9.0) CRC is conducted and then one more CRC step is added. The XML message CRC, is also processed by the main CRC process, as if it was an extra field of datat in the the sent / received message.
You can see the CRC Extra step in this MAVLink 1.0 python code that I wrote recently.
The idea behind CRC extra is that if a transmitting station has altered the XML of a given message, the message will be rejected by a receiving station that does not have exactly the same XML definition of the that particular message. This CRC extra facility in MAVlink 1.0 make the protocol much more reliable as many different version of the XML defifnitions of the messages are developed.
Best wishes, Pete
Thanks for the information.
Also, refer to the mavlink.h file. It defines the differences between 0.9 and 1.0...
I'm porting my code currently and not so impressed with the 1.0 changes--the spec is complex since the extra CRC values are hardcoded in the firmware, enums have changed [names and ids], and big vs. little will create more confusion. It is not compatible with 0.9 w/o a day's worth of changes. Ugh.
Anther difference between 0.9 and 1,0 is that the ID 24 XML definition message does not
match the 'C' header file. There was probably some hand editing of the 'C' header files.
I have a question on MAVLink 1.0 as well..I posted before but perhaps you guys may know the answer. I have monitored the serial messages of MAVLink through RealTerm to confirm formats and etc...however my problem comes when trying to understand how the checksum is generated...
Could anyone elaborate? Also, is the preconditioning polynomial 0xFFFF and the calculating polynomial 0xF0B8??
And where does the CRC extra come into the calculation? Do I add this value to the end of my message then checksum the entire message, or rather add the value to the checksum value directly? I have tried to see if this matches the checksum calculations but obviously it does not:
Thanks for any explanations and help.
The attached sample code worked for MAVLink 0.9. I assume you would apply the crc_extra to the result of the regular CRC calculation. I have decided not to use MAVLink for my telemetry RF link. I may use the link on board so I am not concerned with hard wired bits dropping out.
Yeah, its funky. I don't know if you would really see hard wired communication problems unless you are traveling real far.
I tried for example a heartbeat message that I got from qgroundcontrol in the code
and got the checksum value AD04 where the true checksum should be 7A6C.
Now, the claim CRC_Extra for a heartbeat message is 50, now the question is what to do with this, I have tried adding this to the message then computing the checksum, I have tried to add this to the checksum ....??? Any ideas.???
Also, what is the correct polynomial used in the calculation for MAVLINK 1.0???
I don't see any value added in the CRC calculation change. That is why I am not going to use MAVLink for my RF down link. There are many other digital communication methods that have a standard that is not a moving target. I need to concentrate on software development and not shooting at a moving target for a communication standard.
Somebody should fork the mavlink standard to a new project. This foolishness is only going to get worse and worse.
Some student changed from big endian to little endian so he could get his C- in the course and another added some extra CRC foolishness to get a B+. This is going to keep happening until the standard is complete crap.