Jump to content
Mr.RC-Cam

RCFS-V2: New FailSafe with Glitch Filtering.

Recommended Posts

I have released the details to a new R/C Servo Failsafe with Glitch Filtering project. The full details, with PIC hex files, is located here: RCFS-V2

Features of RCFS-V2:

* Flexible Failsafe Modes (Idle, Hold, Preset).

* Glitch Filtering with Servo Pulse Flywheeling.

* Optional Low Voltage Failsafe.

* Buffered Servo Signal (20mA drive).

* 1000 Step Pulse Resolution Provides Exceptional Pulse Fidelity.

* Easy Range Testing: Status LED Indicates Servo Pulse Errors.

* All Failsafe Features are User Programmable (Easy Pushbutton Operation).

* Designed for electric R/C models. Works with all 5V BEC voltage sources.

post-7-1112745078_thumb.jpg

Share this post


Link to post
Share on other sites

I created a tiny custom PCB. The board turned out great and makes assembly a breeze. It is a double sided .031" FR4 board. Weight is 2.8 grams. All I need to do is add some heatshrink over this one and it is ready to go.

post-7-1113507510_thumb.jpg

Share this post


Link to post
Share on other sites

A very beautiful piece of work. It is more or less what i wanted, after my Tamiya off road nitro buggy went berzerk due to interference and stuck the throttle wide open and smashed into the wall.

Do you use a median filter?

Share this post


Link to post
Share on other sites
Do you use a median filter?

It uses what I call a modified-median filter. It includes impulse rejection. I won't divulge the inner workings, but it seems to be very effective.

Share this post


Link to post
Share on other sites

Hello again.

I'd use a combination of a small window median filter and an averager. But since your works, it must be good work.

I want to learn about how servos operate, specificaly how does one control them. If you can point me at some documents, i'd be very grateful!

Thank you again!

Share this post


Link to post
Share on other sites

Some very basic info can be read in this project: http://www.rc-cam.com/pancam.htm. Skip down to the "How Does PanCam Work?" section.

Beyond that, there are dozens of web sites that have information on controlling R/C servos. Some offer source code to PIC and ATMEL controllers. A little bit of Googling should fill you up with good stuff. Or, start up a new discussion in the R/C Electronic Projects forum and someone may be able to lend you a hand.

Share this post


Link to post
Share on other sites

The PIC10F does not have the resources needed for the performance I wanted. The PIC12F683 was perfect for the app. If size is an issue, then consider the .150" wide SOIC part or the even smaller DFN package (that one is not much bigger than the 10F).

Share this post


Link to post
Share on other sites

Mr.RC-Cam, you know I like your work and products, but...

I think that the whole receiver glitch issue needs to be looked at from a systems point of view, not from the servo's point of view.

The RC Servo Failsafe with Glitch Filtering is a great little device, but it doesn't share its conclusions with anyone or anything beyond the servo it is connected to. The only indication one gets (while flying) that reception is spotty is that the plane no longer responds to the controls. I often am not doing anything at the controls for many seconds, so the fact that I am flying into an area with interference, or out of the range of my RC transmitter, does not become immediately obvious.

I bought your MAHI (a very cute little device) primarily to make my video transmissions legal (it displays my ham call sign, and I am using way too much power for Part 15). I have been noodling with how to best get glitch info back to me, the pilot, in near real time so I can extricate myself (or at least the plane) before I lose contact and get to watch it fly away.

I've been horsing around with the buddy-box connector of my Hitec Flash 5X with the idea that I take the PPM stream from the transmitter and append to it another 3 channels, which are in reality just the first three channels again. On my plane they are rudder, elevator, and throttle, the three most important items for controlling the plane (it's a polyhedral and has no ailerons). In the plane, the idea is to add a PIC chip to the receiver which will compare channel 1 with 6, 2 with 7, and 3 with 8, and if they are not in close agreement then to throw away the info as being bad, and to also put a pulse of current into a capacitor which feeds the pitch input of the MAHI. If I get a lot of glitches in a short period of time the pitch indicator will rise quickly to the stop telling me to get out of there, and when I get back into good reception the capacitor's voltage will bleed off and the pitch indicator will show the reception is good again. RSSI doesn't do much for me for the following reasons:

