Measurements Are Liars. I Trusted Them Anyway.

What if your measurements have been lying to you?

Field-oriented control makes a deal: sample the three phase currents, run them through Clarke and Park, and you get two clean DC numbers: Id for flux, Iq for torque. You control the motor the way you’d control a brushed DC motor, and the time-varying mess goes away.

The deal holds as long as the measurements actually are what the math thinks they are. They usually aren’t. Sequential ADC conversions read the phases microseconds apart. Encoder zeros drift relative to the rotor’s d-axis. Current sensors sit on a DC bias the embedded software never captured. Each of those defects shows up in the dq plot, but each in a distinct shape, and once you know the shapes, the plot tells you which measurement was lying and how.

Meet the Park/Clarke Transform Simulator

The Park / Clarke Transform Simulator lives in the Tools section. You set 3-phase current amplitudes (in pu) and phase offsets, pick a Clarke mode (2- or 3-phase), set the fundamental frequency from 10 Hz to 2 kHz, and dial in the three classes of calibration error (ADC sample skew, θ-offset misalignment, and per-phase current-sensor DC offset) while the αβ and dq signals update in real time.

It’s genuinely useful on its own, a sandbox for anyone teaching field-oriented control or trying to build intuition for what Park and Clarke actually do. But the reason I built it was to make those three lies land visually.

A 30-second Park/Clarke Overview

Clarke takes three phase currents that are 120° apart and turns them into two currents that are 90° apart, same rotating magnetic field, cheaper to think about. Two components, α and β, spinning at the electrical frequency.

Park takes those two, combines them with the rotor angle θ, and gives you the torque-producing current (Iq) and the flux-producing current (Id). In steady state those are DC values, which is the whole game. You control a three-phase motor the way you’d control a brushed DC motor: one knob for torque, one knob for flux, no time-varying waveforms anywhere in the loop. Single most useful coordinate transform in motor control.

The catch: the math assumes simultaneity

Every textbook derivation of Clarke assumes Ia, Ib, and Ic are sampled at the same instant. Nothing in the equations accounts for a time offset between phases. And if you violate that assumption, even by a few microseconds, the math still computes, but it computes the wrong thing.

Here’s why. A sequential-conversion ADC (the kind in a lot of common MCUs and in every channel-multiplexed sampling scheme) converts one channel at a time. Typical conversion time is a few microseconds per channel. So if you start sampling at time t:

• Ia is sampled at t
• Ib is sampled at t + τ
• Ic is sampled at t + 2τ

At 60 Hz fundamental, 2 µs between channels is ~0.012% of a cycle. Sounds negligible. But the rotor angle θ comes from a simultaneous source (usually an encoder or observer), so Park rotates a set of αβ values derived from non-simultaneous Ia/Ib/Ic by a θ that belongs to time t only.

The measured phases are no longer separated by exactly 120°. They’re separated by 120° − ωτ and 120° + ωτ. That’s an unbalance, and Clarke of an unbalanced 3-phase system has both a positive-sequence component (which Park turns into DC) and a negative-sequence component (which Park turns into a component at 2× fundamental).

So Id and Iq pick up ripple at twice the electrical frequency. For an inverter running at 60 Hz, that’s a 120 Hz ripple on the torque command. For a traction drive at 400 Hz, it’s 800 Hz.

See it for yourself

Open the simulator. Defaults put you at 400 Hz electrical (typical high-speed PMSM territory) with no skew. You’ll see:

• Inputs: three balanced 1 pu sinusoids and a clean sawtooth θ
• Clarke: two 90° out-of-phase sinusoids on α and β
• Park: Id flat at 0, Iq flat at −1 pu (sin-convention default)

Clean. Boring. Correct.

Now drag the ADC sample skew slider up. At 400 Hz, 10 µs is ~1.4% of a cycle, already enough to see Id and Iq wobbling. At 50 µs the ripple is several percent of rated current. At 100 µs the dq waveform starts looking like its own sinusoid riding on the DC offset. That’s what shows up in the motor as torque ripple, audible whine, efficiency loss, and (in the worst case) an outer loop that goes unstable because its plant is no longer the clean model it was designed against.

Now drop the Frequency slider back to 60 Hz and leave the skew where it is. The ripple nearly disappears. Same ADC, same τ, but the electrical fundamental is slow enough that ωτ is a fraction of a degree. This is exactly why induction drives at line frequency get away with sequential conversion that would wreck a high-speed PM drive.

