DRV8323: Drive architecture for 300W BLDC Single axis solar tracker

Hello Deepakji,

Introduction:

Thanks for reaching out on the Motor Driver E2E forums. This is a good question but one where I can only generally speak through as these fall the category of  control questions and the DRV8323 expects the majority of control to be handled elsewhere, such as a MCU or processor that interfaces with the DRV8323. As such, I hope you have a software or FW team to help consider some of the problems I will mention.

Specifically, solar tracker would fall under the "position" key care about (as opposed to speed or torque application), so the problem is, as you've mentioned, is tracking position. Most users have some sort of specification in accordance with drift and position accuracy. These are usually in context of degrees. As such, the motor designed for these applications usually have gearing ratios where missing or false triggering of 100 cycles might be less than 0.1% of the full 360 degree mechanical context.

Can this application be done with sensorless?

So can sensorless do it? Yes, and current sense and BEMF detection will be the tools you will use to determine the equivalent information gathered from hall sensors. Specifically. zero crossings are usually used (assuming the algorithms aren't integrating BEMF or current over time to get the information about speed). As we know, slow speed (this means speed ramp up from 0 Hz), will be less accurate to sense as both current and BEMF will be harder to sense. And to answer your second question, yes, these parameters change with different motors that are used (K_e and R_m for example).

The DRV8323 has integrated current sense amplifiers, or you can switch to the DRV8320 and consider adding BEMF comparators externally that can compare the difference. Regardless of what you design, there will come a point where the BEMF or current is too low to sense and you'll need to create an open loop that blindly commutates the motor and "hopes" the rotor will follow until the BEMF or current is large enough to sense. This is where most people lose cycles and this is where most people will have to estimate how many zero crossing there would have been during the open loop process and adds that into the tracking.

Other considerations and conclusion:

Then there's faults, what is the rotor didn't move during open loop? What if the rotor gets jammed during rotation and current is still flowing but the rotor is not moving? These faults need to be implemented for sensored as well (what if your hall sense breaks? what if a phase wire becomes disconnected?) but there's usually more that needs to be developed for sensorless.

Again, I'm sorry I can't be more concrete as the DRV8323 doesn't have an fancy integrated features in regards to control besides the fact that it can handle sensored and sensorless. If you have any questions about the DRV832x, I'd be happy to help, otherwise, control is something that needs to be explored more thoroughly from your side.

Best,

-Cole

Hello TIA,

Answering Questions:

I sort of understand, let's see if I'm able to answer your question. To hopefully summarize, all of the burden of commutating is on the MCU and sensors, the DRV832x just changes the gates depending on the inputs to INx.

The DRV8323 is relatively unintelligent when it comes to commutation, even in the context of 1x PWM mode. If we consider the true INx and GHx and GLx path, the device will do what it is told. The gates turn on and off and the DRV8323 has no idea if the rotor moved, current has flown through the power stage (unless its triggering current protection), or if the rotor is spinning in the wrong direction. This means, there's nothing to track from the perspective of the DRV8323, it will try and turn the gates on and off.

Specifically in the case of 1x PWM mode with hall sensors, there is some sort of feedback to the DRV832x as hall sensors don't toggle if the rotor doesn't move to change the state. This is a logically derivation, its not dependent on the logic or sequence within the DRV83x. In the simple case (or sensorless), you can simulate these hall sensors outputs with the MCU GPIO (as shown in the datasheet) and the DRV832x will blindly change the gates. This means, the DRV83x can never get to confused, it just does what the MCU says (or the hall sensors). If there is a problem, that means there's a problem with the FETs and then the DRV832x protection kicks in and intervenes. 

Small comment on Speed control:

As for PWM and duty cycle, again, the DRV832x is not intelligent. The logic and motor theory (not DRV832x device logic) says if we expose a PWM duty cycle to the motor, its the equivalent of exposing a percentage of the max voltage to the motor which should result in a percent of the max speed. So if a motor driver or gate driver can expose a PWM to the motor phases, that's all it needs to do to meet your criteria. In reality, the speed may oscillate with a constant PWM driven to a motor. This occurs because of variable load, or inefficient commutation (i.e. magnetic field generated by coils does not only contribute to motion as efficiently as possible, it may do it inefficiently or the rotor motion and magnetic field will fight against each other).

My argument is if you have actual feedback that can relate to the actual speed of the rotor (hall sensors, BEMF, current, or maybe your incliometer) should be able to adjust the PWM duty cycle to up and down to get a constant speed or constant angular velocity or degrees over time.

Best,

-Cole