Bourns encoder filter: Is the extra R useful in practice, are the values 'good'?

[741]

As I currently understand the "EC11" style encoders

• On a stable detent, the encoder contacts are well-and-truly un-connected; there is no way 'noise' can occur here
• Between detents is where the action is, there is scraping and the wipers briefly jump away from the track many times in rapid succession, wheras ideally the wiper would be in contact contiguously

If I am correct here, I can see why the Bourns filter circuit (at left) has asymmetrical impedances: we need to discharge C rapidly and ignore brief upward spikes.

But then I think - why have the extra resistor at all? Why not just one R, one C? It is as though Bourns are saying "there will in fact be noise inside the detent area - but it will not be so bad" (?)

Regarding values: Empirically, with an 18-detent unit, the RHS values seem to deliver bettter results.

I have also created an LTSpice simulation.


Very roughly, I think a user can "twizz" 1/2 turn in 1/4 second for rapid movement, and slow movement is say 2s for 1/2 turn.

[MarkF]

You need to look at the suggested circuit differently.
The circuit consists of a pull-up resister and a low pass filter.
The filter suppresses most of the switching noise (debounce).
Both resistors are required.

I have used PEC11R encoders and the values in the datasheet
are a good compromise between noise and rotation speed.

[fourfathom]

You need to look at the suggested circuit differently.
The circuit consists of a pull-up resister and a low pass filter.
The filter suppresses most of the switching noise.
Both resistors are required.

But if we eliminate the series resistor, then at the first instant of switch contact the capacitor will be discharged.  Any subsequent contact open-circuit bounce will be filtered by the 10K pull-up resistor and the capacitor.  The bounce noise filtering will still work.  If you suggest that the capacitor discharge will not be complete, note that neither will it be complete when the series resistor is in place.

Reasons for the series resistor? 

• Perhaps they are worried about the "large" current spike on contact closure?  I would think that with a 10nF capacitor this would not be an issue.
• Possibly they want the 20K combined charging resistance for a slower filter response, and they thought that a single 20K resistor wouldn't be an adequate pull-up?
• Perhaps they want a series resistor to protect the circuit from noise picked up on the wires running to the switch.  This RC circuit would be a good EMI filter.

Only the last reason seems likely.

[floobydust]

You have to debounce an encoder's switch contacts.
The RC filters you show can have a fast rise or fast fall time, or both slow. Also two different time constants 0.1msec or 1msec.

Debounce can be done in hardware- with a heavy RC filter but the problem there is too much lag will ruin the quadrature edge timing and you mess up which direction the shaft is being turned, when spun fast. People fudge the RC filter in desperation to get it to work.

Debounce can be done in firmware- but not if you use input-edge interrupts because a bounce event say a burst of many pulses at usec's can overwhelm the MCU. So you usually see a light RC filter to prevent high frequency usec transitions from making spurious interrupts. The contact bounce can be still longer in the 10's of msec depending on the switch's construction.

I'm saying the RC filter has limitations for debouncing, and depends on which edge you are triggering off of. A long time constant does not work when the knob is turned fast.

The housing (pins) for EC11 need a path to earth ground, expect ESD hits to the knob/shaft.

[rstofer]

If you remove the series resistor, the current spike could be quite high.  i = C dv/dt where the real problem is dv/dt (the change in voltage per unit of time).  For a decent switch, dv/dt could approach infinity, not because dv is high but because dt approaches 0 and division by 'almost' 0 gives a very high result, regardless of dv.  It won't really approach infinity, of course, but it IS a short circuit so it will be pretty high and only limited by circuit resistances.

There's a problem with switches and it has to do with the lack of wiping action (probably not a problem for an encoder) and oxidation.  To burn through the oxide during closing takes voltage and to maintain a sealed contact takes current.  If you increase those pull-up resistors very much (say, 1M), you might find things a little fiddly.  It could happen at 100k as well.  The encoder is nice because the contacts probably wipe.  This is not true for most toggle switches.  They actually make 'high fidelity' toggle switches with bifurcated gold plated contacts.  They don't give them away!

If those are the circuits that Bourns provided, I would tend to use them as is.  They have more experience with their encoders than I do.

[T3sl4co1l]

Note that an analog debounce circuit should still be combined with digital debounce logic.  The principle is signal filtering, and it works just as well on one-bit signals like these, as on 24-bit digital audio.

