Transmitter would not reconnect to Arduplane

I attempted a mission.

Arduplane is set to continue on tranmitter failsafe. After takeoff I turned off the transmitter. I had a telemetry connection. I have flown many flights in the hard config of this plane so i am very positive that the video is not interfering with my signal etc.

If you load and play this log (attached)2016-05-13%2020-22-53.tlog

Question 1

At 25.1% the plane decided to RTL - Why ?

When this happened i entered guided mode on my laptop and set some locations for it to fly to.

At approx 95% on I tried to reconnect my transmitter and manually land. I turned on the transmitter and switiched the mode switch to manual but the plane did not switch to manual. I also tried some other modes.

On the laptop i tried to change the plane to stabilize and control with the transmitter - this didn't work either.

Finally i set it to manual mode on the laptop and sadly the plane nose dived into a spectacular crash.

At home tonight I tested the transmitter connection to the APM and it's working fine.

Question 2

Why would the transmitter not reconnect ?

Damo,

You had the FS_SHORT_ACTN and FS_LONG_ACTN both set to zero, which means "continue in auto mode". That only applies if you are in auto mode though. In the case of this failsafe you were in FBWA mode.

The exact pattern was:

step 1: you were flying in AUTO when the transmitter first went off. We can see that rc3 went to 991, which is below the THR_FS_VALUE and THR_FAILSAFE was 1. This put RC into a failsafe state, but it didn't change out of AUTO
step 2: the receiver came active again while in AUTO. when it did the flight mode control channel (channel 5) went to 1554, which is setup for FBWA. So it switched to FBWA mode.
step 3: less than 1 second later the receiver lost contact and RC3 went down to 900. That engaged throttle failsafe while in FBWA mode. So it started the failsafe process and went to CIRCLE mode then RTL mode

note that on the 2nd receiver failure it went to 900 instead of 991. That indicates the receiver was behaving differently from the first failure. I don't know enough about ezuhf to know what this indicates, but it may be a clue to the RC failure.

Cheers, Tridge

Replies

Developer

Andrew Tridgell May 15, 2016 at 3:44pm

Damo,

The tlog shows very clearly that RC did not reconnect after it was switched off. I had this happen once as well with a FrSky X8R, and it turned out that the receiver had locked up.

I suggest that you setup a landing sequence you can use in case you lose RC and can't get it back. Then you can set the WP number and make it go into AUTO to land.

I can't tell you why the transmitter didn't re-establish link with the receiver, sorry. All I can say is that it can happen occasionally, although it is not common.

Cheers, Tridge
- Damo > Andrew Tridgell May 15, 2016 at 4:00pm
  
  Tridge,
  
  Thanks for the response.
  
  Do you have any idea as to the answer to question 1?
  
  By the way i am using an ezuhf system and a taranis radio.
- Developer
  Andrew Tridgell > Damo May 15, 2016 at 7:27pm
  Damo,
  
  You had the FS_SHORT_ACTN and FS_LONG_ACTN both set to zero, which means "continue in auto mode". That only applies if you are in auto mode though. In the case of this failsafe you were in FBWA mode.
  
  The exact pattern was:
  
  step 1: you were flying in AUTO when the transmitter first went off. We can see that rc3 went to 991, which is below the THR_FS_VALUE and THR_FAILSAFE was 1. This put RC into a failsafe state, but it didn't change out of AUTO
  
  step 2: the receiver came active again while in AUTO. when it did the flight mode control channel (channel 5) went to 1554, which is setup for FBWA. So it switched to FBWA mode.
  
  step 3: less than 1 second later the receiver lost contact and RC3 went down to 900. That engaged throttle failsafe while in FBWA mode. So it started the failsafe process and went to CIRCLE mode then RTL mode
  
  note that on the 2nd receiver failure it went to 900 instead of 991. That indicates the receiver was behaving differently from the first failure. I don't know enough about ezuhf to know what this indicates, but it may be a clue to the RC failure.
  
  Cheers, Tridge
- Damo > Andrew Tridgell May 16, 2016 at 1:07pm
  
  Tridge, thanks for looking at this.
  
  I can 100% say that step 2 was not as a result of turning on the transmitter.
  
  Now i dont know if i trust my setup anymore or if this is a one-off error that will never happen again.....
- Developer
  
  Andrew Tridgell > Damo May 16, 2016 at 1:29pm
  
  I can 100% say that step 2 was not as a result of turning on the transmitter.
  
  it probably wasn't just a stray RF packet, as the channel levels change afterwards from the previous "tx off" values and stay there.
  
  Perhaps a power spike that put the receiver in a bad state? How is the receiver powered? How is the pixhawk powered?
- Damo > Andrew Tridgell May 16, 2016 at 1:34pm
  
  the receiver is powered via the APM 2.6 with JP1 removed. The ESC BEC is connected to this side of the apm board.
  
  The APM is powered via the 3dr power module.

This reply was deleted.

ArduPlane User Group

Replies