Certain Mavlink 1 messages arriving with bad CRC signatures

I keep seeing the MAVLINK_FRAMING_BAD_CRC error being returned from mavlink_frame_char() when receiving messages of type MAVLINK_MSG_ID_EKF_STATUS_REPORT. I am using the Mavlink 1 C language headers to receive the messages using functions such as mavlink_parse_char() (which calls mavlink_frame_char()).

I receive all other messages fine so there is something wrong with this message’s CRC. I note that QGroundControl and MissionPlanner receive MAVLINK_MSG_ID_EKF_STATUS_REPORT messages without any problems.

In the mavlink_msg_ekf_status_report.h header file I see these lines:

#define MAVLINK_MSG_ID_EKF_STATUS_REPORT_LEN 26
#define MAVLINK_MSG_ID_EKF_STATUS_REPORT_MIN_LEN 22

which is unusual as most headers have LEN and MIN_LEN as the same values so I am thinking that the problems originates there. I am not sure at this stage of the purpose of MIN_LEN since the structure in question is 26 bytes long, not 22 bytes:

MAVPACKED(
typedef struct __mavlink_ekf_status_report_t {
 float velocity_variance; /*<  Velocity variance.*/
 float pos_horiz_variance; /*<  Horizontal Position variance.*/
 float pos_vert_variance; /*<  Vertical Position variance.*/
 float compass_variance; /*<  Compass variance.*/
 float terrain_alt_variance; /*<  Terrain Altitude variance.*/
 uint16_t flags; /*<  Flags.*/
 float airspeed_variance; /*<  Airspeed variance.*/
}) mavlink_ekf_status_report_t;

Just posting this in case anyone else has any thoughts on this. I’ve spent 2 days looking at this specific problem. Cheers.

1 Like

I think it’s a bug in Mavlink which in this specific case prevents backwards compatibility of a system using Mavlink 2 headers with a system that uses Mavlink 1 headers:

https://github.com/mavlink/mavlink/issues/1762

Edit: actually, it is probably a bug in my code. :frowning: