Debouncing: Another use

[Coenraads]

In converting a Casavant console to a solid-state combination action, I told the organist that I could provide him with a piston sequencer, even though the combination action had no provision for this. I decided to use an Arduino to scan the 15 general pistons and use relays to operate the combination action instead

Last week I must have spent two days trying to track down a problem with the piston sequencer where operating pistons, especially toe studs, would randomly cause a general combination to be activated. After going down various rabbit holes (additional pull-up resistors, relays to isolate the inputs) I discovered that removing the connections to the general pistons (which run to three of the four manuals) the problem went away.

Now a pipe organ is, electrically speaking, a noisy environment and it appears that the Arduino was picking up and responding to this random noise. You see, I had written the code to respond immediately to the push of a general piston not seeing any reason to debounce that input. So I rewrote the program code to ignore all inputs that did not come from a solid piston push lasting at least 10 ms. After I uploaded the new code, the random behaviour immediately disappeared and the sequencer was responding promptly to its inputs exactly as it should.

Lesson learned: Debouncing can be used to squelch electrical noise.

[gtc]

Good tip.

De-bouncing cheap switch contacts was the bane of my existence years ago when programming PIC micros. Maxim makes a range of de-bounce chips that I was going to try (solving hardware problems with hardware appeals to me), but I don't play in that arena these days.

[Admin]

Makes sense. My only possible concern would be if the noise spikes were of sufficient amplitude to fry the input circuitry. Unlikely, though.

I am, though, curious as to how the pistons were wired. Are they matrixed? Are the inputs pulled high? What are the values of the pullup resistors?

As gtc observed debouncing can be difficult, and there are different ways of implementing it. Thinking out loud, it seems to me that certain approaches would be more effective against suppressing induced electrical noise than others. I'd be interested in your approach.

[Coenraads]

The first time electrical noise/crosstalk bit me hard was when I MIDIfied a Galanti console for a friend. It was already matrix wired ( a single matrix for swell, great and pedal) so it was simple to hook up. I connected the two manuals and all was well. But when I connected the pedal it began to misbehave.
Rabbit hole #1: What did I do wrong? Checked the wiring extensively. No errors found.
Rabbit hole #2: Is it cross talk? What if I separated the wires going to the pedal so they are no longer in close proximity? Hint: this didn't help a bit.
Solution: Separate out the pedal matrix and scan it with a second Arduino Uno. That did the trick! Lesson: there is only so much wire you can hang from an Arduino input before you run into trouble.

The second time was getting this piston sequencer to run on a pipe organ. The combination pistons are all wired active low (i.e., they switch to ground). I tapped into the general pistons and parallel scanned them (no matrix) using 15 inputs on an Arduino kept high by the internal pull-up resistors (~ 30 k I believe).
Rabbit hole #1: Was noise coming in on from the Back and Forward pistons which were wired all over the console? I isolated these two inputs using a couple of small relays, but that didn't help.
Rabbit hole #2: Install 3 k external pull-up resistors on the Arduino inputs. That also didn't work, to my surprise. Was I going to have to relay isolate all 15 piston inputs?
Solution: Install an industrial strength debounce routine that checks each input for 10 consecutive loop cycles (each takes about 1 ms). If a low is returned for all ten checks, then and only then does the program respond to that input. This immediately squelched all the bad behaviour and the sequencer is operating like a champ.

I don't like the idea of random noise running around the organ capable of triggering errant events, but with current pulses of 1/2 A flying around operating the coils on about 70 SAMS, what can one do?
If the Arduino fries, we'll find out. They are cheap enough to risk it. In my old age I'm still learning!

[Admin]

Ground loops and power supply problems can also be contributing causes to electrical noise. I would think that a 3k pull-up would take care of any induced electrical noise. On my MIDI'fied Allen I'm using the internal pullups on the MCP23S17 chips I use as I/O expanders. I don't have any problems with spurious inputs despite having 132 SAMS running at 40 volts. I did not find it necessary to debounce the pistons or toe-studs, although, on occasion a dirty contact would result in a double trigger. I let a Hauptwerk setting take care of that on the MIDI message side of things for me. The stop tabs are all debounced with a 10mS delay like you implemented.

A method of debouncing that avoids the latency is to trigger on the initial state change and ignore any additional state changes for the debounce interval. This, of course, is debouncing in the strictest sense of the word as it assumes that the initial state change is actionable and that any subsequent changes during the debounce interval are due to contact bounce. Needless to say, this will not surpress electrical noise.

[lizny]

If you had a similar rway to deal with noisy slide pots, I'd love to hear it!

[Admin]

There's no good way of dealing with noisy pots if they're passing audio other than to clean them,

Assuming that you're talking about sliders that provide a DC voltage to a digital encoder, and if you're writing your own software, the way deal with noisy sliders is to use a rolling average of the last N samples, where N is large enough to prevent the noise jumps in the digital output, but small enough to produce acceptable latency. This will help, but if the pots are too noisy, there may not be an optimal value for N. This is effectively the same as using a series resistor and a capacitor to ground to form a low pass filter at the input to the converter.

[Coenraads]

I was about to respond by suggesting a rolling average, but Admin explained it much better than I could have.

You could get the same smoothing effect by having the noisy pot control the current through a filament light bulb and then measuring the light intensity using an LDR. (Similar to what you find in some swell pedals)

[John Kinkennon]

If I had to do hardware debouncing I guess I would look at devices implementing hysteresis at the inputs. Software debouncing is cheaper, faster, and configurable as well. I'd sugest scanning contacts every 300 to 500 ms and looking for some number of consecutive measurements to determine the contact state. This amounts to about 2ms total which is a good compromise between latency and handling intermittent pistons and toe studs. For pots I scan about once every 4 or 5 ms which is really too fast and then do an average as mentioned.

[Coenraads]

I think we worry too much about latency. When, in the early 1980s, I had built a multiplex switching system for my 10 rank pipe organ, I decided to experiment with the clock rate by noting the response of the organ with different scan rates. As I lowered the scan rate, I started to only notice the latency below 50 Hz. Ever since, I figure that as long as the scan rate is over 100 Hz there is nothing to worry about. That translates into 10 ms per cycle and with Arduino programs typically completing the main loop in about 1 ms I have stopped worrying.

Now it is true, I was controlling an organ with electro-pneumatic action with its attendant delays. The console to organ distance was about 20 feet and since sound travels at about a foot per millisecond, that in itself constitutes a 20 ms delay. Pipe organists are used to this.

In my debounce routines, I usually monitor a switch over 3 or 4 scan cycles resulting in a 3 or 4 ms latency which IMHO is of no consequence.