# Does rdsOn play into backEmf calculations?

Hello! I spent the last hour trying to narrow down a potential problem with backEmf calculations I was making. However, I couldn’t find anywhere specifically discussing my problem.

(General Situation) I set up a system using Pololu’s pololu.com/catalog/product/1212 and the 172:1 gearmotor. I was using the FB pin to help me calculate approximately how fast the motor was running. I calculated it as such.

backEmf = appliedVoltage - (currentFBpin*motorOhms) ,

Actual Rotational speed = MotorKvConstant*backEmf.

Applied voltage was taken to be the input voltage to the board (12V in this case) times the duty cycle. The FB was properly converted from it’s voltage value into a amperage value, of course. For reference, Pololu’s motor was 2.73 Ohms.

This was working very well for a while. However, I needed to switch to a lower resistance motor, and this has caused me a few problems. My new motor is 0.23Ohms, a magnitude less. The MotorKvConstant for this new motor is about twice as big (just for reference.)

[size=150]End of question setup: Now, the point of my question[/size]

I suspect that calculations for the rotational speed need to account for the resistance of the mosfets in the driver. The spec sheet says something like 220mOhm for the driver board. I think that’s for each mosfet in the h-bridge, so it’s an additional 440mOhm to the current path. Previously, I may have gotten reasonable rotational speeds because 440mOhm was small compared to the 2730 mOhm of the motor windings. Now my motor is only 230mOhm, which is even LESS than the resistance of the mosfets. I think I need to account for the approximate resistance of the mosfets, but I am posting because I am not sure if I am correct- maybe the resistance of the mosfets are already counted in the way at which I assume Vapplied = Vin*dutyCycle… Attached I added two drawings, to further articulate what I’m saying.

Hi, Tomek.

The “applied voltage” part of the back EMF calculation is the voltage applied to the motor, so you will need to account for the voltage drop across the two H-bridge MOSFETs if that drop is significant. As you pointed out, normally this voltage drop is negligible compared to everything else and can be ignored, but in your case, the drop across the MOSFETs is comparable to the resistive drop across the motor.

Part of the reason you are having this problem is that the MC33926 driver is not appropriate for a motor like that. At 12 V, your motor has a stall current of 50 A (this is also how much the motor briefly tries to draw if you start it at full speed from rest); meanwhile, the MC33926 can only handle peak currents of 5 A and our carrier can only handle continuous currents around 2.5 A. One of our high-power motor drivers, like the HPMD 18v25 CS is much more reasonable (the MOSFET on resistances are around 3 milliohms on that driver, which means they are again much smaller than the motor resistance).

- Ben

Hi ben! I appreciate your answer and clarification there. We moved back to the Pololu motor, but hope to get the other one running eventually.

I definitively agree with you the pure DC draw of that motor would be way too insane at stall current. One thing I did is added some appropriate inductors in series with the motor, because that allowed a smoother voltage with the 19.6khz I was driving the motor at (in addition to super low resistance, it also had very low inductance.) But the theoretical peak is still way too high; much more than the driver could deliver or the power supply could deliver. So I think I’ll have to do some more work and calculations before I could get this running properly; the method of measurement might be too crude for the situation. I’m not particularly keen to use the bigger driver because it’s bigger, more expensive, and overkill for the motor. Even though this motor would have 50A stall current at 12V, it would not last more than a second or two pulling that, and we don’t have that kind of power available anyway. So i’ll try to improve my model (I’ve now some more familarity and comfort with matlab’s simuLink software) and code so that we don’t see that situation.