10kW BLDC motor controller up to 90V and 200A with sensorless FOC - build thread

peters

1 kW
Joined
Oct 20, 2012
Messages
373
Location
Hungary
I've been planning to start my controller thread for a long time, now here it is. It's about my latest build that I made for development and testing purpose, started sometime in the spring last year and still in progress.

It was designed to fit in the hammond 1590U or the gainta G0474 box (almost the same, external dimensions: 120x120x59mm):
https://eu.mouser.com/ProductDetail/Hammond-Manufacturing/1590U?qs=lxPAlgZqN%2FxeTOQJUYeowQ==
https://www.tme.eu/hu/en/details/alu-g0474/multipurpose-enclosures/gainta/g-0474/

The circuit consists of 3 boards stacked: power, gate driver and CPU. I planned this way to make it easier to change to another gate driver or CPU board without redesigning the whole unit.
I made the design in an older software (Accel), so instead of the source files I just share pdf and screenshots. No spectacular 3D views.
The schematics are 3 pages, each for one board:
View attachment 10kW BLDC motor controller sch rev01.pdf
PCB drawings:
all boards top
View attachment 01 all top.png
all boards bottom
View attachment 02 all bottom.png
power board bottom
View attachment 03 power bot.png
power board top
View attachment 04 power top.png
power board output nodes in magenta (cut from 0.5mm copper sheet and soldered on the top layer with thin insulation boards above +VBAT (white rectangles in the middle))
View attachment 05 power outputs.png
snubber modules (small PCB-s soldered between the MOSFET legs)
View attachment 06 snubbers.png
driver board top
View attachment 07 driver top.png
driver board bottom
View attachment 08 driver bot.png
CPU board top
View attachment 09 cpu top.png
CPU board bottom
View attachment 10 cpu bot.png
Originally I started to design this controller for this bike (dark green box inside the frame on the bottom plate):
View attachment bike2024.png
But I'm not going to build this frame in the near future, so I will install it on my current bike.

The gate driver circuit is a bit more complex than usual because I wanted to adjust all phases of the MOSFET switching transients separately as much as possible, such as the Vgs rise and fall times, length of the Miller-plateau (Vds edges), length of the current transients for both the turn-on and turn-off, and the high frequency oscillations.
I'm using this controller also to develop my FOC firmware with full torque sensorless start, that is also in progress.
So at the moment I'm building only a single unit for development purposes, maybe later I'll design a simplified version for sale with only 2 boards.
The boards are already built and mostly tested, I will post photos and waveforms later.
Some resistors/capacitors on the schematics may still change.
 
Very nice work. :bigthumb:

I like the layout of the cpu board. Is the missalignment of some of the cpu pads and traces just a rendering issue?

Peters_cpu.PNG

I'm interested to hear why the battery voltage feedback is not isolated given that everything else is?

At what current level does the desat trigger at with 4.3V zeners? I am using the ACPL-337's in a high power Lebowski design which have a higher drive current, they seem like a pretty good gate driver. Can you post a photo of the assembled controller please, I would like to see the mosfet heat sink arrangement.
 
Peters has given a lot of useful input to other user's designs, so looking forward to this one! Hoping it's a reference piece. Will settle for pictures of fire.

Could you explain more about component choice - mcu, how it's wired in, timer use etc? It looks like stm32 but doesn't obviously use the standard timer 1 pinout.
 
kiwifiat said:
Is the missalignment of some of the cpu pads and traces just a rendering issue?

I'm interested to hear why the battery voltage feedback is not isolated given that everything else is?

At what current level does the desat trigger at with 4.3V zeners? I am using the ACPL-337's in a high power Lebowski design which have a higher drive current, they seem like a pretty good gate driver. Can you post a photo of the assembled controller please, I would like to see the mosfet heat sink arrangement.

Yes, just a rendering problem, the screenshot looks like this in this magnification.

