The DSO150 Shell kit oscilloscope has a rotary encoder that's used to adjust the postition of the display and the trigger level, and set other things. I've been working with a guy at the manufacturer to get the best software for reading the encoder, and I think he has made as much progress as we're going to get. But for a device costing $21, as you can imagine the encoder isn't exactly the highest quality, so even after he tweaked the software I still experience some glitches. It works ok, but only ok. There's no hardware debouncing in the encoder circuit. It is read by polling at 3 ms intervals. We tried numerous intervals, and 3ms worked best.
I could replace the encoder in the hope of getting a better one, but the only one I have found that looks like it would physically fit is the Bourns PEC11L, and the datasheet for that isn't encouraging - its bouncing spec (10 ms max) isn't nearly as good as the PEC11R (2 ms max) which I have used before, but I don't think it will fit because of the lipo battery now laying under it.
So I thought maybe I could add some hardware debouncing to the circuit. This is all tiny SMD stuff, except the encoder itself, so my options are limited. The encoder has 30 detents per revolution, and 15 pulses per revolution, so at alternating detents the encoder will come to rest with both switches open, or both switches closed.
The problem is - the port lines used for the encoder and several push-button switches are shared as the data bus for the display. The relevant part of the schematic is shown in the picture.
So the port may be in output mode driving the display, or in input mode for reading the switches, and the 1K resistors appear to provide enough isolation for that to work. So for instance, if the encoder has come to rest at a detent where both switches are closed (grounded), the processor is still able to drive the lines high because of the 1K resistors. But this also means that I can't be hanging .1ufd caps on the lines on the processor side of the resistors because that would mess up data transmission to the display. Now some might say they wouldn't have designed it that way, but I think it's a clever way to get maximum use out of available port pins, if only the encoder worked better.
I don't see a good solution for hardware debouncing that I can implement on my copy. I did try hanging caps from the switch pins to ground, but depending on their value they either had little effect, or prevented the encoder from working at all. The position of the 10K pullups is not helpful since the port line is never fully grounded by the switch - it's only 10/11 grounded.
As far as I can tell, the main problem is that in addition to some bounce when a switch makes contact and the line goes low, which any encoder would have, there is also some bouncing during the entire time the switch is supposed to be closed. In other words, it looks like it never actually settles as closed while it is still moving. Of course when open it works ok.
Well, if anyone sees a solution here, please let me know.