Mavlink 3 CRC calculation

[Guillaume]

Hello,

I porting my system(home made) from mavlink 0.9 to mavlink 1.0 but i
have a problem with the calculation of the CRC:

where am i wrong:

i accumulate all caracters of te message from the beggining except the
start caracter.

the start caracter in mavlink 1.0 is 0xFE

i heard of an extra caracter to accumulate but i dont understand
it ...

Thanks a lot for your responses

[qgroundcontrol]

the extra character is a hash of the message fields and prevents that
if you send a message with the same ID but different fields from being
decoded. This is a dangerous misinterpretation that happened before
this change.

You can read the hash off the C files or if you need to implement it
from scratch I'll provide more documentation how to calculate it.

[Meier Lorenz]

Hi Guillaume,

the fields are ordered for size to prevent alignment issues and the checksum is calculated over these reordered fields to make sure the reordering is correct.

That is a bit unintuitive and we need better documentation. From your strings I can see that you are not ordering the fields, as 16 bit values would have to be before the 8 bit ones. Check the python generator for the sorting and let me know if you need more information - the documentation is really not in shape yet on that topic.

-Lorenz


On Sep 3, 2012, at 3:45 PM, ghelle wrote:

Hello,

i am coding a MAVLink generator for Java and i have a problem to compute the extra crc and build the MAVLINK_MESSAGE_CRCS byte array...

In pyton code i found that :
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)
So during the parsing i build a String and accumulate it.
By example i have :
"FENCE_FETCH_POINT uint8_t target_system uint8_t target_component uint8_t idx " => 90
"SET_MAG_OFFSETS uint8_t target_system uint8_t target_component int16_t mag_ofs_x int16_t mag_ofs_y int16_t mag_ofs_z " ==> 149

but it is not the good values like found in MAVLINK_MESSAGE_CRCS in C header file...

Where am i wrong?
Do i use the good strings and names?

Thanks for your help!

Best Regards
Guillaume Helle

[Meier Lorenz]

By the way - I would be very interested to add this to the official generator - what did you use for generating the Java code?

-Lorenz

[ghelle]

I am using Java... :-)

And i am very happy if my generator and my library will be add in the official Mavlink! :-)

I have received a lot of mails to use my work so this is the best repository for that...

For your information i have several flags to generate the code. I can generate for littleEndian or bigEndian, for embbeded Java or standard Java, for debug,...

 

I do that because i'll use Mavlink Java in the board of VirtualRobotix whith a Hard Real Time JVM Baremetal to replace Acopter32 2.7...

We are using MissionPlanner too...

 

Best regards

 

Guillaume

[ghelle]

Ok i found the ordering code in Python :

            if self.sort_fields:
                m.ordered_fields = sorted(m.fields,
                                          key=operator.attrgetter('type_length'),
                                          reverse=True)

But in this case how choose the order between an Integer (4 bytes) and a float (4 bytes) or a Double and a long?

 

At this time the generation and the library work fine but i am using the magic values found in the C headers...

 

Best regards

 

Guillaume

 

 

-------------------------------------------------------------------------------------