141 replies to this topic

[Mr.RC-Cam]

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.

Attached Thumbnails

• 

[Mr.RC-Cam]

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.

Attached Thumbnails

• 

[gtsiros]

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?

[Mr.RC-Cam]

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.

[gtsiros]

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!

[Mr.RC-Cam]

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.

[Temporary Insanity]

This looks like a great little gadget. Is there any chance it would fit on the PIC10F series?

[Mr.RC-Cam]

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).

[Temporary Insanity]

I'm just spoiling for an excuse to use one of the 10F series. They are just so cute.

[bluegill]

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

[Mr.RC-Cam]

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....ad.php?t=321360

Bruce Abbot has a nice project, with source code here: http://homepages.par...tt/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, 13 July 2005 - 09:36 AM.

[bluegill]

I have created complex PPM frame decoders with failsafe functionality. Details to one of these is found here: http://www.rcgroups....ad.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

[Mr.RC-Cam]

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.

[bluegill]

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

[Mr.RC-Cam]

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, 13 July 2005 - 10:26 AM.

[Temporary Insanity]

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.

[bluegill]

... 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.par...tt/decoder.html His 6-channel design looks like a good starting point.

--bluegill

[Mr.RC-Cam]

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.

[Mr.RC-Cam]

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.

[Temporary Insanity]

Yes, thanks for the link! I'm glad he has included the source code. I'm a fledgling programmer and I'm sure I'll learn some very usefull things.