Driver selection (integrated FET)

Been away from SimpleFOC for a while (so a bit rusty). I’m doing a bit of research for a new board

  • for a single gimbal (r > 5ohms)
  • all components available on lcsc.
  • probably going to try stm32g431cbt6
  • driver to have integrated FETs and current sensing
  • magnetic spi sensor

So looking for advice on integrated fet bldc driver. What I’ve considered:

  • l6234 is unavailable
  • drv8313 is available (and we know quite a bit about it)
  • drv8311 is available but only in drv8311p variant
    • The p variant is unusual and quite interesting. The a/b/c duty is set over tSPI and it cleverly allows 4 drv8311p to be controlled from a single microcontroller. It also has a decent 100ma LDO. However it would be a fair bit of dev to get it supported and seems to be focused on sensorless/velocity controlled applications (e.g. drones see vid).
  • drv8316 and drv8317 are interesting but not available

Of the above the drv8313 seems the obvious choice

Any other integrated FET drivers (available) that I should consider?

Part of the reason for picking stm32g431 is that I’d like to see if I can get USB PD working + I understand that it has good ADCs on it that might help me get results with current sensing (an area that I’ve avoided). Eventually (in a year or 2!) I might string 4 or 6 of these together over canbus to create something of the style of Ascento two wheeled robot.

1 Like

what sort of power level do you need? motor voltage and current?

Welcome back! Haven’t seen you in a very long while, hope all is well.


Max is 20V but in reality, 12V would likely do as I don’t need it to go fast (perhaps 500rpm).
For example I might be using it with something like:

I suspect I’ll be mostly using ~0.5Amp with occasional bursts up to 2A.

At such low current you may not benefit from current sensing.

Check the Mosquito design, it may have most of what you need but you need to replace the MCU.


Thanks Valentine. Your mosquito will be great for cross checking! Nice board.

Why does low current mean I won’t get much benefit from current sensing, too noisy? Or do you mean the low currents mean that I’ll not have much bemf i.e. Vin ~= I *R works well at these slower speeds?

I’ve never been happy with the cogging I tend to see with smaller gimbals at low speed/low load (closed loop) and thought perhaps current sensing was the answer.

1 Like

Seems about right.

That’s a motor design problem, anticogging algorihm is needed there. I’m not sure current sensing would make any difference.

You may be able to mostly avoid it with a well designed motor. But that’s $$$.


Here’s a thread discussing anti-cogging Anyone interested in collaborating on anti-cogging (lowest hanging fruit for smoother motion) - #43 by Candas1

Candas1 linked a good article in post #37.

Hey @Owen_Williams so nice to see you back :slight_smile: :slight_smile: :slight_smile:

Maybe take a look at the MPS (monolithic power) drivers also? I especially like the MP6540 but there’s a few to choose from…

1 Like

I snagged some very low cogging motors, they are very hard to find. You want what’s called a ring magnet. It’s the SM type motor, most are the IP type. The IP type use flat plate magnets, the SM use curved magnets. However I think it’s because the ring magnets have no gaps in between the magnets.

However they are quite hard to find and yes expensive, so I think it would be a really good idea to figure out some anti cogging stuff. Once the software is written then anyone in the world can use a cheaper easier to get motor and get the same results as an expensive hard to find motor. Progress.

Owen, why do you need integrated FETs? It shaves some $ off but is the per unit cost the main thing?

I also would like to use one of the G431 chips as the higher clock speed and M4 core with floating point has floated to the surface as important features, and I know someone else that I think would like to go that route, and the current is also in the same region as what you need. I think maybe we should collaborate.

The lepton runs the motor.move(target) command at 5 khz in open loop, while it runs at 37.5 khz on the b-g431B-ESC1 board, so it is way faster. Also less glitching and noise, although these may be soluble through other means, that floating point hardware and faster clock rate is clearly useful in this context for sure.

As I see it, the next really big SimpleFOC dev. Is Klipper integration, which will enable Gcode controlled machines, to run w. SimpleFOC.

I’m about to start assembling the Field Stack Beta Run. Why not just focus on Klipper ?

SimpleFOC has a Step/Dir interface. If you connect that interface to the output of a microcontroller running something like GBRL, couldn’t you make SimpleFOC work with GCODE?

Interpreting GCODE in my opinion is completely outside of the scope of engine drivers. There are countless variants of GCODE that you have to specify when using a CAM tool.

That is the whole point. If using Klipper w. SimpleFOC, we don’t need the usual step-generating MCU.

Each node will then work like sub-drivers in OPnP

@JorgeMaker maybe you should reed up on Klipper. Klipper interpret Gcode and sends the move commands to each node. Or turn on LEDs, heat-bed, etc.

But of course, diving into actual USB implementation, like Klipper does. Will either make your Studio useless or you will have to upgrade that with a real USB option (64-bit)

Maybe Klipper will be the place to monitor data while in use?

Recent dev. On Klipper → klipper/src/stm32 at master · Klipper3d/klipper · GitHub


// Setup the transfer descriptors in dedicated usb memory
static void
epm_ep_desc_setup(0, USB_CDC_EP0_SIZE);
epm_ep_desc_setup(USB_CDC_EP_ACM, 0);
epm_ep_desc_setup(USB_CDC_EP_BULK_IN, 0);

I was planning to release a g431 lepton variant, when i get some time.

1 Like

Valentine, that’s awesome, I know another guy that is also going down this road, I think we should totally collaborate, I’m waiting to hear back more of his thoughts by email. Releasing a proposed draft could be a good way to do that for sure. I think the guy I know may be willing to pay for getting boards made, and I can help with testing. I think this is going to be a really good thing for the community :slight_smile:

Yo can develop an interpreter of Klipper commands making possible to run Klipper on the same microcontroller that you are using for your SimpleFOC instance, effectively creating a “Klipper Node.”

However, in my opinion, this is not in line with the purpose of SimpleFOC, as it operates at a higher layer. If you look at examples such as oDrive, VESC, or Moteus, none of them go beyond basic motion planning for a single axis.

It’s going to be very close to the Lepton may be with more pins broken out. Then people can use it to mod the board as they need.

I moved this discussion to the proper thread;

I’m still getting back into simplefoc, so klipper/gcode isn’t on my mind at the moment. There are quite a few great boards in development, but like most people I want to make my own!

I’m likely to go the drv8316 route, my pcb design skills and rusty electronics knowledge makes the onboard 200ma buck, integrated fets and current sensing appealing.

Once I’m comfortable with my board/motor setup. I’ll work on a combined power/brain board controlling multiple motor boards perhaps with a bit of ML/vision recognition.