Unexpected results from Encoder::GetRate()

[jhersh]

Originally Posted by vamfun

Ok...I just have to remind myself that the m_counter object register really represents two counter results... output.value and output.count. They are related only when the output.dir is the same as previous dir. The GetPeriod() intro really only truly applies to the event timer count not the value count.

The only meaning that "Count" in the tTimerOutput register has is the number of samples that are included in the sum presented in "Period". It is simply for the purpose of computing the average while avoiding doing the division in the FPGA.

Originally Posted by vamfun

If I wanted to implement my own rate algorithm, I don't think I can determine if a same edge event has occurred by looking at your register information. I believe I would need a same edge flag added to your output register.

If you can actually read the registers fast enough to keep up with each edge (which you would need to do to take advantage of a "same edge" flag), then you can just look for the dir to change.

Originally Posted by vamfun

The only change I would make is to set the rate = zero at this event rather than no report at all.

If you modifiy your GetRate() in the future, I would favor adding the zero rate and same edge flag features.

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.

Originally Posted by vamfun

This question probably needs simulation testing but here is my gut reaction: I don't think this is a good thing. It probably won't matter if the default single pulse is maintained. But if a larger averaging window is truly needed to filter the noise, then your implementation has all the drawbacks of a low pass but few of the benefits. If there are no high frequencies in the signal, the pipeline will just cause phase lag. If there are high frequencies, the filter will be reset often giving a shorter effective averaging pipeline (raising filter band width)and lowering the effective noise reduction.

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.

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.

Thanks,
-Joe