Now that there are several successful demonstrations of switch-based parachute deployment the question should be asked whether indeed an additional channel is the best solution, or whether use of a microprocessor ouput line and some changes to the FC firmware are the better way forward. My proposal would be the latter, also also posted in the thread on chute deployment. I-m reposting part of my post here to try and move this forward on the software side.

The advantage of semi-automated deployment of a chute are:
* saves RC channels for other uses,
* avoids the controler fumbling for a rarely used switch when needed, or accidentally throwing the switch when not needed,
* avoids unnecessary delays in deployment and thus increases the chance of successful timely deployment,
* ensures throttle off is given before deployment and is maintained after deployment.

Thinking about it maybe the following would be a good solution:

* Chute deploy servo is attached to Jx with a arming switch between Jx and servo (so that chute deployment cannot occur if OFF on test or aerobatic flights, will occur if ON for higher altitude AP flights)

* MK FC stores air pressure sensor reading on throttle ON (= zero altitude value)

* MK FC activate the parachute system if

== MK is above minimum deployment altitude (= zero altitude + a programmable value) AND throttle OFF command is give (throttle stick in left bottom corner). This would thus even deploy the chute if this happened accidentally.

== MK is above minimum deployment altitude AND throttle is set to ZERO (stick in bottom position) for more than x milliseconds signaling signal loss. Activation should be preceded by throttle OFF

* After chute deployment throttle ON should be blocked until power has been cycled (to avoid throttle up on signal recovery while hanging below a parachute).

The above would not require complex algorithms to interpret sensor readings such as gyro and ACC sensor readings as indicating the MK is in serious trouble. It would use a reflex most of us probably have at low altitude already: close the throttle and turn off the motors if you know you're going down and may tip over (may save a couple of props). It would maximise use of existing channels.

Any interest to integrate such a routine into the main branch of FC firmware ??

Would be very nice !

One thing should be added: ===> vertical speed.

It really needs some vertical speed to deply ok. So I guess some kind of delta -pressure/time should be included as an "AND" input.

Wouldn't vertical speed be based on a delay between motor OFF and deployment. You do want the props to slow down a bit I guess. Only in the situation where you were going up at full throttle would this be a problem as you may still be balistic with too short a delay. Using the ACC readings might not be good solution as the craft could be spinning which would complicate interpretation. Again the air-pressure sensor might suffice. It should show increasing pressure / decreasing altitude. Looking at that could be part of the delay routine:

* throttle OFF,
* measure air pressure: get air pressure "hold altitude value",
* wait x milliseconds,
* get air pressure current,
* if current alt not y meters lower than "hold altitue value" loop to measure air pressure again
else deploy chute.

Of course this could then result in high speed deployment if you were going balistic at very high speed in which case you would continue going up for some time / distance, then come down a bit more than that distance -gaining a lot of downward speed- before deployment. I don't expect speeds to be "Mach 1" so a properly sized chute for the load should be able to handle a 100km/h or so opening. I.e. might not be worth further complicating the routines to handle what is most likely a very rare situation.

Wonder whether J16 or J17 could be used to trigger the chute servo from a routine as proposed above. Anybody tried that already? And maybe the other for a FC gyro controlled roll servo for the camera mount?