Speed Controls - Analog vs. Digital

The function of a speed control boils down to this: take the signal from one channel of the receiver (square wave with period of about 20 ms and "on" cycle of about 1-2 ms depending on the joystick position); then generate a square wave with frequency of about 1-3 kHz, and 0-100% duty cycle depending on the width of incoming pulses. The resulting output is used to drive the FETs.

An analog speed control typically does this in several steps:

integrate the incoming signal - this means smearing the short pulses over the entire wave period, resulting in a voltage variation of about 0.2 V
compare this voltage with a more-or-less triangular wave whose peak-to-peak variation is a tad smaller than the 0.2 V or so; this generates a constant "low" when the incoming pulses are at 1 ms, a constant "high" when they are at 2 ms, and a low-high pulse anywhere in between

Neither of these tasks is very easy because we are dealing with pretty small changes in the integrated signal. The variation and level of the triangular wave has to be adjusted very precisely to the exact values you get in step (1). I've played with various ideas and tried all the analog designs I saw, and none of them gave a really good, predictable signal.

Attempts to improve the whole process only complicated the circuit (which defeats the idea of building a home-grown simple unit, and increases weight); moreover, they weren't very successful.

The digital age

When I got interested in PIC microcontrollers, it quickly became obvious that they remove all the obstacles, except for one: getting started with PIC development. But once you buy or roll your own programmer, learn a few instructions and get a few chips, there is really no excuse for sticking with the analog designs in my opinion. I'm not a cyberzealot - for example, I don't think I'll ever switch to digital cameras. But in many applications microcontrollers are an absolutely wonderful gadget.

For convenience I use the reprogrammable 16C84 chip, which is not the cheapest (about $6) and the standard version runs at "only" 4 MHz. But considering that the whole circuit now becomes a single chip plus a quartz crystal and a couple of small capacitors, eliminating all op-amps, resistors, trimmer pots etc., it doesn't really cost more. The complexity gets shifted into software, but even that isn't bad.

I now have a simple prototype working, and I can speak from experience when I list the advantages of microcontroller based ESCs:

safe start - simply don't send anything to the output until we've seen the shortest pulse for a while, the longest one, and then the shortest again; this way you will start in the "off" mode, and only after the user moved the joystick down, up and then down again (it's important to have the chip do a full reset when the power is switched on)
detecting pulse width - a trivial counter, potential resolution of several hundred steps (remember that the processor can execute over 1000 instructions during even the shortest "on" input! and then you have almost 20,000 instructions left during the "off" period, so you can do a lot of things at your leisure)
debouncing/deglitching - when a transition occurs on an input, just tell the chip to make sure it stays on or off for several cycles before accepting it as a valid signal change; similarly, have the software ignore "rogue" pulses of unreasonable length
easy feedback - have the unused outputs blink a LED or two in response to certain actions, e.g. confirming the initial setup
adaptability - the initial setup takes care of the variations between manufacturers' radios, different models, trim settings; by checking that the measured "shortest" pulse is indeed shorter by a wide margin than the "longest", and by swapping them if it isn't, you remove all problems with misapplied servo reversing switches
solid output - a correctly designed program can guarantee that pulses close to the longest will produce a full 100% duty cycle, and that those close to the minimum will give full "off"

All of the above is quite trivial. Even with my primitive methods and lack of PIC experience it took about 4 hours to have a half-decent program, and it takes up about 1/5th of the 16C84's program memory. I'll post it when it's a bit more polished.

Imagination is the limit. By tweaking the code you can make the control more or less responsive, use jumpers to switch between various options, even gather statistics of glitches etc. and have them uploaded to your laptop's serial port when you land!

Last modified: 6/8/98