NO RC Receiver (lockup between flight controller and receiver???)
Airframe: Nano Goblin 600 mm flying wing
System:
Omnibus F4 Pro V3
Arduplane v 3.9.4 (Chibios)
Companion computer on board (Raspberry Pi) with 4G modem.
Taranis TX and TBS Crossfire RF module (full)
TBS Nano Receiver
Firmware v 2.88 on the TBS Crossfire module
OpenTX firmware 2.2.3 on the Taranis.
Receiver is set to put out 982 on ch3 in event off lost link to transmitter.
Failsafe set for throttle at 990 PWM.
Lowest value of ch3 is 998 PWM when transmitter is connected.
Testing on bench by turning off receiver:
RSSI (channel 8) goes to zero in Mission Planner.
ch3in goes to 982 in Mission Planner.
Throttle failsafe kicks in, as it should.
However, in the air the following happened:
80 seconds into the flight, the Mission Planner called out
NO RC Receiver
I managed to put plane in auto mode through Mission Planner/companion computer connection and it completed the mission and auto- landed safely.
Exactly on touchdown at landing, the failsafe was removed, suggesting maybe something mechanical.
However post flight inspection shows wiring seems to be good on superficial tugging and wiggling and visual inspection.
bin logs and tlogs (through the companion computer) both show about 1500 from rcin ch3 at the time of failsafe event.
bin logs from on board SD card on flight controller and tlog file from Mission Planner available at:
Bin log:
00000002.BIN (303 KB)
graph at:
tlog:
with these graphs:
THE PROBLEM as I see it is that ch3 raw is giving 1500 or so out, and ch8 (rssi channel) is also giving a high value. Therefore, why did the flight controller Ardupilot software call out a failsafe/NO RC Receiver/Throttle failsafe even?
It is even more confusing because as I show below, the receiver was never out of contact with the Taranis radio as verified by separate telemetry log in the SD card in the Taranis radio which records the RSSI at the radio receiver in the plane, and it was good.
Specifically: logs of the Taranis show the RSSI at the receiver was fine and data was being received by the receiver. (TBS RF module in the radio on the ground has some telemetry with the on-plane radio receiver). Therefore, the radio reciever on the plane was in good contact with the radio on the ground.
image of RSSI etc here:
Green is RSSI in MINUS dBm, i.e. it is about -30 dBm on the ground and about -60 dBm in the first few minutes of flight, which is totally fine. During the landing phase it is on long final and drops to -100 dBm but the link quality shows over 80% so most of the packets are still getting to the receiver in the plane, even though the flight controller thinks it is in throttle failsafe.
Note time is off in the Taranis log graph but the low RSSI is at the END of the flight, long after the failsafe and the RSSI is not low enough for a failsafe.
The FS occurs at 80 seconds after takeoff; the low but ok RSSI value in the Taranis log occurs when the plane is on long final for landing, many minutes after the failsafe event.
Why did Ardupilot call a failsafe event?
Why did it last several minutes through the whole flight, when the transmitter radio on the ground was in good contact with the radio receiver on the plane, as shown by the logs in the Taranis?
Why did the log file show 1500 for the rc3in value even though it was in failsafe?
As a bench test, here is the log when I have the plane on the bench and turn off the radio. It does what you would expect, i.e. the RSSI goes to zero and the throttle (RCIN3 raw) goes to 982, the failsafe value:
2019-08-08 17-36-12.tlog (946.5 KB)