Another attempt at building a motor controller

[mxlemming]

So I set up a quick SPICE model. First time I used spice, holy crap it is clunky. So hard to make things tidy.
I modeled the parasitic trace inductances and output capacitances you might typically see, and set the MOSFETs complimentary PWMing. I gave it 1.5nF output capacitance, 1nH top and bottom then 10nH top and bottom parasitic inductance. Gave it a battery (80V 50mohm, like a large 20s~8p kind of pack) and a bit of capacitance -1000uF with a reasonably large ESR and 100uF with a low ESR.
40uH motor coil with ~half an ohm which I varied to get the different currents.
The whole lot is chooching away at 20kHz, with 100ns dead time and 100ns rise and fall times on the "gate drivers". 10 ohm gate resistors, and it seems to model the FET gate charge... I used the biggest 100V FET I found by just scrolling down the list LTSPICE had -IPB042N10N3- it's pretty representative of the kind of FETs we use.

Note, this looked fairly tidy until I entered parameters and it just spewed them all over everything... Lesson for my next go - leave a LOT of space for SPICE to clutter.

1nH parasitic inductance 80A on phase node

1nH parasitic inductance 80A on phase nodezoomed

1nH parasitic inductance 160A on phase node

1nH parasitic inductance 160A on phase node zoomed

10nH parasitic inductance 80A on phase node

10nH parasitic inductance 80A on phase node zoomed


I also tried a bunch of other combinations. The slow bit is screenshoting, saving, uploading.
Basically, it all looks like there is a critical inductance of about 1nH and 100A, below which the ringing becomes pretty much irrelevant/manageable, frequency of the order of 25MHz, and above that it needs... managing.

It is dependent on current, but there is a lot of ringing even at low current - zero current does not imply zero ringing, so it masks the effect of current to some extent.

The importance of damping becomes clear; adding series resistance, just about anywhere, decreases the ringing time. As you would expect. Adding series resistance in the parasitic loop helps most, but... where we going to get that... that's normally exactly what we try to design out with low RDSon FETs.

Rise times that SPICE is computing are really fast, on the order of 10 ns... which is faster than the FET's rise time, so hmmm...

I am not quite sure how this stacks up with reality, and being new to SPICE, not sure whether my assumptions and inputs stand, but it does tie in pretty well with what I have observed so it can't be too far wrong...

If I input my ESC layout into https://spok.ca/index.php/resources/tools/106-traceindcalc
H=0.25, W=15, T=0.05, L=20 all mm
I get: 0.46nH
I guess this is why I get basically no ringing on my SMT TOLL fets with the ground plane right below, but Thor is getting more with his thicker 2 layer PCB with big spread wide legs on his FETs.

Summary: Make your power stages low inductance, or suffer big losses from slowing your switching right down.

 

[thorlancaster328]

Some good insight here.

The first bump after the rising edge is not part of the oscillation, but it is the drain current turning off and the di/dt induces voltage on the loop inductance that appears as Vds overshoot. With inductive load the rising of Vds voltage and the falling of Id current are not at the same time, but one after the other, that is called hard switching.
BTW, are you testing with inductive load (as a nearly constant current source)?

So the initial peak provides the energy to start the oscillation, but is not the cause of it. Slowing the switching so that it overshot less would definitely reduce the ringing.

Assuming it's not measurement error, you still have a few weapons in your arsenal - snubbers, the gate resistor at 4r7 is still pretty low.

The gate-source transition takes around 350 nanoseconds to reach it's 90% of its final value. This seems high to me but the drain-source transition is only 80 nanoseconds according to this image. Even the gate-source time feels intuitively high to me, I've never scoped a power stage before so this might be normal. I just ordered an assortment of low-value 0805 SMD resistors and will likely try 8.2 or 10 ohm next.

But a much greater oscillation is normally at the turn-on after the reverse recovery of the body diode of the non-switching FET, because the reverse recovery current of the diode falls to 0 in an instant (compared to the period of the natural frequency of the loop), and the remnant energy in the loop inductance starts the oscillation. At higher phase current the di/dt becomes higher as the FET turns on, and so the peak reverse recovery current is also higher. These oscillations are not linked to or caused by the Miller capacitance.

I scoped both the rising and falling edges of both the high- and low-side FETs and the turn-on ringing is about 3x less than the turn-off ringing. I guess this might be due to the low rDS absorbing the ringing.

 

[mxlemming]

350ns gate source transition is pretty fast - the FET actually switches as it crosses the threshold voltage, above and below that it's decreasingthe RDSon and... not doing much.

