Non-silicon and/or soft-switched controller topologies?

[mxlemming]

You might look into laminated busbars. I've never used them because I've always been going smaller smaller smaller with ESCs, but user zombiess and some of the other old timers used to rave about them. The cool thing about them is that even if they're 100nH inductance, the +ve and-ve create the exact same magnetic field so when switching currents between them the inductance is effectively zero.

Essentially it's just a multi layer PCB with higher current capability. Power planes have very very low inductance.

100nH is quite a lot in terms of 3ns switching. Perhaps your ceramics at each node will take care of it, but I'd think carefully and do some math.

 

[ARod1993]

Thanks for the advice! I found the old thread about distributed controllers from 2014 where laminated busbars and the details of how to do clever low-inductance things came up (https://endless-sphere.com/forums/viewtopic.php?f=30&t=55641), and reorienting the half bridges slightly and using laminated busbar would be perfect

 

[zombiess]

Thanks for the advice! I found the old thread about distributed controllers from 2014 where laminated busbars and the details of how to do clever low-inductance things came up (https://endless-sphere.com/forums/viewtopic.php?f=30&t=55641), and reorienting the half bridges slightly and using laminated busbar would be perfect

ARod1993, it looks like this is going to be your first controller design. I'd suggest staying away from working with GaN devices until you better understand what is needed to design a reliable gate drive and power stage. The parts are pricey and you will most likely be making many mistakes along the way. Designing a high power GaN controller is jumping into the deep end of power electronics.

If you are interested in using a VESC as the controller, be aware that it has a switching speed limit of about 60kHz due to processor utilization.

I made this video last year which shows how switching frequency and motor current are related, you might find some of the information useful.

https://youtu.be/LcJCTB-6k2c

 

[mxlemming]

If you are interested in using a VESC as the controller, be aware that it has a switching speed limit of about 60kHz due to processor utilization.

Is that pwm frequency or switching frequency (centre aligned so switching frequency double)?

I'm inclined to agree with zombiess, if this is your first controller and you're making the control using custom FPGA you might consider burning some less expensive transistors and then once you've finished that rig up the 30$ a fet board...

But if you want to jump into the deep end, I won't discourage too much. Would be cool to have some ES GaN. I'm not aware of anyone else doing it.

 

[ARod1993]

Thanks for the advice! I found the old thread about distributed controllers from 2014 where laminated busbars and the details of how to do clever low-inductance things came up (https://endless-sphere.com/forums/viewtopic.php?f=30&t=55641), and reorienting the half bridges slightly and using laminated busbar would be perfect

ARod1993, it looks like this is going to be your first controller design. I'd suggest staying away from working with GaN devices until you better understand what is needed to design a reliable gate drive and power stage. The parts are pricey and you will most likely be making many mistakes along the way. Designing a high power GaN controller is jumping into the deep end of power electronics.

If you are interested in using a VESC as the controller, be aware that it has a switching speed limit of about 60kHz due to processor utilization.

I made this video last year which shows how switching frequency and motor current are related, you might find some of the information useful.

https://youtu.be/LcJCTB-6k2c

Thanks for the link and the video I have some experience doing this before; I built a simple trapezoidally commutated converter in a power electronics lab awhile back, and I have a little experience doing high power-ish board layout from work involving GaN devices being used for RF generation.

On the power side, I'm interested in trying to get a single half-bridge playing nicely as a first step (two FETs, a gate driver (preferably fully isolated), a Schmitt triggered inverter, an RS485 receiver, and a linear regulator if necessary, all on a small 2-3 square inch board), and seeing that work. From there making the power stage of a motor controller should be a matter of paralleling the half bridges to make phases and then combining three phases to make a full controller, with tons of bus capacitance and laminated busbars to reduce parasitic inductance to a minimum. Thankfully the price on the GaN FETs I'm looking at (the EPC2034C) isn't too bad, they're only about $8 per FET ($5-6 in bulk), and the gate drivers are $4ish in bulk, so the price isn't that much worse than a nice silicon controller but the capabilities are much better. I'm also interested in this because I'm interested in low-loss, high-frequency power conversion, and having complete working 200V 30A GaN half-bridges that cost around $30 each but are easy to integrate into other projects makes all sorts of other fun things possible (primarily super small power converters; the faster you switch the smaller your passives can be and so the more power you can throw around in a tiny package). I saw a power module at work today that I'd ordered for a project; 120V to 24V, 300W, isolated, in a 4" x 2" x 0.5" package; the only way I see that working is planar magnetics, wide bandgap semiconductors, and a ridiculous switching frequency (and I'd like to design more things like that)

As far as the brain is concerned, I was considering using an FPGA for the heavy lifting, with a microcontroller for passing in slower signals. The FPGA would be responsible for the Parke and Clark transforms, the SVPWM generation, and the PI controllers needed to generate actual motor torque. I'd probably use fast ADCs to bring the current sensor values directly into the FPGA, and then use the microcontroller primarily for throttle and temperature inputs, and for telemetry back out (system volts, phase RMS current, battery RMS current, system temperatures, etc). I'd probably test that with a little six-FET stage running a DRV8300 and six $1-each TO220 FETS before marrying it up to the nice GaN boards, to be honest (so on the off chance I #*&$ something up (which I probably will) it's not horrendously expensive).

 

[stepus]

Hi, I looked at the diagram and you will have always enabled gate driver ? How you will turn off both fets Hi and Low side ?
GaN is hard to keep cool. You cannot use Aluminium PCB so you can mount only heatsing on them, or run them many in paralel for extending the loss over a larger area.

 

[ARod1993]

Hi, I looked at the diagram and you will have always enabled gate driver ? How you will turn off both fets Hi and Low side ?
GaN is hard to keep cool. You cannot use Aluminium PCB so you can mount only heatsing on them, or run them many in paralel for extending the loss over a larger area.

It's possible to run the gate driver in IIM mode rather than PWM mode, and then do the deadtime management in the FPGA directly but using PWM mode with 20ns dead time should work pretty well. I'm also thinking about this in terms of how many signals I need to send to the half-bridge in order to get it to work well; I'm using inverted RS485 for the gate signal delivery (because differential signals carried in shielded twisted pair should be reasonably immune to EMI); I could go with something more complex so I could turn the FETs off independently in the event of a fault, but that's either another RS485 receiver and Schmitt inverter per half bridge, or some sort of clever serial-to-parallel setup on the far side that's gonna require bringing over a clock from the FPGA anyway. I'd be curious to hear what MxLemming, Zombiess, and HighHopes have to say about the relative merits of that sort of setup.

As far as heatsinking is concerned, the plan is to mount a heatsink atop the FETs using the manufacturer recommended heat spreader material (you can't use anything electrically conductive for thermal paste on the EPC2034Cs arranged this way because the die tops are at drain potential and not isolated), and leave space on the half bridge board for mounting points for that. According to the datasheets for the relevant materials you can get around 5C/W to air with a heatsink on the top, and then another 4C/W for a square inch of copper per device (which I'm probably not going to have because of the need to keep things tight and low-inductance); by the calculations I did at the start of this thread I'm expecting 7-10W total losses per device (6.3W conduction, 0.5-2W switching) if I run them at 30A (derated from 50A, but I wouldn't be surprised if 50A is datasheet KoolAid), so I'm expecting 3-4C/W rise, which comes out to 30-40C above nominal at full power.

 

[stepus]

EPC2034 is a very tiny, 4.6x2.6mm of contact area for transfering 10W of heat to heatsink. I think it's too small an area for such a large power distribution, probably you will need to use a copper heatsink. Driving gate drivers with symetric signal is good but i thing better will be solve EMI radiation rather than EMI imunity. If you will sell it as controller you will deal with EMI anyway. And i have never seen nothing so complicated in commonly sold controllers. In my stock surron controller they driving gate drivers over half the board from MCU, and another half from gate drivers to mosfets and it also works

 

[ARod1993]

EPC2034 is a very tiny, 4.6x2.6mm of contact area for transfering 10W of heat to heatsink. I think it's too small an area for such a large power distribution, probably you will need to use a copper heatsink. Driving gate drivers with symetric signal is good but i thing better will be solve EMI radiation rather than EMI imunity. If you will sell it as controller you will deal with EMI anyway. And i have never seen nothing so complicated in commonly sold controllers. In my stock surron controller they driving gate drivers over half the board from MCU, and another half from gate drivers to mosfets and it also works

That was part of why I was looking into laminated busbars for these things (or more likely just getting copper busbars from BigBlueSaw with the appropriate stubs for half-bridge and capacitor connections and then wrapping them in a layer of Kapton tape); by keeping the inductances between the busbars as low as possible I should be able to avoid throwing off a fuckton of EMI by switching quickly. PWM frequency dithering is also commonly used in SMPS's to cut down on noise, and might be a possibility (higher overall noise floor, but significantly reduced noise intensity) but I'm not sure how nice that's going to play with motor control applications.

I don't know how Sur-Ron does that; I assumed they were either insulating everything carefully or doing ridiculous things like emulating coax in PCB materials (run your gate drive traces on an inner trace with ground planes above and below, via stitch around the sides of the trace, and then control the trace impedances) to avoid accidental turn-on. I also remember hearing an old rule of thumb where 10kW or so was about the maximum power you could get away with suboptimal layout on, and above that point things that you can get away with at 2-3kW result in smoke and tears.

 

[zombiess]

I've done a lot of empirical testing on power dissipation in PCBs for my own designs and I'm pretty sure you will need to reduce your power dissipation to work at the size you are talking about, or figure out a better way to get rid of the heat / produce less of it.

I've found that a 4 layer 1.2mm thick PCB with 1oz outer and 0.5oz inner is able to handle about 0.66W/in^2 which resulted in a stabilized temperature of about 65C (for +30 mins), no cooling. This was on a 2.5x5" with current fed along the long path of the PCB. This was transferring 40A through the PCB, about 8W of dissipation. Dropping to 20A reduced the temperature to 43C.

On a different design, 3 layers of 3oz copper allowed me to pass 100A DC (for +30mins) with the PCB heating to about 60C through a 100mm wide 29mm long copper plane (4.5in^2). Measured resistance was about 100uOhms. 100A^2 * 100uOhms = 1W. 1W / 4.5in^2 = ~0.25W/in^2 (surprising result, isn't it?), it still had a bit of room to go, I eventually pushed 120A through this board but it was running about 70C so 0.33W/in^2.

Another 4 layer design with 1oz outer 0.5oz inner layers measuring 2.75in^2 (square PCB) producing ~1.7W of waste heat resulting in a PCB temp of 70C after 30mins. 1.7W/2.75in^2 = 0.62W/in^2

I've also experimented switching losses on standard Si devices for Fsw < 60kHz. I did not find any appreciable difference in heating time by doubling or tripling the switching frequency, however these tests were not done at thermal equilibrium.

In some buck / boost designs I've done I have seen substantial differences in heating by altering Fsw, but these have all used SMD devices in SO8FL sized packages.

While my results might be anecdotal, at no time was a PCB able to exceed 1W/in^2 in continuous use, even with heat sinking.

I^2*R losses typically dominate in a motor drive unless you try to switch at a high Fsw. Generally you only use as high of an Fsw as needed, this is often dictated by DC link ripple current which is dictated by motor inductance.

 

[ARod1993]

I've done a lot of empirical testing on power dissipation in PCBs for my own designs and I'm pretty sure you will need to reduce your power dissipation to work at the size you are talking about, or figure out a better way to get rid of the heat / produce less of it.

I've found that a 4 layer 1.2mm thick PCB with 1oz outer and 0.5oz inner is able to handle about 0.66W/in^2 which resulted in a stabilized temperature of about 65C (for +30 mins), no cooling. This was on a 2.5x5" with current fed along the long path of the PCB. This was transferring 40A through the PCB, about 8W of dissipation. Dropping to 20A reduced the temperature to 43C.

On a different design, 3 layers of 3oz copper allowed me to pass 100A DC (for +30mins) with the PCB heating to about 60C through a 100mm wide 29mm long copper plane (4.5in^2). Measured resistance was about 100uOhms. 100A^2 * 100uOhms = 1W. 1W / 4.5in^2 = ~0.25W/in^2 (surprising result, isn't it?), it still had a bit of room to go, I eventually pushed 120A through this board but it was running about 70C so 0.33W/in^2.

Another 4 layer design with 1oz outer 0.5oz inner layers measuring 2.75in^2 (square PCB) producing ~1.7W of waste heat resulting in a PCB temp of 70C after 30mins. 1.7W/2.75in^2 = 0.62W/in^2

I've also experimented switching losses on standard Si devices for Fsw < 60kHz. I did not find any appreciable difference in heating time by doubling or tripling the switching frequency, however these tests were not done at thermal equilibrium.

In some buck / boost designs I've done I have seen substantial differences in heating by altering Fsw, but these have all used SMD devices in SO8FL sized packages.

While my results might be anecdotal, at no time was a PCB able to exceed 1W/in^2 in continuous use, even with heat sinking.

I^2*R losses typically dominate in a motor drive unless you try to switch at a high Fsw. Generally you only use as high of an Fsw as needed, this is often dictated by DC link ripple current which is dictated by motor inductance.

Quick question; did you get those numbers with an external heatsink on the transistors you were switching? That is the one really annoying thing about SMT power parts; the heat path into the board is often the best path for device heat. I'm kind of tempted to try to make a heat pipe to sit on top of each transistor with an insulating mounting bracket and a tiny bit of Arctic Silver 5. At 30A, the expected conduction loss in an EPC2034C would be (30A)^2*8mOhm=7.2W, which is going to be hard to remove without doing something interesting, probably with heat pipes. I wonder if using four full layers of 2oz copper would help with the heat dissipation.

 

[zombiess]

Quick question; did you get those numbers with an external heatsink on the transistors you were switching? That is the one really annoying thing about SMT power parts; the heat path into the board is often the best path for device heat. I'm kind of tempted to try to make a heat pipe to sit on top of each transistor with an insulating mounting bracket and a tiny bit of Arctic Silver 5. At 30A, the expected conduction loss in an EPC2034C would be (30A)^2*8mOhm=7.2W, which is going to be hard to remove without doing something interesting, probably with heat pipes. I wonder if using four full layers of 2oz copper would help with the heat dissipation.

No heat sinks. Adding heat sinks helped a little, but not a whole lot unless I added forced air.

 

[ARod1993]

Quick question; did you get those numbers with an external heatsink on the transistors you were switching? That is the one really annoying thing about SMT power parts; the heat path into the board is often the best path for device heat. I'm kind of tempted to try to make a heat pipe to sit on top of each transistor with an insulating mounting bracket and a tiny bit of Arctic Silver 5. At 30A, the expected conduction loss in an EPC2034C would be (30A)^2*8mOhm=7.2W, which is going to be hard to remove without doing something interesting, probably with heat pipes. I wonder if using four full layers of 2oz copper would help with the heat dissipation.

No heat sinks. Adding heat sinks helped a little, but not a whole lot unless I added forced air.

Thanks! Completely unrelated question; what bit depth did you use for PWM on your custom controller, and what's the minimum bit depth you recommend? The Zynq platform I'm looking to use to do the control design on has a maximum clock speed of 780 MHz if I buy the high-speed grade parts; if I want 200kHz center-aligned (100kHz switching) PWM my maximum bit depth is likely around 11 bits (that would give me 2048 possible duty cycles to command), and as PWM frequency went up from there bit depth would go down linearly.

 

[zombiess]

Thanks! Completely unrelated question; what bit depth did you use for PWM on your custom controller, and what's the minimum bit depth you recommend? The Zynq platform I'm looking to use to do the control design on has a maximum clock speed of 780 MHz if I buy the high-speed grade parts; if I want 200kHz center-aligned (100kHz switching) PWM my maximum bit depth is likely around 11 bits (that would give me 2048 possible duty cycles to command), and as PWM frequency went up from there bit depth would go down linearly.

I did not write any motor control code on my designs, I always used someone else's, Lebowski, TI Instaspin and VESC. My main focus has been on gate drive and power stage development as I'm a bit obsessed with parallelization and high currents (+1kA). The closest I've come is simulating stuff in Matlab Simulink for a single phase inverter. It taught me a lot about propagation delay, dead time distortion / correction, PWM schemes and cascade PI controller design/tuning.

Wish I had time to play with FPGA's and controller design, but I can't do everything I want I've also been interested in working with some GaN MOSFETs, but I'm deep into two design projects for the last year which will hopefully come to market this year.

BTW, forget the RS485, you don't need it. If you want to use differential PWM it can be done with transformers or optos triggering the gate driver, works super awesome. You most likely don't need it, but I design it in if my gate drive choice allows it as it's like 10¢ worth of parts per gate drive to implement it. Feed that to a hardware PWM interlock and you end up with a rock solid PWM.

What is your justification on using GaN and high Fsw? Is this a just for a fun project / learning? Building a good gate drive and power stage is non trivial and often error prone in the early stages. Remember that you should keep your propagation delay to <5% of your PWM period if you want to minimize harmonic effects... if that matters to you.

 

[ARod1993]

Thanks! Completely unrelated question; what bit depth did you use for PWM on your custom controller, and what's the minimum bit depth you recommend? The Zynq platform I'm looking to use to do the control design on has a maximum clock speed of 780 MHz if I buy the high-speed grade parts; if I want 200kHz center-aligned (100kHz switching) PWM my maximum bit depth is likely around 11 bits (that would give me 2048 possible duty cycles to command), and as PWM frequency went up from there bit depth would go down linearly.

I did not write any motor control code on my designs, I always used someone else's, Lebowski, TI Instaspin and VESC. My main focus has been on gate drive and power stage development as I'm a bit obsessed with parallelization and high currents (+1kA). The closest I've come is simulating stuff in Matlab Simulink for a single phase inverter. It taught me a lot about propagation delay, dead time distortion / correction, PWM schemes and cascade PI controller design/tuning.

Wish I had time to play with FPGA's and controller design, but I can't do everything I want I've also been interested in working with some GaN MOSFETs, but I'm deep into two design projects for the last year which will hopefully come to market this year.

BTW, forget the RS485, you don't need it. If you want to use differential PWM it can be done with transformers or optos triggering the gate driver, works super awesome. You most likely don't need it, but I design it in if my gate drive choice allows it as it's like 10¢ worth of parts per gate drive to implement it. Feed that to a hardware PWM interlock and you end up with a rock solid PWM.

What is your justification on using GaN and high Fsw? Is this a just for a fun project / learning? Building a good gate drive and power stage is non trivial and often error prone in the early stages. Remember that you should keep your propagation delay to <5% of your PWM period if you want to minimize harmonic effects... if that matters to you.

Honestly, I'm using GaN and high Fsw as much to get the hang of working with GaN and high-frequency switching for future power converter designs as anything else; I also am really interested in using an Emrax motor to build an EV with, but the resistance and inductance are low enough that I assume I'd need pretty high Fsw to provide a reasonable amount of current ripple when driving it (7.5uH and 1 milliohm), and once I took a look at losses trying to run conventional silicon that fast and realized that GaN parts are getting steadily cheaper I figured I'd take a crack at working with GaN for efficiency and personal growth reasons (also SiC is still like $20 a FET for 15-20mOhm devices)

 

[zombiess]

Honestly, I'm using GaN and high Fsw as much to get the hang of working with GaN and high-frequency switching for future power converter designs as anything else; I also am really interested in using an Emrax motor to build an EV with, but the resistance and inductance are low enough that I assume I'd need pretty high Fsw to provide a reasonable amount of current ripple when driving it (7.5uH and 1 milliohm), and once I took a look at losses trying to run conventional silicon that fast and realized that GaN parts are getting steadily cheaper I figured I'd take a crack at working with GaN for efficiency and personal growth reasons (also SiC is still like $20 a FET for 15-20mOhm devices)

I plugged the 7.5uH @ 150V DC link into the formula to calculate ripple current from DC link capacitor. At 50kHz Fsw there is a 70A (RMS) ripple current needed from the DC link. This is a worst case scenario which is calculated at 50% duty cycle. At 100kHz this drops by half to 35A. At 50kHz it needs a minimum of 100uF of DC link which would provide a ripple voltage of 1.7%.

This looks like a fun motor which could do bursts of 150kW 8)

 

[ARod1993]

Honestly, I'm using GaN and high Fsw as much to get the hang of working with GaN and high-frequency switching for future power converter designs as anything else; I also am really interested in using an Emrax motor to build an EV with, but the resistance and inductance are low enough that I assume I'd need pretty high Fsw to provide a reasonable amount of current ripple when driving it (7.5uH and 1 milliohm), and once I took a look at losses trying to run conventional silicon that fast and realized that GaN parts are getting steadily cheaper I figured I'd take a crack at working with GaN for efficiency and personal growth reasons (also SiC is still like $20 a FET for 15-20mOhm devices)

I plugged the 7.5uH @ 150V DC link into the formula to calculate ripple current from DC link capacitor. At 50kHz Fsw there is a 70A (RMS) ripple current needed from the DC link. This is a worst case scenario which is calculated at 50% duty cycle. At 100kHz this drops by half to 35A. At 50kHz it needs a minimum of 100uF of DC link which would provide a ripple voltage of 1.7%.

This looks like a fun motor which could do bursts of 150kW 8)

The EMRAX 208 is beautiful; it's 68kW peak, 25-40kW continuous, 58rpm/V, claims 400A continuous and 800A 2 min burst rating, and it's only 20lbs. It's basically a giant (208mm diameter, 85mm length) axial flux outrunner, and I'd like to build a three-wheeled vehicle around it (one in back, two in front, mostly because that way I can license it as a motorcycle).

My current plan is to design the motor controller, then design an LTC3300/6804-based BMS for the pack, design a charger for the pack (PFC boost to some sort of resonant converter most likely; Cree had an awesome eval board that used a bidirectional PFC and an LLC-based dual active bridge to charge car packs off 208 line voltage and the combo apparently hit 96-97% efficiency), and then get the frame design out of Solidworks and into real life.

I got stuck on this idea because people on Endless-Sphere brought the EMRAX motors up before, and the consensus I'd seen was "They're amazing, but lol good luck controlling them", so I figured an FPGA-based controller using wide-bandgap semiconductors would be able to maintain a high enough switching frequency to make them controllable for my purposes Also, if I get this working, then TheCoco974 could use a smaller one to drive his higher-power axial flux motor

 

[mxlemming]

If you follow zombiess advice, you'll definitely end up with something that works well and reliably. He does this for money I believe, he has a strong interest in making things that work and don't fail.

But that's not much interest to me. I would rather see you fail and learn a whole load than succeed with a fairly standard controller, because I do this entirely for the lolz. My last job was dull as hell, i started this to prevent my brain turning into a potato.

I vote... You've been warned of the risks, you know the cost... Do the GaN.

Now... To your questions...

Bit depth isn't hugely critical for a motor driver generally, since the non sinusoidal ness of the motor will massively dominate the errors from bit depth. High bit depth is important for audio and precision power conversion, not this. I run my code at 1024 ARR/ 10 bit. Honestly, i don't think it would run any worse with half that.

Since you're playing with GaN and FPGA, you might want a bit more but 2048 is plenty.

Do you know the bemf profile of the emrax? Unless it's sinusoidal, FOC might not even be relevant/ and possibly less efficient. Non sinusoidal motors end up hammering the Id->Vd control loops and result in large useless currents heating the motor. Square wave motors I have found in great detail are better controlled with Square wave control and more optimally yet a hysteresis controller with phase quenching/fast decay at the turn off.

100khz Fsw is perfectly feasible with<1% loss in silicon. Switching times of 50ns can be attained so 50/10000ns is the time spent switching as a proportion, with 50% loss... That's only 0.25%.

An lm5017 switches at about 400khz, that's silicon.

So if you're doing GaN, target much faster.

Regarding the rs485, if you're running separate phase boards, you'll need some kind of noise immunity. This can come from isolated gate drivers, differential signalling or other... But you'll need it when you start throwing huge currents at 100khz on 3 separate boards.

Personally I prefer to sidestep this by using 1 board with a solid ground plane and broadly separate/highly localised power ground. The surron manages this by switching slowly and having a single power board... Very little power flows between the power and logic boards.

Regarding the ability to turn all phases to high impedance, this is essential. If it takes more rs485, isolation, whatever... You'll have to do it, and it can't afford to be flaky, have glitches etc.

 

[mxlemming]

Further to the turning it off and floating all phases, the first thing I'd implement in code is to every single pwm cycle measure the bus voltage and turn it off instantly if the bus rises to the Vddmax of the FETs. Better yet, you might consider doing this with a comparator and latching it.

Over current failures are generally slow, you get a chance to survive them through PID loop, current limiting power supply etc. Over voltage failure from e.g regen into a power supply or BMS turning off is instant failure of the FETs.

 

[zombiess]

If you follow zombiess advice, you'll definitely end up with something that works well and reliably. He does this for money I believe, he has a strong interest in making things that work and don't fail.

But that's not much interest to me. I would rather see you fail and learn a whole load than succeed with a fairly standard controller, because I do this entirely for the lolz. My last job was dull as hell, i started this to prevent my brain turning into a potato.

I vote... You've been warned of the risks, you know the cost... Do the GaN.

Warning, I'm getting meta here.
As mxlemming has noticed, I put heavy emphasis on making stuff reliable, because I like to push the limits. I only want to ride the struggle bus for as short a time as possible. There is a HUGE difference between making something that works on the bench vs something that goes to market. I HATE doing rework and if I'm going to sell something, I want it to be reliable.

I always recommend people start simple with power electronics and build something that is likely to work before getting too experimental, but to each, their own. Failure is the ultimate teacher, I love try storming / iterative prototyping, I fail a lot.

Further to the turning it off and floating all phases, the first thing I'd implement in code is to every single pwm cycle measure the bus voltage and turn it off instantly if the bus rises to the Vddmax of the FETs. Better yet, you might consider doing this with a comparator and latching it.

Best practice is to handle a fault in hardware first because it's faster and more reliable than software, but also signal the software to shut down. A comparator plus latched shut down is nice to have.

Over current failures are generally slow, you get a chance to survive them through PID loop, current limiting power supply etc. Over voltage failure from e.g regen into a power supply or BMS turning off is instant failure of the FETs.

Shoot through events are extremely fast over current events which can be addressed by selection of a good gate drive, but it's also good to have hardware + software over current protection to handle the more common slower events. I like to do both when I can.

Short shoot through test, I love how effective the protection is.
https://youtu.be/bvqAEGtAvEM

All this talk about GaN has caused me to give it a go myself. I have a 130V to 24V buck converter I designed for powering my controllers off the traction pack, but it's only about 90% efficient and produces over a watt of waste heat which is quite difficult to get rid of. I already have a working design, so now I'm going to tweak it for use with GaN devices so I can do a comparison. Hopefully it allows me to shrink my design size. A buck converter is pretty simple to design, but it took me multiple revisions (six I think?) to get to the design I have now. Thermal management turned out to be WAY more difficult than I anticipated. I killed about 15 controller chips while learning from various screw ups.

Bit depth isn't hugely critical for a motor driver generally, since the non sinusoidal ness of the motor will massively dominate the errors from bit depth. High bit depth is important for audio and precision power conversion, not this. I run my code at 1024 ARR/ 10 bit. Honestly, i don't think it would run any worse with half that.

I'm not as advanced in software design as you two, but one way to think about the control problem is by asking "what is my limiting factor". In this application, it's probably going to be the motor itself. The motor acts as a mechanical low pass filter, so then the question is how fast can the motor accelerate. Your worst case would be an unloaded motor. Is there an advantage to controlling a motor with micro second precision if the motor takes 100ms to start accelerating to what the controller commanded? <-- serious question

 

[zombiess]

Darn it. My exploration into GaN is being thwarted because Coss losses dominate my device selection. My current Si part works better than most parts I'm finding.

 

[ARod1993]

If you follow zombiess advice, you'll definitely end up with something that works well and reliably. He does this for money I believe, he has a strong interest in making things that work and don't fail.

But that's not much interest to me. I would rather see you fail and learn a whole load than succeed with a fairly standard controller, because I do this entirely for the lolz. My last job was dull as hell, i started this to prevent my brain turning into a potato.

I vote... You've been warned of the risks, you know the cost... Do the GaN.

Now... To your questions...

Bit depth isn't hugely critical for a motor driver generally, since the non sinusoidal ness of the motor will massively dominate the errors from bit depth. High bit depth is important for audio and precision power conversion, not this. I run my code at 1024 ARR/ 10 bit. Honestly, i don't think it would run any worse with half that.

Since you're playing with GaN and FPGA, you might want a bit more but 2048 is plenty.

Do you know the bemf profile of the emrax? Unless it's sinusoidal, FOC might not even be relevant/ and possibly less efficient. Non sinusoidal motors end up hammering the Id->Vd control loops and result in large useless currents heating the motor. Square wave motors I have found in great detail are better controlled with Square wave control and more optimally yet a hysteresis controller with phase quenching/fast decay at the turn off.

100khz Fsw is perfectly feasible with<1% loss in silicon. Switching times of 50ns can be attained so 50/10000ns is the time spent switching as a proportion, with 50% loss... That's only 0.25%.

An lm5017 switches at about 400khz, that's silicon.

So if you're doing GaN, target much faster.

Regarding the rs485, if you're running separate phase boards, you'll need some kind of noise immunity. This can come from isolated gate drivers, differential signalling or other... But you'll need it when you start throwing huge currents at 100khz on 3 separate boards.

Personally I prefer to sidestep this by using 1 board with a solid ground plane and broadly separate/highly localised power ground. The surron manages this by switching slowly and having a single power board... Very little power flows between the power and logic boards.

Regarding the ability to turn all phases to high impedance, this is essential. If it takes more rs485, isolation, whatever... You'll have to do it, and it can't afford to be flaky, have glitches etc.

The Emrax is sinusoidal (at least according to Page 5 of the manual), so FOC seems to make the most sense.

I'm curious how you're doing that switching loss calculation; the way they showed in undergrad was to assume that for a very brief period of time the device sees full voltage and full current, and then use the turn-on and turn-off times to calculate loss (assuming a linear rise and fall during the switching interval), and then add the Coss losses; this app note gives something similar but slightly different. If I use the app note's method then the EPC2034C at 30 A gives (Vin*Iout*Fsw*(Qgd+Qgs)/Igd) = 120V*30A*100kHz*(5.8nC)/1.5A = 1.4W, while the IRFP4668 at 100A gives 120V*100A*100kHz*106nC/5A = 25.44W, so an equivalent figure of merit per amp would be 0.03W/A vs 0.25W/A at 100kHz. Conduction losses are about even (because both devices have 8mOhm Rdson), so in theory I could run the GaN devices up to 1MHz for equivalent losses; the issue is gonna be getting the heat out of the GaN package at that point.

As far as isolation and phase-by-phase control is concerned; I'd probably want to switch to the ADUM4221A for gate driving because it has two independent inputs, and so I can force both inputs low if I need to (also it's internally isolated, so I could bring over input +5V, input GND, and the two PWM signals over from the control board if I so chose The chip apparently has an anti-shoot through thing such that if you slam both inputs high at the same time it won't drive them both at once, but it's possible to pull both inputs low if you need to slam everything high impedance on a few nanosecond timescale.

If you follow zombiess advice, you'll definitely end up with something that works well and reliably. He does this for money I believe, he has a strong interest in making things that work and don't fail.

But that's not much interest to me. I would rather see you fail and learn a whole load than succeed with a fairly standard controller, because I do this entirely for the lolz. My last job was dull as hell, i started this to prevent my brain turning into a potato.

I vote... You've been warned of the risks, you know the cost... Do the GaN.

Warning, I'm getting meta here.
As mxlemming has noticed, I put heavy emphasis on making stuff reliable, because I like to push the limits. I only want to ride the struggle bus for as short a time as possible. There is a HUGE difference between making something that works on the bench vs something that goes to market. I HATE doing rework and if I'm going to sell something, I want it to be reliable.

I always recommend people start simple with power electronics and build something that is likely to work before getting too experimental, but to each, their own. Failure is the ultimate teacher, I love try storming / iterative prototyping, I fail a lot.

Further to the turning it off and floating all phases, the first thing I'd implement in code is to every single pwm cycle measure the bus voltage and turn it off instantly if the bus rises to the Vddmax of the FETs. Better yet, you might consider doing this with a comparator and latching it.

Best practice is to handle a fault in hardware first because it's faster and more reliable than software, but also signal the software to shut down. A comparator plus latched shut down is nice to have.

Over current failures are generally slow, you get a chance to survive them through PID loop, current limiting power supply etc. Over voltage failure from e.g regen into a power supply or BMS turning off is instant failure of the FETs.

Shoot through events are extremely fast over current events which can be addressed by selection of a good gate drive, but it's also good to have hardware + software over current protection to handle the more common slower events. I like to do both when I can.

Short shoot through test, I love how effective the protection is.
https://youtu.be/bvqAEGtAvEM

All this talk about GaN has caused me to give it a go myself. I have a 130V to 24V buck converter I designed for powering my controllers off the traction pack, but it's only about 90% efficient and produces over a watt of waste heat which is quite difficult to get rid of. I already have a working design, so now I'm going to tweak it for use with GaN devices so I can do a comparison. Hopefully it allows me to shrink my design size. A buck converter is pretty simple to design, but it took me multiple revisions (six I think?) to get to the design I have now. Thermal management turned out to be WAY more difficult than I anticipated. I killed about 15 controller chips while learning from various screw ups.

Bit depth isn't hugely critical for a motor driver generally, since the non sinusoidal ness of the motor will massively dominate the errors from bit depth. High bit depth is important for audio and precision power conversion, not this. I run my code at 1024 ARR/ 10 bit. Honestly, i don't think it would run any worse with half that.

I'm not as advanced in software design as you two, but one way to think about the control problem is by asking "what is my limiting factor". In this application, it's probably going to be the motor itself. The motor acts as a mechanical low pass filter, so then the question is how fast can the motor accelerate. Your worst case would be an unloaded motor. Is there an advantage to controlling a motor with micro second precision if the motor takes 100ms to start accelerating to what the controller commanded? <-- serious question

As far as shoot through is concerned, what's your recommended way for detecting and surviving that? I figured that bus input current would spike and you'd see it on the DC bus, but I don't know if that would be fast enough to save everything.

 

[zombiess]

As far as shoot through is concerned, what's your recommended way for detecting and surviving that? I figured that bus input current would spike and you'd see it on the DC bus, but I don't know if that would be fast enough to save everything.

A gate drive which is able to detect it and take action. But I've never worked with GaN so I'm unfamiliar with gate drivers used with them. Something on the DC bus would probably be too slow to take action, generally you need to shut down as quickly within 5us (sometimes a two level off if using an IBGT to prevent a large overshoot). Shoot through can be induced from miller turn on, so gate drives often use a clamp or negative voltage bias. GaN devices usually have a pretty low threshold for Vgs(th) and I don't know if a clamp would work well at high switching frequency, but negative bias also works well if it's an issue.

 

[marcos]

There are zero GaN gate drivers out there with desat detection or similar so I can't think of a way of protecting a GaN controller from a phase short for example. They are ok when the switching node doesn't leave the pcb like a dc/dc converter (I made a few), but I would never use GaN if the half bridge output leaves the board. They are also very difficult to parallel for higher current.

With SiC on the other hand you have plenty of options with SiC-rated desat, miller clamp, and negative gate drive. Having seen <3uH motors being driven by Si at 30kHz makes it difficult for me to see why would you want to aim for something like 100kHz in a motor drive. The only application I can imagine is extremely fast eRPM. Even at 25kHz you can improve power density a lot when you compare it with an efficiency targeted controller.

 

[mxlemming]

There are zero GaN gate drivers out there with desat detection or similar so I can't think of a way of protecting a GaN controller from a phase short for example. They are ok when the switching node doesn't leave the pcb like a dc/dc converter (I made a few), but I would never use GaN if the half bridge output leaves the board

Why not a phase shunt/other current measurement and a comparator? That could be made to trip within 1-2us, which would almost certainly protect from phase dead short.

Shoot through (this is an area where me, Marcos and Zombies are in some contention) I think you can manage by having gate drives that enforce dead time and no high/low both on condition and by making sure your FETs are chosen to have low enough miller capacitance that the miller cannot turn the FET on. Beyond that, I think you have a dead board that's shorting something open anyway and all bets are off/your next line of protection is a proper case that stops conductive fluff from getting on your board.

But my GaN inverter experiance is limited to reading a few appnotes and thinking hard about it, so meh. The big semiconductor companies seem to have voted in favour of no desat. This may be because desat requires blanking and managing the ringing (normally invisibly inside the gate drive chip) that would be very very hard at MHz switching speed.

They are also very difficult to parallel for higher current.

Why so? Is this because of the propogation delay and matching to the gates? Or because they are not positive Rdson with temperature? or lack of sufficiently weighty gate drivers to power many? Or other...?

I'm curious how you're doing that switching loss calculation; the way they showed in undergrad was to assume that for a very brief period of time the device sees full voltage and full current, and then use the turn-on and turn-off times to calculate loss (assuming a linear rise and fall during the switching interval), and then add the Coss losses;

My calc was just assuming full V full I dropped resistively across the FETs in a 50ns switching time. During this, the average V is half the full V, so there's a factor of 1/2.

I then just compare the time switching to the time fully conducting (10000ns = 100khz, 50ns switch time). To get a %, you don't even need to plug any V and I in, because they cancel out in the eficiency calc.

I ignore the Coss and Ciss losses because they do not scale with power converted; they are a constant overhead.