DRV8323: Audible noise from motor with zero torque.

Hi Mads,

Thank you for all of the information. I will work through this with you and help to debug. 

It seems like you have tried a lot of ways to fix this noise issue. I appreciate the effort!

What interests me is the following:

Mads Hoeffer said:

I have tried measuring the phase voltages with an oscilloscope. Here I primarily saw all 3 phase voltages rise/fall simultaneously. BUT i sometimes randomly saw one of the phase voltages was delayed by +- 20ns and i am concerned if this could be the reason for the audible noise.

I would like to investigate this further as this is possibly the source of the noise. You mentioned that this happens "sometimes" and seemingly randomly, but would you be able to provide:

1. How often the observed delay occurs? There is absolutely no pattern to how often the delay is observed?

2. A picture of phase voltage waveforms from oscilloscope, one picture with good behavior, and one with the delayed behavior

Hi Jospeh,

Thank you for a quick response. I have tried to perform the requested measurements, that i will go through in the following.

The used DSO is the following: "Siglent SDS1204X-E 200MHz Four channel oscilloscope " if that is important.

In all of the following images the following is true:

Channel 1 (yellow) = Phase C

Channel 2 (magenta) = Phase B

Channel 3 (blue) = Phase A

Below you see 3 cases of the delay on the phase voltages on the rising edge, 2 with trigger = ch1 and the final one with trigger on ch2

3 Images of incorrect falling edges:

An example of a correct rising edge:

An example where I captured the rising and falling edge in the same waveform.

Trigger on 3 different channels with "live" view.

Finally i tried to perform some statistics by performing 190 single triggers and noting which channel was offset from the two others. Trigger was set to CH1 for all of this:

Total measurements = 190

Phase C (CH1) delayed = 16 times = 8.4%

Phase B (CH2) delayed = 3 times = 1.6%

Phase A (CH3) delayed = 6 times = 3.2%

For good measure i have also measured the PWM_H A,B,C signals coming out of my MCU, they are consistently as seen below:

I am still wondering: If this delay is the reason I can hear noise from the motor, shouldn't the noise frequency change with my PWM frequency?

I look forward to hearing from you and further investigating the issue. Let me know what you think and what other measurements could be useful!

Hi Mads,

Thank you for providing the waveforms!

I have some theories about what could be causing the delay, but before diving into that I would like to check some other things that might be a larger influence on the noise than this delay as it is still within reasonable bounds.

1.Are we sure that we can rule out noise coming from the commutation algorithm you are using? These algorithms are usually fine tuned to the specific motor type that you are working with, and small inconsistencies/errors in these commutation algorithms might have some resulting motor noise. 

2. When there is a delay, are you seeing current in the motor? If I understand correctly, this phenomenon would insinuate that there is, for that delay time, a small amount of current flowing through the motor at the time the delay occurs. I am wondering if this is even enough to cause noise? The motor does not actually spin right?

3. You mentioned you tried input PWM frequencies from 10-50kHz. Was there a trend in motor noise? I would expect the noise to be quieter at higher PWM frequencies. Was this the case?

Please let me know, and we can continue debugging!

Thank you,

Joseph

Hi Joseph,

1.

Well, I am not running any commutation algorithm. I command a 50% duty cycle between the v0 and v7 null vectors, in the space-vector-PWM diagram. So 50% of the time all top 3 switches are closed, and the other 50% of the time the 3 bottom switches are closed. Per my understanding (and I may very well be wrong) this corresponds to running FOC with space-vector-modulation using alternate reverse sequencing BUT commanding a Iq and Id current of 0. I.e the alpha and beta voltages are also 0. I have implemented my software according to "Intro to Field Oriented Control" by Dave Wilson.

2.

I unfortunately don't have access to a current clamp sensor or similar equipment.

No the motor does not spin.

I have tried measuring the current out of the DRV8323 current amplifier and i am seeing practically no current. In the attached pictures below CH4 is the output SOC (Phase C current) of the gatedriver. The 3 other channels are the phase voltages. As seen there is no difference between the delayed case and normal case. I have observed the same voltages when measuring the phase A and B currents.

Extra:

I have measured the 3 phase voltages and exported the data (F_PWM = 25kHz). I calculate the difference between all combinations of the 3 phases, i.e : V_a-V_c, V_a-V_b, V_b-V_c, threshold the data to remove noise and perform an FFT on the combined voltage differences. The results can be seen below. As seen on the zoomed view there is a significant spike at ~9.4 kHz. Why this differs from the 8.1kHz and 8.7kHz i measured using my phone i am not sure. I can share the python code and data if needed.

3. I will try to go through a range of PWM frequencies, describe the noise and add the FFT plot.
10kHz: Lower overall volume, but clear 10 kHz frequency.

15 kHz: Lower noise, clear 15kHz frequency

20kHz: Louder than 10/15 kHz but lower frequency noise (8-9 kHz)

25kHz: Similar noise to 20kHz

30kHz: Lower volume same frequency

Notice the FFT is different now but the delay is still present.

35 kHz: Same volume and frequency

40kHz: Similar volume and slightly higher frequency:

45 kHz: Similar to 40kHz

50 kHz: Same noise as previous 2

So what i am seeing/hearing is:
For 10/15 kHz the actual PWM frequency dominates the sound.

