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

mxlemming said:
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.

A phase shunt + comparator could work, but I don't know how sensitive GaN devices are to overload. Si devices handle it quite well, but from what I've read and heard, GaN design takes more finess. Unfortunately, I don't have experience. Down side with phase shunts is power dissipation, but in a low power application they could work. Catch a shoot through event is a last chance safety net which hopefully never happens because everything else has been designed to prevent the scenario from occurring. However external events such as mechanical wear on phase wires causing a short happen unexpectedly. It's nice if the controller doesn't plasma ball until the fault can be cleared.

The suggestions Marcos and I make are usually to quicken others path to success in a deceivingly complicated field, I'm still learning new stuff on a regular basis and I've been at it since 2011. Design choices come down to the designers risk appetite, but often times designers don't understand the risks and therefore don't properly rank them.
 
zombiess said:
mxlemming said:
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.

A phase shunt + comparator could work, but I don't know how sensitive GaN devices are to overload. Si devices handle it quite well, but from what I've read and heard, GaN design takes more finess. Unfortunately, I don't have experience. Down side with phase shunts is power dissipation, but in a low power application they could work. Catch a shoot through event is a last chance safety net which hopefully never happens because everything else has been designed to prevent the scenario from occurring. However external events such as mechanical wear on phase wires causing a short happen unexpectedly. It's nice if the controller doesn't plasma ball until the fault can be cleared.

The suggestions Marcos and I make are usually to quicken others path to success in a deceivingly complicated field, I'm still learning new stuff on a regular basis and I've been at it since 2011. Design choices come down to the designers risk appetite, but often times designers don't understand the risks and therefore don't properly rank them.

The EPC2034C GaN FETs are apparently not terribly sensitive; they're rated to 50A continuous, but they're rated to like 215A pulsed for 300uS (so you can probably get away with a nasty pulse briefly if something happens); I found an interesting paper on desaturation detection in parallel GaN, and a gate driver that looks like I could make both desaturation detection and GaN work on it; the STGAP1AS is the successor to a device I found in a master's thesis that included discussion of desaturation detection for GaN (the device named in the thesis has been obsoleted, so I went hunting for a successor). I might take another crack at the layout using the STGAP1AS and see if I can't get the desat detector in the paper to play nice with that driver.
 
Also I just discovered these: https://gansystems.com/gan-transistors/gs-065-150-1-d/ For big-boy inverters they look amazing, although the datasheet is behind an NDA wall and I think they're still figuring out packaging for the dies.
 
Stgap chip you linked looks like it won't work with your FETs since the uvlo values can't be set to acceptable levels for the GaN. It looks like an excellent chip for igbt.

I'm always sceptical of anything behind an NDA wall. It's like oooh look we might have some magic sauce... Then they sucker big companies in who commit to some stuff and get stuck onto some proprietary crap not realising they can buy better next day from mouser... If it worked, why wouldn't they just sell it and make money like st, on semi etc.

Incidentally, the VESC i made has been running FOC at the standard 30khz switching (15khx pwm)on a 6uH (six) motor with 70V... The ripple is nasty and at high currents it trips the hardware over current but... 6uH... Even less convinced you need GaN for the axial flux motor you were talking about.
 
Fair point, and that's a whole lot better than I expected; at that point I might just do my first controller with TO-leadless FETs and run 100kHz center-aligned (50kHz switching) PWM. On that note, how exactly does one do third-harmonic injection? My understanding is that you're basically predistorting the waveform you feed into the motor at super high power (when the native waveform the controller outputs starts to become trapezoidal); is there an easy way to figure out how much you're supposed to run at which power levels, and when you add it in? My first thought would be to generate the third harmonic post-inverse Park transform and pre-inverse Clark transform, and then do the vector sum before feeding it into the SVPWM module.
 
ARod1993 said:
On that note, how exactly does one do third-harmonic injection? My understanding is that you're basically predistorting the waveform you feed into the motor at super high power (when the native waveform the controller outputs starts to become trapezoidal); is there an easy way to figure out how much you're supposed to run at which power levels, and when you add it in? My first thought would be to generate the third harmonic post-inverse Park transform and pre-inverse Clark transform, and then do the vector sum before feeding it into the SVPWM module.

SVPWM and third harmonic injection are not to be used together, they're either-or methods, and their utility is mainly to increase the useable voltage range.

