Unexpected results from Encoder::GetRate()

[jhersh]

Originally Posted by vamfun

1) I see you took my suggestion for the x1,x2 and x4 averaging pulse count. Did you take a look to see if this really helped the rate noise increase with the x2 and x4 configs? I sort of have mixed feelings on this now. It should sure help if all the pulses are within a single reference frame, but would be less effective if averaging pulses which are part of different frames.

Absolutely. At least for the encoder I was using, it made an incredible difference. Both phase noise and high vs. low time noise (slit width). It's essentially mandatory unless you know you have a high precision encoder. Without it, the measurements were very noisy... around 30% variation for my encoder.

As far as your concern about frames, an encoder doesn't have "frames". The pulses are from one slit to the next and are typically pretty uniform (more so than the A-B phase or the slit-spoke ratio). I think this works just great.

Originally Posted by vamfun

I still would like you to add a SetMovingAveragePulseCount(int max_count) procedure to allow user control of this.

I agree. It's always been my intention to have this configurable by the user, I just never got around to adding the function to expose it. Fortunately the rest of the code can handle when the value is changed, so last year the worst a team would have to do is hack in their own little accessor. It's on my list of things to do this year.

Originally Posted by vamfun

2)Did you set the rate = zero at a same edge event rather than no report at all in your subcode? If not is this in your plans?

This would be an FPGA change... I'm looking into it. Setting the rate to 0 would involve setting the count to 0. This is directly related to #3.

Originally Posted by vamfun

3)Did you try to implement the signed pipeline as I suggested so you don't have to reset the pipeline at zero crossings http://www.chiefdelphi.com/forums/sh...5&postcount=85 ?

I have not tried it yet, but I have looked at the code and have a good idea of how it would fit in. Essentially, I would add a sign bit to the count output, and instead of resetting the count to 1 on a direction change, I would just set the direction as the sign bit. This way if you change direction, the counts cancel out and gives you 0 (from #2 above). I believe this is the signed sum behavior you were looking for.

It also means that the direction is available in this TimerOutput register as well as the position output register. We would no longer need to access the position register to dermine the direction as we do today. I still need to decide whether to reduce the range of the timer or the resolution to get the bit I need for the sign bit.

-Joe