Does a new Cube Red ship with secondary firmware already loaded? If so, is updating it part of normal maintenance or only needed for specific fixes?
What’s the current recommended procedure for flashing CubeRedSecondary on 4.7.x? Does stable Mission Planner 1.3.83 handle it, or is beta MP still required? Is the two-USB-connector workaround described in early 2025 still necessary?
With the secondary running IOMCU firmware, does it still present as a separate MAVLink system? If it’s acting purely as an IOMCU, I’d expect no second MAVLink system at all — in which case does the MAV_SYSID 2 question become moot? And is the issue described in PR 34215 present in released 4.7.x?
Is the primary↔secondary interconnect internal to the Cube module, or does any of it route through the carrier? The Red has two 80-pin connectors rather than one, and I want to know whether IOMCU health can be verified over USB with no carrier attached.
Which physical outputs come from the primary FMU and which from the secondary? For a quadplane with four VTOL motors, a pusher and control surfaces, is there a recommended assignment across the two processors?
What happens if the secondary fails in flight? Does the primary take over its outputs, or are those channels simply lost? I’d rather understand the actual failure behaviour than assume the dual-processor architecture provides redundancy it doesn’t.
Is BRD_IO_ENABLE applicable on Cube Red, with the same semantics as Orange+?
Does an accelerometer calibration performed on the bench carry over when the module is installed on the final carrier in the airframe? I’d expect yes, with AHRS_ORIENTATION as the separate airframe-mounting setting, but I’d like that confirmed.
Anything quadplane-relevant missing from the CubeRedPrimary build? The firmware limitations list shows EKF2 and the EKF3_RESET aux function absent; EKF2 I don’t care about.
Any known issues running quadplane on Cube Red that I should know about before committing the airframe to it?