The goal is to place the analog and digital filters' cutoff frequency Fc so that, their combined attenuation is less than 1 LSB (or whatever your noise threshold is), at Fs - Fc.  For Fc < Fs/2.  That is, so anything aliased above the Nyquist frequency Fs/2 is attenuated significantly.

For a 1-bit input, the attenuation is trivially 1 LSB to begin with, so we want some arbitrary amount less, maybe 0.1 LSB.  Or we might simply plan on using a low enough cutoff frequency (which for an encoder, can be some kHz, not a big deal).

Note that a fixed sample rate means you can't use interrupt driven encoder input; or, you can but you need to calculate the sample index every time, which is probably a pain.  (The running sample index doesn't much matter, only how it changes relative to the most recent edges; I guess you could make a sort of event-driven callback FIR filter response, so it's watching to see if the triggering edge is actually a runt pulse or noise, and only sets the internal variable once it's been stable for some time.  That would be cool, but ridiculously over-complicated for the purpose, hah.)

Also if you're using interrupt driven input, that's a good reason to prioritize even better analog filtering, maybe follow it up with a 74HC7014 or something to get nice crisp edges (so you aren't depending on the MCU's input pins to turn slow-varying analog levels into logic states).

In addition to a A/D filter pair, you may want a nonlinear function, like hysteresis.  Putting that in analog form is nice.  You can also do it digitally: consider a window of the previous N samples of the pin state (this will use a shift register).  Set the internal variable to '1' if all samples equal '1'; set to '0' if all samples equal '0'.

This works very well for generally any switch input.  It's a bit over-the-top for an encoder, but is still a good idea if you intend to use every single step of the encoder's movement.

Now, if you've got an MCU with quadrature decoding hardware, you'll again want to prioritize analog filtering or hysteresis, but on the upside, you can choose an encoder with twice as many steps as you were initially considering, and halve it in software (plus hysteresis) -- that way, a one-bit flip won't disturb the state of your program, and both contacts bouncing is unlikely (at least, until a bit later into the encoder's lifetime).

Deep analysis, yes; pedantic, over the top, perhaps; but the high level subjects distill nicely down to simple functions, bringing justification for what may otherwise seem arbitrary.  And it still took less time to write this discussion than to actually write the code, so it's not wasted time, or at least not as over-the-top as it may seem.

Tim

[thm_w]

If you remove the series resistor, the current spike could be quite high.  i = C dv/dt where the real problem is dv/dt (the change in voltage per unit of time).  For a decent switch, dv/dt could approach infinity, not because dv is high but because dt approaches 0 and division by 'almost' 0 gives a very high result, regardless of dv.  It won't really approach infinity, of course, but it IS a short circuit so it will be pretty high and only limited by circuit resistances.

There's a problem with switches and it has to do with the lack of wiping action (probably not a problem for an encoder) and oxidation.  To burn through the oxide during closing takes voltage and to maintain a sealed contact takes current.  If you increase those pull-up resistors very much (say, 1M), you might find things a little fiddly.  It could happen at 100k as well.  The encoder is nice because the contacts probably wipe.  This is not true for most toggle switches.  They actually make 'high fidelity' toggle switches with bifurcated gold plated contacts.  They don't give them away!

If those are the circuits that Bourns provided, I would tend to use them as is.  They have more experience with their encoders than I do.

Annoyingly they've left out minimum current from the datasheet: https://www.bourns.com/docs/product-datasheets/pec11l.pdf?sfvrsn=7b1089f1_5
One ALPS encoder I found said 1mA but that seems a bit high. Then 0.5mA for the tactile portion. Maximum current is 10mA.

A decent mechanical switch is 10uA. I would expect these to be not quite as good as that though.

[MarkF]

In my case, I was using a PIC18F2550 with a fixed 500 Hz interrupt to poll the encoder inputs
and I selected pins that had schmitt trigger inputs.  On the software side, I used the algorithm
described in the attached Application Note (It does NOT use a lookup table).  The interrupt
routine determined the direction of rotation and then either incremented or decremented a global
count variable.  Then in the main() function, the count variable was used and cleared.  Thus,
the running count could be applied at a slower rate than the encoder sampling rate.

On a side note, you could use the amplitude of the running count as a pseudo acceleration if
your main execution loop occurs at a relatively regular rate. 
For example, to set some amplitude:

int count=0;       // Running encoder count from interrupt
int amplitude=0;   // Variable to be changed