The on-board power supplies are not isolated, the GND DC level is the same, there are just inductors to filter the voltage spikes (could be a common mode choke instead). The phase voltage feedbacks are also not isolated, the current through the voltage divider resistors is just 1-2mA, that shouldn't make any problem.

I tried desat only once, the current was 650A or maybe even more, I wrote that somewhere on the schematics. It was an estimation from the turn-off overshoot voltage and length: the integral of the overshoot is the flux in the output loop (=L*I).
Maybe I'll change the zeners to 4.7V, but the problem is that the desat voltage tolerance range of these ACPL-s is too high, plus the Rdson increases with the temperature, and I'd like to avoid false desat triggers.
The "heatsink" is just cut from a 4mm thick aluminium sheet and mounted to the FETs and the PCB with a silicon insulator in between, and will be mounted inside the box, but that is not finished yet.
 
mxlemming said:
Could you explain more about component choice - mcu, how it's wired in, timer use etc? It looks like stm32 but doesn't obviously use the standard timer 1 pinout.
It's the same MCU that you have on your board, but the 64 pin version (STM32F303RCT7), and I chose it mainly because it has 6 analog comparators that can be set up for phase overcurrent detection, but only 3 dedicated pins can be used for that (PA1, PB13, PB14). Those pins are common with some timer1 outputs, and the other option for timer1 is the same as the USB pins (as far as I remember), that ruled out timer1, so I use timer8 for PWM.
 
Some photos of the build process

The power and the driver boards are my diy PCBs made with hobbyist tech, but I think I won't do that ever again since the prices at JLCPCB are low, much cheaper than the local proto manufacturers here.

