Quote:
Originally Posted by jhersh
What's a proper count? If the lines did it, it gets decoded. It seems unreasonable for the decoder to make assumptions about what the sensor meant to encode. The way I've implemented it allows you to read the true position at any point independent of the rate calculation.
|
I suspect the accuracy of both approaches would be comparable, just have max errors occurring at different locations in the resolution cycle. On a change of direction, yours would be off by a count initially but be more accurate just prior to the next edge count. Mine would be more accurate on the initial reversal and off by a count just prior to the next count. Probably needs a simulation to verify.
Quote:
|
I then address the concern you have for the rate measurement independently by ignoring any count that has changed direction for the purposes of calculating rate
|
Here you have disconnected the rate from the position signal temporarily. This is why I like Kevin's or my approach .. since it doesn't require this and yet maintains the same accuracy if what I said above is true.
Quote:
|
Because I'm using an FPGA, I can afford to implement the decoder correctly without regard for shortcuts in interrupt handling
|
. No argument there.... just so we know what you are doing.
Please, please, please put these algorithms in the code documentation at the nearest opportunity. I don't want to spend the rest of my retirement slowly extracting this information on our CD threads