I tried to get third harmonic injection working, but it was tricky. I think you need to know the phase angle of the resulting Va&Vb as well as the rotor angle, at least... I found no way to inject it except after the Clark transform... The Clark doesn't play nicely with sin(3x) terms. It's a very simple algorithm for injecting it onto a basic sinusoidal inverter, but a PITA for FOC.

SVPWM is AKA midpoint clamp. You take the Clarke output and subtract the average of the most extreme values. You don't strictly need to do the inverse Clarke, if you crunch the matrix math, you can get expressions for each sector in terms of the Va and Vb terms (which is what you'll see in most appnotes), but all this gains you is confusion and saving a few clock cycles.

The other option is top or bottom clamp which has the advantage of less switching loss and simplest implementation but the disadvantage of more heavily loading the top or bottom side FETs and gaining errors due to the minimum on time of the gate drivers. I opted for this option, but using pure sinusoidal modulation until moderate duty cycles where it switches over, which makes for a smoother start and once the motor is rotating, the FETs are more evenly loaded.

SVPWM is the generally accepted standard. The easiest to understand implementation I've seen is stancecoke's lishuiFOC.
 
mxlemming said:
ARod1993 said:
On that note, how exactly does one do third-harmonic injection? My understanding is that you're basically predistorting the waveform you feed into the motor at super high power (when the native waveform the controller outputs starts to become trapezoidal); is there an easy way to figure out how much you're supposed to run at which power levels, and when you add it in? My first thought would be to generate the third harmonic post-inverse Park transform and pre-inverse Clark transform, and then do the vector sum before feeding it into the SVPWM module.

SVPWM and third harmonic injection are not to be used together, they're either-or methods, and their utility is mainly to increase the useable voltage range.

I tried to get third harmonic injection working, but it was tricky. I think you need to know the phase angle of the resulting Va&Vb as well as the rotor angle, at least... I found no way to inject it except after the Clark transform... The Clark doesn't play nicely with sin(3x) terms. It's a very simple algorithm for injecting it onto a basic sinusoidal inverter, but a PITA for FOC.

SVPWM is AKA midpoint clamp. You take the Clarke output and subtract the average of the most extreme values. You don't strictly need to do the inverse Clarke, if you crunch the matrix math, you can get expressions for each sector in terms of the Va and Vb terms (which is what you'll see in most appnotes), but all this gains you is confusion and saving a few clock cycles.

The other option is top or bottom clamp which has the advantage of less switching loss and simplest implementation but the disadvantage of more heavily loading the top or bottom side FETs and gaining errors due to the minimum on time of the gate drivers. I opted for this option, but using pure sinusoidal modulation until moderate duty cycles where it switches over, which makes for a smoother start and once the motor is rotating, the FETs are more evenly loaded.

SVPWM is the generally accepted standard. The easiest to understand implementation I've seen is stancecoke's lishuiFOC.

Ahhhhh, that makes a lot of sense; my initial thought process was to take the inverse Park output, put it in mag/phase form, vector-add a small component at 3x the angle, and then use that vector to drive the SVPWM setup, but that may not work so well depending on the motor back-EMF shape and rotor position.
 
ARod1993 said:
Ahhhhh, that makes a lot of sense; my initial thought process was to take the inverse Park output, put it in mag/phase form, vector-add a small component at 3x the angle, and then use that vector to drive the SVPWM setup, but that may not work so well depending on the motor back-EMF shape and rotor position.