Any higher frequencies the volume level and audible noise frequency are similar and approx 8-9kHz.

I do wonder why the FFTs differ so much at higher frequencies though.

The delay is present at all frequencies.

I have also measured the phase voltages without the motor attached, same delay is observed.

Additionally i have measured the outputs of the gatedriver GHx to ensure that the delay is a result of the gatedriver and not the FETs. The GHx signals also show the delay: (Delayed, non-delayed respectively)

I realize this is a lot of information but i really hope it can be helpful in getting closer to solving this issue.

Thanks,

Mads

Follow up: I also tested using the driver in 3x PWM mode unfortunately same result.

Hi Mads,

Thanks again for the update. I appreciate all of the effort and extra information!

I like seeing these FFTs, I have done some work with data converters in the past so I am somewhat familiar with this kind of analysis. I am curious what sampling frequency your python code is using. Probably 100kHz? This are interesting graphs to see.

Here is what I would like to look at next:

Since there is no clock provided as an input to our gate drivers, the devices usually have an internal clock sampling at 25 MHz used to synchronize inputs in order to have uniform and smooth output cycles. I am thinking the delay could be caused by the slight timing variation in inputs causing one of them to miss the clock cycle that captures the other two, leaving one of them delayed by a clock cycle. However, this does seem kind of unlikely for this phenomenon to happen ~8% of the time, but maybe still possible. If this were the case, I would also expect the delay to be 40ns (1/25mhz), not the 20ns you are seeing.

Nonetheless this is what I think we should check next. I am thinking, can we prove that this is not what is happening by feeding all 3 inputs the same exact input signal? For 50% duty, ideally, they all get the same signal correct? If we tie all of the inputs to one signal, and the delay is gone, we can rule out the small timing variation in the 3 inputs as cause for the delay. If the delay still persists when feeding the exact same input signal, then we know it is from somewhere else.

Let me know what you think.

Thanks,

Joseph

Hi Joseph

The FFTs are done on the raw DSO data so sampling rate is from the DSO. I dont recall the excact frequency but >100kHz

Certainly sounds like an interesting thing to verify. When i get back to work tomorrow i will bridge the 3 high side PWM channels and return with the results.

I assume you are on US time, so if the problem persists in next week I will try to move my working hours to better align with yours, hopefully we can efficiently get to the bottom of the issue. 
Also I’m considering spinning up a quick PCB with only the gatedriver and FETs, to possibly rule out any issues on my current PCBs. 
Let me know what you think. 
Thanks,

Mads

Hi Mads,

Yes, I am on CST time zone,  (UTC-06:00).

Your plan sounds good. If it gets to a point where communicating becomes too laborious to type out, we can also work on this over a call (or series of calls). Whichever you prefer. 

Looking forward to your updates,

Thanks,

Joseph

Hi Joseph,

I tested what we discussed unfortunately no difference in behaviour. I bridged the 3 high side PWM channels, configured two of the three pins as floating., configured the gatedriver in 3xPWM mode, left the PWM_L logic high and tested by measuring the GHx signals from the gatedriver.

I realized that my DSO is able to measure the time between rising edges on two channels, so i tried to perform the measurements for 5 minutes while the DSO performs statistics. See the following three images with trigger on CH1,CH2 and CH3 respectively.

CH1 = GHC

CH2 = GHB

CH3 = GHA

Explanation of measurements:

FRFR [2-3] is the time between the rising edge of CH2 and a rising edge on CH3.

Note: The measurement FRFR[1-3] is missing as my DSO can only show 5 measurements at a time

As seen by the count values some combinations e.g FRFR2-3 and FRFR2-1 are much more common compared to the others independent of trigger channel. Could this indicate that it primarily is GHB that is "early" i.e GHA and GHC are delayed?

The PWM frequency is 25kHz, so 5 minutes should equal 7.5 million rising edges. However the measured count values do not correspond to the ~8% I measured earlier. So I am unsure how reliable the statistics are.

Looking forward to hearing from you,

Mads

Hi Mads,

Thank you for checking this. It is possible that this small delay is due to die-to-die variation. Seeing this, I'm much less concerned about this delay causing the noise issue now, because as you say even with the much tighter grouping of signals here, the issue persists. 

For me, this makes me less suspicious of the gate driver being the source but maybe something related to the natural frequencies and harmonics present in the motor itself. 

I have had to do some research regarding this issue, as I am most familiar with the gate driver itself. While looking I came across this paper which may be of use here: https://www.mdpi.com/1996-1073/16/14/5311

Especially sections 3.2.2 and 3.2.3

I am interested to hear what your thoughts are. Are you still suspicious of the gate driver here or do you suspect another part of the system now? Also, are you still considering doing the alternative board spin you mentioned earlier?

I am looking forward to solving the issue,

Joseph

Hi Joseph,

I will be working this evening and was hoping we could jump on a call and discuss how to move forward. Is that a possibility for you?

Hi Joseph,

I just tried soldering a resistor (220 ohm) to each phase wire to see what influence that might have, which has completely removed the noise. Although this is not a solution to the issue it might provide some insights. Looking forward to hearing from you,

Mads

Hi Joseph,

Yes the noise is present even with the lowest IDRIVE setting.

Sounds great, looking forward to investigating,

Mads