For bonus visceral effect, also try unbalancing the phases directly (different amplitudes, or big phase offsets). The dq ripple looks the same. The controller can’t tell the difference between “your motor has unbalanced windings” and “your ADC is sampling sequentially.” It just sees ripple.

The other calibration trap: θ offset

There’s a second slider labeled θ offset, and it teaches a sibling failure mode.

Where sampling skew creates 2f ripple on Id/Iq, a θ offset shifts the Park-frame rotation by a fixed angle. The dq plots stay perfectly DC (no ripple) but they rotate into each other: pure Iq (the torque-producing current) leaks into Id, and pure Id (flux or demag current) leaks into Iq. You lose torque-per-amp, and you’re throwing magnetizing or demagnetizing flux into the rotor that nobody asked for.

In a real drive this is an encoder or resolver calibration error. The motor’s electrical d-axis has to be physically aligned to the sensor’s zero, and if it’s off by even a few degrees the controller is silently off-optimal. Every production PM drive includes an angle-alignment commissioning routine for this reason.

Drag the simulator’s θ offset slider to see it: Id and Iq stay flat but rotate into each other. At ±90° they swap outright. It’s the other classic reason a well-tuned loop produces disappointing torque on the dyno.

The third trap: uncalibrated current sensors

One more slider, one per phase: Sensor DC offset. Hall-effect sensors and shunt amplifiers drift with temperature and aging, so a current reading of “zero amps” usually isn’t actually zero. It’s some small bias. You’re supposed to capture that bias while the shaft is stationary and the gates are disabled, then subtract it from every subsequent sample. Both conditions matter: for a PM motor a spinning rotor generates back-EMF, and if that BEMF is high enough to push current through the inverter’s freewheel diodes, your “zero-current” baseline is polluted. Stopped shaft plus gates off is the only combination that actually guarantees zero phase current. Skip the calibration and the controller is convinced the motor is pushing current that isn’t there.

A DC bias on Ia/Ib/Ic propagates into α and β as a stationary offset, and then Park rotates it at ω, so it turns into 1f ripple on Id/Iq, at the fundamental frequency. That gives three distinct signatures for the three calibration errors the simulator models:

• 1f ripple on Id/Iq: sensor DC offset
• 2f ripple on Id/Iq: sequential ADC skew
• DC rotation between Id and Iq (no ripple): θ offset

If you see a specific ripple in a dq log and know what frequency it sits at, you can often narrow the root cause to the right calibration bucket before you touch any code.

Try it: set Sensor DC offset on Ia to 0.1 pu. Clean 1f wiggle on Id and Iq. Now match the same offset on all three legs. It disappears, because the common-mode component falls out of the Clarke transform. Only differential sensor offsets cause ripple; matched offsets across phases are benign. In embedded software, the fix is the zero-offset capture at enable: with the shaft stopped and gates disabled, sum a few hundred ADC samples per channel, compute each mean, subtract from every subsequent reading. Takes a millisecond, kills the defect class.

A story from my own hardware

I ran into this on a PM motor drive I was bringing up a few years back. The torque was… fine. But there was a consistent 2× fundamental ripple on Id and Iq that I could not make go away with any amount of tuning. Controller gains, bandwidth, observer coefficients. All clean, math all checked out, and yet the dq plots were always wobbling.

The fix turned out to be embarrassingly simple. The MCU had two independent ADC cores: one tied to channels 0-7, the other to channels 8-15. I had Ia, Ib, and Ic wired to CH0, CH1, and CH2. All three on the same core. ADC2 sat idle on currents while ADC1 serialized the three, microseconds apart. The moment I re-routed Ib to CH8 so it would convert on ADC2 in parallel with ADC1’s first slot, the ripple collapsed. Same gains. Same motor. Same loop. Just honest sampling.

It’s the kind of fix that doesn’t show up in any textbook. The math doesn’t warn you. The datasheet for the ADC doesn’t say “if you sample sequentially your dq will wobble.” You just have to know.

Modern motor-control MCUs make this trivial. The parts I reach for today ship with four ADC cores, enough to sample all three phases truly simultaneously with room to spare for DC-link voltage, temperature, and whatever else the inverter cares about. If you’re specifying a greenfield design, count the ADC cores before you commit. The cost premium is small. The headache of working around sequential conversion in embedded software is not.

