Motor runs extremely loud


I have got a large 10 pole inrunner motor with hall sensors but im really struggling to get it running without it being horrendously loud in closed loop mode.

In open loop it sounds nice and quiet which is pretty much expected as the drivers all seem to be performing well. As soon as I try closed loop FOC in any form I get a 2.6kHz whistling noise which increases proportionally to the current, and there is also a horrible grinding oscillation noise which is proportional to the RPM. There is no mechanical issues with the motor because it works perfectly when driven by a VESC.
Here’s a video of what it sounds like at about quarter speed.

Originally I thought that it could be an issue with the hall sensors, but I’ve since added some strong pull up resistors and the scoped hall sensor signals look fine to me. I’ve also printed the number of interrupts while revolving the motor and everything seems to be in order.

I am using 0.33 milliohm shunt resistors which are crazy small, but thats because I expect around 200 phase amps with this esc. I have since increased this to 1 milliohm to give a better current sense resolution but this didn’t change anything.

I have used this ESC to control a hoverboard motor and a 14 pole outrunner, both of these ran fine and didnt make the same horrendous noise as this big motor, but is still a bit louder than I was expecting from FOC. It sound equally as loud, or slightly louder than a typical trapezoidal controller.

With regards to code, its pretty much the standard example code

  #define POLE_PAIRS 5
  // Interrupt routine initialization
  // channel A and B callbacks
  void doA(){sensor.handleA();}
  void doB(){sensor.handleB();}
  void doC(){sensor.handleC();}
  BLDCDriver6PWM driver = BLDCDriver6PWM(PA8, PB13, PA9, PB14, PA10, PB15);
  LowsideCurrentSense current_sense = LowsideCurrentSense(0.001, 16, PC0, PC1, PC2);
  BLDCMotor motor = BLDCMotor(POLE_PAIRS);

  void setup() {
    sensor.pullup = Pullup::USE_EXTERN;
    // initialize sensor hardware
    // hardware interrupt enable
    sensor.enableInterrupts(doA, doB, doC);
    //Configure and initialise the gate driver
    //Normalised dead time with respect to pwm period
    driver.dead_zone = 0.05f;
    driver.pwm_frequency = 20000;
    driver.voltage_power_supply = 20;
    driver.voltage_limit = driver.voltage_power_supply * 0.95f;
    // driver init
    //Enable the TIM1 Break input function for overcurrent protection
    // current_sense.skip_align = true;
    // link the current sense to the driver
    // initialise the current sense
    // link the motor to the sensor
    // set motion control loop to be used
    motor.torque_controller = TorqueControlType::foc_current;
    motor.controller = MotionControlType::torque;
    //Set the voltage to be applied during sensor alignment
    //This should be as small as possible 
    motor.voltage_sensor_align = 1;
    motor.voltage_limit = 19;
    motor.foc_modulation = FOCModulationType::SpaceVectorPWM;
    motor.LPF_current_q.Tf = 0.05;
    motor.LPF_current_d.Tf = 0.05;
    // init driver
    // link the motor to the driver
    // link driver and the current sense
    // link the motor to current sense
    // initialize motor
    motor.initFOC(); = 0;

  void loop() {      


Any advice, tips and debugging steps would be hugely appreciated as this is driving me insane
(apologies if i reply slowly, i am about to head to bed)

Wow, you designed a real Nazgul there, holly smokes! That screech can wake the dead.

Let me check your code.

Seems you need to tune your PID parameters and remove any loop interruptions. What is that


doing in your code?


PS I would probably experiment a little without current sense and run only in voltage mode with the halls, and tune it like that, then graduate to current sensing. With CS you get way too many variables to consider.

Hey @Valentine

It sounds like a demented tractor doesnt it!!

I have used the IWatchdog library (as part of the stm32 arduino) to ensure that the MCU resets in the event of a lock up. The reload line simply resets the watchdog register i believe so it should be super quick.

I think youre absolutely correct with regards to focusing on voltage mode, i think ive jumped the gun and got too confident after it worked okay on the hoverboard motor

1 Like

You are not using the smoothing sensor?

You need this when using the smoothing sensor with hall sensors

smooth.phase_correction = -_PI_6;

1 Like

Awesome I’ve been eyeing up the smoothing sensor class, and it makes so much sense seen as hall sensors are ridiculously low resolution.

The main reason why i havent tried it yet is because my motor performance was so poor, much worse than trapezoidal commutation which i assumed would be the minimum performance i would get without any smoothing.

I’ll definitely implement it asap and let you know how significant the improvement is

Without smoothing you are running kind of trapezoidal as you only get one position update per sector, so every 12 degrees if you have 10 pole/5 pole pairs ?
Hoverboard motors get an update every 4 degrees.

Hi Candas,

A silly question and it’s related to the same thread. To implement the smoothing sensor for the Hall sensor (sensor needs to be replaced by the smooth)


No, smoothing sensor will run on top of any other sensor class.
You need to set up your hall sensor as usual.

1 Like

Don’t forget this for hall sensors.

1 Like

I added the smoothing sensor and sadly it gave no improvement (maybe a slight reduction in noise but barely noticeable).
I am running in voltage control with no current sensing to rule out my current sense setup, and I still get identical performance. So I think this is starting to point towards something being wrong with the actual hall sensors themselves.

When spinning the shaft with a drill and using the smoothing sensor, I get the following angle plot…

There appears to be repetitive jitters in the angle

This also holds true when not using the smoothing sensor as the angle steps seems to be rather irregular.

Do you think I’m on to something here, or is this fairly standard hall sensor behaviour?

Edit: This may also be relevant: Other hall sensored motors successfully pass the PP check, whereas this motor does not. I also have to manually alter the zero angle in order to get it to spin without getting stuck at a phase or drawing crazy amounts of current

Have you linked the motor to the smoothing sensor instead of the hall sensor?

I think pp check is not relevant with hall sensors.

yep I linked it and it seemed to apply correctly as I could see the smoothing take effect in the first image of the previous reply. I’m at a loss with this motor :confused:

Have you tried tuning the PID parameters?


Yep and sadly it doesnt seem to make much of a difference. What method do you use to tune your PIDs?

I use a hardware board with manual tuners, but that’s probably a little outside your envelope.


Well folks I think I’ve found the issue… the hall sensors in this motor are absolutely cr*p.
After ruling out current sensing, and knowing that my driver setup was fine, I set the motor to open loop velocity and plotted the hall signals.

Look how terrible that is!!! At one point a state change on the blue hall happens at the exact time as the red hall signal…

For reference, here is a plot of a working motor:

I dont suppose anyone else has experienced this behaviour? and has anyone got any solutions?
Sadly I cant use any other form of sensors in this setup, so it may be time to investigate sensorless commutation

You said it works well with VESC ? Was it with he hall sensors or sensorless ?
A shift in the signals could be explained by hall sensor placement.
VESC also creates a hall table with angles measured during the calibration.

But it also looks like the ON states are not of equal width for the same hall sensor, so maybe problems with the magnets ?

If you don’t care about control at low/zero speed, you can try this flux observer sensor (with a PSU). Here is also an example. You will need to measure the motor parameters.

If the magnets are the problem I guess it could also impact the flux observer.

1 Like

I only tried sensorless when using the VESC which likely explains why it performed decently. My next experiment will be to hook up the halls to the VESC and see what issues it causes.

Yeah the patterns look really strange, not only is the phase shifted, but the widths in the on and off states fluctate quite a lot. Im going to contact the supplier and see if i can understand what exactly is the issue here

Awesome thanks for that sensorless code! Ill absolutely give it a go.
When you say try it with a PSU, is that just for safety incase it is unstable? In the end i intend on powering this motor from a VW golf GTE battery module which can certainly pack a punch if things go wrong

Because things can go bad if the motor parameters are wrong.

But I think you are using an overcurrent trigger as break input so it should be ok

Sweet yeah im using the timer break and it seems to do a pretty good job. I accidently shorted the phase leads and it cut off immediately

Ill give that sensorless example a go during the next week and i’ll let you know how I get on