Confused by DRV8302 behaviour

[jbombastor]

I began by attempting to follow this tutorial: DRV8302 example | Arduino-FOC

I have wired it up as commanded there. I am using a 12V power supply.

— first off, I got an error saying that the sketch was too big. This surprised me, and I saw no reference to it on this forum.

I swapped to a Due and found the “getting started” page to follow instead: Getting started | Arduino-FOC

— I can now see the info coming back from the encoder, but cannot pass the standalone_driver test. I am using the file blcd_driver3pwm_standalone from the installed Examples.

I expect to see the voltages 3V, 6V and 5V between the GND in from the power supply and each of the motor phases respectively. I do not see this, instead all phases show the same voltage, about 8.8V.

I have tried setting driver.pwm_frequency = 32000, following the comment about atmega328s being fixed to that value. I have obviously corrected the BLDCDriver3PWM driver = BLDCDriver3PWM(9, 5, 6, 8); line to use the correct PWM pins that match the wiring, BLDCDriver3PWM(9, 10, 11, 8);

I then changed the values of driver.setPwm(3,6,5); and noted the results. I can’t make head nor tail of them:

Results for driver.setPwm(a,b,c):

given params a b c	measured phase voltages a b c
0 0 0	0.67 0.67 0.67
1 0 0	8.82 8.82 8.82
0 1 0	8.80 8.80 8.80
0 0 1	8.80 8.80 8.80
1 1 1	8.84 8.84 8.84
3 0 0	8.7 8.7 8.7
3 3 3	6.8 6.7 6.7
5 0 0	8.8 8.8 8.8
5 5 5	6.8 6.8 6.8
10 0 0	9.96 9.96 9.96
0 10 0	9.52 9.52 9.52
0 0 10	9.55 9.55 9.55
10 10 10	11.34 11.34 11.34

When driver.setPwm() is commented out, the values all take 0.67V.

Can anyone more familiar with the DRV8302 have a guess at what might be happening?

[jbombastor]

So, I disconnected the DRV8302 inputs and just measured the voltage coming out of the PWMs on the Due. That gave me:

At Due pin outputs:

setPwm(a b c)	pins 9 10 11
0 12 0	0 3.25 0
12 12 12	3.25 3.25 3.25
0 1 0	0 0.27 0
0 6 0	0 1.62 0

This all looks fine to me, so I’m assuming we can rule out any problems with the code or the Due.

Next I disconnected the motor phases and just measured the voltage coming out of the DRV8302.

At DRV8302 outputs, motor disconnected:

setPwm(0, a, 0)	measured result
12	12.03
11	11.56
10	11.33
9	11.04
8	10.43
7	9.48
6	9.3
5	9.6
4	9.6
3	9.3
2	8.94
1	8.84
0	0.65

→ other two phases consistently 0.65V

With motor connected, all phases read the same as each other - as they did in my first post.

This implies to me that there’s a problem with the motor, but even disregarding that, there’s something off with the DR8302. The PWM-to-output-voltage mapping is roughly linear, but with a bizarre scale and offset applied.

Does anyone know what could cause this?

Moving on to the motor, all phases are the same and measure 0.4Ohms.

Motor phase resistances

phases	resistance (Ohms)
blk → yel	0.4
yel → red	0.4
red → blk	0.4

This seems low to me, but I don’t know what values I would expect to read instead. The fact that they’re all the same implies to me that 0.4 is a deliberate value, not the result of a short circuit between two of the lines.

The motor is this one: N2830 RC Drone Quadcopter Helicopter Aircraft Alloy Brushless Motor 1000KV 270W | eBay

Does anyone know anything that might help?

[jbombastor]

Bump. Does no one have any ideas at all?

[Owen_Williams]

So you’ve switched from an Uno to a Due? It is very hard to get motor control working well on ATmega328P - not surprised sketch was too big. It is possible to work hard to get things a bit smaller, but you’ve moved on

Your motors are have quite high kv and low resistance, unless you need fast rotation they may not be the best choice. I tend to use 100kv 10ohm motors (gimbal motors) but others have used motors like yours. If you are using the aliexpress board linked in that tutorial it claims 15A but I suspect it would need some cooling to achieve that. Until you get a feel for temperature - I’d work on the basis of trying to keep things under 1 or 2Amps. This means you need to pay attention to setting voltage limits.

The tutorial you are referring to is doing low level things with driver.setPwm(). I suspect most people don’t do that step. Have you tried a more generic tutorial e.g. open loop/voltage control?

When you were applying those setPWM was then any movement or noise from motor at all?

Finally whenever you switch MCU (Uno → Due) you have to give some thought over pin selections. The drivers sometimes make use of special features (e.g. timers) to work well and at the very least those pins need to be PWM capable. Did you purposefully select those pins for Due? (I’m not familiar with Due, so can’t assess whether your choice is good). Searching through this forum someone else used BLDCDriver3PWM driver1 = BLDCDriver3PWM(5, 9, 6, 8); for Due. Might be worth trying those.

[jbombastor]

Hello Owen and thanks for replying.

Yes, I switched to a Due for purposes of testing. I would certainly like to get things working with the atmega328P in the future, but that can wait until I’m more familiar with how everything works.

In answer to your question, no there has never been any movement or noise from the motor.

I don’t believe there’s anything wrong with the Due pins, or that there’s anything wrong with the tutorial I’m using - in fact I’m inclined to believe that the Due is doing its job perfectly, based on measuring the voltage coming out of the pins.

The issue is there’s some weird “bias” to the DRV8302 board. Instead of a steady increase in output from 0 to 12V, it’s starting at 8.8V and increasing to 12V in much smaller increments.

