Variation in motor current with PWM frequency

I see a big variation in motor current with PWM frequency. I am using
• Arduino Uno rev3.
• TB9051ftg-dual_motor-driver-shield. 11V Motor supply.
• Pololu-4847 brushed motor, 25mm “HP model” (100:1 gear]. No load.

Initially I used the default 490 Hz PWM frequency.
Measuring current (as taken from the TB9051ftg output, smoothed with 10 uF cap), I saw:
PWM (%) = 20% / 50 % / 75% /100 %
Curr (mA) = 130 / 370 / 410 / 220

Then I switched to 3.9kHz (490/8) and saw much reduced current:
PWM (%) = 20% / 50 % / 75% /100 %
Curr (mA) = 10 / 80 / 130 / 170

I am surprised at the large reduction in current with a higher PWM frequency, as well as the fact the the max. current was at 75% PWM/speed at 490 Hz, and at 100% speed with 3.9kHz PWM.

Any explanation for this? In particular, I don’t really want to do more complicated frequencies, but could I see a performance change if I did?

Note, in general, the behaviour is well-behaved. stable current sensing, speed sensing (encoder frequency) is as expected, speed proportional to PWM modulation.

A final query- I could not set a PWM modulation below ~ 12%. I.e. a speed 12% of max. The motor just stalled at 10% PWM. This was when reducing speed. From start, I could not start it moving below ~30% PWM.
Is this normal?


The inductance of the motor windings probably accounts for the effect.

It is normal that startup and RPM depend on PWM frequency, and that RPM is not a linear function of PWM value.


All sorts of things, including PWM frequency, can affect a motor’s current draw and performance. One immediate thing that could be leading to weird behavior is the extra 10µF capacitor you added. That is a pretty big cap for noise suppression, so a lot of current could be going toward charging and discharging it. The encoder board included on your gearmotor already includes a noise suppression cap, so you might try testing your motor without any additional caps.

What you are seeing could also be a result of your measurement tools rather than a real affect. The best way for you to get a good understanding of what’s going on would be to look at your motor with a current probe on an oscilloscope. Such probes are expensive, but I’m mentioning it in case you have access to a work or school lab with such equipment. Otherwise, you can get pretty good (and much cheaper) results with our current sensors and a regular oscilloscope:

It is normal for motors to not operate well at low duty cycles since it becomes hard for the motor to overcome its own cogging torque, so low speed operation usually requires closed-loop speed control. (The high-power motor you have uses especially strong magnets for its size, so its cogging torque is especially high.)

- Patrick

Thanks for the very prompt response. I did some tests and , maybe of interest to others:
(a) The 10 uF capacitor is needed to much reduce the noise on the current sense. 1 uF is not as good.
(b) A scope shows the dominant noise is related to the encoder ouput at small speeds- eg at 25% max speed =25 RPM output (no-load current under 50 mA) I get a 200Hz ripple. At max speed, the no-load current =160mA (= nominal value) and the dominant noise (on the current sense signal) is the PWM frequency (~4 kHz).
(c) I used a DMM in series with the 11V power line and it get similar currents to that seen on the current sense, read by the Arduino.
My conclusion is:

  1. The no-load current is much lower than nominal (160mA); at low speeds it drops to 10-20mA.
  2. A 10uF noise supression capacitor is needed on the current sense line.
    [Maybe if I could significantly change my wiring, perhaps improved earths, I could improve the noise. I guess that radiated noise is not the problem at ~ kHz].

Regarding slow speed operation, to go at slow speeds I guess I’ll have to write software to start at maybe at least 30RPM, to overcome the cogging, and then wind down to whatever I can achieve- maybe 10 RPM once its moving.

Can you post your scope captures along with some pictures and a wiring diagram of your setup?

Your proposed approach of hard-coding a kick start then slowing down might be okay, but since it seems like you are using a motor that has a built-in encoder I suspect you would be better off using that to do closed-loop speed control (especially if the load on your motor or your supply voltage might change while your motor is running).

- Patrick