B-G431B-ESC1 with FPV 2205 14/7 pole motor and AS5600

Hey folks,

I’ve setup the B-G431B-ESC1 with an old EMAX RS2205 I’ve got lying around that should have plenty of power for my application. I feed it with 15V.

The motor has 14 magnets, and my understanding is this means it is a 7 pole pair variant.

I’ve ran through the setup guide and both the encoder as well as PWM “just work”.

But when I go to the third step and try some angle control, nothing works properly. The motor is jittery and very noisy, jerks around through calibration, and angle control isn’t working.

I’ve got two identical setups and they both exhibit the same behavior.

Any suggestions as to what could be the problem?

Code is here: /** * B-G431B-ESC1 position motion control example with encoder * */#in - Pastebin.com - I added a print into the loop to see if driving the motor would upset the I2C comms an I don’t get good angle data, but that wasn’t the case and the behavior is the same without.

Oh, and as a side note: there’s a STM32 arduino release 3.0.0 that does not work with SimpleFOC so I downgraded to 2.12.0. No idea if you can safeguard against this or fix the code base that it works in both versions.

I’m surprised you said the encoder is working?
IMHO you have to include and init the “wire” (I2C) interface?
Another minor thing is: you use a generic I2C sensor class, but there is a more specific model for the AS5600.

I didn’t need any changes anywhere other than pulling in the class and use it for I2C to work. There’s the 5 pin connector with PB7/8 (if memory serves) that’s available for this.

And the test program showed operation.

I just followed the setup guide that suggested testing the encoder, PWM, and then angle mode. So yes, no tuning. But even the calibration move at the start isn’t working at all. I’ll try and upload a video, had some issues with that yesterday.

Hopefully this works: iCloud Photos - Apple iCloud

This is the calibration move right at the start. No commands given. Motor gets hot.

For one thing your calibration voltage is too high. I use 0.6V on a 2300kv 2204.

Try disconnecting the motor and setting it up to rotate slowly in open loop mode with SinePWM modulation, and probe with multimeter between ground and each of the phase outputs to verify that they ramp up and down. If that’s working, plug the motor in and look at the current sense readings in serial plotter. If one phase doesn’t get any current, then you’ll know where to look for a bad connection.

  static long nextPrintTime = 0;
  if (millis() - nextPrintTime > 0) {
    nextPrintTime = millis() + 20;
    PhaseCurrent_s c = currentSense.getPhaseCurrents();
    char string[256];
    sprintf(string, "%+5i,%+5i,%+5i,\n", (int)(c.a*1000), (int)(c.b*1000), (int)(c.c*1000));
  Serial.print(string);
}

Is calibration voltage the align voltage? I’ve reduced that, and tried setting up a constant rotation. See the current code here: /** * B-G431B-ESC1 position motion control example with encoder * */#in - Pastebin.com

The current sensing puts out values like this:

  -98, -101,  -96,
 -157,  -72,  -66,
 -128, -101,  -66,
  -40,  +44,   -7,
  -69,  -43,  -96,
 -128, -131,  -66,
  -98,  -43,   -7,
  -98,  -13,  -66,
 -186,  -72,  -96,
 -128,  -72,  -96,
  -98,  +15,  -37,
  -98,  -43,  -96,
 -157, -101,  -96,
  -69,  -43,  -66,
  -40,  -72,  -66,
 -128,  -43,  -37,
  -98,  -72,  -66,
  -40,  +15,  -96,
  -69,  -72,  -37,
  -98, -101,  -37,
 -128,  -43,  -37,

And here is a video with the motor movement and the three phases in the background on the oscilloscope. You can see them on the three lower traces.

The motor seems to rotate in the beginning quite ok, but then again squealing. Is this maybe a PID issue given the three phases seem operational?

I checked all the examples regarding I2C sensors and they all had one line in common:
// configure i2C
Wire.setClock(400000);

Yes.

I’m not sure what the problem is, but there sure is one. The values in each row of the printout should sum to 0, and be nice sine waves going positive and negative rather than the mostly-negative chaos here. If my calculations are correct, your 0.3 velocity target should give 16 prints per electrical revolution, so resolution is not the issue.

