12 pulse per rev rotary encoder - estimated RPM values - observations

Hi all. I've recently been checking out estimated RPM measurements of a basic 12V DC motor, with RPM of approx 4300 RPM when 12V DC is applied. The motor comes with a 12 PPR rotary hall encoder, which looks just like this:

When I plot estimated RPM against time, I notice repeating patterns in the plot.

What attracted my attention is that there appear to be distinct 'lines' where the dots lie (in a "dot-only" plot).

And there is a repetitive pattern in the values (in a "join-the-dots" plot).

Just wondering if anybody that uses the same 'budget' 12 PPR rotary hall encoders sees the same sort of thing?

At the moment, I was thinking of what's behind this pattern...... such as --- the magnets of the 12 pulse encoder aren't spaced evenly --- leading to offsets in estimated RPM?

On the other hand, it's possible that the way that I'm gathering the "time-of-interrupt" might be wrong. What I have been doing is to use a two-element volatile array ..... initially initialised to {0 0}. When a falling edge interrupt occurs, I store the current micros() time into the right-most position of the array.... such as {0 t1}. Then, when the next interrupt occurs, I store the current time "t2" into the array like this {t1 t2}. Then when the next interrupt occurs at time "t3", the array becomes {t2 t3}..... and so on.

This all happens relatively fast, so my main loop basically halts interrupts briefly to pull some values out every 1 millisecond. So the plots shown here have spacings of approximately 1 millisecond between consecutive dots.

If you are calculating the RPM from the time between encoder ticks, such a plot does not surprise me. It would be more accurate and less noisy if you calculated the RPM from the time for one revolution.

I imagine that the hall sensor is reacting to different magnetic field strengths as it goes around the circle, tripping earlier or later from region to region.

Please post a link to the sensor.

jremington:
If you are calculating the RPM from the time between encoder ticks, such a plot does not surprise me. It would be more accurate and less noisy if you calculated the RPM from the time for one revolution.

I imagine that the hall sensor is reacting to different magnetic field strengths as it goes around the circle, tripping earlier or later from region to region.

Please post a link to the sensor.

Thanks Jrem! I will definitely follow your recommendation today ...... I'll see what I get for RPM calculated from 1 revolution.

I was mainly starting with estimating RPM from consecutive pulses as I want to get rough estimates of the motor speeds as it picks up speed. So basically wanting to see the step response behaviour.

I'll go for the 1 revolution way. That will probably sort it! Thanks JRem!

To answer your question about the hall sensor/encoder combo ..... this sensor is a mystery right now, as these same ones come with motors of this variety, but no idea which company makes them.... or data sheet etc. They just tell us they're 12 PPR, and that's about it. Still searching for info on them though!

It looks like you posted the photo of the sensor after I responded to the post. Looking at that photo, I am pretty confident of my explanation.

The magnetic cylinder is polarized in sectors, alternating N-S-N-S-... around the circle, and I think it is nearly impossible to get all the sector field strengths equal. So the apparent sizes, or arc lengths of the sectors vary, from the Hall sensor's point of view.

Thanks for the heads up! I've been looking at motors like that, for example from Banggood (which claims 11 PPR, by the way).

jremington:
It looks like you posted the photo of the sensor after I responded to the post. Looking at that photo, I am pretty confident of my explanation.

Thanks again JRem! I posted the photo of the sensor for a visual only. I had been searching for info about this encoder/sensor combo.

Thanks very much for letting me know you had been looking into these kinds of motors, and for explaining those observations. It makes very good sense. Greatly appreciated!

jremington:
(which claims 11 PPR, by the way).

Nice pick-up Jrem! The 11 ppr would mean 360/11 = 32.72727272727272...etc degree spacing. While 12 ppr translates to 30 degree spacing. They would have a nice time trying to get 32.7272727272.... heheh.

Jrem..... for the steady-state RPM measurements, I got some RPM measurements based on the amount of time taken for each revolution. I get the usual motor deadband (for which below some PWM level there motor doesn't spin), so that's fine.

I can see that the 'measured' speed versus pwm-level curve is relatively straight .... follows a line. Although it clearly doesn't connect up with the origin (0,0) when a straight line is fitted to the measured curve.

This offset isn't related to dead-band, but due to bearing friction forces?

I'm amazed that the curve of RPM versus PWM is that linear. Under load, I imagine you will see something quite different.

What motor driver are you using?

jremington:
I'm amazed that the curve of RPM versus PWM is that linear. Under load, I imagine you will see something quite different.

What motor driver are you using?

Hi Jrem!

I'm using a DRV8838 break-out board, soldered onto a circuit board. All the testing is done with no load, mainly to just tinker with the no-load motor speed.

I think I'll update the diagram in a moment. I should mention that I took the average of 20 readings - each individual reading (before averaging) taken every 1 millisecond. Update : I did another plot with no averaging done, just to see, and got very similar plots. I have more of these same motors, so I'll do some measurements on them as well later. Thanks again Jrem.

Southpark:
.

This offset isn't related to dead-band, but due to bearing friction forces?

Brush friction dominates small brushed DC motors. Its the main reason
why brushless motors are noticably more efficient.

MarkT:
Brush friction dominates small brushed DC motors. Its the main reason
why brushless motors are noticably more efficient.

Thanks for adding this very helpful information MarkT!