power board top; etched, drilled and tinned:
01 IMG_20200508_152535.jpg
power board bottom:
02 IMG_20200508_152607.jpg
0.5mm copper layers for DCbus (maybe wouldn't be needed for a PCB with thick copper, but mine was a standard 35um):
03 IMG_20200508_152329.jpg
top side, more copper for the output nodes and holders for 6mm gold plated RC connectors:
04 IMG_20200525_140447.jpg
top side finished:
05 IMG_20200601_154611.jpg
bottom side finished:
06 IMG_20200601_154906.jpg
battery connectors:
07 IMG_20200601_161100.jpg
motor wire connectors:
08 IMG_20200601_160841.jpg

The finished power board with components (looks better and cleaner in real life):
09 IMG_20210301_162952_1.jpg
Bottom side, snubbers are in the middle, over the ceramic DCBus capacitors:
10 IMG_20210301_162345.jpg
Bottom side without the snubbers:
10_1 IMG_20200717_120624.jpg
Gate driver board:
11 IMG_20210301_162156.jpg
12 IMG_20210301_162146.jpg
CPU board:
13 IMG_20210301_162422.jpg
14 IMG_20210301_162428.jpg
the stack:
15 IMG_20210301_162628.jpg
in the box:
16 IMG_20210301_162750.jpg
 
A Rolls Royce controller if I ever saw one, thanks for posting. Is the copper laser cut or did you hand make those sheets? Having made copper sheets for the Lebowski power boards by hand I find copper quite difficult to drill so if those were hand made even more kudos to you.
 
This is quite a remarkable execution. Much love and care gone into it. Only thing left to do is mine the copper and refine the silicon yourself.

I don't understand a lot of the choices, the avago gate drivers with 5kV isolation, IGBT drivers with all the miller desat stuff when you're using MOSFETs, isolation everywhere for 90V... But it's fascinating. It would be really unlucky if it didn't work. Hopefully it's bulletproof

Pretty sure btw that the comparators are accessible on many other pins and are completely compatible with timer 1... I know this because I'm using 4 of them like that... But timer 8 is identical so meh.
 
mxlemming said:
Pretty sure btw that the comparators are accessible on many other pins and are completely compatible with timer 1... I know this because I'm using 4 of them like that... But timer 8 is identical so meh.

Sorry, just realized you're using multiple comparators per phase to get the window behavior you need for phase shunts. Makes sense now.
 
mxlemming said:
I don't understand a lot of the choices, the avago gate drivers with 5kV isolation, IGBT drivers with all the miller desat stuff when you're using MOSFETs, isolation everywhere for 90V...
The gate drivers may be overkill, but I wanted the protection by the desat and the isolation to save the components if I accidentally short something. It's a design for doing tests and development so the cost was not so important.
From another point of view I already simplified a few things: the low side drivers could also have isolated power supplies and there are no diff amps on the current sensor outputs against the common mode noise.
 
mxlemming said:
I don't understand a lot of the choices, the avago gate drivers with 5kV isolation, IGBT drivers with all the miller desat stuff when you're using MOSFETs, isolation everywhere for 90V... But it's fascinating. It would be really unlucky if it didn't work. Hopefully it's bulletproof

This is the way.

The gate driver is the most critical and sensitive part of a controller.

Peters, have your verified your snubber design will handle the power dissipation? I've done a lot of simulation on snubber design and in most cases the power dissipation was several to 10's of watts.

peters said:
kiwifiat said:
Is the copper laser cut or did you hand make those sheets?
Manually cut, filed and drilled and grinded with a dremel. Needed some patience...

You are a masochist!

I use JLCPCB for my prototyping and assembly, but since you are in Europe they probably kill you with theft...I mean taxes. Four layer boards are low cost and make design much easier. I sometimes use 6 layers for compact designs.
 
zombiess said:
mxlemming said:
I don't understand a lot of the choices, the avago gate drivers with 5kV isolation, IGBT drivers with all the miller desat stuff when you're using MOSFETs, isolation everywhere for 90V... But it's fascinating. It would be really unlucky if it didn't work. Hopefully it's bulletproof

This is the way.

+1. And love the reference.

I made the exact same choices on a quite similar motor drive I have on the bench now. :bigthumb:
 
marcos said:
zombiess said:
mxlemming said:
I don't understand a lot of the choices, the avago gate drivers with 5kV isolation, IGBT drivers with all the miller desat stuff when you're using MOSFETs, isolation everywhere for 90V... But it's fascinating. It would be really unlucky if it didn't work. Hopefully it's bulletproof

This is the way.

+1. And love the reference.

I made the exact same choices on a quite similar motor drive I have on the bench now. :bigthumb:

So what do we actually expect to cause desat of these MOSFETs?
I'm 100% behind:
Over current
Over voltage (though this seems routinely overlooked despite being the single biggest cause of FET death)
Shoot through protection/hardware dead time
Fuses before the ESC
Inrush limiters
Défensive coding
Watchdog timers
All set up in hardware (even if on the stm32...)


I guess I'm jaded because at work I'm a tech lead/mech eng and I'll be like "right, i want a boards to drive 5x24V valves,2 steppers, 2 thermocouples and 2 spare analog. Also, USB to serial to communicate with it. Use stm32f4xx please, like the last device."

I come back 2 weeks later and there's a 384 pin bga thing, 5 million little black widgets by the connectors, each valve has 4 chips (gate drives, FETs...), a bunch of other little widgets, the thermocouples use a 48 pin adc that can sample at 100MHz and the whole lot cost 7x as much as I expected. We also have to employ a Verilog consultant because it's sprouted an FPGA.

Eventually, project manager decides time is important so we'll just order as is, and it arrives... 6 weeks where we'd like it in 2... It takes 3x as long to get running, and we find later there are various bugs in the extra widgets, and resort back to a dev board to drive the xxxx part.

Somehow the BGA makes it to production, where it's later found that the screws holding the board in stress it enough that some of the pins detach and the whole board fails, so the boards get scrapped and replaced with a version with lqfp chips.

This isn't facetious. This or a variant of this has happened on half the projects I've ever worked on, whether as a cad engineer or tech lead.

So I always ask: "are you piling up complexity because we truly need this and it's going to add value, or do you just like fiddling with the expensive complicated chips? Because if it's the second, why don't you just buy a dev board with the clever chip on it to fiddle with?"
 
zombiess said:
Peters, have your verified your snubber design will handle the power dissipation?
With 3.3nF the snubbers add only 0.5W/FET at 90V and 18kHz, or a little more, because the capacitors are charged to the overshoot voltage. I find it very effective below 100V to stop the oscillations, I'll post waveforms with and without the snubbers.
 
In some industries there are regulations to design for safety and reliability, like medical, and I guess automotive and aerospace, too. The high level requirements translated to engineering level and after evaluation of the potential failures, it normally comes out that short-circuit protection is needed for the outputs going out from the boards. In this case the desat is not an unnecessary complexity. Some DRVxxxx 3-phase drivers from TI also have built in desat, just they have a different name for it.
BTW I would do everything in FPGA if they were high density in low pin count QFP; the uC with its messy peripheries is just a low cost workaround :)
 
