openinverter forum

This is a separate thread from this post. I went digging through old OEM inverter/DSP asm code and fell into the PWM rabbit hole. I checked most of open source foc codebases if anyone implements any optimizations like that and to my surprise I found none, maybe for a reason. My current goal is simple: possibly reduce switching losses (less heat) without touching the core FOC current controllers, while operating at somewhat silent PWM carrier frequency. My reasoning for this research is that using the stock OEM firmware in my inverter seems to cause bond wire fracturing from heat stress, with observed failure of IGBT every 40ish thousand km. I believe that mean time between failures can be improved here. I have no clue how often zombified inverters show signs of failure, so feel free to chip in, if this is even a problem. I don’t have a proper test bench yet, so for now I’m sharing findings + a proposed investigation plan.

0) What does a “modulation scheme” actually change?
FOC produces a desired voltage vector. PWM modulation turns that into 3 phase duties (A/B/C) by deciding:

• how much time we spend in the zero states (000 / 111), and
• how often each inverter leg actually commutates (switches).

A nice mental picture:


1) Continuous vs discontinuous PWM in simple terms

Continuous PWM (all three legs keep switching all the time)

• SPWM: classic “3 sine refs vs triangle carrier”. Simple, but not the best DC-bus utilization.
• SVPWM: injects a common-mode offset so you use the DC bus better (more usable voltage before clipping), often lower distortion than plain SPWM.
• THIPWM: add 3rd harmonic (commonly 1/6) to extend linear range; in practice it’s very close to SVPWM min/max injection in the linear region.

Rule of thumb: continuous schemes spread switching events fairly evenly across legs.

Discontinuous PWM (DPWM) (intentionally “clamp” one leg to +DC or -DC for parts of the cycle)

• DPWMMIN / DPWMMAX: choose the common-mode so either the minimum or maximum phase gets clamped for long intervals. Fewer commutations → lower switching loss.
• DPWM0/1/2/3 etc: a family of clamped patterns that move the clamp window around the electrical cycle. Which one is best depends on operating point (power factor angle / field weakening / modulation index).

Good illustration of what “clamping” means (one leg stops switching for chunks of the cycle):

And a block diagram view of “zero-sequence injection”:

Overview of common DPWM variants:


Why this matters (short version)

• Switching losses are strongly tied to commutations. DPWM reduces commutations, so switching loss can drop noticeably at high modulation / high power. More switching losses = more thermal stress on the junction and bond wires, even if it is well hidden by an overengineered package cooling loop.
• SVPWM/THIPWM improve DC-bus utilization (more voltage headroom before overmodulation).
• No single PWM pattern is “best everywhere”, so hybrid/adaptive strategies show up a lot in literature.

2) What stm32-sine FOC does today
FOC modulation is continuous SVPWM common-mode injection + short-pulse suppression. No DPWM variants exist in STM32-SINE FOC today.

• Common-mode offset is exactly

  Code: Select all

  (min + max) / 2

• Applied in the FOC inverse Park/Clarke path
• Only clamping is “short pulse suppression” near 0% or 100% duty, not sector-based DPWM

So: current behavior is clean and conservative. This thread is about optional additions.

3) Proposal A: add DPWMMIN / DPWMMAX via the existing common-mode injection (small change)
stm32-sine already centralizes the common-mode offset. That makes DPWMMIN/MAX a relatively small modulation-layer change:

• SVPWM (existing):

  Code: Select all

  offset = (min+max)/2

• DPWMMIN: choose offset to clamp the minimum phase
• DPWMMAX: choose offset to clamp the maximum phase
• More elaborate DPWM schemes could be implemented after that with dynamic switching depending on operating region.

FOC loops stay untouched. We only change how we place zero-time.

4) Proposal B: optional dynamic carrier frequency (bigger change)
Carrier frequency (17.6 / 8.8 / 4.4 kHz in stm32-sine) is a separate knob. Lower carrier reduces switching loss, but can increase audible content and current ripple, and it’s more invasive to change safely at runtime. Reading the threads trying to tune motors for foc here at different carrier frequencies makes me think that this is no go at this point, so just feel free to skip this idea at this point.
If attempted, it should be staged:

• disable PWM outputs cleanly
• re-init timer period/repetition counter
• update anything tied to timing (PI dt/calling frequency, duty scaling, min-pulse meaning)
• add hysteresis + dwell time to avoid mode flapping
  This is skethy imo, so just food for thought.

