Matrix user forums

If you consider the question below should not have been posted here, then please move it here:
viewforum.php?f=65

1) Would be possible to make next improvement to the Rotary Quadrature Encoder component?
The actual software denouncing is based on time delay.
Besides that the user must do a hardware debouncing, to use additional hardware components to clean up the signal, if wants to not miss a count.
There are better ways to do a software denouncing. Let’s call it digital filtering.
It would be very helpful if the user can implement his own custom software debouncing /digital filtering to the Rotary Quadrature Encoder component.
Right now between pins/inputs of the Rotary Quadrature Encoder component and its counter there is no visible connection/exposure to the user.
What I would like to see/have is next: the Rotary Quadrature Encoder component should let you see and set the 2 pins (as it is now) and then to have also 2 variable for a custom macro where the user can write his own custom software debouncing /digital filtering.
The custom software debouncing should be placed between the 2 hardware input pins and the 2 variables as output from custom software debouncing going to be used for counting register.
The user should be able to choose between existing options as no debouncing or delay debouncing or custom debouncing self-written macro.
That will help a lot, because simple delay debouncing many times is not good enough.
The idea is to let the user to come in-between 2 input pins and the counter register.
If no software debouncing is used, then the 2 input pins are connected directly to the 2 variables and the user can only see that, but has no access to modify something.
If delay debouncing is used, then the 2 input pins are connected to the delay macro and the 2 variables are output from delay macro going to counter register and the user can only modify the delay time as it is now implemented.
If custom debouncing is used, then the 2 input pins are connected to the custom debouncing macro and the 2 variables are output from the custom debouncing macro going to counter register and the user must implement his own code.
The counter register should count based on those 2 variables/bits instead of the hardware pins as it is now.
Depending by PIC and CPU frequency used, that additional macro debouncing macro may introduce delay with improper result, because usual we need to read the encoder and count as fast as possible, but that should be up to the users, their choice. It is enough a short notice/warning about that.
The improvement will help because are many situations when the user/application requires very low number of hardware components, no hardware debouncing. Even is not really recommended, there are enough such situations when each additional component/penny counts and then only software debouncing, better than simple delay, is possible and in fact enough.
The improvement should not be so hard, it is only necessary to add the 2 variables/bits and point to a custom delay macro.

2) If you have no time to do it, then would be possible to post the source code of the Rotary Quadrature Encoder? Then we will try to do it.

Thanks!
We'll consider the options when Ben gets back in the office.

Any idea when Ben comes back in the office?

To cut it short:
-It would be enough if at Connections A and B beside the hardware port pins to have also the possibility of 2 bits/variables.

Let’s say we have bit variables FIN1 and FIN2 (Filtered Input 1 and Filtered Input 2 or FINa and FINb with a and b instead of 1 and 2).
To add these 2 bit variables it should not be so hard when you have the source code of the component.
Then I can make a custom digital filtering/debouncing macro where I assign the hardware port pins A and B as input variables for the macro and FIN1 and FIN2 as output variables for macro, which are used for counter register as are used now hardware connection A and B. That would be enough and would do the job that I need.

Hello,

Back in the office today.

Sounds interesting, though hardware debouncing will always be a better option if available.

Here is the component source, adapted to generate a new component so you can have a go at changing the code without effecting the existing component.
With components like switch inputs we allow time based debounce which works like this.
It's not purely a delay, it's a delay broken up into many stages where we must have a stable input throughout the entire delay time before returning a value.

With encoders it's hard to tell the difference between a bounce and a valid edge transition, missing an edge transition will lead to counting errors so it's best to filter out the debounce in hardware if possible.

Let us know how you get on.

Thank you very much for the source code.
I will try to look into it hopefully in about 2 weeks from now on.

Only now I have time again to look at the microcontroller projects, and unfortunately not for long time.
I will try to test different software debouncing methods.
Looking on internet over the last years I found next debouncing methods to be the best.
I will try some of them, one by one when I have time. I will just put them here for future reference.
http://www.ganssle.com/debouncing-pt2.htm
http://www.eng.utah.edu/~cs5780/debouncing.pdf

https://www.cc.gatech.edu/~hadi/teachin ... bounce.pdf
http://drmarty.blogspot.de/2009/05/best ... -ever.html
https://www.circuitsathome.com/mcu/read ... n-arduino/

https://hackaday.com/2010/11/09/debounc ... -them-all/
http://playground.arduino.cc/Main/RotaryEncoders

Ben,
I just need one confirmation from your side.
You mentioned above that “With components like switch inputs we allow time based debounce which works like this.” But looking inside the Quadrature Encoder source that you provided above I do not see any debouncing.
I see only “Repeat Rate” as parameter for simulated repeat rate when clicking and rotating the encoder.

Is it true that there is no debouncing implemented in the code for the quadrature encoder? Or do I not see it clear?