Perhaps your difference in rise and fall is due to the intrinsic resistance of the gate drive, the UCC datasheet implies the pull up is 10x the pull down strength, even though it claims 4A up 6A down... Not sure what is going on here re. the datasheet...

 

[thorlancaster328]

My god that's a lot of ringing. Are you sure that the ESR of your 100uf is low enough? With a whole row of 1206 ceramics soldered to the edge of my board, I estimate a few mOhm at most of ESR with the ceramics (1206, 6mOhm, 6Mhz self-resonant frequency, about 10-20 close enough to the FET to matter).
Here's my layout. Brown rectangles are 1uf 100v ceramic capacitors

Your drain-source graph looks a lot like mine did when I had the 2.2 ohm gate resistors installed. I think you might have too much inductance in your simulation.

 

[thorlancaster328]

The UCC has a somewhat unconventional structure to drive the output pin, with an N-channel providing current until about 2 volts below vCC and a P-channel providing current above that. See section 9.3.4 in the datasheet.

350ns gate source transition is pretty fast - the FET actually switches as it crosses the threshold voltage, above and below that it's decreasing the RDSon and... not doing much.

:thumb:
I'll definitely be increasing the gate resistors then. I'll have to add more deadtime to compensate, and the PWM within a few percent of fully on and fully off will be nonlinear, but that should be fine since FOC uses a current control loop.

Until the assortment of gate resistors arrive, it's time for the software side of things.

 

[mxlemming]

Lowering the ESR of those caps doesn't reduce the ringing. Actually it just makes it sustain longer.

I hypothesise that spice finds a worst case since there are no losses to radiation, Eddie currents in other planes etc as a real board would have.

Could you not have just made your PCB 5mm bigger and put the caps on properly?

 

[thorlancaster328]

I hypothesise that spice finds a worst case since there are no losses to radiation, Eddie currents in other planes etc as a real board would have.

Yeah, skin effect at 20 Mhz is only 20 micrometers, so that probably helps quite a bit.

Could you not have just made your PCB 5mm bigger and put the caps on properly?

And add at least 10mm to the loop? I see your point for >100v designs where you need two caps in series but the existing setup is electrically optimal and pretty easy to manufacture. Soldering the caps together before putting them on the board is the hardest part. For mass production I could easily make a silicone mold, add some solder paste and caps, and pop it in an oven to reflow. Then all I would have to do is epoxy the capStrip to the edge of the board and it would solder itself when I soldered on the pre-tinned bus bars.

Also the location of the heatsink makes making the board any wider behind the FETs impractical. If I went with a heatsink / FETs under the board (makes the whole thing smaller), I could mount the caps the standard way and eliminate the capStrips.

 

[mxlemming]

It hardly adds 10mm to the loop. It's area you really care about anyway not length, and you can reduce that to virtually nothing.

If you do this, they get placed by a pick n place machine for virtually nothing, with far higher reliability.


The inductance of the "wires"to the caps is nearly nothing because they're so wide - 200mm, or whatever the full length of your PCB is.

 

[thorlancaster328]

Placing the caps on the standard way will add 5mm to the width of the board. You're right, if I place my vias under the caps, the loop area won't change hardly at all. Also, the extra width of the board is halfway offset by not having the capacitor soldered to the edge of the board. Total width increase will be somewhere around 3mm. Only other change I'll have to make is to make the aluminium bar behind the FETs 1/8" thicker. That's only a 0.013 celsius/watt increase, which is pretty negligible.

If I'm trying to make these in bulk, the more stuff I can have a machine do, the better.

 

[peters]

Yes, your simulations are pretty good and realistic for turn-on.
But I doubt your estimation for 0.46nH, the TOLL package also has 1nH source inductance as I remember, that is the wire bonding or a flat copper strip from the source pins to the silicon chip. Once I measured a board with the same IPT015N10N5 FETs, the ringing frequency was 57MHz and the calculated loop inductance was 5.2nH. Your 4 layer board is better, surely below 5nH, but you'd really need a higher bandwidth oscilloscope to see the details of the switching transients.

 

[peters]

You can calculate your inductance from the oscillation frequency and the Coss of the FET. (See the capacitance graph at the Vds voltage in the datasheet, not the table).
TO-247 also has some common source inductance, I think 5nH or higher, (maybe smaller for these new very high current FETs with stronger wire bonding) and you have a horizontal passage from one FET to the other in the loop.
The lowest inductance layout I measured with TO-247 was 15-17nH, I'd expect something similar in your case. With through-hole packages there are physical constraints to make it any better.

 

