Interference and Buzzing

Based on what I have seen, I believe the “going bananas” problem and the “buzzing” problem result from two different effects. The first is caused by electromagnetic interference/radiation (EMI/EMR) and the second is more commonly to do with the mechanism that transmits force and motion to the point tie-bar. Unfortunately, if we are not careful, in trying to solve the one, we might make the other worse.

From the description of how the servo controller chip works, if enough EMI energy is coupled into the servo input, the internal monostable will trigger and launch the servo into a cycle. During the cycle it will attempt to reduce, or eliminate, any error between its current position and the latest demand position it “thinks” it just received. If, by a complete fluke, the EMI happens to produce an input pulse width that is about the same as the monostable pulse width, the servo might just “twitch” slightly. The more likely result is that, thanks to the pulse stretcher, it will swing wildly through many degrees, and as EMI often comes in a burst of events, several cycles will launch and the servo will attempt to cancel the error for each one and swing erratically until the EMI subsides.

To make matters worse, the servo does not have a large amount of noise immunity while the input is in the “low” state. That’s not a criticism of the device. In the environment for which it is intended, its noise immunity is quite sufficient. The problem is that model railways can produce a lot of EMI from many sources, and if there is a long wire connecting the input of the servo to the servo controller, it will act as an excellent antenna and collect all the EMI energy it can.

The buzzing problem that many people have encountered isn’t really so much a problem with the servo itself. Buzzing occurs, either because the widths of the pulses driving the servo are not stable enough (which, in most cases, is not very likely), or (much more likely) the servo can’t quite get to the point of cancelling out the error because of mechanical “back pressure”. When that happens the servo will try valiantly to get to the position demanded, and it won’t quit trying until it does.

It’s very desirable to set the servo up so that it maintains pressure between the selected point blade and the stock rail. Unfortunately, maintaining that pressure means that the servo has to keep trying to get to a position it can’t quite get to, or does get to but is then repelled slightly because of compliance (springiness) in the mechanical connection. Even over-center springs won’t necessarily help because they can drive the servo beyond the precise position required.

It’s not difficult to observe this situation. Just connect a servo to a stable pulse generator and try to force the servo to a slightly different position with some finger pressure. (Not too much; you don’t want to strip the gears.) The servo will keep fighting back, and if the pulses are set to arrive 50 times a second, you will hear and feel a 50 Hz buzz.

To overcome this we could adjust the input pulse widths very precisely for each point so that the servo positions the blades at the “just right” position where there is almost no gap between the blade and the rail and there is no pressure exerted on the rail. There are a couple of snags with this. It’s a bit of a pain to have to customize the settings for each point, and it assumes that everything will stay constant over time.

Unfortunately, as the monostable in the servo is not clocked from a highly stable crystal circuit, it is susceptible to the effects of temperature and component ageing, and random noise within the servo itself. This means that, even if you precisely set the pulse widths at the controller to prevent a servo buzzing, there is no guarantee that it won’t start buzzing at some point in the future.

Another possible solution to the buzzing problem is to have the controller only send pulses to the servo for a limited time after the point direction has changed and rely on the considerable mechanical friction in the servo’s gear train to maintain the desired position. The problem with this approach is EMI. Should EMI launch a servo cycle, the servo won’t return to the desired position. It can remain in some indeterminate position indefinitely until the next real position update. Consequently, this method of eliminating the annoying buzzing problem can lead to a much more serious functional problem.

What’s a person to do?!