The oscilloscope is bizarre. At first it looks relatively normal, with PWM duty changing on each phase as the motor turns, though it is odd that the amplitude is changing as well. But then it suddenly changes to those weird shapes. Are you using a current limiting power supply? Maybe that’s what’s causing the amplitude variation, and then it drops below the ESC1’s minimum voltage and starts malfunctioning.

Had a week of work, back on it. Yes, it’s a limiting supply, but it’s at 3A, and while there’s some voltage drop observable, I’m not seeing anything above 1A, so I doubt it is at fault here.

I did set the I2C speed to 400K, but as expected that’s not at fault here - I’m reading the angle all the time so I fail to see how that could’ve influenced the situation.

Any other suggestion as to what I could attempt?

As a follow-up: I have a gimbal motor (2204 260KV) that I’ve used before with an ESP32 and a miniFOC shield or whatsit called. This worked before. I reworked the connections to attach to the STM and the result is quite different.

The motor spins but with jerky back-movements, about 30/revolution, and they look like two short back-ticks. The PWM looks quite reasonable on the scope, basically always one is at zero, the other two are waxing/waning as the laymen would expect. The current is rock-solid, I’m at 10V/0.75A, so the motor is quite toasty.

Hope this produces more insights.

If you’re printing anything to serial, try removing that. It will usually block the CPU on STM32 if you make more than one call to Serial.print per 20 milliseconds or so, which causes jerky motion. You can use sprintf to prepare a more complex string with text and multiple variables, and then print it in a single call. But STM32’s sprintf does not support floating point, so what I do is multiply by 1000 and cast to int, so voltage is in millivolts, etc.

There is no serial output, I’ve thought about that possibility already.

So I thought that maybe some noise on the I2C lines would create some jerkiness. So I hooked up the logic analyzer, and after some data transformation this is how the rotary encoder information decoded from raw I2C looks like:

We see the jerks, but the output correlates directly with what I’m observing - I don’t see any bitflips/random results. So I’m confident in the I2C readings.

As I’m looking at the oscilloscope in parallel I see the reading of the I2C data is incessant. No gaps. Is that expected?

Is it caused by an inconsistent magnet field? Magnet and sensor are both centered well?

It’s 3d-printed parts properly aligned, distance is ok and max deviation of .25mm on the axis is likely achieved. I would also rather expect a (hard to observe) speed derivation over a full rotation, not these rather per-pole-pair issues.

My money right now is on the current sensing. This whole OPAMP + sample period stuff is complex, any suggestions for verification setup are very welcome.

So whilst playing around with the device to see if I can dig deeper into the current sensing setup I discovered something that leaves me baffled. I’ve written a custom program that just turns one phase high, and the two others to ground. Then I put a 470O resistor between the phases to see the current flow, and measured that. Running the system at 10V I’d expect ~20mA of current. However I saw 14, and eventually discovered that the voltage between the phases sits at ~7.5-8V.

The gate drivers have the full 10V at their H/L outputs, and according to the datasheet (see below) and my limited understanding of these things the mosfet should be switched fully on.

I’ve tested this with several units to see if my attempts burned one or some such - they all showed the same behavior. Any suggestions as to what could be happening here?

You can use driver.setPwm(pwmA, pwmB, pwmC); to test your current setup.

The diagram show the required gate-source voltage ( not gate-GND) , which is problematic for the high-side FETs.
I wondered if the bootstrap circuit needs a PWM signal < 100% to do the charge pump magic?
If so, then you’d probably see only a single short spike on the gate of the high side FET?

edit. Here is what chatGPT has to say about the bootstrap:

On the B-G431B-ESC1, the high-side gate drivers use the L6387, which has a bootstrap supply. The bootstrap capacitor must periodically be recharged by pulling the corresponding phase node low. ST explicitly confirms that the driver cannot support 100% duty cycle because it uses bootstrap technology.

Very interesting. I’ll buy some better load resistors today because the 0.003 ohm shunts need a bit more current than my measly 20mA, and my 4 ohm ones are heating up too much. Then I’ll try and use the PWM modulation.