main() {
   int x;          // Temp storage for encoder count

   while (1) {
      x = count;   // Get encoder count
      count = 0;   // Clear count right away to avoid missing an encoder change
      if (x>0) {
         amplitude += 10^abs(x-1)
      } else if (x<0) {
         amplitude -= 10^abs(x-1)
      }
      // Do Other Stuff...
   }
}

I choose the 500 Hz interrupt rate because of other functions it also needed to do. 
You can experiment with the rate to see how slow is acceptable.

The code (I rewrote it in C):

Code: [Select]

; PROGRAM: Read Rotary Encoder (RD_ENCDR.SRC)
; This program accepts input from a rotary encoder through bits RA.0 and RA.1,
; determines the direction of rotation, and increments or decrements a counter
; appropriately. It displays the hexadecimal contents of the four-bit counter on a
; seven-segment LED display connected to port RB.

; Remember to change device info when programming a different PIC.
               device   pic16c54, rc_osc, wdt_off, protect_off
               reset    start
encoder        =        ra
display        =        rb

; Variable storage above special-purpose registers.
               org      8
temp           ds       1
counter        ds       1
old            ds       1
new            ds       1

; Set starting point in program ROM to zero.
               org      0
start          mov      !rb, #0           ; Set rb to output.
               mov      !ra, #255         ; Set ra to input.
               clr      counter
               mov      old, encoder
               and      old, #00000011b

:loop          call     chk_encoder
               mov      w, counter
               call     sevenseg
               mov      display, w
               goto     :loop

chk_encoder    mov      new, encoder      ; Get latest state of input bits.
               and      new, #00000011b   ; Strip off all but the encoder bits.
               mov      temp, new
               xor      temp, old         ; Is new = old?
               jz       :return           ; If so, return without changing counter.
               clc                        ; Clear carry in preparation for rotate-left instruction.
               rl       old               ; Move old to the left to align old.0 with new.1.
               xor      old, new
               jb       old.1, :up        ; If the XOR resut is 1, increment counter, otherwise decrement.
:down          dec      counter
               skip
:up            inc      counter
               and      counter, #00001111b
               mov      old, new
:return        ret

sevenseg       jmp      pc+w              ; display lookup table
               retw     126, 48, 109, 121, 51, 91, 95, 112
               retw     127, 115, 119, 31, 78, 61, 79, 71


[741]

Can pure firmware ever work well? - DSP texts show that sampled systems always requires analog anti-aliasing pre-filters.

Are there real-world reasons why pure firmware (no analog filter) can actually be made to work 'pretty well' in practice? I am discounting parasitic filters here, and assuming ordinary uP clock speeds, say a PIC at 16MHz, nothing ultra-fast.

PS: Really nice hi-res scope shot of contact noise here https://www.sheffieldhackspace.org.uk/wp-content/uploads/2016/04/10k0n.png.

[MarkF]

At a minimum I would use their suggested circuit.

I was able to get a PEC11R to work somewhat with a PIC, on schmitt trigger inputs and the internal 10K pull-ups.
However, there were many sign reversals and missed rotations.  In addition, you had to move the knob slowly.
Say 1/2 second per detent.  There is quite a lot of switch bounce even with a brand new one.

You still have 10% of the switch bounce even with the filtering.  And it gets worse the faster you turn it.

You can try checking the inputs several times (or at least wait to see the same value twice in a row) to try
software debouncing.  But you need to poll pretty fast and you tend to miss valid changes. 
I was never able to get it good enough to suit my tastes.  Forget it if you want to see fast rotations.

If you are able to get a pure software solution to work, please post it for us to see.

[Dubbie]

I have used this exact encoder plugged into an STM32 timer configured as a quadrature decoder. I used datasheet values and have never had any trouble at all with my encoder behavior.
I seem to recall I looked at it on the scope and decided that the suggested component values were well-chosen given the resulting waveforms.

[T3sl4co1l]

Can pure firmware ever work well? - DSP texts show that sampled systems always requires analog anti-aliasing pre-filters.

Are there real-world reasons why pure firmware (no analog filter) can actually be made to work 'pretty well' in practice? I am discounting parasitic filters here, and assuming ordinary uP clock speeds, say a PIC at 16MHz, nothing ultra-fast.

