Unexpected results from Encoder::GetRate()

[EricVanWyk]

I really hope that I can end this thread with this post, but I'm not holding my breath.

Lets examine the Rate and Position functions separately - assume that selecting one implementation of Position does not necessitate selecting the matching implementation of Rate.

Position
JoeMethod -
. Error is bounded to [-.5, .5]
. Uncertainty is bounded to [-.5, .5]
. Position is repeatable (no hysteresis).
ChrisMethod -
. Error is bounded to [-.5, .5]
. Uncertainty is bounded to [-1.5, 1.5]
. Position is dependent on direction (hysteresis).

View the position as a circle divided into quadrants. A true quadrature decoder tells you which quadrant you are currently in. You then make the optimal assumption that you are right in the middle of that quadrant. Thinking in terms of assuming that you are on the border is non-optimal. Joe will always report the correct quadrant. You will be off by one half of the time, depending on which direction you are traveling.

As far as I'm concerned, that is a clear win towards using an actual quadrature encoder, such as the one currently implemented.

Arguments as to 'free hysteresis' are bunk as far as I'm concerned. I don't want features that belong in my controller sneaking into my sensor. Tell me what is happening, and I'll work with it from there.

Rate
JoeMethod GetRate
. Given an oscillating edge, no rate is reported
JoeMethod GetPosition+hand derivative
. Given an oscillating edge, the correct rate is reported for the time period.
ChrisMethod
. Given an oscillating edge, zero rate is reported.

These all stink in their own way. But, none of them report rate "spikes". I'd rather get the GetPosition delta at fixed time intervals as rate, if I could choose.


I'm not saying that every aspect of the FPGA is perfect, but I will assert that the encoder implementation is what I hoped it would be. If it was implemented per your suggestion, I'd be disappointed.