This happens with the phases disconnected, so it’s not the fault of the motor. The motor is obviously too small, as you point out - but does that explain why it ties the phases together the way it’s doing? I understood that the motor phases are electrically isolated and (for this setPwm test) just getting a fixed DC voltage each. By what mechanism can they affect each other?

[robca]

One thing worth considering: a PWM pin is not outputting an analog signal, but a digital signal with a certain duty cycle. If that signal is fed into a load, the load usually has a “smoothing effect” and the voltage measured is closer to a (very noisy) analog signal. But without load, it’s just a series of square waves from 0 to max V. Especially when measuring with a modern digital multimeter, a PWM pin voltage can be misleading.

If you had an old style analog multimeter with a physical needle over a scale, that would act as an integrator and show the voltage as an analog voltage.

You could use an oscilloscope to see the signal out from the DRV8032, or add a load (like 8ohm, 5W resistors) to the outputs to see if you can measure the signals you expect

[Owen_Williams]

Yes - I agree, your pins are good.

I’d be quite cautious with this motor (worried about burning the DRV8302 board). Lets say you were providing 12V and you wanted to keep current to <2A (as you are not sure of how well cooling is on your board) then you might want to set a Voltage limit of 0.8V. (I know this is insanely low, but we are talking about a 0.4ohm motor and ohms law is in play). For newbies, gimbal motors such as these are far more forgiving.

So I’d be setting really low values for setPwm. I’d also be setting motor.voltage_limit=1; // or 2 so that SimpleFOC can clamp the voltage for you.

[jbombastor]

Do you think it’s likely that I’ve destroyed the board and/or the motor, and that’s what’s giving these results?

12V / 0.4R gives 30A, which is a large value, but I understood that the DRV8302 could handle that much. Is there any way I could check the DRV8302 board before buying a totally new one?

@Owen_Williams

For newbies, gimbal motors such as these are far more forgiving.

I thought the N2830 I bought was the same thing as the N2830 listed on that page. Can you confirm that there’s a difference? The given spec on that page is 0.104Ω, which doesn’t match what I measure on mine but is also low enough to cause the same problems - yet the motor is in the “explicitly works with the DRV8302” list.

[Owen_Williams]

I’m suspicious of any high current ratings of boards that have no heat sink - they typically quote the max current in the mosfet datasheet without doing heat management. If you look at highly tested high current boards (vesc/odrive) they have heatsinks.

I wouldn’t give up on your board yet, how about sending some pics of how your cables are connected and the exact code you are using.

I suspect your motor is not too different to the one you were planning to buy. The higher resistance (0.1 → 0.4) is helpful. 1000KV is high though e.g. 1V == 1000RPM. What do you actually want to do with this driver/motor when you get it working?

[jbombastor]

I will send some photos, possibly later today but probably have to be tomorrow. As for what I’m trying to do: It’s really just getting the feel of things at this point, I want to put that little motor through its paces and get the feel for it before I move on to real projects with bigger ones.

[jbombastor]

Okay, photos:

You can see the motor is held in a little laser cut stand, up against an AS5047P encoder; I’ve tested this and it works fine.

Code is just the provided example code. In this case:

// BLDC driver standalone example
#include <SimpleFOC.h>


// BLDC driver instance
BLDCDriver3PWM driver = BLDCDriver3PWM(9, 10, 11, 8);

void setup() {
  
  // pwm frequency to be used [Hz]
  // for atmega328 fixed to 32kHz
  // esp32/stm32/teensy configurable
  driver.pwm_frequency = 50000;
  // power supply voltage [V]
  driver.voltage_power_supply = 12;
  // Max DC voltage allowed - default voltage_power_supply
  driver.voltage_limit = 12;

  // driver init
  driver.init();

  // enable driver
  driver.enable();

  _delay(1000);
}

void loop() {
    // setting pwm
    // phase A: 3V
    // phase B: 6V
    // phase C: 5V
    driver.setPwm(3,6,5);
}

[jbombastor]

Bump. I don’t suppose anyone can see any obvious problems?

[VIPQualityPost]

Is the underlying issue just that you can’t get the standalone driver test to work?
Have you tried just a barebones sketch with init driver, motor and encoder (that you write yourself)?
What errors do you get in the serial console if you do that?

[jbombastor]

Is the underlying issue just that you can’t get the standalone driver test to work?
Have you tried just a barebones sketch with init driver, motor and encoder (that you write yourself)?
What errors do you get in the serial console if you do that?

If you look at the numbers I posted, it implies the microprocessor is doing its job fine, and the problem is in the DRV8302 board. I don’t know what trying a different sketch on the microprocessor would prove in that case.

[VIPQualityPost]

I saw the numbers, but for the same reason that @robca mentioned it may be that this is just an issue with the sampling rate/ bandwidth on your multimeter and not reflect the ‘true’ output of the driver. Unless you confirmed with an oscilloscope and I missed that?

[jbombastor]

No, haven’t had a chance to use an oscilloscope yet. But the readings from the multimeter I have are exactly what I’d expect them to be, and I’m having trouble imagining a scenario where they feed the multimeter the exact right value and yet the DRV8302 gets such a wrong one.

[VIPQualityPost]

I think you are getting hung up on the wrong thing here. Why not just try an open loop simpleFOC script and see if the motor turns? Trying to measure things with the motor disconnected with the wrong tools just seems easy to go wrong. The driver does things, which is why it’s a discrete chip. The bias you are seeing could be because it is unloaded, or for any other number of reasons. It would make more sense to just hook things up and see what happens, or, if you want to follow that guide, you should use an appropriate tool to look at the waveforms (oscilloscope).

[jbombastor]

Okay. When I next get a chance to work on this I’ll try that approach. I will also get a bigger motor and try it with that as well.