Skip to content

RFC: negotiated bytewise parameters and PARAM_EXT replacement - #31

Open
tridge wants to merge 4 commits into
mavlink:masterfrom
tridge:pr-param-extended
Open

tridge wants to merge 4 commits into
mavlink:masterfrom
tridge:pr-param-extended

Conversation

@tridge

@tridge tridge commented Sep 28, 2026 •

Copy link
Copy Markdown
Member

Extend the existing parameter protocol to preserve full-width integers and carry the values and asynchronous write status needed to replace PARAM_EXT. This builds on the explicit bytewise types and requester opt-in proposed in #18.

The RFC specifies:

  • Explicit signed/unsigned 32-bit types in the existing four-byte value field, with zero extensions and no additional MAVLink2 payload overhead.
  • A 128-byte typed extension for signed/unsigned 64-bit integers, REAL64 and opaque CUSTOM values.
  • Receive-support masks in PARAM_REQUEST_READ/LIST, a component capability, and shared-channel compatibility rules.
  • Negotiated IN_PROGRESS notifications, terminal write errors, exact value acknowledgements, and the limits of correlating writes without transaction IDs.
  • PARAM_EXT migration and handling of catalog entries that cannot be represented for a requester.

Related work:

tridge added 3 commits July 21, 2026 18:53
Lossless transport of parameter values that don't fit the PARAM_VALUE
float field, via extended_type/extended_data extension fields and
MAV_PARAM_TYPE_EXTENDED. int32 is the first encoding; the typed
container is designed to later carry types the parameter protocol
has never supported, such as int64 and short strings. Replaces the
RFC 0017 parameter-encoding proposal (PR mavlink#18).
Replace the extended int32 proposal with explicit raw 32-bit types and signed/unsigned 64-bit extensions. Document support masks, shared-channel compatibility, raw NaN preservation and the reference implementation.
Specify REAL64 and a 128-byte custom container, negotiated asynchronous write progress, and terminal write failures. Document migration, unsupported catalog entries and the limits of value-based acknowledgement correlation.
MAVFTP supports parameter writes and individual reads. Describe this proposal as improving PARAM_* encoding alongside MAVFTP, and remove the incorrect limitations from the motivation and alternatives.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant