Further to this, Both Rx’s are configured for no pulses.
If I boot up with both Tx turned on, FS_THR_ENABLE - 0, it works semi as expected. However, mission planner does not show any inputs from the second tx other than occasional flashing between the two. I can change flight modes with the herelink, and confirm connection, but mission planner shows nothing.
With both Rx’s set to no pulses, If I force arm the aircraft (no motors) and take off, then turn all the Txs off I have no failsafe and it’ll continue in any mode left in.
options value 8 won’t work on a CubeBlack as it is a STM32F427 which doesn’t support pin swapping.
what pin is it connected on? Will need to be the RX pin
To narrow things down:
check that the receivers work independently (connect one at a time and test)
once confirmed separately then connect both and try physically disconnecting one at a time and check the other takes over. If this works and TX switch off doesn’t work then the receiver is not setup for no pulses properly
Issue still exists, I can get all behaving, and have hand over working fine with failsafe disabled through FS_THR_ENABLE.
Failsafe works fine with a single Rx plugged into RCIN, however using the CONS connector and nothing in RCIN results in the loop of failsafes as per video. I have confirmed there are no pulses coming out of the Rx on the CONS connector.
@tridge If I plug the SBUS from Herelink into RCIN, univerted, all behaves normally. If I invert it and plug it back into CONS I get the failsafe insanity again.
Appears to be a bug in the way failsafe is detected with an inverted input?
Have you tried without inversion on serial 5, just for the purpose of process of elimination. Where are the instructions for dual RX? This is the first I’ve read about having two receivers connected and my brain hurts trying to guess how this works.
RCIN is a mess, as expected. This is a boot with both Txs on, then the one on CON turned off (starting failsafe loop) then RCIN turned off as well. Then RCIN turned on again, starting the failsafe loop again.
It doesn’t appear to be a failsafe problem. It’s an RC problem. The RC input is bouncing around, which is constantly tripping the failsafe on and off. The failsafe is just the outwardly visible symptom of the RC being all wonky. Now, is the RC problem due to your hardware or AP’s handling of it? Way over my head.
If the SBUS works directly into the RC In, but goes bonkers when it’s inverted and hooked up Serial 5, my first suspect would be what you’re using to invert it. How sure are you that device is working properly.
Have tried 3 different SBUS inverters now, 3rd one using totally different hardware, identical behaviour. All look like normal SBUS on an oscilloscope. I have a orange cube here, might use that to troubleshoot and remove the external inverter from the loop.
Tested with a Cube orange in a standard non ADS-B carrier board. No external SBUS inversion. Plug into console port, identical config as cube black above, with inversion onboard.
Exactly the same behaviour, works fine, until there is a failsafe on whatever input is on console pins.
The failsafe is “looping” because that’s what it sees the input doing. The failsafe sees the signal is constantly going out and back, so the failsafe is going on and off. If you’re sure the signal coming into it is good, which it sounds like you are, then I’d say AP isn’t receiving or handling it consistently which @tridge will need to address.