peters said:
In some industries there are regulations to design for safety and reliability, like medical, and I guess automotive and aerospace, too. The high level requirements translated to engineering level and after evaluation of the potential failures, it normally comes out that short-circuit protection is needed for the outputs going out from the boards. In this case the desat is not an unnecessary complexity. Some DRVxxxx 3-phase drivers from TI also have built in desat, just they have a different name for it.
BTW I would do everything in FPGA if they were high density in low pin count QFP; the uC with its messy peripheries is just a low cost workaround :)

The other issue with fpga is they tend to be remarkably expensive and operate at hundreds of MHz which puts you into different emc test bands. But yes, pwm generation, fault handling etc is beautiful in fpga.

I'm moderately well versed in medical device. Not atall in aviation. I see in medical stuff, a lot of system level requirements imposed on modules, and extrapolation... Ultimately for medical, it's risk based and the key ethos is that no failure can result in harm. There's no prescription of how you implement. And you do have to consider the implication of a safety subsystem failure. And the failure of the system that deals with the failure detection system. And....

Aviation... Sure. If your rudder drive goes down you'd better have a full redundancy and have tested everything to death because otherwise you kill a plane full of people... But for an ebike driving the rear wheel? You'll skid to a stop at worst. Esk8... Hmmm... Lot of VESCs with basically no protection that can dump people on their faces...
 
I'm totally unqualified to even be reading this thread :). At least I'm absorbing the terminology by osmosis... Kudos to you guys designing the brains behind the motor, and the specs are in the sweet spot for a powerful lightweight ebike. 20s+, and enough current to TIG 1/4" aluminum.

Very nice craftsmanship peters. A work of art, as I'm sure the other projects here are. You mention sensorless full torque startup at the top of the thread- does anyone want to write a few sentences in plain English how that phenomenon works? How does the motor know which way to spin, and should one expect smooth controllable application of power off zero throttle? Do not want to jack the thread, just a few words.

I'm about to deal with this situation soon (with a commercially available vesc style 6.6 and sensorless motor) and have never even programmed a controller.
 
Barncat said:
I'm totally unqualified to even be reading this thread :). At least I'm absorbing the terminology by osmosis... Kudos to you guys designing the brains behind the motor, and the specs are in the sweet spot for a powerful lightweight ebike. 20s+, and enough current to TIG 1/4" aluminum.

Very nice craftsmanship peters. A work of art, as I'm sure the other projects here are. You mention sensorless full torque startup at the top of the thread- does anyone want to write a few sentences in plain English how that phenomenon works? How does the motor know which way to spin, and should one expect smooth controllable application of power off zero throttle? Do not want to jack the thread, just a few words.

I'm about to deal with this situation soon (with a commercially available vesc style 6.6 and sensorless motor) and have never even programmed a controller.
Regarding the sensorless startup, have a look at the discussion on thor lancaster's thread that's been going recently. We discussed a lot.

Peter's power board is one of the most beautiful diy pieces I've ever seen. I'm loving it. We're all arguing over fairly niche things tbh... Wouldn't worry too much about it. All of us have motors that spin away quite happily :lol:
 