That's basically what the analysis comes down to, in terms of number of bits of filtering by Fs/2 or thereabouts.  Since this is a 1-bit channel, there isn't really any meaning to a >1 bit level, or to a <1 bit level.  It's really just timing, and you can indeed do a good job (like a sliding-window hysteresis, or if you like, "majority voting", function).

The one thing that's unique to analog in this situation, is that the impedance of the switch varies between ~0 and ~infty.  We can harness this with a filter to give a fast fall and slow rise, affecting some debounce action right away without impacting, well, the falling edge anyway.

Even on a PIC, you're only looking at some dozens of cycles to process a few bytes worth of inputs.  Unless you're so hard pressed for time that you literally don't have this much to spare (in which case, you really need to consider a more powerful chip!), yeah, it's no problem to fit that in once every millisecond or so.

Tim

[741]

I used datasheet values and have never had any trouble at all with my encoder behavior.

Based on my own experience, and also on a fair number of web searches, I have the impression that this level of satisfaction is unusual - maybe it is something about the input hysteresis on the STM32 and also it might relate to # detents?

Admittedly also, if something works as expected, it is unlikely to get posted up on a forum.

[Yansi]

I am quite surprised no one mentioned it already, but the other resistors are there also to protect the encoder contacts from discharging the super-low impedance ceramic capacitors that would otherwise be connected directly across the contacts.

...as that can shorten the lifespan of the encoder contacts, significantly.

[thm_w]

I am quite surprised no one mentioned it already, but the other resistors are there also to protect the encoder contacts from discharging the super-low impedance ceramic capacitors that would otherwise be connected directly across the contacts.

...as that can shorten the lifespan of the encoder contacts, significantly.

Was mentioned twice.
But if you are confirming it will actually shorten the contact life then that is useful information. As they don't spell this out in the datasheet, although it can be implied (10mA max current so if you put 10A+ through it even for a short time its probably not good).

Can pure firmware ever work well? - DSP texts show that sampled systems always requires analog anti-aliasing pre-filters.

Are there real-world reasons why pure firmware (no analog filter) can actually be made to work 'pretty well' in practice? I am discounting parasitic filters here, and assuming ordinary uP clock speeds, say a PIC at 16MHz, nothing ultra-fast.

PS: Really nice hi-res scope shot of contact noise here https://www.sheffieldhackspace.org.uk/wp-content/uploads/2016/04/10k0n.png.

With high quality switches, yes. With something like shown in your image, not really, its always a bit of a hack so you compromise on something.

[ratatax]

Quite old thread but yeah, I also use bourns EC11 and the ONLY way I managed to make them work properly is by using both software and hardware deboucing.

