Failsafe for Turnigy receivers

gohsthb · Post by **gohsthb** » Wed Jun 20, 2012 5:36 pm

I saw this in the Er9x development forum and decided to move it here.

buzz wrote:Hypothetical scenario:

Background:
* suppose I have a desire for "long range" ( think FPV etc)
* suppose my TX/RX are all stock hardware ( ie no FrSky etc )
* suppose I'm interested in having a failsafe, but don't care for digitial telemetry ( I have also a video downlink and OSD gives me this data)
* suppose I'm an embedded systems programmer

Plan:
I therefore want to implement an on-board microcontroller that can listen to data coming from RC ( eg, on a specific channel like channel 8 ), and all I want it to do is "trigger a failsafe" into my other on-board computer systems ( ArduPilot ) - which I can do by outputting a specific PWM value on a single channel. The ArduPilot can then switch mode/s, and turn the plane around , and fly it back to me.

Idea:
I already know that in the event of signal loss, the stock turning RX "holds" the last known position of the servo/s, so following on from an idea got elsewhere [*], I want to make the TX ( running er9x) output a constantly varying stream of data on channel 8 ( eg, flipping constantly from PWM1000, to PWM2000 ). In the planned microcontroller that I'll plug into channel 8, it will simply watch for changing data, and if the incoming stream of data doesn't *keep changing* ( within a time limit of say 1 or 2 seconds), then it will change the output value to the appropriate fixed PWM value to signal RC link loss.

For other user/s without onboard flight-stabilisation, it could be as simple as connecting the PWM output to a servo that opens a parachute ( to prevent fly-aways), or the PWM output could be connected to the rudder,flap,aileron or whatever, so that the plane starts to "turn around", and hopefully come back into radio range.