mxlemming said:
So what do we actually expect to cause desat of these MOSFETs?
I'm 100% behind:
Over current
Over voltage (though this seems routinely overlooked despite being the single biggest cause of FET death)
Shoot through protection/hardware dead time
Fuses before the ESC
Inrush limiters
Défensive coding
Watchdog timers
All set up in hardware (even if on the stm32...)

FYI, I'm adding some additional info to this to assist other people reading this thread.

A common cause of shoot through is shorting the phase leads.

Technically speaking nothing causes desaturation in a MOSFET as it's an IGBT phenomenon, but the same detection circuit can work with a MOSFET. The desat detection of a gate drive is used because it can respond fast to a high current fault. As you probably know faults should be handled in multiple stages to ensure a fail safe state. Managing a shoot through event is about controlling energy dissipation. General rule of thumb is to detect the event and shut down in <5us. Most current sensors aren't going to respond fast enough for this type of event.

Over voltage often happens during a short circuit event and not all devices are rated to handle repetitive avalanche events (acts like a zener clamping the voltage).

General fail safe method I've been taught/learned for fault handling is:
0. Always know and control what state the controller is in.
1. Shut down the gate drive output first through hardware (fastest method).
2. Manage the energy during the sudden turn off event, this is where 2 level / soft off features come in, but this is more geared towards IGBTs.
3. Shut down PWM into the gate drives through hardware control from the gate driver fault signal
4. Trigger a fault condition on the controller so it shuts down and stops sending PWM

In addition to the above, a hardware based output sensor over current fault detection should shut down the PWM into to the gate drive. This serves a similar function to desat, but it is slower.

The gate drivers should also feature UVLO to prevent unknown states. Some applications will also monitor gate driver power supply and trigger a fault if it's out of range.

PWM Inputs to gate drives can have a hardware lock out circuit added to improve reliability, some dual drivers have this built in, but most lack the other features like a clamp or desat.

Gate drivers should also have a Miller clamp (this feature is almost mandatory IMO) to force a low impedance path to ground on the gate of the device to mitigate Miller turn on effect. Power to the gate drivers should be isolated from the rest of the system through unregulated DC-DC converters to minimize noise into and out of the gate drivers and provide voltage isolation for safety. Connection of the gate driver to the power device should be made through a "Kelvin" style connection to gate-source to reduce noise from the power pass.

The heart of a power stage is the gate driver, it is the most important and sensitive part of a design. I know you consider most of this overkill, but these methods help ensure a successful, reliable high power design. Not every controller needs all of this, but once you start crossing into the +10kW range, things you might not think are problems such as layout decisions start to pop up. When working in the lower power ranges it's possible to get away with many sub optimal design choices.

If you are designing a product for sale, you need to take into account failure rates and customer satisfaction. Assume the end user is going to do something dumb. The additional costs incurred by adding good gate driver design can have a long term payoff through reputation. If you were building a 40HP electric motorcycle, would you rather buy a Kelly controller or the much more expensive Sevcon? Which one is more likely to fail causing you to have an accident? It costs about $50 to build a fully isolated 3 phase gate drive in small quantity with almost all the features I listed.
 
zombiess said:
FYI, I'm adding some additional info to this to assist other people reading this thread.

A common cause of shoot through is shorting the phase leads.

Technically speaking nothing causes desaturation in a MOSFET as it's an IGBT phenomenon, but the same detection circuit can work with a MOSFET. The desat detection of a gate drive is used because it can respond fast to a high current fault. As you probably know faults should be handled in multiple stages to ensure a fail safe state. Managing a shoot through event is about controlling energy dissipation. General rule of thumb is to detect the event and shut down in <5us. Most current sensors aren't going to respond fast enough for this type of event.

The gate driver he has detects desat at 6.5V. Peters hasn't said what FETs he's using (has he?) but I'm going to assume that 2to247s have an Rdson of about 1-2mohms. So the desat kicks in at 3-6.5kA. I don't think 1) the FETs will be able to break this current 2) his battery can supply that current 3)I suspect in this case even with a microsecond FET/FET leg/PCB is going to vaporize anyway. So I seriously doubt the utility of the desat protection.