5) What to test

• A/B temperature rise: SVPWM vs DPWMMIN/MAX at same carrier frequency
• low-speed smoothness, audible behavior, when and to what a dynamic switching scheme should be applied.
• scope gate timing and deadtime margins
• if pwm carrier f switching is added: confirm dt/duty scaling stability

References (mix of review + algorithms + practical notes)

• Chalmers PMSM drive PWM comparison + operating regions:
  https://publications.lib.chalmers.se/re ... 256161.pdf
• Holtz PWM survey (review):
  https://www.semanticscholar.org/paper/P ... 0afe192274
• Holmes & Lipo book (PWM bible):
  https://books.google.com/books/about/Pu ... Gi1AjSfpcC
• DPWM family, generalized discontinuous PWM (algorithm paper):
  https://users.metu.edu.tr/hava/apec97.pdf
• imperix explainer (visuals for SVPWM and DPWM):
  https://imperix.com/doc/implementation/ ... techniques
  https://imperix.com/doc/implementation/ ... inuous-pwm
• Deadtime and commutation effects overview:
  https://vbn.aau.dk/ws/files/329318065/e ... 196_v2.pdf
• IGBT reliability and thermal cycling context:
  https://www.researchgate.net/publicatio ... g_lifetime
  https://assets.danfoss.com/documents/la ... 000201.pdf

Any specific implementation has to keep in mind that dynamic DPWM is widely used by OEMs, but different algorithms for when and how it switches between CPWM and DPWM are patented and most are still in force in a lot of jurisdictions. Basic modulation index or rpm for a switchover seems safe and are prior art from 1980s. Efficiency/thermal LUTs, Iron loss calcs, bus ripple or harmonics calculations seem to be a more riskier route.

Questions
1) Has anyone tested DPWMMIN/DPWMMAX/any other DPWM schemes in stm32-sine FOC or any other inverter for thermal benefit vs side effects?
2) Any known pitfalls with current sampling / torque ripple when a leg is clamped for long intervals?
3) If adding dynamic pwm carrier f switching, what is the safest staging approach in stm32-sine without upsetting loop timing? What gotchas could be here stopping a safe implementation?

The only data point I have for zombified inverter longevity is this comment:

johu wrote: ↑Sun Oct 19, 2025 12:30 am Basically the situation is the same as before, we just acknowledge the fact that SDU inverters broke at an over-proportional number with the OI board. I can't really put a percentage on it but over the years I sold 350 SDU boards and read perhaps about 20 IGBT failures. That would be 5%, not counting boards that were sold by someone else or manufactured from the files.
And also not counting silent failures that were never reported or boards that were never commissioned.

In comparison I sold 220 LDU boards and had perhaps 5-10 failures which also puts it in the 2.5-5% ball park. The difference to SDU inverters is they died from "mistreatment" such as P.S. Mangelsdorf rather than during slow takeoff/maneuvering.
Nissan boards I sold 110 and remember one failure due to over voltage during regen. Call it a 0 failure rate.

All failure numbers are "felt" combined from support calls and forum posts (dubbed SDU overcurrent). If someone can improve on that it would be welcome.

So maybe the basis question here should be not "if we could" but "if we should", as in my opinion this, even more so used on "private property only" still touches the most vital part of the powertrain and thus extensive testing and validation would be required.

Lately I found that FOC can restart into a running motor, so dynamic frequency switching would be possible as long as you're outside field weakening.
Also the control loop itself runs at a constant frequency thanks to the repetition counter.
Concerning different modulation schemes with a mode switch parameter this would be backward compatible.
As announced elsewhere I will leave coding and testing to someone else (you?)

My Initial idea to somehow qualitatively assess what modulation frequency and at what point would be suited is to extend the IPM Motor Sim to work at a lower layer to try and add pwm modulation data and some switching loss model in to it. Then some sweeps with each DPWM style could help understand usability for each one, most likely coraborating with academic literature. Alternatively a proper bench testing station could yield better results, but the problem for me, for the time being is I have no zombified inverter as of yet to do so. I hope this will change in the near future, but still a lot of work is required on my end to zombify my inverter before I can start experimenting with esoteric stuff like this on it.

johu wrote: ↑Mon Feb 02, 2026 8:50 am Lately I found that FOC can restart into a running motor, so dynamic frequency switching would be possible as long as you're outside field weakening.
.....

