Search code, repositories, users, issues, pull requests...

Copy link

@jlpoltrack jlpoltrack commented Jan 21, 2026 •

edited by qodo-code-review bot

Loading

User description

Two changes:

Add new MSP message for bind
Add new CLI command to send bind message to receiver

New message and command chosen as MSP receivers don't use serial_rx used by the existing rx_bind / MSP2_BETAFLIGHT_BIND stuff.

Tested with: olliw42/mLRS#395

PR Type

Enhancement, New Feature

Description

Add MSP2_RX_BIND message for MSP receiver binding support
Implement CLI command to send bind message to MSP receivers
Update documentation with new bind command and MSP message details

Diagram Walkthrough

flowchart LR
 CLI["CLI bind_msp_rx command"]
 PORT["Serial port lookup"]
 MSP["MSP port validation"]
 SEND["Send MSP2_RX_BIND message"]
 RX["MSP receiver binding"]
 
 CLI -- "port index" --> PORT
 PORT -- "port usage" --> MSP
 MSP -- "msp port" --> SEND
 SEND -- "bind request" --> RX

File Walkthrough

Relevant files

Relevant files
Enhancement	cli.c `Add CLI command for MSP receiver binding` src/main/fc/cli.c Add includes for MSP serial and protocol headers Implement `cliBindMspRx()` function to handle MSP receiver binding via CLI Register new `bind_msp_rx` CLI command with port parameter validation Validate serial port existence and MSP configuration before sending bind message +38/-0 msp_protocol_v2_common.h `Define MSP2_RX_BIND protocol constant` src/main/msp/msp_protocol_v2_common.h Define new MSP2_RX_BIND message constant with code 0x3001 +1/-0
Documentation	Cli.md `Document new bind_msp_rx CLI command` docs/Cli.md Add `bind_msp_rx` command to CLI command reference table +1/-0 Rx.md `Document MSP receiver binding command usage` docs/Rx.md Rename section from "CLI Bind Command" to "CLI Bind Commands" Add documentation for `bind_msp_rx` command with port parameter syntax Explain MSP receiver binding functionality +7/-1 msp_messages.json `Add MSP2_RX_BIND to message documentation` docs/development/msp/msp_messages.json Add MSP2_RX_BIND message definition with code 12289 Include notes about MSP receiver protocol requirement Provide description of binding functionality for mLRS receivers +8/-0 msp_ref.md `Add MSP2_RX_BIND reference documentation` docs/development/msp/msp_ref.md Add MSP2_RX_BIND to message reference table of contents Create detailed documentation section for MSP2_RX_BIND message Include description, payload details, and protocol notes +11/-1

Enhancement

cli.c

Add CLI command for MSP receiver binding

src/main/fc/cli.c

Add includes for MSP serial and protocol headers
Implement cliBindMspRx() function to handle MSP receiver binding via
CLI
Register new bind_msp_rx CLI command with port parameter validation
Validate serial port existence and MSP configuration before sending
bind message

+38/-0

msp_protocol_v2_common.h

Define MSP2_RX_BIND protocol constant

src/main/msp/msp_protocol_v2_common.h

Define new MSP2_RX_BIND message constant with code 0x3001

+1/-0

Documentation

Cli.md

Document new bind_msp_rx CLI command

docs/Cli.md

Add bind_msp_rx command to CLI command reference table

+1/-0

Rx.md

Document MSP receiver binding command usage

docs/Rx.md

Rename section from "CLI Bind Command" to "CLI Bind Commands"
Add documentation for bind_msp_rx command with port parameter syntax
Explain MSP receiver binding functionality

+7/-1

msp_messages.json

Add MSP2_RX_BIND to message documentation

docs/development/msp/msp_messages.json

Add MSP2_RX_BIND message definition with code 12289
Include notes about MSP receiver protocol requirement
Provide description of binding functionality for mLRS receivers

+8/-0

msp_ref.md

