I found the release version of PowerShield:

Could I know more details about the board? I mean, more example codes will be helpful.

It’s exactly what I’m looking for.
@Antun_Skuric: Will this shield be able to handle the low resistance motors, as well? I’m currently struggling with the simple foc shield V2 to drive a 0.7 ohm motor. I can’t get him run smooth. But with more current this might work.

Hey Guys,
Yes I am excited about this baord! It has been completely inspired by the infineons board.

It is designed to support the middle range BLDC motors up to 500W. I am still a bit in the testing phase, namely to determine which kind of current sensing we will be able to use with it and what is the actual current it will be able to withstand. :smiley:

Features for now

  • Plug & play: In combination with Arduino SimpleFOClibrary - github
  • Low-cost: Current price of fabrication is less then 20€
  • High-side current sensing: - not yet supported by SimpleFOClibrary
  • Max power >500W: max current 30A, power-supply 24V
  • Arduino headers: Arduino UNO, Arduino MEGA, STM32 Nucleo boards, Aruidno DUE…
  • Small size: 55mm x 55mm
  • Open Source: Fully available fabrication files

Future features

  • Stackable: running 2 motors in the same time
  • Encoder/Hall sensors interface: Integrated 3.3kΩ pullups (configurable)
  • I2C interface: Integrated 4.7kΩ pullups (configurable)
  • Configurable pinout: Hardware configuration - soldering connections

How to use it

This board has enable pins for each of the phases for now and it has completely static pinout.

name description pin
IN1 pwm 1 9
IN2 pwm 2 6
IN3 pwm 3 5
INH1 enable 1 8
INH2 enable 2 7
INH3 enable 3 4

The simplefoc library v2.0.x does not support the BLDC drivers with 3 enable pins.

simplefoc library v2.1

But if you download the dev version which will be released very soon it does so you can just do:

// Open loop motor control example
#include <SimpleFOC.h>

// BLDC motor & driver instance
// BLDCMotor motor = BLDCMotor(pole pair number);
BLDCMotor motor = BLDCMotor(11);
// BLDCDriver3PWM driver = BLDCDriver3PWM(pwmA, pwmB, pwmC, Enable(optional));
BLDCDriver3PWM driver = BLDCDriver3PWM(9, 5, 6, 8, 7, 4);

//target variable
float target_velocity = 0;

// instantiate the commander
Commander command = Commander(Serial);
void doTarget(char* cmd) { command.variable(&target_velocity, cmd); }
void doLimit(char* cmd) { command.variable(&driver.voltage_limit, cmd); motor.voltage_limit=driver.voltage_limit/2;}

