Replies to This Discussion

Permalink Reply by Andrew Radford on July 4, 2012 at 9:31am

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.

• ▶ Reply

Permalink Reply by Warren Mall on July 4, 2012 at 9:42am

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.

Thanks,

Warren

• ▶ Reply

DeveloperPermalink Reply by Pete Hollands on July 4, 2012 at 11:03am

Warren,

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

• ▶ Reply

Permalink Reply by Warren Mall on July 5, 2012 at 5:44am

Hi Pete,

Thanks for the information.

Warren

• ▶ Reply

Permalink Reply by Cliff-E on July 17, 2012 at 3:21pm

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.

• ▶ Reply

Permalink Reply by Warren Mall on July 17, 2012 at 4:57pm

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.

• ▶ Reply

Permalink Reply by UAV_Enthusiast on July 21, 2012 at 12:40pm

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:

http://diydrones.com/forum/topics/i-need-help-with-the-mavlink-chec...

Thanks for any explanations and help.

• ▶ Reply

Permalink Reply by Warren Mall on July 22, 2012 at 5:27am

Hi,

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. 

Thanks,

Warren

Attachments:

• Z.CPP, 2 KB

• ▶ Reply

Permalink Reply by UAV_Enthusiast on July 22, 2012 at 7:29am

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

FE099E0101000000000002035104037A6C

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???

Thanks

• ▶ Reply

Permalink Reply by Warren Mall on July 22, 2012 at 2:26pm

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.

Warren

• ▶ Reply

Permalink Reply by Jake Stew on July 22, 2012 at 6:35pm

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.

• ▶ Reply