[mxlemming]

Yes, your simulations are pretty good and realistic for turn-on.
But I doubt your estimation for 0.46nH, the TOLL package also has 1nH source inductance as I remember, that is the wire bonding or a flat copper strip from the source pins to the silicon chip. Once I measured a board with the same IPT015N10N5 FETs, the ringing frequency was 57MHz and the calculated loop inductance was 5.2nH. Your 4 layer board is better, surely below 5nH, but you'd really need a higher bandwidth oscilloscope to see the details of the switching transients.

Maybe 1.5nH is more realistic. Hard to know since I can't see any ringing with the scopes I've got available (tried the 50M ISO tech in the pics, tektronix 100M 2000 series, and a rigol ds1104z)

Can you recommend a scope that'll suffice? I'm actually about to lose the use of the one in the pics I posted (work scope, moving job...) so I'll have to buy myself one. Budget say 1kgbp max. I'm not doing this professionally... Yet... And probably ever... So Rhode and Schwartz are off the table. Keysight just bumped the price of the dsox1204 50% moving it from eeerrr maybe at a push... at 1200 to 1800gbp which is basically a nope.
I was considering the new 200MHz siglent which is about 600 but it seems from some reviews that 200M is very optimistic, 3db point 1X0MHz and simply ignores signals over 200M...

 

[thorlancaster328]

I use a scope similar to this one: https://www.valuetronics.com/product/tds3012b-tektronix-digital-oscilloscope-used. I don't own it, University does, but I'll have access to it for another 3 semesters.

It has about 10x the bandwidth necessary for measuring the ringing of my TO-247 parts and is probably suitable for pretty much any motor controller work.

 

[mxlemming]

So i just found this on my gate signals. (Low side gate at switch off event; the little pulse occurs at exactly the switch node rise).



Was a bit surprised since it's 10x the gate bounce given by the Infineon appnote for that FET! Even more surprised that it doesn't seem to lead to any bad effects.

The solution to this seems to be that it's an artefact created by the package inductance and the dumping of the charge built up in the junction diode in the FET.

This is supported by the fact that this artefact is worst at zero current. With load, it disappears for many of the cycles, and varies in magnitude.

It seems you can't simply measure the true bounce on the gate, you're always going to have the parasitic inductances and output capacitances interfering with it (unless you managed to remove the package?)

Just wondering if this is part of what you saw before.

 

[thorlancaster328]

What I saw before in my circuit was a wiggle symmetrical to the ground plane. The gate signal rose above, dipped below, and then levelled off.

I've never seen a noise artifact get better with higher currents...

Since your signal is (1) entirely positive, (2) has a fast rise time and slow decay time, similar to the actual transition, and (3) coincides with the switch node rise, I think it is caused by Miller capacitance. Depending on which way the current is flowing, the transition would be faster or slower due to body diode, etc. At least that's my best guess.

However, it's not even close to bad at only 1.2 volts.

 

[thorlancaster328]

Managed to get SVPWM and saliency-based position detection working after a weekend of programming. Now I see why every motor controller doesn't have saliency-based sensorless starts. Not only does the inductance-detecting tone produce a whine, it is computationally intensive as well. CPU usage is now up to around 30-35% for the main loop, up from 20-25% for just the measurement code. Fortunately, it's not likely to get any higher, as all the computationally intensive stuff is just about done.

To detect position, I modulate the amplitude in 6 steps, with A being higher for steps 123, B higher for 345, and C higher for 561. This varying voltage sets up a varying current depending on each phase's inductance. With this information I can measure the rotor's position....

... To the nearest 180 degrees . Since Saliency can't tell whether the North or South pole is causing it, I get identical readings for rotor positions 180 degrees apart. I can reduce the impact of this quirk by keeping track of BEMF as the bike is pushed around and running a continuous pilot tone. Then there would only be the chance of a wrong guess when the controller was first powered on from a standstill or after the pilot tone was paused to save power during an extended period of inactivity.

While writing this post, I found a paper by Lebowski that details how to do silent, correct, sensorless drive from a standstill. I'll have to read and implement it, my system is pretty good but his would surely be simpler and better. Thank you so much Lebowski for sharing your knowledge.

 

[thorlancaster328]

The paper had quite a bit of math in it that I didn't fully understand. However, I understood enough of it to implement an improved sensorless FOC algorithm that could reliably determine the motor's position, including the leading 180 degrees, from standstill.

• Instead of varying the PWM amplitude over several cycles and generating noise, I can offset the three PWM signals to generate the AC current. To control the amplitude, I can adjust the phase offset. This has the advantage of being inaudible.