1. It shows the strength of the signal coming in, but doesn't indicate whether that signal is from me or is interference, and

2. It decreases slowly with distance, while the glitches start popping up in profusion with location the plane is flying in, what other transmitters are in the area, and how much the high-tension insulators on the power lines are arcing due to dew and dust. In other words, there is no "safe" value of RSSI because that depends on the environment, which changes sometimes over a period of several minutes.

I've looked at the Berg and other glitch-catching receivers, but I really want to know about problems as they occur, not after the flight is over. One reason, of course, is that I may not see the plane again. But even if I do successfully get the plane back (which I have so far), looking at the LED and seeing that I got some glitches doesn't tell me very much about where I got them and how rapidly or slowly they added up over the course of a 50-minute flight.

I've found Francis Thobois' site Radio Modelisme interesting, but I don't think he really addressed the whole issue either. My understanding is that in the US it is illegal to use two channels simultaneously. His other main concept, putting a transmitter ID in the pulse stream is useful, but we still need to get the information back to the pilot as the glitches are being encountered.

What are your thoughts?

--bluegill

Share this post


Link to post
Share on other sites
I think that the whole receiver glitch issue needs to be looked at from a systems point of view, not from the servo's point of view.

A single channel failsafe is not as robust as analyzing the full PPM frame. But, gadgets like the RCFS-V2 do a decent job. If you tried it I think you would be impressed.

BTW, from what I have found, not everyone is interested in hacking their Rx to replace the decoder (but they will gladly connect something up to the servo).

I have created complex PPM frame decoders with failsafe functionality. Details to one of these is found here: http://www.rcgroups.com/forums/showthread.php?t=321360

Bruce Abbot has a nice project, with source code here: http://homepages.paradise.net.nz/bhabbott/decoder.html

As far as a full implementation for your app, I would recommend a combination of RSSI (Relative Signal Strength) monitoring and glitch detection. Each offers a different perspective to R/C signal health.

Edited by Mr.RC-Cam

Share this post


Link to post
Share on other sites
I have created complex PPM frame decoders with failsafe functionality. Details to one of these is found here: http://www.rcgroups.com/forums/showthread.php?t=321360

Yes, I had seen that thread but I thought you had decided not to add it to your list of current projects -- in other words, the preprogrammed PIC chips are no longer available.

I certainly do agree with you that

It may be seem tempting to just design a DSP decoder gadget that plugs into the servo connectors (for hack free upgrades). But, the results would definitely not be as good as feeding the DSP hardware with the native demodulated RF signal.

I had not seen Bruce Abbot's thread, and appreciate the link you provided.

--bluegill

Share this post


Link to post
Share on other sites
Yes, I had seen that thread but I thought you had decided not to add it to your list of current projects

The four channel DSP R/C decoder chip was something that I initially created for myself. There seemed to be some interest from others so I created a variant that was more generic for use beyond the buggy Plantraco Rx. Although I sent out about three dozen DSP PIC's, only a small fraction of folks actually implemented the part into their Rx (the GWS Naro and R4P Rx was a common host). It was just a tough modification for the average guy due to the soldering of the wires to the little PCB traces on the Rx.

So, the RCFS-V2 was created to ease the pain. If you have not tried it then I think you may be underestimating its performance. It is NOT an average "me-too" servo glitch filter. It really works and has very good performance.

Share this post


Link to post
Share on other sites
So, the RCFS-V2 was created to ease the pain. If you have not tried it then I think you may be underestimating its performance. It is NOT an average "me-too" servo glitch filter. It really works and has very good performance.

