What we do

Motor control development and tuning

We develop drive firmware from scratch and take on drives already built. Engagements run from a short tuning exercise to end-to-end delivery of production firmware.

Field-oriented control

Sensored and sensorless FOC on PMSM and BLDC motors, built on ST’s motor control libraries or from first principles.

Sensorless position estimation

State observer and PLL rotor position estimation, with tuned handover from open-loop start to closed-loop control.

Starting and stopping under load

Rev-up control and residual-speed detection, so a drive starts against back pressure, high inertia, or a rotor already turning.

Tuning and stabilization

PI control on Id, Iq, and speed with feed-forward terms, plus torque, power, thermal, and low-line limiting.

Problems

Motor control problems we work on

The motor does not start reliably under load

Open-loop start into a loaded or already-turning rotor: back pressure on a fan, high inertia, a rotor that has not fully stopped. Where start reliability is a percentage rather than a certainty, the cause is usually the handover from open-loop to closed-loop control.

The drive loses sync when the load changes

A step change in torque producing speed undershoot, a stall, or a fault trip. Usually observer or current-loop tuning rather than a hardware limit.

There is audible noise at particular speeds

Resonances excited by the modulation scheme or by startup ramp timing. Often addressed in firmware by changing how quickly the drive passes through the resonant band, without mechanical changes.

Single-shunt current sensing is unreliable

Reconstructing three-phase currents from a single shunt has boundary conditions that need explicit handling to stay reliable.

The firmware is inherited and undocumented

Drives taken over from a previous supplier or a departed engineer, with no documentation and no test coverage.

The drive fails EMC

Switching frequency, deadtime, cable layout, and the control scheme all move emissions. We can test the effect of each in our own EMC pre-compliance lab.

Why us

Why choose us

FOC in production

Field-oriented control shipped in production motor systems, including sensorless drives.

Validated against numbers

Acceptance criteria agreed as figures up front, then measured. Over a million tests run on client motor-control products.

Measured results

A production motor tester cut from over a minute per unit to 10 seconds, with the fault traced to firmware timing rather than the hardware.

Platforms

Motors, silicon, and techniques

Motor types

PMSM, BLDC, AC induction, PSC, constant-torque loads, high-inertia loads.

Control methods

Field-oriented control (FOC), space vector modulation (SVPWM), variable frequency drive (VFD), soft start, field weakening, torque control, speed control, position control.

Position and current sensing

Sensorless observer and PLL estimation, hall sensors, incremental and absolute encoders, single-shunt current reconstruction, three-shunt sensing.

STM32 motor control

STM32 across the F0, F1, G0, G4, L0, and L4 families and STSPIN integrated motor drivers, leveraging ST’s X-CUBE-MCSDK motor control SDK.

Other silicon we work on

Nordic nRF52, Espressif ESP32, Renesas RX, Cypress PSoC 6, and Silicon Labs EFM32.

Power stage

Three-phase inverters, IGBT and MOSFET bridges, intelligent power modules, gate drive, bootstrap supplies, overcurrent protection, brake resistors.

FAQ

Common questions

FOC controls the motor’s current vector to hold it 90 electrical degrees ahead of the rotor field, which is the most efficient orientation. Against trapezoidal commutation it gives smoother torque, lower audible noise, and better efficiency, at the cost of more complex firmware and more accurate current sensing. For most PMSM and BLDC products at volume it is worth it. ST’s motor control ecosystem is a reasonable starting point for background.

Sensorless removes an encoder, its cable, its connector, and its failure modes, and reduces unit cost at volume. It costs low-speed and standstill performance and makes startup harder. If you need full torque from zero speed or precise positioning, use a sensor.

Both. X-CUBE-MCSDK is a reasonable starting point and we work within it regularly, including fixing and extending it, for example adding dynamically variable switching frequency where an application needs it.

Intermittent faults need instrumentation and long-duration testing rather than bench debugging. We add diagnostics so the device reports its own internals, then run it continuously across temperature and load until the fault reproduces.

Yes. The inverter, gate drive, and protection are designed by the same team that writes the control firmware.

Related services