General fail safe method I've been taught/learned for fault handling is:
0. Always know and control what state the controller is in.
1. Shut down the gate drive output first through hardware (fastest method).
2. Manage the energy during the sudden turn off event, this is where 2 level / soft off features come in, but this is more geared towards IGBTs.
3. Shut down PWM into the gate drives through hardware control from the gate driver fault signal
4. Trigger a fault condition on the controller so it shuts down and stops sending PWM
Solidly agreed.

In addition to the above, a hardware based output sensor over current fault detection should shut down the PWM into to the gate drive. This serves a similar function to desat, but it is slower.
Easily achievable in a few us with low side shunts, phase shunts maybe slightly slower. Maybe 5-10us?

The gate drivers should also feature UVLO to prevent unknown states. Some applications will also monitor gate driver power supply and trigger a fault if it's out of range.
Agreed
PWM Inputs to gate drives can have a hardware lock out circuit added to improve reliability, some dual drivers have this built in, but most lack the other features like a clamp or desat.
This is already implemented in the stm timer, the gate driver or both. I don't see the point in piling more versions of it on.

Gate drivers should also have a Miller clamp (this feature is almost mandatory IMO) to force a low impedance path to ground on the gate of the device to mitigate Miller turn on effect. Power to the gate drivers should be isolated from the rest of the system through unregulated DC-DC converters to minimize noise into and out of the gate drivers and provide voltage isolation for safety. Connection of the gate driver to the power device should be made through a "Kelvin" style connection to gate-source to reduce noise from the power pass.
Miller turn on is a function entirely of the FET being used, and can therefore be easily avoided by picking the right FET. You simply don't need it for the more recent generations of MOSFET.

The isolated power supply I get when you're playing with mains but for batteries? Hmmm. Unregulated is inviting other issues... At least clamp it... Feedback/regulation doesn't have to mess up your clean analog ground.

Fully agreed on there layout and Kelvin connection.
The heart of a power stage is the gate driver, it is the most important and sensitive part of a design. I know you consider most of this overkill, but these methods help ensure a successful, reliable high power design. Not every controller needs all of this, but once you start crossing into the +10kW range, things you might not think are problems such as layout decisions start to pop up. When working in the lower power ranges it's possible to get away with many sub optimal design choices.
Good layout is free. I'm a solid advocate of good layout.
If you are designing a product for sale, you need to take into account failure rates and customer satisfaction. Assume the end user is going to do something dumb. The additional costs incurred by adding good gate driver design can have a long term payoff through reputation. If you were building a 40HP electric motorcycle, would you rather buy a Kelly controller or the much more expensive Sevcon? Which one is more likely to fail causing you to have an accident? It costs about $50 to build a fully isolated 3 phase gate drive in small quantity with almost all the features I listed.
Kelly does like to blow up... So do VESCs... But they both have literally no protection whatsoever... I do wonder what causes the failures, is it inrush? Overheating? Crappy FETs ? Software crashes?
Peters' controller seems to have it all, with minimal extra cost. I only contend that 1) his desat probably does absolutely nothing beyond giving a false sense of security against shorts to ground. 2) the isolation is nice but probably unnecessary. But cheap and harmless so meh.
 
mxlemming said:
The gate driver he has detects desat at 6.5V. Peters hasn't said what FETs he's using (has he?) but I'm going to assume that 2to247s have an Rdson of about 1-2mohms. So the desat kicks in at 3-6.5kA. I don't think 1) the FETs will be able to break this current 2) his battery can supply that current 3)I suspect in this case even with a microsecond FET/FET leg/PCB is going to vaporize anyway. So I seriously doubt the utility of the desat protection.

You put diodes in series or use a zener to alter the voltage at where it triggers. It works really well, I've designed many gate drives using this method, even with low 3mOhm MOSFETs.