If you have mag/phase form available (i didn't, you have to do arctangent calcs cycle by cycle) it's perfectly reasonable and much easier to do this, but you might have to inject after the inverse Clarke. Since Va= kVu, the mag and phase is useable either side of the inverse Clarke, just from memory the Clark didn't play nicely with it... The alpha-beta components are 90 degrees apart and the 3-phase is 120 apart so... Where would you inject in alpha beta?

But it was many months since I tried... And I didn't try especially hard. Do share if you're successful.
 
mxlemming said:
ARod1993 said:
Ahhhhh, that makes a lot of sense; my initial thought process was to take the inverse Park output, put it in mag/phase form, vector-add a small component at 3x the angle, and then use that vector to drive the SVPWM setup, but that may not work so well depending on the motor back-EMF shape and rotor position.

If you have mag/phase form available (i didn't, you have to do arctangent calcs cycle by cycle) it's perfectly reasonable and much easier to do this, but you might have to inject after the inverse Clarke. Since Va= kVu, the mag and phase is useable either side of the inverse Clarke, just from memory the Clark didn't play nicely with it... The alpha-beta components are 90 degrees apart and the 3-phase is 120 apart so... Where would you inject in alpha beta?

But it was many months since I tried... And I didn't try especially hard. Do share if you're successful.

This is where I think doing the whole thing on the FPGA gives me an edge; I can create extra CORDIC modules, and if I do it right I can get them completing in 30-40 clock cycles, which means that I can probably make this work given the 700ish MHz internal clock on the FPGA. If I'm understanding this correctly, in one PWM cycle I need to do the following things:

-Measure back EMF on all three phases
-Estimate rotor position and velocity from back EMF
-Sample phase currents
-Park transform
-Clarke transform
-New current command (PI controller update)
-Inverse Park transform
-Rectangular to polar conversion of current vector
-Third harmonic calculation
-Polar to rectangular conversion of current vector
-Polar to rectangular conversion of third harmonic vector
-Vector addition of current and third harmonic vectors
-Rectangular to polar conversion of vector sum
-SVPWM calculation

If I run at 100kHz center-aligned PWM, and the max clock frequency on the FPGA is 700MHz, I have about 7000 clock cycles to do all of that. I think this might actually be possible to do that way if I get the individual modules designed properly.
 
-Measure back EMF on all three phases
-Estimate rotor position and velocity from back EMF
-Sample phase currents
-Park transform
-Clarke transform
-New current command (PI controller update)
-Inverse Park transform
-Rectangular to polar conversion of current vector
-Third harmonic calculation
-Polar to rectangular conversion of current vector
-Polar to rectangular conversion of third harmonic vector
-Vector addition of current and third harmonic vectors
-Rectangular to polar conversion of vector sum
-SVPWM calculation
Firstly, check absolute phase current and voltage are within limits what shut down.

BEMF has to be estimated, you can't measure it directly since the pwm pulls high or low at all times. BEMF=Vpwm-IR -Ldi/dt then apply some loop filter, integrator, pll... You choose.
-Park transform
-Clarke transform
-New current command (PI controller update)
-Inverse Park transform
All correct

Third harmonic OR SVPWM. Not both, so next...

SVPWM calc

Or
-Rectangular to polar conversion of current vector
-Third harmonic calculation
-Polar to rectangular conversion of current vector
-Polar to rectangular conversion of third harmonic vector
-Vector addition of current and third harmonic vectors
-Rectangular to polar conversion of vector sum

I think the vector addition of thd and voltage vector (not current vector! That disappeared in the PID loop!) Might need to happen in polar coordinates, and you may have to do inverse Clarke before thd addition so...


-Rectangular to polar conversion of voltage vector in VaVb frame
-Third harmonic calculation
-Inverse Clarke in rectangular frame
-Add thd to the sinusoids generated by inverse Clarke
-Write the pwm to hardware, no SVPWM required

7000 clock cycles is masses to do this, especially if you have CORDIC and/or FPU. I'm doing it in much less than 2048 clock cycles, without BEMF observer (using a pll on the halls) and using bottom clamp not SVPWM or THD.
 
mxlemming said:
-Measure back EMF on all three phases
-Estimate rotor position and velocity from back EMF
-Sample phase currents
-Park transform
-Clarke transform
-New current command (PI controller update)
-Inverse Park transform
-Rectangular to polar conversion of current vector
-Third harmonic calculation
-Polar to rectangular conversion of current vector
-Polar to rectangular conversion of third harmonic vector
-Vector addition of current and third harmonic vectors
-Rectangular to polar conversion of vector sum
-SVPWM calculation
Firstly, check absolute phase current and voltage are within limits what shut down.

BEMF has to be estimated, you can't measure it directly since the pwm pulls high or low at all times. BEMF=Vpwm-IR -Ldi/dt then apply some loop filter, integrator, pll... You choose.
-Park transform
-Clarke transform
-New current command (PI controller update)
-Inverse Park transform
All correct

Third harmonic OR SVPWM. Not both, so next...

SVPWM calc

Or
-Rectangular to polar conversion of current vector
-Third harmonic calculation
-Polar to rectangular conversion of current vector
-Polar to rectangular conversion of third harmonic vector
-Vector addition of current and third harmonic vectors
-Rectangular to polar conversion of vector sum

I think the vector addition of thd and voltage vector (not current vector! That disappeared in the PID loop!) Might need to happen in polar coordinates, and you may have to do inverse Clarke before thd addition so...


-Rectangular to polar conversion of voltage vector in VaVb frame
-Third harmonic calculation
-Inverse Clarke in rectangular frame
-Add thd to the sinusoids generated by inverse Clarke
-Write the pwm to hardware, no SVPWM required

7000 clock cycles is masses to do this, especially if you have CORDIC and/or FPU. I'm doing it in much less than 2048 clock cycles, without BEMF observer (using a pll on the halls) and using bottom clamp not SVPWM or THD.

Yeah, looking at the SVPWM paper I found it looks like SVPWM does the same thing as THD, and for what I'm trying to do I'll take SVPWM (paper reference here)

My next goal is to write a CORDIC module that can do the angle rotation serially (which would likely take 33-35 clock cycles to do at 16-bit precision, plus however long it takes the multiplier to do the gain scaling at the end), and then writing wraparound modules that can operate the CORDIC in vectoring or rotation mode (rotation mode for polar to rectangular conversion, vectoring mode for rectangular to polar conversion). That way I can instantiate a single CORDIC pair, feed them the stuff in rotation mode to do the Park transform, feed them stuff again in vectoring mode to do the inverse Park transform, and thus achieve a reasonable balance between FPGA space and clock time).

It's probably not worth it to roll my own hardware multiplier or FPU; I can probably use the built in DSP slices on the FPGA to do the multiplication for gain normalization at the end, and fixed-point math isn't terribly bad to work with. I'm trying to figure out how to build a back EMF estimator as well, because that would get me mid- to high-speed control. I'm unsure how one designs something that can run sensorless from a standstill, though; the literature says that below 5% max speed traditional back-emf based approaches don't work terribly well. Then there's the matter of putting together the estimator; I'm tempted to try to use a Kalman filter in hardware to do that (which is likely going to eat a bunch of clock cycles and DSP slices and require a few CORDICs of its own).

Have you or any of the other old crowd had an opportunity to play with Kalman filters much?
 
ARod1993 said:
The other alternative would be to use a soft-switched motor driver; they exist and I've seen them in papers, but they're uncommon, wonky, and low power thus far. There's apparently a startup that's commercializing them, but they're actually using an AI to control the preresonant circuit: https://www.electronicsweekly.com/news/design/pre-switchs-soft-switching-power-inverter-2021-04/ I was wondering if any of the old hands on here had any experience with this sort of stuff, and what people's thoughts were on these sorts of controllers?
This BRUSA Elektronik AG company have been useing soft-switching for some time.
Was thinking to build a soft-switching controller for 4-6s but is still on the draingboard and in the spice simulater.
 
https://patents.google.com/patent/US8199544B2/en?assignee=Brusa+Elektronik+Ag&page=1

This appears to be their patent that shows what they're doing.

I wonder if it works? I'm not aware of it being in any cars etc but it might be. Generally whenever people dismantle car inverters they find a standard 3 phase bridge with an obscene amount of extra blumpf around it.

Usually this means it's unreliable, limited operating band etc... But they could just be asking for unreasonable royalties, not have production capacity etc!
 
mxlemming said:
https://patents.google.com/patent/US8199544B2/en?assignee=Brusa+Elektronik+Ag&page=1

This appears to be their patent that shows what they're doing.

I wonder if it works? I'm not aware of it being in any cars etc but it might be. Generally whenever people dismantle car inverters they find a standard 3 phase bridge with an obscene amount of extra blumpf around it.

Usually this means it's unreliable, limited operating band etc... But they could just be asking for unreasonable royalties, not have production capacity etc!

It's a clever idea; I haven't really delved into the design of ARCP inverters so I'm not sure; the stuff I saw talked about high circulating currents in the resonant leg; my best guess is that the AI is mostly timing the resonant leg commutation as needed to drive the circulating current to the minimum to still provide ZVS turn-on and ZCS turn-off; I found a thesis and an article describing the concept in more detail.
 
Back
Top