Add MSP2_RX_BIND reference documentation

docs/development/msp/msp_ref.md

Add MSP2_RX_BIND to message reference table of contents
Create detailed documentation section for MSP2_RX_BIND message
Include description, payload details, and protocol notes

+11/-1


 msp bind message

20bd706

@qodo-code-review

Copy link

Contributor

qodo-code-review bot commented Jan 21, 2026 •

edited

Loading

PR Compliance Guide 🔍

All compliance sections have been disabled in the configurations.

@qodo-code-review qodo-code-review bot added the Review effort 2/5 label

Jan 21, 2026

qodo-code-review[bot]

qodo-code-review bot reviewed

Jan 21, 2026

View reviewed changes

src/main/fc/cli.c

Comment on lines +3613 to +3618

int portIndex = fastA2I(cmdline);

if (portIndex < 0 || portIndex > 7) {

cliShowArgumentRangeError("port", 0, 7);

return;

}

Copy link

Contributor

@qodo-code-review qodo-code-review bot Jan 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: Replace fastA2I with strtol to ensure the entire port argument is a valid number, preventing partial parsing of non-numeric input. [possible issue, importance: 6]

Suggested change

int portIndex = fastA2I(cmdline);

if (portIndex < 0 || portIndex > 7) {

cliShowArgumentRangeError("port", 0, 7);

return;

}

char *endptr;

long portIndex = strtol(cmdline, &endptr, 10);

if (endptr == cmdline || *endptr != '0円') {

cliShowParseError();

return;

}

if (portIndex < 0 || portIndex > 7) {

cliShowArgumentRangeError("port", 0, 7);

return;

}

@b14ckyy b14ckyy added this to the 9.1 milestone

Jan 22, 2026

Copy link

Collaborator

b14ckyy commented Jan 22, 2026

Tagging for a possible 9.1 since it just adds a feature without altering existing config or functionality.

Copy link

olliw42 commented Jan 25, 2026 •

edited

Loading

@sensei-hacker @b14ckyy

since we have here a typical hen-egg situation, I would be eager to merge to mLRS what it needs, so that it is ready for when INAV does it. We are preparing for a next release; otherwise it would dongle around in mLRS dev versions for a good while.

To do so, all we would have to know is what the message would be going to look like.

The message as designed here is ok and will eventually become part of the standard?
Changes suggested? E.g., should it get a u32 payload to be more future proof? ??
Not possible to say now?

Copy link

Collaborator

b14ckyy commented Jan 25, 2026

do you have any future upgrades in mind that just don't make sense right now? Considering its "just" a bind trigger?

@sensei-hacker

Copy link

Member

sensei-hacker commented Jan 25, 2026

@xznhj8129 you're deep into MSP.

Any thoughts?

Copy link

olliw42 commented Jan 25, 2026

do you have any future upgrades in mind that just don't make sense right now? Considering its "just" a bind trigger?

not being MSP savy I would not know :)
Maybe something like a port number, if that can be figured out, or a flag to distinguish between an extrenal receiver and an on-board receiver if the FC has any (which I would assume the FC code knows about), stuff of that kind, and all the stuff which doesn't come yet to mind. LOL

Copy link

Collaborator

b14ckyy commented Jan 25, 2026

That's fair. @sensei-hacker since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver, I think it would not hurt to have a payload option, even if its empty now?

@sensei-hacker

Copy link

Member

sensei-hacker commented Jan 25, 2026

That's fair. @sensei-hacker since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver, I think it would not hurt to have a payload option, even if its empty now?

Sounds reasonable to me. But I'm not deep into MSP like @stronnag and @xznhj8129 are, so I may be missing something.

Copy link

olliw42 commented Jan 25, 2026 •

edited

Loading

since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver

ah, not intended to also be potentially send e.g. by a GCS?

Copy link

Collaborator

b14ckyy commented Jan 25, 2026