Why PM control is where this really bites

Sequential sampling is a problem for any FOC drive, but it’s especially a problem for permanent-magnet motors. PM drives run at higher electrical frequencies than a typical induction or AC drive: fundamentals well into the hundreds of hertz and sometimes up to 1000 Hz, with switching frequencies around 12 kHz to keep the current waveform clean. A 2 µs skew that’s 0.01% of a cycle at 60 Hz is 0.2% at 1000 Hz. Same microseconds, 16× the phase error, 16× the dq ripple. The higher you push the fundamental, the less forgiving sequential conversion becomes, and PM drives push it hard because the motor responds to it.

The contrast is sharp: induction drives running under about 200 Hz fundamental (which covers most VFD applications short of high-speed spindles) barely register this effect. The skew is there in the math, but at those frequencies the ripple on Id/Iq is small enough that a reasonable current loop absorbs it without visible torque ripple. If you’re designing an induction drive for line-frequency-adjacent applications, sequential ADC sampling is a “nice to avoid” but rarely a “must fix.” If you’re designing a PM servo or traction drive that spends real time above 500 Hz fundamental, it’s a must-fix.

The position sensor matters too. For PM control at these speeds you usually see resolvers, not incremental encoders. Resolvers give you a continuous analog angle signal that you can sample synchronously with the current ADCs off the same PWM trigger. Current and position land in the same instant, Park sees a coherent (αβ, θ) pair, the math behaves.

Incremental encoders and Hall-effect sensors are another story. They’re edge-triggered: the position counter updates whenever the sensor emits a pulse, not when you ask for it. Reading the counter at the ADC sample instant gives you the last-known position, which is stale by up to one count period. You can’t “trigger” it into alignment the way you can with a resolver. Hall sensors are sometimes used in conjunction with encoders to get absolute position on power-up, but the fundamental “when did this value become true?” problem doesn’t go away. If you’re doing high-performance PM control, a resolver is the right answer for reasons beyond robustness; this is one of them.

The simulator’s skew slider captures the same math as current-vs-position misalignment. It’s the same defect class, just a different variable doing the skewing. Time alignment is part of the physics, not just an implementation detail.

What FOC controllers actually do about it

A few strategies, from most-to-least robust:

1. Use every ADC core you have. Parallelize the phase conversions across independent ADCs so they happen simultaneously, not sequentially. If your chip has 2, use 2. If it has 4, use 4. This is the fix.

2. Simultaneous sample-and-hold. Even a single ADC can be effectively simultaneous if it has multiple S&H circuits that all fire at the same instant and convert afterward. Modern TI C2000 parts have this.

3. Pair current sampling with a resolver, triggered off the same PWM event. Resolvers are continuous analog signals. You sample them like any other ADC channel, and they land in the same instant as the phase currents. For high-performance PM control this is the default for a reason.

4. Software skew compensation. If you know τ, you can advance the θ used for Park by ω · τ/2 to partially cancel the effect at a single operating point. Stops working cleanly when the motor accelerates.

5. Low-pass filter the dq values. Don’t. Kills the ripple on the plot, adds phase lag to the control loop, makes the whole thing unstable.

The simulator doesn’t model strategies 2-5. It’s designed to let you feel the raw effect so you understand why strategy 1 is worth the hardware selection effort.

Who this is for

• Embedded Software engineers working on motor controllers, especially on MCUs where you have a choice between simultaneous-sample and sequential-sample ADC peripherals.
• Students learning FOC who’ve read the math but haven’t felt the consequences of violating its assumptions.
• Anyone who’s seen 2f ripple in a dq log and wasn’t sure whether it was the motor, the encoder, the current sense, or the sample timing. (Spoiler: it’s often the sample timing.)

I’ve run into this exact failure mode on shipping hardware (PM motors), and it burned more time than I care to admit. The fix is usually “use more of your ADC cores.” But nobody believes it until they see the dq plots.

Now they can see the dq plots right in the Park/Clarke simulator.

Stuck on something like this?

If you’re chasing dq ripple you can’t explain, bringing up a PM drive that won’t behave, architecting a motor controller and trying to get the sampling topology right before the board spins, or spinning up a fresh project and want a second set of eyes on the plan, I can help. Reach out, happy to do a review call or a longer engagement, whichever fits.