- Only hardware debounce : still not reliable at all
- Only software debounce : works more or less depending on the encoder (they don't behave exactly all the same...)

I currently have no resistor between the capacitor and the encoder contacts, so I may add one since as you said it may prematurely ruin the contacts

[MarkF]

I just started a new project with a Bourns PEC11 encoder.
I used the suggested circuit in the datasheet but found that a 20nF cap instead of the 10nF works better.
No debounce in code (snippet follows):

Code: [Select]

/* * * * * * * * * * * * * * * * * * * *
 * PIC18F2620
 *
 * PEC11 Encoder pins:
 *      C0 = Encoder_SW
 *      C1 = Encoder_A
 *      C2 = Encoder_B
 *
 * * * * * * * * * * * * * * * * * * * */
#include "config.h"
#include <xc.h>

// Global variables
int8_t en0;
int8_t count;
uint8_t sw0;
uint8_t lastA0;
uint8_t lastSW0;

//============================================================
void main(void)
{
   // Setup oscillator (order is important)
   OSCCON=0x70;            // Select primary oscillator @ 8MHz
   OSCTUNE=0x40;           // Select 4 x PLL for INTOSC
   
   // Setup rotary encoder
   en0=0;
   lastA0=PORTCbits.RC1;
   sw0=0;
   lastSW0=1;

   // Setup CCP2 configuration for clock interrupt
   CCPR2H=0x07;                  // 500 Hz interrupt (32 MHz system clock)
   CCPR2L=0xd0;
   CCP2CON=0x0b;                 // Compare mode, trigger special event
   // Setup Timer3 configuration
   TMR3H=0;
   TMR3L=0;
   T3CON=0xb9;                   // RD16 | TMR1->CCP1 && TMR3->CCP2 | 1:8 Prescale | TMR3ON bits
   // Enable CCP2 interrupt
   PIR2bits.CCP2IF=0;            // CCP2 Interrupt Flag bit
   PIE2bits.CCP2IE=1;            // CCP2 Interrupt Enable bit
   INTCON=0xc0;                  // GIE and PEIE interrupts

   // Main loop
   while (1) {

      // Process encoder switch
      if (sw0!=0) {
         sw0=0;
         // TODO:  Your code
      }

      // Process encoder knob
      if (en0!=0) {
         count=en0;
         en0=0;
         // TODO:  Your code
      }

      // TODO:  Your code

      __delay_ms(100);
   }
}

//============================================================
void __interrupt() isr(void)
{
   uint8_t pin;
   uint8_t currA0;

   if (PIE2bits.CCP2IE && PIR2bits.CCP2IF) {

      PIR2bits.CCP2IF = 0;    // Clear CCP2 Interrupt Flag

      // Read rotary encoder
      pin = (PORTC >> 1) & 0x03;
      currA0 = pin & 0x01;
      if (lastA0==0 && currA0==1) {    // rising edge?
         pin = (pin >> 1) & 0x01;
         if (pin!=currA0) en0--; else en0++;   // clockwise?
      }
      lastA0=currA0;

      // Switch 0 (encoder)
      pin = PORTCbits.RC0;
      if (lastSW0==0 && pin==1) sw0=1;    // If button release, set sw0
      lastSW0 = pin;
   }
}



[maginnovision]

Pretty interesting. I use the PEC12 encoders with no hardware filtering, just pullups. Spinning like a top you get 0 movement, slow-normal-fast speeds are 0 problem though, very reliable. Maybe next revision I'll add some optional filtering and compare it to software performance.

[dom0]

Debouncing doesn't really matter for incremental encoders, since only one phase is bouncing at a time, and no matter where you sample that track, if you decode the phases correctly you will always get the correct result after the bouncing is done. If you are using every sampling result this may mean that during bouncing your value will bounce as well, but that will be +-1 [unit], when you are in/decrementing +-1 [unit], so it probably doesn't matter. Otherwise you can debounce after decoding the encoder, e.g. by waiting and comparing.

I've used these routines (German) for a long time and they always worked: https://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C

[ratatax]

Things get complicated when you turn the encoder very quickly (there is almost no "boucing free" time window), and also I use encoders with detents which probably makes a lot more noise than smooth ones...

But it's possible to make them reliable even at high speed, one soft/hard debounce I tried worked up to the physical limits of my fingers  (like 200 steps/s). It's great to combine this with software acceleration, so the user can quickly reach the value he wants. (too much devices lacks this unfortunately)

[bson]

Can pure firmware ever work well? - DSP texts show that sampled systems always requires analog anti-aliasing pre-filters.

You do, in general need filters.  However, it's not the debounce that's a problem, if it were you could replace the 100µs TC RC with a 150µs rearming delay on the edge trigger and be done.  Because that's exactly what the RC does, except with a phase delay while a firmware trigger rearm delay provides an instant response on the first of a series of bouncy pulses as the contact closes, then just ignores ay spurious input for a little bit.  The problem is any glitching if the switch is moved while in a closed position prior to changing state to open (if it actually does); those need to be filtered out.  Not unlike the wiper of a pot; it's probably going to rub a little bit before the glitch train indicating opening occurs.

[SiliconWizard]

The filtering network above is recommended in pretty much most of the mechanical rotary encoders datasheets I've ever run into.

It has benefits beyond mere "debouncing". As as been said above, it also spares the contacts. And it also protects against potential spurious edges coming from EMI.

I have personally always included it. Whether you need any additional digital  "filtering" will depend on the encoder itself, and also on the decoding mode you're using. There are essentially 3 modes you can use: x1, x2, and x4.

[wraper]

Can pure firmware ever work well? - DSP texts show that sampled systems always requires analog anti-aliasing pre-filters.

If done properly, it will work better than any analog crap you can come up with. What aliasing filters? It's not like you are feeding it into ADC. The only reason there might be some need for input filtering is strong EMI.

[wraper]

You do, in general need filters.

In general you don't. In most cases analog filtering is done by those who don't know any better. Or is there are "non general" reason to do so.

[mjs]

The series resistor is important - the capacitor discharge current can be quite big and will quickly destroy the contact.

I've seen 5-10A pulses from 100nF cap in similar settings without the series resistor when digging out why there was a lot of field failures in one device.