I am sure that old adage, you get what you pay for applies here. Spend a little more cash for good quality encoders. Those cheap ones found on the net are really sub-par and the bounce is pretty apparent.
Hi there,
I have gotten some very cheap ones, like one doller (USD) each or something like that. They are mechanical, and i find that the only problem is getting the right software to match the encoder. Once i got the software and modified it as per suggestions right here in ETO, it worked every single time with no missing codes. I was actually very surprised that it could work that well.
Mine have 10k pullups on the clock and data lines, but in software both lines are treated the same...no preference for either one. I can post the code if anyone wanted to see it, and the encoder code pattern.
I also found that there are at LEAST two different code patterns for the mechanical encoders, and of course there could be more as i only had two different models to test.
I have also had some thoughts on "debouncing" these things, and i put that in quotes because i have to wonder if we really need this or not. I think we do need some debouncing when the encoder is read in software, but maybe not when it is done in hardward.
If we think about it step by step, it may be easier to understand.
The first thing that happens is the first switch closes, and that generates an interrupt. Now if we are using two interrupts (one for each pin) then we know already which pin started the sequence. It doesnt matter if that one bounces, because we have all the informaton we need from that one pin so far.
Next, we have to read the other contact or wait for another interrupt. Say we read it. If it reads low, then we know the sequence: the sequence was SW1 then SW2. There's no need to wait for anything else because we know what the sequence is.
There is a catch however, and that is if the bounce of the first switch was too long and we turned the shaft too fast, we might be already waiting for another interrupt, and that bounce may look like another interrupt. This means we'd need some time to wait, and i would call that the debounce time.
This is similar to debouncing a single push button switch: we wait for a change, and any change means it was pressed, then wait for some reasonable time after the state goes back to 'open' before we look for another change.
I cant say that all encoders will work like this of course because i only have experience with two models so far. They both work almost the same, except the switch pattern is different over one rotation.