I found out similar with Lebowski sensorless mode as well. out of FW it would instantly recover any blips... but when in FW range it would cycle recovery attempts until it would spool down to base speed.
...
I tested this with 6khz, 7khz and 8khz. Same result, but Leaf motor ran better at 7khz...
I briefly tested with 16khz... inverter heated up fast and lebowski would cutoff... I had thermistor on the base plate...

So spent most of the night with a few gifted agents vibecoding this fork:
https://github.com/skrubis/IPMMotorSim-PWM

It is an effort to refactor and extend the IPMMotorSim to a into a PWM-edge, deadtime-aware inverter + motor simulation that can:

• generate *actual switching waveforms per PWM cycle*,

• simulate phase current ripple and current paths (MOSFET/IGBT + diode conduction),

• estimate inverter efficiency (conduction + switching loss),

• sweep modulation strategies (SVPWM, DPWM variants, hybrid/blended),

• export results for building a real-time mode scheduler (when to switch which PWM mode).

Non-goals (for now):

• full EMI modeling, parasitic inductances, snubbers, detailed gate-drive transient waveforms

• thermal coupling beyond simple temperature parameterization

Implemented Functionality (this fork)

• SVPWM + DPWM variants (DPWM0/1, DPWMMIN/MAX) with blend control.

• PWM modulation graph with zero-sequence/clamp/timing/sector visibility toggles.

• Power stage loss estimation (conduction + switching + diode recovery) with PM300CLA060 placeholder curves.

• Power stage parameter editor (deadtime, thermal, Vce/Eon/Eoff/Irr/trr curves, etc.).

• Inverter losses window with per-device loss breakdown and averaged summary strip.

• CSV logging includes modulation diagnostics, losses, and basic thermal estimates.

PWM/Loss Model Shortfalls (current limitations)

• PWM is still averaged per control timestep; there is no event-based switching timeline yet.

• Deadtime and conduction paths are modeled per-period, not per-edge; no minimum pulse clamp.

• Switching loss uses curve interpolation without gate-drive dynamics, Miller effects, or parasitics.

• Diode recovery is approximated from Irr/trr; no detailed charge waveform or reverse recovery shape.

• Thermal model is first-order with fixed Rth values; no coupling or Cth from datasheet.

• Motor plant remains the legacy average model, so phase current ripple is not yet resolved.

My motor-fu is inadequate to even have a grasp on what I am even looking at, given that this is my first time interacting with this software, for most of the knobs I have added helper text, but I still have a lot of theory to learn.

I have no test motor to try and measure constants for, so whatever was there by default I used. For power stage constants Mitsubishi PM300CLA060 is used, it's an ancient IGBT brick my electric motorcycle uses from the factory.
SVPWM, start at 1000RPM: DPWMMAX, start at 1000RPM: I would be very happy if anyone with knob turning skills could give some feedback.

So the latest commits on github now do per edge loss estimations, which should be much more closer to reality.
There are now a few more power stage presets, namely LDU, SDU, Leaf gen2,bmw I3ish one along with the vectrix vx-1 powerstage. I tried to add as much as I could about each of these powerstages, including DC link caps, and parallel devices, but needs to be double checked for acuracy.
There now is an option to use some of jsons I fetched from /parameters db using foc builds, as well as browse for a json file. This doesn't address the motor constants not in jsons.
Which lead me to wondering, that a centralized place for motor parameters (fw and sim) would be of great benefit to anyone who sails this path in the future as now I am using random motor values found in the sim thread.

Github now has kind of working release CI building binaries for people who don't want to build from source, although mac OS builds are still borked. This still needs a lot of improvement, as, say, win bins still have some packed stuff missing from the archive, but should be a much faster way to run sims without signing up for a QT account.

My plan going forward is to make a headless sweeper to somewhat replicate the chalmers dpwm paper criteria and methodology, create a dpwm strategy supervisor and have some conclusions, with deliverables being a condensed pdf report (loss, THD, strategy) and possibly a LUT for inverter FW to use per motor to operate in an optimal loss area at all times. Maybe it's an overkill and simple "if modulation > 0.x do DPWM x" and leaving SVPWM for most low speed operation is more than adequate.
In a perfect world a real motor and its params could be simulated in various sweeps against given desired constraints to produce a tiny lut for inverter fw to use with little variance between individual motors of the same part number as long as in doesn't infringe with claims of any published and in-force IP in most jurisdictions.