@olliw42 the CSG (or in this case potentially just INAV configurator) only commands the FC to send the MSP message to the Rx. Like that CLI command bind_msp_rx 1. I don't know how that works from GUI though. But over CLI, the ground station does not to implement anything dedicated.

Copy link

olliw42 commented Jan 25, 2026

thx for the clarification
this is the current state, which may not be the final state
just wonder if it couldn't/shouldn't be seen more general. Would there be reason it would not come from different sources too? I mean, in terms of MSP protocol hygiene.

@xznhj8129

Copy link

Contributor

xznhj8129 commented Jan 25, 2026

I haven't seen anything about binding, not that i looked, but if there's already a function to send a bind message, it only takes a handle case in fc_msp

@stronnag

Copy link

Collaborator

stronnag commented Jan 26, 2026

since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver

ah, not intended to also be potentially send e.g. by a GCS?

A GCS has no interest in this. It is effectively a private capability between a mLRS management tool, the FC and the radio. All it needs is that the MSP function ID is publicly documented to avoid reuse. The payload is only relevant to the MLRS capability, if / how / when mLRS decides it needs to implement a payload need not concern other MSP users. It might as well be documented as "opaque".

Copy link

olliw42 commented Jan 26, 2026

THX

so, after also having had a conversation with Marc, let's somewhat conclude:

INAV is to accept a BIND message to the MSP standard. Right?
naming it MSP2_RX_BIND and assigning it to 0x3001 / 12289 is also acceptable. Right?
defining it to have a u32 payload, which may simply be called 'flags', is also acceptable. Right?

if you guys answer is a triple yes, I am going to take it as herewith defined, and we will prepare mLRS for it.

Copy link

Collaborator

b14ckyy commented Jan 26, 2026 •

edited

Loading

Olli, JLP and I did some brainstorm.

we ended up with the following:

MSP2_RX_BIND will have 32bit payload. port_id 8 bits and 24bit reserved (for future use outside of configurator and RC system dependent operations)

bind_msp_rx n in CLI > the MSP2_RX_BIND message is sent out to the receiver by INAV via UART as a Response with the u8 for the port number and u32 = 0
MSP2_RX_BIND with Port number as a request to the FC (From configurator over USB or another external application) > Standard acknowledge response from INAV to the configurator + Additionally as a response forwarded to the defined UART number.

Reason for using response instead of request: INAV existing code only allows responses to be sent by FC and it would need more custom code.

In case of MSP:

Configurator > MSP2_RX_BIND to FC > FC forwards message with unaltered payload to Rx (as a response) > Rx goes in BIND > FC sends Ack response to Configurator.

Everyone okay with that? That seams to be the least intrusive way to implement it and still leaves headroom for the System itself for future custom extensions.

jlpoltrack added 2 commits

January 26, 2026 15:54


 add payloads

f3f6831


 update cli command to send port

Copy link

Collaborator

b14ckyy commented Feb 12, 2026

@jlpoltrack Since Olli wants to release 1.3.8 until weekend, can you please check and resolve the conflicts towards master? I have very limited time currently to setup an mLRS build environment again So I am waiting for the release. the mLRS side code is in I assume? If yes I can then test with INAV and my hardware here too.

@sensei-hacker is preparing 9.0.1 as well so the snapshot should be fix afaik. Then we can get this in and get this merged for 9.1.

Copy link

Author

jlpoltrack commented Feb 12, 2026

resolve the conflicts towards master

Do you mean against the 'maintenance-9.x' branch?

the mLRS side code is in I assume? If yes I can then test with INAV and my hardware here too.

Yea, both the bind and msp reboot are in mLRS, so will be part of next release.


 Merge remote-tracking branch 'origin/maintenance-9.x' into msp-bind-m...

4f5f37c

...essage

Copy link

Author

jlpoltrack commented Feb 12, 2026

FWIW - I don't see how the Windows SITL fail is a result of this change, log complains about installing 'chocolatey' ?

image