Prototype console interface for embedded projects
At the UK Makerfair during a brief lul the conversation turned to rotary encoders, simply as I had ordered a paw full from china for one of my many projects that simmer along in the background. The picture here shows the initial prototype that I used for this article. The feedback about rotary encoders that I received was that they were terrible and to be avoided. Principally as the switch contacts were very noisy and produced way too much bounce. I was still interested in using them firstly as having done embedded stuff for years bounce is something I consider trivial and fixable, secondly as they make a really cool, easy and feature full user interface using the minimum of pins.
The circuits I most commonly use for de-bouncing simple switch contacts are shown in the picture here. I ran this up in Kicad for the article. Something worthy of note is that Arduino’s and a number of other micro controllers have internal pull-ups that you could use. Do not use these when de-bouncing your inputs. They vary very widely in effective resistance value and the results will be massively variable when used with the same external components. Indeed a quick search of the internet shows a range of circuits and values mostly with a string of comments along the lines of someone found a different value or combination to work better. What is happening here, and why so much variability of what should be a trivial, bread and butter type, of interface circuit.
Time to dig out the Bitscope I bought from Pimoroni a while back and capture some waveforms. It will work as a capable enough DSO for this investigation. On the left is the A output of the rotary encoder from the previous picture set-up as a switch with pull-up as per the schematic above. The value of the pull-up resistor in this case is 10K Ohms a fairly typical pull-up value. The large nice square pulses are the outputs from the encoder and the very narrow horrible pulses are the switch noise and bounce. This looks reasonably what I would have expected although the switch looks to be more noisy than bouncy. I spun the input shaft quickly by hand to get enough pulses into shot and it is noticeable that the rubbish pulses produced are proportional to the speed of spin. The other thing that is noticeable is the duration of the pulse are quite short. With a standard press button you can not move your finger that quick and a de-bounce period in software of around 10mS is not uncommon. In this case though, if you did this it is clear that you would be missing a lot of steps from the encoder. Each one of those noise pulses is a full logic value in height and will trigger an interrupt, giving you a wildly incorrect count and wasting a whole shed full of precious processing cycles. I can see why you might think they were to be avoided if you had not de-bounced them in any way.
100nF De-bounce Capacitor
Adding a 100nF capacitor as per the above schematics produces the results below. This produces a very large reduction in the height of the noise pulses but they are still large enough to trigger some interrupts, the amount of processor time we waste though is reduced. The number of incorrect counts is also reduced but there are still some present. Also look at what is happening to the corner of the rising edge of the pulses that we want to work with. They are no longer square and are being rounded off. So a big improvement but still not as good as we would like. In a simple switch this rounding etc is not a problem. We are working with a rotary encoder though and the relative position of the edges in each channel is important to us. Where an edge curves too much it becomes unclear where the micro controllers input will decide it has switched from logic 0 to logic 1. If we got such a big improvement for adding in 100nF, will adding in some more be helpful?
200nF De-bounce capacitor
So lets add in another 100nF capacitor in parallel across the one we put in last time. Taking the total up to 200nF. Yes the noise is reduced much further and we could probably work with that at a push. But look at the state of the rising edges. As we increase the capacitance we increase the loss of definition of the rising edge and consequently our ability to correctly resolve the direction of the encoder. The faster the encoder is turned the more problematic this becomes as the curve remains the same width but the width of the pulse we are relying on has become narrower. We could have kept the capacitance value the same but increased the resistance to say 20K and we would get exactly the same result. The RC network that is cleaning up our signal has a time constant that is proportional to the ratio of the resistance and capacitance that makes up the circuit. It is this time constant that is low pass filtering the pulses and giving us the effects we can see on the scope. Bearing this in mind if we check out the Atmel AVR data sheet, as this is the most popular micro-controller in the Arduino series, we see that the internal pull-ups have a value of between 20K and 50K. So a massive variation in the pull-up value and consequently a massive variation in the de-bounce action and on our pulse edges is produced by this, hence why de-bounce circuits that use the internal pull ups are to be avoided. We need results that are consistent.
For a simple press button a simple RC network as shown in the above works great as it is a very slow logic signal, but what can we do to recover nice square edges on our fast, encoder signal pulses, and get rid of the noise pulses. The answer is to use a Schmitt Trigger which increases the level at which a rising edge will be consider to have switched from low to high and reduces the level at which a falling edge will have switched from high to low. This circuit will ignore the noise pulses that we have reduced in height leaving us with a clean pulse train and nice square edges from our encoder. Check out the linked wikipedia article, ignore the over complicated mathy explanations and control theory waffle look closely at the wave form diagrams at the top right of their page. What is more this circuit is so useful that it comes already built in to a number of inexpensive logic gates. You don’t need to make one.
Unfortunately I don’t currently have the parts to hand to show the fully processed pulse train but the procedure is to add in a Schmitt Trigger logic gate (ie a 74LVT14 or similar) as per the diagram above, pick the pull up resistor value for your chosen application 10K is good for most applications, looking at our scope waveforms you may want to go to somewhere conveniently around 20K. Then starting with a small capacitance for the de-bounce capacitor increase it until all your noise pulses on the output of the schmitt gate have gone. Using your scope to see when this happens. Once you have achieved this you know what the correct values are and can pick the nearest off the shelf value to use every time and get repeatable results. What’s more you will not be wasting any precious processor cycles on clever de-bounce code and unnecessary interrupts.
Take away points from this are:-
- Do not use the internal pull-ups with de-bounce circuits it is a false economy.
- Simple RC circuits are plenty good enough for simple push buttons and switches.
- You need a logic gate with a schmitt trigger input to clean up the faster logic pulse trains from rotary encoders.
- You can do a lot of electronics and get an intuitive grasp of what is happening by laying on a scope and laying off the math.
- Clean up your signals before trying to code them clean, crap in equals crap out.
- Rotary encoders are great if you know how to work with them.