modyfying RPi.GPIO module - need sub-millisecond debouncing

[evgueni]

Good day all, I hope this is an easy question. I am using RPi2 with a mechanical rotary quadrature encoder (the inexpensive sort that are used as volume controls etc). The decoding is done in Python and I use the threaded callback of RPi.GPIO 0.6.2 for edge detection. After scoping the quadrature signals I can see that the shortest debouncing time that RPi.GPIO allows, which is 1ms, is too long. When the encoder is spun fast, the square waveforms have a period of the order of 1ms. Contact bounce is of the order of 100 us.

Looking at the RPi.GPIO source code, it should be trivial to remove the limitation of 1ms. I would like to try, but I do not know how to go about replacing installed RPi.GPIO with the modified version, or better still, installing the modified module alongside it - perhaps under a new name RPi.GPIO2 which would allow me to keep the original and to be certain that the modified install has worked.

Perhaps this has already been done by someone, or the exact same problem has been solved another way?

[joan]

Can't help with RPi.GPIO but an alternate would be my pigpio module which offers a glitch filter if needed.

http://abyz.co.uk/rpi/pigpio/python.htm ... tch_filter

Python rotary encoder example at http://abyz.co.uk/rpi/pigpio/examples.h ... encoder_py

[elParaguayo]

I'd just add that I use this pigpio code for my rotary encoders (which sound the same as yours) and the code works beautifully.

[evgueni]

Thank you joan, I have already tried your rotary encoder example and it works reliably in preliminary test, with default values for the glitch filter. Either by pure luck the default filtering is suitable, or the contact bounce that I see with the scope is not detected as such by RPi2. I couln't easily see what the default for the 'steady' parameter is, is it 0? I am curious because if the default is no filtering / debounce then the cheap encoder must be better than I think.

[joan]

Thank you joan, I have already tried your rotary encoder example and it works reliably in preliminary test, with default values for the glitch filter. Either by pure luck the default filtering is suitable, or the contact bounce that I see with the scope is not detected as such by RPi2. I couln't easily see what the default for the 'steady' parameter is, is it 0? I am curious because if the default is no filtering / debounce then the cheap encoder must be better than I think.

That Python code will predate the glitch filter so you will be getting raw data. http://abyz.co.uk/rpi/pigpio/piscope.html will give a good indication of the bounce you get from the rotary encoder.

[evgueni]

I'd just add that I use this pigpio code for my rotary encoders (which sound the same as yours) and the code works beautifully.

Thank you, I just happened to try it already earlier!

[evgueni]

That Python code will predate the glitch filter so you will be getting raw data. http://abyz.co.uk/rpi/pigpio/piscope.html will give a good indication of the bounce you get from the rotary encoder.

Thank you joan once again, Piscope is very useful and shows that the cheap encoder produces cruddy quadrature signals with plenty of ringing both close to the edges and also sometimes in arbitrary places. Well, it's good to know what I am dealing with!

[joan]

...
Piscope is very useful and shows that the cheap encoder produces cruddy quadrature signals with plenty of ringing both close to the edges and also sometimes in arbitrary places. Well, it's good to know what I am dealing with!

Be aware that pigpio samples data, by default every 5 µs, so there is an arbitrary filtering of short edges depending on their length. I.e. simplistically, on average a 2.5 µs long transition will only be detected 50% of the time.

[evgueni]

Just as an update, I have now integrated joan's suggestion for rotary encoder into my Kivy app and it works as well as it did standalone. Before that I had tested the code from Sunfounder (https://github.com/sunfounder/Sunfounde ... Encoder.py) and this was almost perfect - suffering only from an occasional artefact whereby it would reverse the count by one when encoder came to rest. Perhaps it is something that could be optimised.. Sunfounder code potentially has an advantage for some in that it relies only on the 'standard' RPi.GPIO library and does not require a daemon to be running. I am glad I got to try joan's pigpio though, it's a treasure trove.