PPM Summ Out Signal Failsave detection

[djmad]

I want to report that the Failsafe handling in the case of a RC-Signal Loss with a Sum Signal connection (SUMO8) does not work correctly

Graupner and Futuba changed in the latest Updates of there receivers the failsafe output

the following lines are translated from the Graupner support
"after a request from Flybarless, DJI and Mikrocopter we shut down the Sumo Signal in a case of error"

the problem at arducopter is following:
If the sumo shuts off every channel is on PWM900 which if you are actually in acro mode generates a very fast uncontrollable spin.
now the RTL kicks in (some time later... to late) because the Channel 1 too is below 900 and tries to capture the copter again. at this moment i already lost around 30m of height, the copter flipped over multiple axis... REST IN PIECES

we need a failsafe which triggers on SUMO-signal loss and does not interpret the non existent inputs as PWM900 for all 8 channels, which is really really bad

[rmackay9]

djmad,
Which version of Arducopter are you using? 2.9.1b?
You don't have a tlog or dataflash log file do you?
I think that the RTL should start in less than 1/10th of a second so it shouldn't lose 30m of altitude so I'd like to understand more what happened.

[Gregmaan]

Within my tests failsafe never activates. Maybe APM makes a hold if no signal arrives?

[djmad]

i try to recover the logfiles

[rmackay9]

@gregmann,
You have definitely enabled the throttle failsafe feature using the mission planner's Configuration, Failsfae page? It will be a couple more days before I can re-test that it works because my copters are in boxes coming back from Sparkfun.

[djmad]

The Point is, that in my case the PWM failsafe was at 900, which is now profed by graupner and futuba that they DONT deliver a failsafe signal, they only shut down the protocoll.
Question is now, how the APM reacts and interpretes theise signals. As in my case it seems -100% for each Servoaxis

I arduciópter 3.0.0rc6

[rmackay9]

djmad,
The failsafe, if enabled, will trigger either when the channel 3 drops below the FS_THR_VALUE (defaults to 975) or when the receiver stops sending updates. In this case it's the updates stopping that should be the trigger.
When you say "the PWM failsafe was at 900" are you saying that you sent the FS_THR_VALUE to 900? If that's the case then that could be the problem. What could happen then is:

1. the receiver stops sending updates
2. the ppm encoder sees the updates stop and starts sending 900 to the main arducopter code (note that this 900 is hardcoded...it has nothing to do with the FS_THR_VALUE)
3. arducopter compares the 900 from the ppm encoder vs the FS_THR_VALUE (also 900). There is always some ppmencoder jitter however so it may or may not fire.

[djmad]

as the sumo on channel 3 in my case goes from ~ 907 - 1890 i maybe did a unlucky setting :-(
i think i entered 901, as soon my usb is soldered back on the board i will post my settings with the errorlog, that may help clearing that up

[rmackay9]

I believe we determined that in this case the FS_THR_VALUE parameter was set to 900 which is why arducopter did not recognise the failsafe. I'll add a pre-arm check that these values are correct so I'm closing this issue.