It's not like you are feeding it into ADC.
Yes you are, a 1-bit ADC
It'd be interesting to see your code...
It's not like you are feeding it into ADC.
Yes you are, a 1-bit ADC
By this logic, every digital IC is ADC. Even more, there is no digital at all. All is analog because electricity is not digital and "digital" signals have transition time with voltage levels in between.
Well: It can be argued that digital is "overdriven analog".
Really, my point is that (I believe) we still have a "sampled data system", even with "1 bit resolution".
By this logic, every digital IC is ADC. Even more, there is no digital at all. All is analog because electricity is not digital and "digital" signals have transition time with voltage levels in between.
Yes, quite!
Every pin is an ADC or DAC, as the case may be. Within the chip, we can follow the rules of digital logic (combinatorial and sequential logic, drive strengths if applicable, and propagation delays), and make some exceptions or precautions for metastability where applicable; but outside the chip, it's the wilderness. This is why logic circuits don't always simply work when you lash them together. You can't ignore analog considerations like signal quality forever.
Tim
Some more bounce testing here:
http://www.ganssle.com/tem/tem387.html (scroll half way to "Encoder bouncing").
The PEC11 was better than spec, 250us worst case, CUI was 5ms.
Cheap aliexpress PEC clones I have are usually good but will sometimes bounce up to ~6ms or so. A lot of it due to the technique you use to turn it.
Jack Ganssle (TEM) has given some interesting info. See The Embedded Muse #387 (
http://www.ganssle.com/tem/tem387.html ) for more info, scope shots etc
He found a 24 detent unit seemed to be ideally filtered with Bourn's suggested generic RC, but a 12 detent unit was not so easily tamed. My own experience has been that with a Bourns PEC-11 18 detent unit, the results were more like the images given for the 12-detent unit.
Both resistors are required.
(Attachment Link)
Ok but why don't use the internal uC's pull-up?
Both resistors are required.
(Attachment Link)
Ok but why don't use the internal uC's pull-up?
It may work, it may not, it might not be reliable, ...
Sometimes your gray_code count decoding will actually reverse direction.
You are basically eliminating the low pass filter by only using the built-in pull-ups, allowing more switching noise into the MCU. Also, the internal pull-ups would be after the filter. Not before as desired.
It may work, it may not, it might not be reliable, ...
Sometimes your gray_code count decoding will actually reverse direction.
You are basically eliminating the low pass filter by only using the built-in pull-ups, allowing more switching noise into the MCU. Also, the internal pull-ups would be after the filter. Not before as desired.
Thanks for your answer.
Yes, surely, the internal pull-ups would be after the filter. This was mainly my doubt.
In my experience a normal push-button with RC low-pass filter + internal uC's pull-up is reliable.
But of course here we have an encoder so also the train pulses speed and direction matter.
You don't need low pass filtering on an encoder switch like this, in general you don't get both contacts bouncing at the same time so any microcontroller sampling of the signals sees a valid quadrature signal. And even if you do occasionally who cares, its an encoder switch, its relative, not absolute. Just don't sample it too fast and any uncorrected bouncing issues will be limited in effect.
If absolute position matters you need an absolute encoder switch anyway, like this:
https://www.mouser.co.uk/ProductDetail/Bourns/EAW0J-B24-CE0128L?qs=N2XN0KY4UWWoYrMCVscpfw%3D%3D
You don't need low pass filtering on an encoder switch like this
Then why do the rotary encoder manufacturers recommend using them in the datasheets, providing recommended circuits and values?
You don't need low pass filtering on an encoder switch like this, in general you don't get both contacts bouncing at the same time so any microcontroller sampling of the signals sees a valid quadrature signal. And even if you do occasionally who cares, its an encoder switch, its relative, not absolute. Just don't sample it too fast and any uncorrected bouncing issues will be limited in effect.
Actually, the exact opposite of everything you said is true.
These encoders (example a Bourns PEC11) are very noisy when switching (look at them on a scope).
A resistor and a capacitor on each pin is trivial to ease the burden on the software.
And unless you're willing to accept turning the encoder very slowly, you will want
a pretty fast sample rate. I sample mine at 500Hz to provide an expected response.
It's been some time since I've looked at these, but you certainly want to be above 100Hz.
As I said earlier, no filter, a slow update and you will often get a response in the opposite
direction than you're turning encoder. Unless you want to drop big bucks on an optical encoder.
Just to mention that a big downside of interrupt based encoder servicing - a large number of interrupts generated by bouncing - can be avoided by having interrupts enabled on only one line at a time. So when A triggers its interrupt, the ISR disables further interrupts on that line, and enables them on B, which should be stable by now. So subsequent bouncing on A will not trigger interrupts. Special provisions are needed to deal with a change in direction, but in the end you end up with four interrupts per detent for a standard encoder. The encoder needs to not be totally awful, because if both lines are bouncing at the same time, this won't work. But if that's the case, no firmware method will work.
Just to mention that a big downside of interrupt based encoder servicing - a large number of interrupts generated by bouncing - can be avoided by having interrupts enabled on only one line at a time. So when A triggers its interrupt, the ISR disables further interrupts on that line, and enables them on B, which should be stable by now. So subsequent bouncing on A will not trigger interrupts. Special provisions are needed to deal with a change in direction, but in the end you end up with four interrupts per detent for a standard encoder. The encoder needs to not be totally awful, because if both lines are bouncing at the same time, this won't work. But if that's the case, no firmware method will work.
Never interrupt on pin change. That's just asking for trouble.
And the interrupt service routine WILL get swamped.
You set up a timer and interrupt at a fixed clock rate.
Then check for pin changes and decode into an up/down count.
Very short quick interrupt service.
The main process then uses the count from the interrupt (i.e. + or - count since last).
Increments/decrements whatever (can do some acceleration here) and clears the count from
the interrupt service and waits (or does something else) until the next count arrives.
(Usually check for a non-zero count somewhere during your main processing loop.)
You are basically eliminating the low pass filter by only using the built-in pull-ups, allowing more switching noise into the MCU. Also, the internal pull-ups would be after the filter. Not before as desired.
These are some screenshots for a single encoder's channel.
scope_10/11 are with the 10K pull-up removed from encoder's pin and moved after the RC as it was a uC's internal pull-up.
scope_12/13 are as suggested by encoder datasheet.
scope_15/16 are with just a 10K pull-up.
The encoder is a generic one, not the Bourns.
Interesting images. Is is possible to show the two channels (A,B) on the same screen-shot?
Interesting images. Is is possible to show the two channels (A,B) on the same screen-shot?
Images below refer to the datasheet suggested solution (RC=10k+10nF, pu=10k) applied on both channels.
After the previous analysis I think it's the best solution, as pointed-out by @MarkF.
Going without the RC filter is too expansive to be handled by the fw in my opinion.
The solution with internal pull-up might work tuning a bit the RC filter because the uC's internal pull-up is not tunable of course. And uC's Vil_max must be respected.
e.g. stm32gxxx has 40k typical pull-up and Vil_max near 1V.
scope_17/18: both channels, single knob step
scope_20/21: both channels, fast knob turning
These images show good logic levels - provided the read is made soon after an edge (e.g. a falling edge) is seen. For instance in scope_21.jpg , it would be necessary to read green within 1ms of yellow falling, preferably within 0.5ms.
I am impressed that the eges are so clean ('strictly falling' or 'strictly rising', not "up & down"), so the RC does seem to be "just right". I seem to recall that I had less well-behaved edges, even with RC filtering.
Also, I notice that the high level is more steady than the low level - perhaps suggesting the read should be best done following a rising edge.
How many 'detents' are on this encoder (and what make is it out of interest?).
On the Bourns PEC11 encoders I've been using, both pins go high when it's not being turned (i.e. the encoder contacts are open).
Mine were 24 detents but I don't think that effects the gray code or the way you would process it.
The biggest impact is the rotation speed. Obviously, the faster the rotation the less time you have to detect transitions in the gray code.
I don't know how fast the encoder was being turned for the screen captures. The faster you sample the pins, the faster you will be able to turn the encoder a get good results. The happy medium for me given a 48MHz pic18f2620 MCU is about 500Hz (2ms, which is quit a bit slower than the 0.5ms you pointed out).
Again, I don't recommend doing interrupts based on Interrupt-on-Change.
If you look earlier, you see that a periodic interrupt service should be able to get in and out in only 6 or 7 lines of code.
How many 'detents' are on this encoder (and what make is it out of interest?).
20 steps; brand/make unknown because there is no marking on the encoder.
I am impressed that the eges are so clean ('strictly falling' or 'strictly rising', not "up & down").
The trace of scope_12.jpg is not so clean (because the encoder was probably spinning at a higher speed).