Easily achievable in a few us with low side shunts, phase shunts maybe slightly slower. Maybe 5-10us?
Shunts aren't a very good solution on a controller which outputs hundreds of amps, and shunts should be as fast as the comparator.

PWM Inputs to gate drives can have a hardware lock out circuit added to improve reliability, some dual drivers have this built in, but most lack the other features like a clamp or desat.
This is already implemented in the stm timer, the gate driver or both. I don't see the point in piling more versions of it on.

The uC doesn't know that a PWM line got pulled high by an external fault between it and the gate drive. A setup pre gate drive would detect this.

Gate drivers should also have a Miller clamp (this feature is almost mandatory IMO) to force a low impedance path to ground on the gate of the device to mitigate Miller turn on effect. Power to the gate drivers should be isolated from the rest of the system through unregulated DC-DC converters to minimize noise into and out of the gate drivers and provide voltage isolation for safety. Connection of the gate driver to the power device should be made through a "Kelvin" style connection to gate-source to reduce noise from the power pass.
Miller turn on is a function entirely of the FET being used, and can therefore be easily avoided by picking the right FET. You simply don't need it for the more recent generations of MOSFET.

If only it was that easy. Clamping guarantees a low impedance path between gate and source vs just a pull down resistor. Remember we are trying to guarantee states are predictable. So many people underestimate how much an issue Miller Effect turn on can be, but they often find out.

The isolated power supply I get when you're playing with mains but for batteries? Hmmm. Unregulated is inviting other issues... At least clamp it... Feedback/regulation doesn't have to mess up your clean analog ground.

Unregulated is preferred as the regulation introduces additional circuitry which depends on feedback in a noisy environment and can potentially oscillate.

Kelly does like to blow up... So do VESCs... But they both have literally no protection whatsoever... I do wonder what causes the failures, is it inrush? Overheating? Crappy FETs ? Software crashes?

Mostly caused by layout decisions and not following design choices I discussed causes them to fail because people push them to hard for what they are.
 
That's a lot of power in a very small area. Looks really professional for home-etched circuit boards. :thumb:
For higher power levels you'll likely need more cooling - JB-welding a heatsink to the bottom of the case wouldn't be a bad idea.

I really like the layout of this. The next version of my controller will definitely do this as well; making my heatsink my structural base will make assembly much easier. Also horizontal FETs take up much less space than vertical ones.

zombiess said:
Technically speaking nothing causes desaturation in a MOSFET as it's an IGBT phenomenon, but the same detection circuit can work with a MOSFET. The desat detection of a gate drive is used because it can respond fast to a high current fault. As you probably know faults should be handled in multiple stages to ensure a fail safe state. Managing a shoot through event is about controlling energy dissipation. General rule of thumb is to detect the event and shut down in <5us. Most current sensors aren't going to respond fast enough for this type of event.
The current sensors I use in my design (MLX91220 - https://www.mouser.com/pdfDocs/MLX91220-Datasheet-Melexis.pdf) can detect a short circuit in 2 microseconds, which will result in the FET turning of in under 3 microseconds with hardware fault detection (no ISR). They are also a lot cheaper than the ACS758 (I think) that is currently being used. To detect higher currents, you just solder a heavy gauge copper wire in parallel with the sensor and use Ohm's law to calibrate. Thermal linearity should be pretty good in this case because the copper shunt and sensor are in close proximity and experience similar heating levels.
 
My FETs are IRFP4568 now with 2.5mOhm Rdson (2 parallel), but at high junction temperature it's double of that. The threshold is reduced with the zener diode, my desat current was 650A (or more, kiwifiat also asked it above), the 2 FETs can survive that for a few us, but I tried it only once on this board yet, because first I want to check the waveforms with a higher voltage zener.

DRV8301 on VESC also has this feature under the name "Overcurrent Protection and Reporting(OCP)" in the datasheet, I just don't know if it is set up from the firmware.
 
Back
Top