Bad custom dialect routing(CRC).

[Derker2002]

Bug Report

I was trying to implement a custom command to control the onboard computer via MAVLink. I saw that ArduPilot 4.7 can route packets with bad CRCs.(PR) But unfortunately, it is not working at all. QGC is not arguing that the command is unknown, and FCU does not route it to the onboard computer. If I send a command straight to the onboard computer, it works. The issue lies within the FCU itself.

Issue details

FCU does not route custom dialect commands to components when the ‘MAV2_OPTIONS’ parameter is set to 8. Aka bad CRC packets.

Version
ArduPilot 4.7.

Platform
[ ] All
[ ] AntennaTracker
[x] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
X-type

Hardware type
Matek mateksys H743 slim v3

LOGS
bin. I was trying to send command MAV_CMD_REQUEST_MESSAGE with custom MSG_ID.

[rmackay9]

Hi @Derker2002,

Any chance that you have an onboard log? That will allow us to check that the configuration has been done correctly.

[tridge]

is it a bad CRC or an unknown CRC? Do you have the tlog?

[Derker2002]

Hello! I've updated the issue.

[IamPete1]

bin. I was trying to send command MAV_CMD_REQUEST_MESSAGE with custom MSG_ID.

MAV_CMD_REQUEST_MESSAGE is a target command, so if you send it to the flight controller system/component ID it will consume it and not forward. Contents of MAV_CMD_REQUEST_MESSAGE make no difference.

Please explain exactly what it is your trying to do. What you expected to happen and what actually happens.

[Fenix-125]

I’m encountering this issue too. On the latest beta, even after the fix from PR #25419

Setup
QGroundControl → ArduPilot FC → Companion Computer
Custom MAVLink dialect (custom messages + commands)

Original issue:
Custom MAVLink messages sent from QGC were dropped by the FC due to CRC mismatch (unknown message), so they never reached the companion computer. This conflicted with MAVLink routing expectations where unknown messages should still be forwarded.

PR #25419 appeared to address this.

Current behavior:
MAV2_OPTIONS BAD_SRC bit is enabled
Custom dialect messages are still not forwarded
Companion computer does not receive them
I also do not see these messages at all in the general MAVLink logs, which suggests they may still be getting rejected before routing

So the behavior looks the same as before the PR — unknown/custom messages appear to be dropped rather than forwarded.

Question:
Is forwarding of unknown/custom MAVLink messages still expected to work with the current implementation, or is there some additional condition required for them to pass through?

[Derker2002]

Clarification of behavior:

I'm using MAV_CMD_REQUEST_MESSAGE from the GCS to request a custom dialect message from an onboard computer connected via serial to the flight controller.

What I'm trying to achieve:
GCS → sends MAV_CMD_REQUEST_MESSAGE
FC → forwards it to the onboard computer
Onboard computer → receives the request and generates the requested custom MAVLink message
FC → routes the response back to the GCS

What actually happens:
The MAV_CMD_REQUEST_MESSAGE is correctly forwarded to the onboard computer
The onboard computer does generate and send the response message
The problem is that the response message is dropped by the flight controller
As a result, the GCS never receives the custom message

So the issue is not in the request path — it reaches the onboard computer correctly — but in the return path where the custom MAVLink message from the onboard computer is not being forwarded by the FC back to the GCS.

[IamPete1]

Thanks for the more detailed explanation. Are you sure that MAV2_OPTIONS is the correct parameter for the companion computer link? A easy way to eliminate this as problem would be to set all the MAVx_OPTIONS parameters and re-test.

[Derker2002]

Yes, it was the wrong parameter. After setting all MAVx_OPTIONS to 8, the FCU started to route the custom dialect flawlessly!

[rmackay9]

@Derker2002, great stuff, thanks for the feedback and thanks to @IamPete1 for helping get to the bottom of this