Unexpected results from Encoder::GetRate()

[jhersh]

Originally Posted by vamfun

The more I think about this the stronger I believe that you are doing the wrong thing by decrementing on the reversal. The encoder knows it is the same edge so it is sure that it has not moved since the last edge. Before the reversal, the encoder knew that it was on a new edge so the increment was valid and warranted. Any other situation there is a 1 count uncertainty.

I don't understand why introducing phase error between forward and reverse is preferable. I have an encoder on a shaft because I want a specific angular range on that shaft to be represented by a number in my software. Why would I want the range that a number represents to be different based on the direction that the shaft was last rotating? I believe the answer is that I would not.

Originally Posted by vamfun

By allowing the oscillation in position, you are penalizing those who derive rate from position with unwarranted errors that you corrected for in your GetRate().

I'm not clear on what algorithm you are using to compute the rate in software. Depending on what you are using, this may or may not be a moot point or have other issues. Please describe what you are using.

Originally Posted by vamfun

As a user , I want the rate to be the time derivative of the position. Here the position is moving and the rate is not. In this case, the rate is correct because it recognizes that the encoder has not changed position and should have a zero rate.

This is not an accurate statement. A rate is a difference in timing between two events. As such the first event can not have a "rate" associated with it because there is no reference as to when that motion began. That is why the first edge in a given direction can not calculate a rate.

-Joe