void setup() {

  // driver config
  // power supply voltage [V]
  driver.voltage_power_supply = 12;
  driver.voltage_limit = 1;
  // link the motor and the driver

  // limiting motor movements
  motor.voltage_limit = 0.5;   // [V]
  motor.velocity_limit = 5; // [rad/s] cca 50rpm
  // open loop control config
  motor.controller = MotionControlType::velocity_openloop;

  // init motor hardware

  // add target command T
  command.add('T', doTarget, "target velocity");
  command.add('L', doLimit, "voltage limit");

  Serial.println("Motor ready!");
  Serial.println("Set target velocity [rad/s]");

void loop() {

  // open loop velocity movement
  // using motor.voltage_limit and motor.velocity_limit

  // user communication;

Thie example uses some of the new features of the simplefoc v2.1, for example Commander interface.
In this example you can set/get target velocity with commad T. For example to get target velocity just send T and to set for example 2.5 rad/s send T2.5.
The same can be done for the voltage limit, with command L.

simplefoc library v2.0.x

For the version of the library v2.0.x you can enable additional pins by hand, here is an example:

// Open loop motor control example
#include <SimpleFOC.h>

// BLDC motor & driver instance
// BLDCMotor motor = BLDCMotor(pole pair number);
BLDCMotor motor = BLDCMotor(11);
// BLDCDriver3PWM driver = BLDCDriver3PWM(pwmA, pwmB, pwmC, Enable(optional));
BLDCDriver3PWM driver = BLDCDriver3PWM(9, 5, 6);

void setup() {

  // driver config
  // power supply voltage [V]
  driver.voltage_power_supply = 12;
  // link the motor and the driver

  // enbale pins set to high
  pinMode(8,OUTPUT); // inh1
  pinMode(7,OUTPUT); // inh2
  pinMode(4,OUTPUT); // inh3

  // limiting motor movements
  motor.voltage_limit = 1;   // [V]
  motor.velocity_limit = 5; // [rad/s]

  // open loop control config
  motor.controller = ControlType::velocity_openloop;

  // init motor hardware

  Serial.println("Motor ready!");

float target_velocity = 0; // [rad/s]

void loop() {
  // open loop velocity movement
  // using motor.voltage_limit and motor.velocity_limit

  // receive the used commands from serial

// utility function enabling serial communication with the user to set the target values
// this function can be implemented in serialEvent function as well
void serialReceiveUserCommand() {

  // a string to hold incoming data
  static String received_chars;

  while (Serial.available()) {
    // get the new byte:
    char inChar = (char);
    // add it to the string buffer:
    received_chars += inChar;
    // end of user input
    if (inChar == '\n') {

      // change the motor target
      target_velocity = received_chars.toFloat();
      Serial.print("Target velocity ");

      // reset the command buffer
      received_chars = "";
1 Like

Hi, I’m starting with a board using IFX007T’s.
I tried the v2.1 example code, and it works.

Can I ask why you didn’t use the output capacitors? Is it to reduce power consumption?

(close your eyes when looking at my hand soldering)


Very nice, you have a great looking board!

I’ve not used them mostly to avoid unnecessary components at this early stage, since the power lines are pretty short I decided to avoid them at this point. For the kind of use cases this shield is intended for I am not sure that they make too much difference. If you expect to be running higher currents I would definitely suggest you to follow the datasheet and put them.
I am really not an expert though :smiley:

Did you manage to test the board in closed loop mode, does it work as well as it looks? :slight_smile:


No I haven’t tested closed loop yet - I’ve tested that the encoder (MA702) works, and CAN works (both tested with ESP-IDF), but I don’t have a physical assembly to hold everything together yet…

@Jason_Kirsons Nice design.

Thank you for sharing.

@Antun_Skuric can I just connect PIN INH1/INH2/INH3 to high voltage point(3.3v)to save my GPIO pin, on this board(Arduino-SimpleFOC-PowerShield)?
Thank you for answering

Yes sure. I’d suggest you to connect them all to one pin to be able to disable the driver.

@Antun_Skuric thank you very much!

Hi @Antun_Skuric,
What is the corresponding between the phase current and the IS output of this component IFX007 or BTN for current reading ?

Hey @Marc_O,

A priori these drivers have implemented high-side sensing. And that would mean that you can sample their IS current as the low-side sensing but on the opposite side of the PWM cycle (when all the PWM signals are high - or when the high-side mosfets are up).

This is the good news. But the bad news is that from the tests that I was able to do it seems that the IS is an absolute value of the current. Or better said, it might be that it doesn’t have the current sign information which would make it unusable for FOC.
I’ve done another version of the shield with In-line sensing, it has arrived today so I’ll let you guys know if this makes sense as an option. But I am pretty optimistic :smiley:


that’s good news! I still could not find an affordable solution for bipolar stepper driver plus in-line current sensing.
By the way: How would SimpleFOC limit the amount of current through a low-resistance stepper ? I have seen in an Trinamic eval board schematic TMC-UPS-10A70V-EVAL,
that they do extra current sensing for the sum of all currents. That goes to an extra P-control loop for the overall current in their TMC4671 FOC chip.
Does SimpleFOC limit somehow the current based on the sum of phase currents ? I have some problems in understanding what’s the equivalent of voltage/current control you see in stepper controllers to FOC principles.

one more thing… You rate the board for max.24V. BTN8982TA is good for 40V. What would be needed to make the board work at 40V ? Is it just the CAP (25V)?

Hey guys,

The board works pretty well really. I am very happy!
Even though it has the shunt resistor of 1mOhm it still can do the true FOC for gimbal motors well.
I’ll try to make it stackable soon and release first real version.

Simplefoc library implements the current limiting in the motion control loops you can find the schemes in the docs.
We are not summing the phase currents but calculating the current vector using park and clarke transformations. We do not limit the cumulative phase current (or a sum) but the real current vector. It is the standard approach for FOC control. There is no real difference in between FOC for stepper and BLDC motor. The only difference is how you calculate the current vector (using 3 or 2 phases).
At this moment we only implemented the true FOC support for bldc motors but that will change with the next release.

Yep, the smd caps are a bit hard to find, especially for these huge values. The advised value is 1000uF . But you can easily get around this by using a through hole cap.


Hey guys,

I am deep in the testing of the PowerShield and I am having a lot of trouble with the slew rate and the rise-time of the mesfets. It is very very long. In average the raise time is around 3-6us what is really too much and any pwm frequency above 10kHz really does not make sense. The losses are just too high, for my board at least.
Especially when dealing with the higher-power motors which operate on 0.5-3Volts, the cogging becomes a real problem. Since the raise time is so slow, even a bit of ringing is producing a great deal of error in voltage vector set to the motor. And when I try to combine the current sensing into all of this then the story becomes even worse :smiley:
So I am seriously considering dropping the PowerShield :smiley:

I mean, it works and it can handle about 20-25 Amps without problem (that is how much I tested) but the fine grain position control is really hard to do, much harder than it is supposed to be :smiley:
It works verry well for gimbal motors though, since for them the phase voltages are much higher the slow rise time does not have such an influencem but they are still a bit less smooth than SimpleFOCShields.
I’ve rewatched @Jason_Kirsons’s video of his board and I think I am seeing the same issues, for low velocities (especially when motor is trying to hold the position) you can hear the cogging :smiley:

I’ve also tested the high-side current readings (this was the discussion some time ago with @alp ) and it works, but the current reading is unidirectional and you cannot read the negative currents. So the FOC is out of the question, but maybe the BEMF would be possible though.

So my opinions for the BTN8982 based board can be summarized in:

  • Problems:
    • Very slow rise time (even without slew resistor), needs the PWM frequency under 10kHz
    • Integrated current sensing not unidirectional and cannot be used for FOC - but maybe BEMF ?
  • FOC possible (full current control)
    • For higher velocities (300 rpm+)
    • Fine smooth position control for higher phase resistance motors (gimbal motors)
  • FOC using voltage will work well for most of the motors (tested up to 25Amps ) - not as smooth as gimbal motors but as smooth as @Jason_Kirsons’s awesome video :smiley:

Do some of you have different experiences? :smiley:

1 Like

Yes, I had to tune it a bit so that it wouldn’t shoot past the target position while fighting the cogging… This is my first high current FOC board, so I don’t have much to compare it to.

Have you tried changing the slew rate resistors? I think the data sheet lists specs down to 0 ohms:


There is something to be learned in every experience.
I think these integrated drivers are meant to replace inefficient brushed DC motors in things like battery powered drills etc. Then the motor would have the same physical dimensions. Which would mean : a 2 or 4 pole inrotor operating at about 6000 RPM. Which would require a 100/200 Hz sinewave, which doesn’t require high speed PWM.
If you read the specs of the driverchip, they also mention high-side P-channel mosfets that do not need a boost circuit.
But they have much higher Rds-on resistance than N-channel.
FCC rules must have been high on the designers list of requirements.

This is called a community. So why not design a board as a community ? It is very hard to be perfect at everything.


That’s unfortunate. Surprising too. I am currently testing the infineon ifx007t demo board and so far looks fine. BTN8982TA is a drop-in replacement to the IFX007T so there should not be that much difference? Are you saying the BTN8982TA is incapable of operating with PWM above 10k due to slew losses?

I will bring my infineon driver to my lab and test with my oscilloscope, until now i’ve just been messing at home with the board and a mega. I’ve never driven it at high rate due to mating it to a mega board, that’s why I wanted to drive the demo shieldt with the nucleo it’s got a lot higher frequency. I’ll mate it to a blue pill and check it out, or build a rat’s nest and drive it with a nucleo.


Wow, ok that’s surprising, but its actually as per the datasheet. That’s really slow. Like, really, really slow. The FETs I’ve been collecting data sheets for (for my hypothetical future high power ESC design, which I have been scared of doing so far because of fear of high currents, discrete mosfets, etc…) are at least 30x faster than this, and some are like 1000x faster. The delay and rise/fall times are measured in single- or double-digit nanoseconds, not microseconds!

Check out an AO4406, or something like a GS61008P, or if you like Infineon, maybe a BSC040N08NS5…

Personally, my (future) plan was to more or less duplicate the design of one of those Mini-F4 ESCs (but a bit larger for convenience), replacing its (typically Fortior) driver with something more suitable. There’s also the various BOOST boards from TI, and some high power reference designs from ST-Micro to use as inspiration.

I think Infineon themselves say in some application note somewhere that I can’t find right now, that the minimum on-pulse time should be several times (>10x ?) the switching time. So that means slow FETs limit your PWM speed and resolution. 100ns switching time means 1us minimum pulses, at a resolution of 1000 that would be 1ms period or 1kHz PWM :frowning: did I get that right??

I wouldn’t abandon the Power-Shield, but maybe redesign with different FETs?