protocol: support 32 bit system IDs - #15
Draft
julianoes wants to merge 1 commit into
Draft
Conversation
A system ID no longer fits the 8 bit fields this was using, so widen the ones that hold a system ID to uint32_t and take the 32 bit proposal's extended header into account where a target travels in it. The three messages split into two groups: - REQUEST_EVENT and RESPONSE_EVENT_ERROR carry a target_system, so a target above 255 moves into the extended header and the payload field reads as 0. On receive, the generated getter already resolves that, so handleEventError() uses it instead of the decoded struct. On send, requestEvent() cannot express the wide target in the struct it hands out, so send_request_event_message() now gets it as a separate argument for the caller to pass to mavlink_msg_request_event_pack_chan(). - EVENT's destination_system is not a routing target, which is what its name is about, so it never moves into the extended header and stays 8 bit. An event therefore cannot address a system above 255, and such a system only receives broadcast events. That needs a wider field in the message itself and is left as is, with a comment. Note that send_request_event_message() gaining an argument is a source break for callers that build the Callbacks struct.
bkueng
approved these changes
Aug 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a draft towards supporting 32 bit sysid, see: ArduPilot/pymavlink#1229, used in mavlink/MAVSDK#3041.
A system ID no longer fits the 8 bit fields this was using, so widen the ones that hold a system ID to uint32_t and take the 32 bit proposal's extended header into account where a target travels in it.
The three messages split into two groups:
REQUEST_EVENT and RESPONSE_EVENT_ERROR carry a target_system, so a target above 255 moves into the extended header and the payload field reads as 0. On receive, the generated getter already resolves that, so handleEventError() uses it instead of the decoded struct. On send, requestEvent() cannot express the wide target in the struct it hands out, so send_request_event_message() now gets it as a separate argument for the caller to pass to mavlink_msg_request_event_pack_chan().
EVENT's destination_system is not a routing target, which is what its name is about, so it never moves into the extended header and stays 8 bit. An event therefore cannot address a system above 255, and such a system only receives broadcast events. That needs a wider field in the message itself and is left as is, with a comment.
Note that send_request_event_message() gaining an argument is a source break for callers that build the Callbacks struct.