Part Number: DRV8302
Hello motor control gurus. I am not one of you.
I made a BLDC control board to control an RC airplane motor- and it works well enough below 4k RPM, but goes unstable at higher RPM and loses sync. The type of control is sensorless trapezoidal high side PWM. This is the one where you use the ADC to sense the floating phase during the PWM "ON" duty, and then linear interpolate between the samples to find the exact time the signal would have crossed the Vin / 2 mark. That time is used to predict the commutation time. Inspiration came heavily from Dave Wilsons blog, TI appnotes, and Microchip appnotes.
I am using a 4 sample binary filter where each bit is either < or > the Vin / 2 and the filter looks for 0011 or 1100. Then linear interpolation to find the exact zero crossing time between sample 2 and 3. If I run the motor open loop at a fixed pwm and commutation cycle combo, I can adjust the power supply voltage until the motor is running ultra smooth and whisper quiet. So the instability is coming from my control algorithm somehow.
Per the theory the zero crossing occurs 30 degrees into a 60 degree commutation step, so if I identified the time of the zero cross TZCD, the proper commutation step time under steady state conditions would be 2 * TZCD. But that doesn't work. What works is to take the difference between the current commutation period and 2 * TZCD and add a fraction of it to the current commutation time:
Tnew = Tcurrent + B * (2 * TZCD - Tcurrent), where B is some fraction, like 1/8 or something. If B is over .5 it doesn't work, and if B is less than .1 it doesn't work. But all the values of B which let the motor run also has it oscillating and the motor loses sync at over 4000rpm.
Has anyone made a sensorless BLDC motor controller and had a similar problem? Is there a better commutation or filter algorithm? I tried keeping track of previous Tcommutation with a running average but that doesn't seem to work unless the running average is less than 4 samples, and even then the oscillation is the same.
Rick DuncanMotor Applications Team
In reply to Rick Duncan:
100% sure its not the interrupts. The problem is with the way I use the zero cross time to predict when to commutate.
Tcurrent is the previous/current Timer T compare value, Tcommutate is the new Timer T compare value, Tcross is the measured zero cross time in counts. B is a scale factor, .25 seems to work.
I'm sure there is a better way to predict the correct commutation time but I have no idea what that is. The app notes are really good about finding the zero cross and explaining the commutation cycle, but they are not so good on the exact algorithm. Most of them just say Tcommutate = 2*Tcross.
This is the motor running. The green and blue are the hall signals. Go figure the hall signals are not aligned with where the motor needs to commutate, guess that explains why it won't run in sensored mode. Guess that's a cheap motor for ya. But every motor should run sensorless :( I would appreciate any hints about how to predict the correct commutation time.
In reply to Nick Wernicke:
In reply to Prashant Abhishek:
Thank you for responding Prashant- I am pretty new to motors. I will work harder on my filtering and linear interpolation. It seems plausible that small inconsistencies could cause big problems at higher speeds.
Let me clarify my ignorance about the difference between sensored and sensorless mode. So here is the same motor running approximately the same speed in sensored and sensorless mode. From the sensorless mode capture, it looks like the sensors are triggering on the BEMF zero (or power supply 50%) crossing. In sensored mode, the current is switching when the sensor switches!
I think that means in sensored mode the coils are switching 30 degrees late, during which time it is slowing down the motor. Sensorless operation is qualitatively quieter and uses a little less current, indicating it is more efficient. Is it common to create a 'phase-shift' for sensored motors to try and get them to switch closer to the right time?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.