This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Part Number: DRV8323
Other Parts Discussed in Thread: CSD88584Q5DC, DRV8320, DRV832X


We are developing a single axis solar tracker controller, where we are replacing an existing Geared PMDC motor and H Bridge drive with a Geared BLDC motor. The motor will be a 24V / 300W BLDC Motor. 

We are not decided on whether or not it should be a motor with hall effect sensors feedback. We are planning on using the DRV8323 + CSD88584Q5DC for this system. Following are the questions we have at this time.

1. The application requires start - speed ramp up - steady speed - speed ramp down - stop cycles up to 20 times a day.  Do we need a motor with hall sensors? or can we do with sensor less control. 

2. With senseless control - do we have to recalibrate / tune the system if we change motor vendors / ratings / size etc?

  • Hello Deepakji,


    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.



  • Cole,

    Thanks for taking the time our for explaining this in such detail. 

    You are right in saying that the control has to be else where - MCU in this case. Just to add some detail on this aspect - we do have a MCU paired with a inclinometer that will ensure the angular accuracy of the tracking, with a closed loop control. 

    The MCU will be driving Direction and PWM information to the DRV8323, and it is my expectation / target that, the DRV8323 + FETs combination with the internal current sensing ensure that the motor spins in the right direction and at a speed governed by the PWM duty cycle (Much like the control of a PMDC motor with a single H Bridge)

    I understand the part about loosing some cycles until the BEMF and Current are big enough and fast enough for the DRV8323 to "understand" and generate subsequent commutation signals as well and that is fine by me as well. Solar trackers are slow devices and a few 10's of rotations of the motor in the wrong direction / random direction wont even get noticed. But the real question is after a few 10's of wrong commutation will the DRV8323 with its internal logic, figure out the right communication sequence by itself? Or will the MCU have to intervene there too. 

    I hope I am making sense here. Please let me know if any of this needs more clarification. 


  • 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.