Problem measuring the velocity of a BLDC motor

Question

I'm coding a PIC24FJ256GA106 to make a PIPD velocity control for a BLDC motor by using the Hall sensors instead of back-emf. Currently I can control start, stop and direction of rotation of the motor.

When I try to measure the current velocity of the motor I'm facing a problem, because I'm reading the time between position changes of the Hall sensors, which allows me to detect when the motor has moved 60 mechanical grades. Using that, I can calculate the velocity of the motor as if the motor has a constant velocity, but this gives me problems when the motor is accelerating or or slowing down its velocity.

Looking at the internet, I found a couple of papers from ST and Microchip where they describe how specific models of ASIC for BLDC motor control work for calculating the velocity of the motor. The Microchip document explains that they simply calculate the velocity as I explained before, measuring time between position changes and considering the velocity change if it is linear.

The ST document on the following link

https://www.st.com/resource/en/application_note/cd00004396-l6235-three-phase-brushless-dc-motor-driver-stmicroelectronics.pdf

explains that they use a monostable circuit which generates a fixed width pulse being triggered by the rising edge of the Hall sensor pulse. This fixed width pulse forms a square signal whose "on time" is the fixed width of pulse generated by the monostable circuit, and the "off time" is the remaining time until the next rising edge of the Hall sensor occurs. This finally makes a square signal of variable duty cycle and from that it is possible to obtain a DC signal with a voltage proportional to the velocity of the motor. From that, I can calculate the velocity of the motor.

On the second method, I don't plan to add a monostable physical circuit to the system that I have, but I can easily add that behavior to my code. The only problem here is that my motor has a nominal velocity of 4000 r.p.m. and when I do the code for the fixed pulse with an appropriate width for this velocity, I think it will be narrow enough to have a very low DC voltage from the square signal when the velocity of the motor is too low. The outcome will be the same problem as if I was using the method of measuring time and calculating the linear velocity, as explained first.

So, is there a method for calculating the velocity using the Hall sensors accurate enough to have good velocity calculations when the motor is accelerating or decelerating, or not?

Answer 1

All you have to do in your code is note the elapsed time from one positive edge of hall sensor to the next positive edge of the same sensor. This is the PERIOD of the electrical frequency. If you have an input capture timer, then it should be very easy to get this period automatically. If you don't, you can still record the elapsed time by reading from a free-running timer every time you get a positive edge. I know you have to detect the positive edges because otherwise you would not be able to commutate the motor at all.

You do not have to try to emulate the monostable with your code. That will not help you in any way that I can see.

Answer 2

Next time before you start any design, convert all the qualitative words into quantities in a design spec. And an acceptable, reasonable % tolerance.

"narrow enough to have a very low DC voltage" = TBD , considering SNR ratio and resolution of uC 8 bits gives a possible speed range up to 256:1 and range of duty cycles. or 4000 RPM to 32 RPM in each direction.

If you have a max RPM of 4000 RPM you could make full scale 4800 RPM = 80 Hz or 125 ms/cycle for the one-shot. Then with a bit of algebra or a lookup table you can compute the RPM from any pulse off time with a frequency counter.

You can also integrate down from the off-time for each cycle with a counter and scale it.

"Hall sensors accurate enough" that depends on if they drop out at low speed and your lowest speed.

There are plenty of other ways with I2C tach chips and WSS chips (wheel speed sensors) from Infineon.

Answer 3

Since your rotor is moving 60 mechanical degrees between hall events, a two-pole motor is implied. So at 4000 rpm, the time between hall events is 2.5 mSec. However, the ST device you have referenced performs its speed sensing from a single hall device, so its input sample time occurs once per revolution, or every 15 milliseconds.

During the 15 milliseconds (disregarding all of the protection circuitry), the controller provides a PWM signal. The PWM circuit turns "on" until the current sense reaches a reference, then turns "off" for a fixed time. This reference threshold value does not change until the completion of the revolution.

This is where your PID comes in. You will measure the amount of time required to get the one revolution, and your PID algorithm will adjust the current threshold with the PID loop. The PID constants have to be selected based upon the expected frequency of torque changes and the inertia of the load, but, in any case, your loop doesn't make any adjustments until the next sample, 15 milliseconds later (or longer if running more slowly). If you choose your constants properly, the loop will do a fair job of predicting when the next sample will hit, and make only small adjustments. If not, your motor will slow down or stall when loaded and overshoot when unloaded, or may even "hunt." You need only measure the currents and can do everything else in software, but you can't adjust the motor drive more than once per revolution, and it may take more than one revolution for your loop to "catch up" to an abrupt change. If your concern is that your speed may vary during a single revolution of the motor, you could run your PID from each transition of all three halls and get down to one-sixth of a revolution between PID corrections, but I think you will likely find that the motor inertia will make this unnecessary.

Good luck!