Conversation
Branch Targeting SuggestionYou've targeted the
If This is an automated suggestion to help route contributions to the appropriate branch. |
|
|
Just an FYI for contributors: The tentative schedule for INAV 10 is to have a full release in mid December. That means RC2 needs to be in early to mid November, which places INAV 10.0RC1 at September 1. Please plan to have any new features for INAV 10.0 ready for RC1 no later than September 1. After that, 10.1 will follow about six to seven months later. |
2daaffe to
cfa5bb8
Compare
|
Configurator test build ready — commit Download build artifacts for PR #2694 Available platforms (scroll to the Artifacts section at the bottom of the run page):
|
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
PR Summary by QodoAdd dual receiver configuration, telemetry, and handover
AI Description
Diagram
High-Level Assessment
Files changed (12)
|
Code Review by Qodo
1. Wrong RX operator ID
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
| 64: { | ||
| name: "RX handover", |
There was a problem hiding this comment.
1. Wrong rx operator id 🐞 Bug ≡ Correctness
The new RX handover operator is keyed as 64 even though the Dual RX firmware contract assigns “Select RX link” to operation 63. Because the UI uses the object key as the serialized operation ID, selecting this entry sends operation 64 and will not invoke the intended firmware operation.
Agent Prompt
## Issue description
The Dual RX logic operator is registered as operation 64, but the firmware contract defines `LOGIC_CONDITION_RX_SELECT_OVERRIDE` as operation 63. The configurator serializes the operator-table key directly, so the current entry sends the wrong operation.
## Issue Context
Keep the configurator's operator metadata and any firmware-derived enum copies synchronized with the firmware value and intended “Select RX link” semantics.
## Fix Focus Areas
- js/logicConditionOperators.js[378-383]
- js/transpiler/transpiler/inav_constants.js[30-92]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
body updated |
|
Confirmed still accurate — neither of the last two commits touched this. On the firmware side ( One extra wrinkle: that firmware branch is stale vs. current |
|
This branch has not been deployed
2 participants
Dual Receiver support
Configurator support for INAV Dual RX.
This exposes the second receiver configuration, allows each receiver to be assigned to its own serial port, shows the state of both links live, and provides manual/Programming Framework handover controls.
Companion firmware PR: iNavFlight/inav#11748.
What this adds
Dual RX configuration
Dual RX can be enabled from the Configurator and exposes separate receiver configuration for:
RX1 remains the normal existing receiver configuration. RX2 is an additional receiver configuration used when Dual RX is enabled.
The existing channel map is currently global. For example, an
AETRmap is applied to both RX1 and RX2 rather than being configured separately per receiver.Ports
Adds the secondary serial receiver function:
using firmware serial-function bit 13:
A typical serial Dual RX setup therefore has:
The two receivers may use the same supported protocol or different supported protocols.
Receiver status
The Receiver tab displays live Dual RX state, including:
The status is obtained using:
The returned status includes configured, initialized and valid-link state separately, so the UI can distinguish cases such as:
rather than treating every unavailable receiver identically.
Per-link statistics are only displayed when the firmware reports both the link statistics and the corresponding statistic fields as valid.
Manual handover
The Receiver tab provides:
controls using:
The firmware only accepts a handover to a currently valid receiver.
The button for the active receiver is disabled, as is a button for a receiver which is currently unavailable.
This is an explicit handover event, not a persistent receiver preference.
Programming Framework
Adds the Dual RX handover Logic Condition operation:
matching the current firmware enum:
Operand A selects the requested receiver:
This allows a Logic Condition to request an explicit receiver handover.
OSD
Adds Configurator support for the firmware Dual RX OSD items:
These allow the active receiver and individual link state/statistics to be shown in the OSD.
How to configure it
A serial Dual RX setup currently involves three parts of Configurator.
1. Enable Dual RX
Enable Dual RX in the Configuration tab and save/reboot.
2. Assign the receiver ports
In the Ports tab:
Each receiver must have its own appropriate serial port.
If a receiver protocol also requires another serial function on the same port, such as MAVLink telemetry, configure that as required by that protocol.
3. Configure both receivers
In the Receiver tab, configure the primary and secondary receiver independently.
For example:
or:
Save and reboot.
The Dual RX Status section should then show both configured links and which one is currently active.
Runtime behavior
RX1 is the initial active receiver.
When both links are healthy, receiving valid data on RX2 does not automatically replace RX1.
If the currently active receiver becomes invalid and the other receiver is valid, firmware transfers control to the surviving link.
Recovery of the previously lost receiver does not automatically take control back.
For example:
The Configurator reflects this firmware state rather than implementing receiver-selection policy itself.
Manual handover through the Receiver tab or Programming Framework can explicitly select the other currently valid receiver.
Supported combinations
The firmware decides whether a receiver pair is supported.
Same-driver Dual RX is supported for drivers which have independent per-link state, including:
Mixed receiver types such as:
are also supported where the corresponding firmware drivers can operate independently.
Some same-driver combinations remain intentionally unsupported where the underlying receiver/telemetry implementation still uses shared singleton state.
Configurator reports these cases through the firmware Dual RX status instead of silently hiding the second receiver.
Firmware compatibility
This Configurator change targets the current INAV 10 Dual RX implementation.
Important parts of the current firmware contract are:
Dual RX configuration is carried by the extended RX configuration data/settings. It does not use an
activeRXbyte appended toMSP2_INAV_MISC.The active receiver is runtime state reported by
MSP2_INAV_GET_LINK_STATS.Testing
The Configurator has been exercised against current Dual RX firmware on real hardware.
Confirmed configurations include:
with live receiver state visible in Configurator and receiver failover functioning on hardware.
The Configurator-side status display has also been verified with real CRSF link statistics.
Firmware-side SITL coverage separately exercises receiver selection, failure/recovery behavior, mixed receiver configurations and explicit handover.
Current UI/workflow limitations
The functionality works, but the setup workflow can still be improved.
At present configuration is spread across:
That is functional but not especially discoverable.
There are also some smaller presentation issues worth improving:
These are UI/workflow improvements rather than blockers for the current Dual RX functionality.
The current goal of this PR is to expose the firmware feature correctly and make Dual RX usable in Configurator without inventing a separate receiver-selection model in the UI.