• To determine the leading 180 degrees, I can increase the pilot tone enough to cause measurable 2nd harmonic distortion. The sign of the second harmonic determines whether we're offset 0 or 180 degrees

• The improvements won't require me to change my algorithm much. The only significant difference will be an adjustable strength pilot tone that starts strong to get the 2nd harmonic and then gets dialed back to save energy

Should have it implemented in a few days.

 

[mxlemming]

This is a really really good result. Awesome work. I tried something similar but the noise was too high on my first boards, it simply didn't work. I now have a lower noise board so will try again

To work out which way you are in the 180 degree problem, you could guess, then apply a torque vector while still tracking and see which way it goes? It will be opposite depending which pole you have, then you can swap after a few ms if you guessed wrong?

How on earth are you using so much mcu? Surely all you have to do is bump the pwm one way or another, wait until the next cycle, add that result to a bank, and every 6 cycles run a V=Ldi/dt calculation?

For motors with sensible inductance, you can assume linear current decays and avoid the second order derivatives.

I can see this using some MCU, but you've probably got masses of compiler generated blumpf... Not that you give a damn if you've got a super computer.

Re. The miller, it really really looks like Miller but unless the FET is counterfeit it seems really unlikely. ST cover this in AN4150, claiming directly it's the result of the parasitic inductance. And this makes sense given the nature of the glitches and them coming and going.

I've actually opened a forum case on Infineon forums about it. I'll see what they say and report back.

 

[mxlemming]

The paper had quite a bit of math in it that I didn't fully understand. However, I understood enough of it to implement an improved sensorless FOC algorithm that could reliably determine the motor's position, including the leading 180 degrees, from standstill.

• Instead of varying the PWM amplitude over several cycles and generating noise, I can offset the three PWM signals to generate the AC current. To control the amplitude, I can adjust the phase offset. This has the advantage of being inaudible.

• To determine the leading 180 degrees, I can increase the pilot tone enough to cause measurable 2nd harmonic distortion. The sign of the second harmonic determines whether we're offset 0 or 180 degrees

• The improvements won't require me to change my algorithm much. The only significant difference will be an adjustable strength pilot tone that starts strong to get the 2nd harmonic and then gets dialed back to save energy

Should have it implemented in a few days.

Is a shortcut on this to inject the tone at the Va Vb stage of the FOC? Could you then read back the current changes from the ia and ib?
Struggling to visualize this.

Where did you get Lebowski paper? Would like to read.

 

[stancecoke]

Where did you get Lebowski paper?

https://endless-sphere.com/forums/viewtopic.php?t=103025

regards
stancecoke

 

[thorlancaster328]

Is a shortcut on this to inject the tone at the Va Vb stage of the FOC? Could you then read back the current changes from the ia and ib?
Struggling to visualize this.

That's sort of what I'm doing with the pilot tone. The voltage (duty cycle) varies a bit with each PWM cycle, in a 6-step pattern. The oscillating voltage sets up an oscillating current in the windings dependent on inductance. See the graph below:

To work out which way you are in the 180 degree problem, you could guess, then apply a torque vector while still tracking and see which way it goes? It will be opposite depending which pole you have, then you can swap after a few ms if you guessed wrong?

That's sort of what I was planning on doing, but it's not optimal. I only have to write the firmware once and want this to be the best controller on the market. Having the sensorless start sometimes produce a jerk backwards on takeoff would be on par with current controllers. I could also run a continuous pilot tone to keep track of which pole was correct after the first start, but this would waste energy.

I can see this using some MCU, but you've probably got masses of compiler generated blumpf... Not that you give a damn if you've got a super computer.
...
This is a really really good result. Awesome work. I tried something similar but the noise was too high on my first boards, it simply didn't work. I now have a lower noise board so will try again

I manage to get 12 ADC readings/phase every PWM period and pass them through a filtering algorithm that includes a slow bubble sort. This accounts for the bulk of the CPU usage. I also use floats and Doubles liberally with of plenty of pointless casting. Optimization can come after I get the proof-of-concept working.

And by oversampling the bejeesus out of the signal and throwing away the upper and lower third of the readings, I get virtually no noise even though the input to the ADC is noisy and sometimes spikes by up to ~5 measured amps. ~90-95% of the readings are dead-on though. This is sort of what the noise looks like:

The noise is independent of whether I'm driving the FETs or not and seems to come from the switching power supplies. Next revision will have ferrite beads and feed through capacitors on the 5v line and I'll keep the SMPS away from other components as much as possible. From oscilloscope measurements, most of this noise is at 20+ MHz and the existing 0805 caps on the 5v line aren't helping that much.
Edit: I plan on using https://www.arrow.com/en/products/blm21sp601sn1d/murata-manufacturing and https://www.arrow.com/en/products/yff21ac1e473mt0y0n/tdk Should take the noise down by ~80db at the problem frequencies.

@mxlemming I plan on getting the code up on a private github repository sometime tonight or tomorrow.

 

[peters]

I don't know which oscilloscope is good at low price nowadays, for this stuff I use my own diy scope built around a Xilinx FPGA dev board: https://opencores.org/projects/xilinx_scope
It works only at 160MSPS, but the analog part is a simple wideband instrumentation amplifier, and the bandwidth is limited only by a 120MHz RC filter at the ADC input. This shows oscillations also on the SW node of DC/DC converters close to 80MHz or maybe above that (with aliasing). For those I can't tell the exact frequency and amplitude, but sometimes it's enough to know if there is some ringing.

 

[peters]

It's great you set up the saliency-based detection very quickly.
For the initial 180 degree detection I also tried a simple method earlier: applied 1 or 2 100% PWM cycles in forward and reverse directions for all phases (also 6 steps, same length pulses, 30..40Amps was needed for reliable detection, but had to wait for the decay of the current after each step) then calculated the difference and the sum of the measured forward and reverse currents. The sum gives the vector for the accurate position at the double frequency and the difference gives the +/-180 degree decision. Running Clark transform for both gave the angles.
It worked with hub motors, had an audible click due to the current, but that may be ok at start. Lebowski's method is silent also at start, I think.

 

[Lebowski]

The paper had quite a bit of math in it that I didn't fully understand. However, I understood enough of it to implement an improved sensorless FOC algorithm that could reliably determine the motor's position, including the leading 180 degrees, from standstill.

• Instead of varying the PWM amplitude over several cycles and generating noise, I can offset the three PWM signals to generate the AC current. To control the amplitude, I can adjust the phase offset. This has the advantage of being inaudible.

• To determine the leading 180 degrees, I can increase the pilot tone enough to cause measurable 2nd harmonic distortion. The sign of the second harmonic determines whether we're offset 0 or 180 degrees

• The improvements won't require me to change my algorithm much. The only significant difference will be an adjustable strength pilot tone that starts strong to get the 2nd harmonic and then gets dialed back to save energy

Should have it implemented in a few days.

Nice to see someone playing with this

I didnt do oversampling or throwing away ADC samples or anything like that. I subsample and just good old fashioned FIR filtering and down sampling. Thats why I have a section at the end about how to choose the frequencies, so that the sub and down sampling does not lead to tones too close to each other. The ADC performance can be improved by external analog amplification and filtering.

 

[mxlemming]

It would be nice if we could remodel this to not require the phase controlled pwm, because then it would be applicable to the stm32 controllers used in... Most things.

Looking at the data sheet for the stm32 suggests that asymmetric pwm is limited to using 2oc channels making 3 phase asymmetric pwm tricky if not impossible.

Determining the 0 or 180 phase had always stuck me as being the achilles heel of this saliency. Using the second order terms (essentially looking at the effect of saturation of the iron right?) has one significant problem - it involves driving close to saturation - high current.

I had another idea I'll share here, that I came up with while accidentally making unstable FOC loops.

I observed that if I got certain things backwards, rather than generating spinning, it would generate oscillation/vibration, essentially as the angle progressed, the control loop would reverse the current direction and pull the rotor the opposite direction.

I thought of it as an irritation at the time, and flipped signs until it span nicely.

The other thing I observed was that adding field current changed the vibration characteristics - frequency and amplitude. This is I guess related to the "stiffness"generated by the magnetic and electric field interacting, and with field weakening this stiffness can be made stronger and weaker.

So I've been thinking, if I
1)determine, relatively simply, the angle within the 180 degrees,
2) apply an oscillating quadrature voltage and a constant field voltage/current
3) apply an oscillating quadrature voltage and the opposite constant field voltage/current (best if the oscillation frequency in both cases is close to known resonance, but known which side it is off by)
4) observe vibrations with different amplitudes, and thus know the 0/180 phase. (E.g the current vs constant voltage oscillation)

This would only require a few cycles at the resonant frequency to determine

Obviously there's limitations on this method related to acceptable vibration, and some motors might be so heavy/stiff this becomes unfeasible...

One day I'll implement this. If someone else does, please let me know!

If it works, and no one has already done it/patented it, it's now public domain,free for all.