Measuring speed with QEI

[SoBot]

I'm trying to measure speed using the QEI. My encoder has 512 tics per rotation. QEI is setup for 4x mode, that means the encoder has effectively 512x4=2048 tics per rotation. One tic is 360/2048 = 0.1758 deg. The velocity postscaler is set to 1, so every tic will cause a velocity interrupt. Now I read the value of VREG in the velocity capture interrupt and subtract the previous VREG value from it and put it in delta_t. The period of TMR5 is 1/5Mhz = 0.0000002 sec (when running at 20Mhz and timer 5 clock is divided by 4). Then the speed should be: speed = 0.1758/(delta_t*0.0000002). But I get wrong speed values like 5000 deg/sec when turning it by hand. The printf also gives gibberish when it goes too fast.

Can someone please give me some advice on how to do this?
Thanks

Here is my basic code:

[PCM programmer]

Without looking at the QEI aspects at all, and just looking at coding
issues I can see at least one thing.

[Kenny]

There are several other problems without looking at the code too closely.

1. The input to the timer 5 prescaler is Fosc/4 not Fosc.

2. T5 will overflow at low speeds. Define the minimum rotational speed that you need it to work, and set the T5 prescaler and velocity event postscaler so that T5 doesn't overflow.

3. Measuring instantaneous speed every 0.1758 degrees of rotation will keep the processor very busy.
Increase the interval so that the processor can cope at the highest rotational speed expected.
Since T5 will be reset after each capture, the T5 count will be the measurement.
Either set a flag in the IC1 isr and poll for it in main(), or much faster poll the hardware flag bit IC1IF and clear it after getting the captured T5 count.
If conversion to rpm is needed, to speed things up precalculate some values and use scaled integer arithmetic.

From one of my old projects:

[psicko275]

[asmboy]

you say
"turning it by hand"

what is "IT" ??

got a schematic ??

#1-
has this actually been built, or are we discussing a simulation??

#2
WHAT is rotating and how fast as a top speed ??

that has a great bearing on the situation.

care 2 share what this design is ABOUT ??

[psicko275]

[asmboy]

with what you reveal,
that works out to a top speed of 200 HZ coming from a single encoder,
and
you are NOT using the quadrature signal to detect direction, correct? -

we can also assume the minimum speed is zero hz -
and this further implies your code,
if this is for a real product -
needs to be trapped.
SO....
what sort of data UNITS are you trying to capture and return to the host ??

HZ ?? RPM ?? other ??

[Ttelmah]

and of course we have the old one of doing a float calculations in the interrupt.
One multiplication, and a division. Total time at 20MHz, 361.4uSec. Add the other code in the interrupt, and the time to get in/out, and you have a maximum count rate of about 2500ints/second. With 2048 triggers per rev, just about 75RPM.....

Never ever ever (unless you know exactly what you are doing), do anything other than the simplest integer arithmetic inside an ISR.
Read the time, and get out. The ISR should concentrate on being as simple as possible.

Then in the main loop store a copy of the time verify it hasn't changed, and work on this. Do the maths outside, using this value.

Best Wishes

[psicko275]

I try to return RPM, correct in this moment I'm not intersted in the direction, only speed.

the speed 0-100 RPM and I try to convert with this equation:

RPM=( (Operating Frequency/4) / (PPR x Velocity Update Rate x Pulse Reduction Ratio x Timer5 Prescale x VELR<H:L>)) x 60

this equation is: EQUATION 5: CALCULATING SPEED FROM VELOCITY REGISTER VALUE in the note: AN899: Brushless DC Motor Control Using PIC18FXX31 MCUs, page 15.

so

[Ttelmah]

Yes. Then in the main code have code like:

[psicko275]

I done this:

[asmboy]

[psicko275]

[asmboy]

[psicko275]