Unexpected results from Encoder::GetRate()

[vamfun]

Originally Posted by jhersh

I tend to agree that I should set the rate to 0 on a same edge. I'll look for a way to work that in for next year. As for the same edge flag, that info is not very useful and already available as stated above

.
Well, Ill have to work on you a little more. This flag would make the register a complete representation of the A/B state information which doesn't seem like a bad thing. I don't think a fast read would be practical solution.

The average engine does have trouble at around 0 rate, which is why I suggested integrating the direction and not resetting the pipeline on direction change. When not at zero, it works great. Presumably in a lot of cases if you want zero rate, you can just turn off the motor, so it doesn't seem like a showstopper case.

I worry about a position servo case which drives to a reference and then holds zero rate. You may not be able to turn off a motor if there isn't sufficient braking torque to hold the controlled object.. ie a heavy manipulator arm.

Does anyone have a better idea for filtering noise from this kind of system than a sliding window average that doesn't reset at 0? Remember that we are HIGHLY space constrained so keep in mind that we need small and simple algorithms that are effective.

Can you pipe the DIR flag into the pipeline so there would be 0's and 1's in the pipe line ? If so, couldn't you construct a recursive pipeline sum by summing the 1's in the pipeline and then computing a signed_sum = 2*(sum of 1's) - max_count. Then in GetRate() compute rate = (signed_sum )/period rather than 1/(period/max count). The summation would take a little extra time... not sure what the FPGA could do to optimize this.

The other alternative would be to use a IIR exponential filter. This would weight the latest pulse heavier than prior pulses. I would prefer the FIR pipeline filter over this but it might work fine.