I didn't mean to imply that the RCFS-V2 is ineffective. In fact, based on your other designs as well as comments about how it works, I would be very surprised if it was not effective.

My line of thought isn't about the effectiveness of its glitch-busting, but about informing the pilot that he is getting into dangerous territory and needs to get out. I can tell from your comments about RSSI that your environment is quite different and much quieter than mine. I can easily show areas where RSSI of my receiver shows a strong signal, and that's without my transmitter being turned on! We have a major electric substation near where I fly, and very high tension lines feeding it, and a only somewhat lower voltage line running from it for several miles to another smaller substation. Being on the coast we get salty dew and fog, which means there is often some insulator arcing and creating broadband noise. Which insulator(s) arc varies, and sometimes the electrical noise at the flying field is very low, but other times there are distinct "rays" of noise, created by the lay of the land, buildings, and whatever between the arcing insulator and the field. The position of these rays varies depending on which insulators are arcing. We know of some consistent problem areas, but others show up sporadically and unexpectedly.

--bluegill

Share this post


Link to post
Share on other sites
I can tell from your comments about RSSI that your environment is quite different and much quieter than mine. I can easily show areas where RSSI of my receiver shows a strong signal, and that's without my transmitter being turned on!

That is why I recommended the combination of monitoring the Rx's RSSI signal AND glitch detection for your application. On their own they have limited info. Together, they offer more than just the sum of their parts.

There will be times that the RSSI will show an signal level that is not from the R/C Tx. But, this is real RF energy that can corrupt the R/C signal. That is where a "glitch" detector will earn its keep. But, during the times when the external interference is more tame, the RSSI can give you a relative indication of R/C Tx's signal strength, indicating pending doom when the RSSI signal is weak. And, if your model is at distance, and the RSSI value suddenly indicates a strong signal, then you could use that info to steer in another direction to avoid possible signal conflicts.

It's all data. What we do with it is what matters. :)

Edit: I forgot to say that if you want extensive glitch detection, then tap into the Rx's data slicer and perform a full frame analysis (template fashion). Observe pulse sync widths, servo pulse count, pulse width, and frame length/rate. Then apply your acceptance criterial to each of these. This is a huge software task, but any less will probably result in "just another decoder." If the latter is what would be created, then consider monitoring a couple of servo outputs; it is a lot less work and will do a decent job for most folks needs.

Edited by Mr.RC-Cam

Share this post


Link to post
Share on other sites

Ironically, the SOIC and DFN take up about the same board space. The DFN arguably will take up more space because of routing issues on a simple PC board. My thoughts were that there was no servo in a given application that I would elect NOT to protect if I chose to protect any. (You can imagine the outcome if say: the throttle behaved but all the rest of the servos went dithering to lock). So my question about the 10F series was driven by wanting to plop down multiple PICs for all servos on a common board with a common programming switch. I hope you see my point.

Share this post


Link to post
Share on other sites
... if you want extensive glitch detection, then tap into the Rx's data slicer and perform a full frame analysis (template fashion)....

Oh yes, I quite agree! That is why I am especially appreciative of the link you gave to Bruce Abbot's project at http://homepages.paradise.net.nz/bhabbott/decoder.html His 6-channel design looks like a good starting point.

--bluegill

Share this post


Link to post
Share on other sites
I hope you see my point.

I actually prepared myself to use the tiny PIC10F in the RCFS-V2 project (bought a $40 programming adapter, several chips, etc.). But it just did not have the resources to satisfy what I wanted to do. It is definately a tiny part though. :) For those of you that have not seen this new PIC, well it is about the size of a grain of rice.

Regarding the RCFS-V2, the .150 wide SMT PIC parts are very small. Six of them (for motor, rudder, aileron, flaps, elevator, etc.) on a board would not take up much space (hint: use both PCB sides). I estimate the servo connectors would eat up most of the real estate.