I'm quite comfortable with building the in-air part of this ( microcontroller, software etc ) , but I'm not familiar with the insides of er9x, so I want to know if
(a) is this do-able
(b) would the existing formware be able to be made to do it?
(c) how much re-programming effort would it take?
(d) any volunteers? ( I'll send you one of my prototype failsafe units if you need to write actual code! )

* http://eastbay-rc.blogspot.com.au/2011/ ... gy-9x.html

As Crucial pointed out the servo test template could be used as a base for the 9x side.
From the servo test template in Er9x
CH15 +100% CH16 Slow(u1:d1)
CH16 +110% FULL Switch(SW1)
R -110% HALF Switch(SW2)
R +110% HALF Switch(SW3)

The only thing I changed was the slow speed on CH15. You can then make a mix like this CH8 +100% CH16 And you will have your oscillating channel.
-Gohst

- I wonder if anyone has actually tried using a parachute with failsafe on a model plane??

Post by **cre8tiveleo** » Wed Jun 20, 2012 6:42 pm

I have. Just as an experiment on my 800 glider i have a parachute on an elastic band release when the signal loss occurs, it cuts throttle and releases the chute. Works pretty well. I want to do this for my cirrus sr22 turbo.

buzz · Post by **buzz** » Thu Jun 21, 2012 3:35 am

Thanks for your input. I'm not sure I understand the suggested "mix", but I'll read the manual ( again) to figure it out.

Also, I've ordered some microcontrollers , as I plan to see this through to a working prototype at least.

It's conceptually a very easy piece of code to write as at its simplest it's just one PPM channel in, and one PPM channel out. Although.... I'll probably make it two channels in, and one channel out:
eg: assuming two PPM inputs A&B, and one PPM output C: during normal operation it just passes PPM untouched from A->C, but if PPM input B stops changing, it "forces" output C to a fixed position, ignoring the input from A.
The physical formfactor could be similar to a small servo reverser , or a servo "Y" connector. ( ie tiny, and in-line ) . If I add a little pushbutton to the unit, then the position of the output when it's on override could be set without any re-programming etc ( eg, have it output any of 8 values by pressing the button repeatedly, and it remembers last setting permanently in EEPROM or something. )

are there any downsides to this? has something similar already been done? I'm thinking i should be able to make it for under $10

gohsthb · Post by **gohsthb** » Thu Jun 21, 2012 3:33 pm

Depending what uC you are using you might be able to use an internal comparator as the pass through. That way there would be very minimal delay. Then when signal is lost you can just disable the comparator output and do whatever you want with it. I think you might setup the push button as a go to this value kinda thing. Set the normally oscillating input to what you want the output to be. Then press the button and have it remember that position.
If you are using this to release a parachute you shouldn't need 2 channels for input. You could simply program a switch to stop oscillating the input channel which would then cause your circuit to think signal was lost and release the parachute.
-Gohst

buzz · Post by **buzz** » Mon Jun 25, 2012 2:22 am

While thinking about the code, it's occurred to me that there are a couple of improvements I could make:

1 - "using up a channel" is poor form, and unnecessary.

If my uC code is "listening" for a constantly changing PPM signal in order to determine if failsafe has occured, then it could either listen for channel "jitter" as a sign that the RC is in-range, or it could listen for PPM that isn't "sweeping" betwen values, but jumping between them.
If one of these values was *min* ( eg 1900 ), the other value being jumped to could be the "real" desired PWM value for that channel.
So, we deliberately introduce a periodic PWM value of 1900 into an otherwise perfectly normal channel, and use that as a "heartbeat" from the TX.
My unit would simply detect the presence of that "heartbeat", and never pass it through to it's output. this means that the channel this unit is plugged into would still operate perfectly normally.

2 - the original idea was not as-useful for simple ( RC only) systems as it could be.

There are a number of ways to make it more useful to RC-only systems, but they all introduce more cost ( eg putting failsafe on all channels needs more connectors and a bigger uC, and bigger footprint etc ). I've decided that if I implement this to a product stage ,with the above (1) function included, then each channel can still be used for its original purpose, so if someone wants failsafe on more than one channel, then they can use one of my unit/s on each channel requiring failsafe. ( eg, if they want to force throttle off at the same time as deploy a parachute, then they can use two of this unit) . This way you only pay for what you you need, and no more. I expect cost per unit to be low enough to justify buying multiple of them if someone wants to.

3 - PWM Vs PPM. Many modern RC systems can work in PPM mode, allowing you to output a 8 channel PPM stream from your RC with just one plug. My unit has just one plug. nuff said.

I consider this a possible future enhancement, not part of the original spec.

Post by **Rob Thomson** » Mon Jun 25, 2012 3:49 pm

I think as that as a simple device to sit inline and provide fail safe on 1 or 2 channels.. This could have legs!

---
I am here: http://tapatalk.com/map.php?eqe1xk
Sent from my iPhone using Tapatalk

Post by **Crucial** » Mon Jun 25, 2012 3:56 pm

Sounds similar to this device.

http://www3.towerhobbies.com/cgi-bin/wti0001p?&I=LXHLV3 I have one on my nitro truck and it works well.

Post by **ShowMaster** » Mon Jun 25, 2012 4:24 pm

I thought many modern digital rx's hold last position when ppm is lost? Not a settable failsafe however on many. I'm sure this device monitors and looks for a loss of ppm out on the monitored channel it uses for failsafe? Does the stock rx lose output on loss of link? I've never used any I have, just store them. I've just installed Frsky right away.
SM

buzz · Post by **buzz** » Thu Jun 28, 2012 3:26 am

there are a lot of receivers on the market, and (for non-fail-safe ones, which is most of them) there are two common alternatives when PPM is lost:
(a) hold last position ...ie fix servo PWM output to last known pulse setting
(b) stop transmitting PWM info entirely ( ie no pulses).
(c) ( rarely) transmit a default PWM signal, sometimes 1500 or 1000.

None of these works well as a "failsafe" by itself ( ie the aircraft will crash eventually):
(a) because the throttle and ailerons are held in-place, and aircraft will keep flying potentially straight, allowing fly-away.
(b) because servo's without a PWM signal can be unpredictable. some go limp, some hold position, who knows.
(c) this is the worst, and it will force surface/s all to the wrong place, and typically spiral-in a plane.

Turnigy 9x 2.4Ghz receivers do (a), which is at least the least-bad of the three bad options.

AFAICT, the failsafe listed above ( towerhobbies) only works with recievers that their last position when PPM is lost, ie type (b) receivers in my above list. However, it does at least still/also offer protection from low battery brown-out etc.

buzz · Post by **buzz** » Thu Jun 28, 2012 3:28 am

Also, the micro-controller/s I ordered have arrived, and I've connected one to my programmer, and got it accepting code! now I just have to get the code ideas onto the chip, and I'll be laughing!

msev · Post by **msev** » Sun Jul 01, 2012 7:40 pm

But do turnigy receivers do (a) also on the throttle channel? Wouldn't that mean the throttle was still on, from what I've seen the throttle is off when it doesn't have signal?

buzz · Post by **buzz** » Mon Jul 09, 2012 3:55 pm

Progress! I've just spent a few hours thrashing out some code... and I've made a "working" , proof of concept.

This is my first time coding on an attiny85 (the atmel chip I selected), and I've reached a couple of conclusions. Attiny85's do not have a 16bit Timer Counter ( my oversight) , so creating/managing a Servo pulse-train data without jitter is my current problem. I have *nasty nasty* jitter, except when I disconnect the input signal, and artifically create my own fixed PWM pulse stream.

working features: passes-through PWM pulses normally ( jittery) ; in the event of PWM input signal loss for more than ~1/10th of second, it generates its own PWM pulse-train, pushing the servo to a fixed pre-programmed position ; LED indicator comes on to indicate problem/s with PWM signal.
not working feature/s: all other ideas.

I intend to fully re-work this code to be interrupt driven, and possibly revisit my choice of chip so at to include a 16-bit Timer Counter, and that will fix most of the current malaise.

Buzz.

gohsthb · Post by **gohsthb** » Mon Jul 09, 2012 6:24 pm

Just put a resistor and diode in the signal line. I think something like a 1k might work. Have one uC pin connected before the resistor and diode to read the incoming pulse, and another connected after the resistor and diode. Then instead of recreating the signal through the uC you only need to read it. When you want to take over and send your own signal just switch the output pin out of high-impedance. It should be able to overdrive the signal coming from the receiver.
-Gohst

buzz · Post by **buzz** » Fri Aug 24, 2012 4:38 pm

I know I must seem daft, but I can't figure out what the sugested settings mean. I can figure out how to get the lines into my TX to look the same as these, but it doesn't work in the simulator. ( I use eepe, so would rather it described in terms of which Tab to use in there, and which field name, etc)

CH15 +100% CH16 Slow(u1:d1)
CH16 +110% FULL Switch(SW1)
R -110% HALF Switch(SW2)
R +110% HALF Switch(SW3)

gohsthb · Post by **gohsthb** » Fri Aug 24, 2012 8:21 pm

Does this help?
-Gohst

msev · Post by **msev** » Sun Sep 02, 2012 7:16 pm

Buzz can you share the code and schematics for the attiny85 you are using! I would like to use such a project....In my case I would go like this, have two channels connected, the throttle channel which goes blank when receiver looses signal (this way the attiny could detect when receiver lost signal)...And when the attiny would find you there is not signal going to the receiver it would send a 1300us pulse (like middle 3-way switch position) on channel 8...I would need this to initiate return to home on my flight controller board.

buzz · Post by **buzz** » Wed Sep 05, 2012 2:14 pm

msev: the attiny85 code is c**p, and will never reach production, ( its not interrupt or timer based, and is jittery, I will not wish this code on anyone. )

all: I've discovered I was wrong to idetify turnigy receivers as being type (a) in my earlier list of three options, and after putting one on hte oscilloscope for myself, and seeing it first-hand, they are in-fact type (b) - they completely drop the PWM signal/s when the TX is off ( ie when the red light goes out on the RX, the PWM signals stop entirely).
> (a) hold last position ...ie fix servo PWM output to last known pulse setting
> (b) stop transmitting PWM info entirely ( ie no pulses).
> (c) ( rarely) transmit a default PWM signal, sometimes 1500 or 1000.

This means two things:
1 - I do not need to detect movement or jitter in a channel to know if it's "alive" ( yay ) ,
2 - it also means that any-old pre-existing AM/FM failsafe like the above suggested towerhobbies device, or similar from HK will probably do just as well as my device would have. result: no need to make my original product as I originally thought.

Finally, I have also discovered that despite an atmel328 only having a limited number (3) hardware PWM outs, it's got PCINT hardware interrupts on enough pins that it looks quite useful enough that I am thinking about making a full 8 channel failsafe unit with just a single chip. At the moment I have a unit that can take 8 full PWM input channels , and create a single PPM output stream ( as used in some equipment ), and I'm playing with the idea of making it a 8-way failsafe unit, for just a couple of dollars worth of chip. ..... we'll see.

Post by **Kilrah** » Wed Sep 05, 2012 2:19 pm

buzz wrote:all: I've discovered I was wrong to idetify turnigy receivers as being type (a) in my earlier list of three options, and after putting one on hte oscilloscope for myself, and seeing it first-hand, they are in-fact type (b) - they completely drop the PWM signal/s when the TX is off ( ie when the red light goes out on the RX, the PWM signals stop entirely).

Have you checked all channels? From what I've read not all channels behave the same way, and then differ between receiver versions. So for example 2 will hold but the others will go dead, etc

msev · Post by **msev** » Wed Sep 05, 2012 2:33 pm

Kilrah wrote: Have you checked all channels? From what I've read not all channels behave the same way, and then differ between receiver versions. So for example 2 will hold but the others will go dead, etc

I've also heard the same, maybe its different between different "ages" of receivers?

Post by **Kilrah** » Wed Sep 05, 2012 2:37 pm

Found the thread again:
viewtopic.php?f=44&t=663&p=21919#p8657

There's really a mix of (a), (b) and (c) among channel number, brand and version... I guess you should scope any channel that's critical on every receiver to make sure it behaves how you want.

ReSt · Post by **ReSt** » Wed Sep 05, 2012 5:44 pm

I just recently verified some 6Ch receivers.
The Turborix receiver drops signal on all channel, while the HK receivers hold the last position on channel 4 and 5

Reinhard

buzz · Post by **buzz** » Thu Sep 06, 2012 1:20 am

to gohsthb: thanks for the model file, it really helps!

here's how it looks in eepe:

Gladiac · Post by **Gladiac** » Tue Oct 09, 2012 7:11 pm

Hi!
Can anyone tell me what do i need to do to have failsafe on turnigy recivers?
I am new at this so please explain good

THX

Post by **Crucial** » Tue Oct 09, 2012 7:44 pm

You can't. There is no programmable fail safe on the Turnigy rx's.

Gladiac · Post by **Gladiac** » Sat Oct 13, 2012 7:37 am

But here people are talking of some kind of failsafe that can be set. If i understand with some kind of addon to channel and mix described in post.

Am i wrong ?

Post by **Kilrah** » Sat Oct 13, 2012 7:48 am

The OP had the idea of developing a little add-on board that could be put between the receiver and servos to offer failsafe, but I don't think it ended going anywhere.

Post by **Rob Thomson** » Sat Oct 13, 2012 7:49 am

Looks to me like it is a bit of magic - an add on module that sites between your servos and the receiver to provide a fail safe of sorts.

Probably easier to just switch to frsky and get failsafe on all channels!

Rob

Post by **Kilrah** » Sat Oct 13, 2012 7:54 am

Those modules were common in the MHz days! Much easier to implement on PPM receivers that simply stopped sending pulses or sent out just noise when RC was lost though. But yeah, there are much better solutions nowadays.

ReSt · Post by **ReSt** » Sat Oct 13, 2012 10:40 am

Only the 3 channel receiver has a real failsafe setting on one channel (ch3 IIRR)

Reinhard

Gladiac · Post by **Gladiac** » Sat Oct 13, 2012 8:14 pm

Hehe i would try frsky but i have about 20 turnigy recivers so it would be cheaper to make addon

openrcforums