If it was me, I would design such a board so that the male servo connector pins on the Rx would line up with a row of matching 3-pin sockets on the multichannel RCFS board. That would eliminate the Rx-to-RCFS cables and make for a very compact affair. Installation would be plug in (no hacks to the Rx). I'll bet that is what you had in mind.

Share this post


Link to post
Share on other sites
His 6-channel design looks like a good starting point.

He is a good man for publishing the project (and he is a very talented fellow).

But in regards to what I am talking about, his design it is not what I call a "full frame" decoder. It does perform pulse width analysis, but only on a pulse by pulse basis. All the other frame related criteria I mentioned is needed if you are looking for extensive glitch detection. And such a design will require some serious work to fully implement. But, its just code. :)

Share this post


Link to post
Share on other sites
I would design such a board so that the male servo connector pins on the Rx would line up with a row of matching 3-pin sockets

Actually, the mating connector can be simpler than that, because the card needs to get the power and ground pins only once, not for each servo connection on the receiver. So one needs only 7 connections for a 5-channel receiver (power, ground, and the 5 channels).

A story in frustration, though -- I designed such a board to make it easier for me to move my Hitec 555 receivers among several planes. It worked fine

-- BUT

One of my 555 receivers suddenly decided it was intermittantly dead. I looked at having Hitec repair it, but that was nearly the same cost as getting a Hitec Electron 6 that was on sale at Hobby-People. Naturally I bought the new Electron 6. Naturally the Electron 6 not only runs the channels in the opposite order as compared to the 555, but spaces the servo connectors closer together.

Do I say ARRRRGH now?

--bluegill

Edited by bluegill

Share this post


Link to post
Share on other sites
... his (Bruce Abbot's) design it is not what I call a "full frame" decoder

Yes, I noticed that. I also noticed that he claimed he was averaging the current pulse (if it seemed OK) with the previous good one, but what he is actually doing is exponentially filtering each pulse. Nothing inherently wrong with that as long as everyone understands what is going on.

Still, it looks like a solid design to start from, and will allow me to get my toes wet in PIC assembler with a useful starting point. I've done a lot of assembler code in years past, but this will be the first time for the PIC, which looks like a *very* different beast than what I'm familiar with.

--bluegill

Share this post


Link to post
Share on other sites

I mean really, this is, if you pardon the expression, a "legacy" idea. With glitch-correcting receivers getting cheaper and more plentiful, I've moved almost exclusively to these newer types. Castle Creations has taken over the Berg line too. Castle knows how to crank out production and their published pricing looks very good. This leaves me with a couple of 555's that have started twitching like yours--and a Hitech Superslim which is about the same circuit as the 555. I wouldn't use any of them anymore any way. I've got a stable full of FMA's and Berg's to choose from. Perhaps the time for this idea has come and gone for all but the most fruggle of hobbyists.

T.I.

Share this post


Link to post
Share on other sites
Perhaps the time for this idea has come and gone for all but the most fruggle of hobbyists.

From my experience, nearly all R/C'ers are frugal maniacs. :) But, there is more to this than just trying to save money; Part of the joy for guys like me is devising new ways to use existing things.

If you look closely, that is really the basis of the rc-cam web site. In fact, it wouldn't exist if there weren't a bunch of DiY'ers out there with an interest in hacking things. But, your point is certainly well taken.

Share this post


Link to post
Share on other sites

...Besides my blatant misspelling of “frugal,” I have to in part, agree. I do observe a sometimes near-obsessive drive to save a buck, on the part of some hobbyists. Others seem at the other end of the spectrum. Whatever the polls would tell us, it is clear that hobby money is discretionary spending. Every time I buy something expensive like the open class, carbon sailplane that I just laid out about $2K to get in the air, I’m comforted by the thought that there are plenty of people out there that have $20,000+ ski boats that get used only on occasion. By that measure, most of what we do here is peanuts.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×