Direct Torque and Flux Control for sensorless PMSM speed control, delivered through a modular firmware architecture. Reuse the motor-control core across products, add application-specific functions, and evaluate MCU and sensing choices around the system requirements.
Explore the original figures and photographs from Theta’s supplied technical materials. Select a view and enlarge it to inspect the detail.
Application, system, hardware-abstraction, and driver layers separate product behavior from target-specific implementation.
Theta’s implementation models the motor from its torque and flux equations. The supplied architecture uses a stator-flux-oriented reference frame, PI regulators, and third-harmonic PWM. Its phase currents are sinusoidal.
Closed-loop startup and a dual-model sensorless observer are central features of the implementation described in the papers. One model takes precedence at low speed and the other at high speed. The usable operating envelope is established with the target motor, load, and inverter.
The implementation integrates equation-based flux weakening for operation beyond base speed, without the dedicated motor-specific flux-weakening tables described in the supplied comparison. Motor parameters, inverter constraints, and application validation still matter.
Maximum torque per ampere (MTPA) seeks to deliver the requested torque with minimum current at the operating point. Maximum torque per volt (MTPV) addresses voltage-constrained operation. The papers also describe a deceleration mode that dissipates kinetic energy in the motor resistance while managing the DC-bus voltage. Thermal and electrical limits must be evaluated for the application.
The toolset provides guided motor-parameter configuration, calculation of PI gains, communication with the inverter, motor commands, and visualization of internal variables. These tools support setup and evaluation across motor variants.
The papers document a DTFC implementation designed for a 40 MHz Cortex-M0+ and support for multiple motor instances on one microcontroller. The available processing time, firmware functions, sensing topology, and number of motors must be assessed for the selected platform.
The current white paper defines the implementation as sensorless speed control, rather than a complete closed-loop position-control solution. Robotic joint positioning and other position-critical functions require a separately defined control architecture. The documented scope is three-phase PMSMs with delta or wye windings; the papers describe other motor types as future support.
The papers describe Class B readiness and supporting library information. This supports the OEM’s engineering and verification process; it does not automatically certify an end product. Performance, protections, and applicable requirements must be verified for the actual product.
A new simulation study with the real firmware demonstrates identification of stator resistance, current-dependent d/q inductances, magnet flux linkage, and inverter dead-time drop. These values support the observer and control loops. Explore the News article for the method and the reported simulation results.
Theta structures its motor-control library for reuse across applications. Smart algorithms and application modules are selected for each project, while MCU-specific drivers support portability across processor vendors. Explore the modular firmware architecture to see how this can reduce repeated development and support consistent maintenance.
The September 2025 materials document single-shunt DTFC on M0+ and a low-cost MCU implementation example using 8 kB RAM and 64 kB Flash. These are documented implementation references. Processor resources and sensing suitability must be confirmed for the chosen motor, PWM timing, and complete application.
Reuse the control library across products and MCU platforms. Evaluate M0+ and single-shunt implementations to connect engineering efficiency with hardware cost.
A modular foundation helps reduce repeated engineering while each product retains its own integration and verification requirements.
| Architecture | Theta DTFC in the supplied papers | Comparison context |
|---|---|---|
| Regulated variables | Estimated torque and stator flux directly. | The conventional FOC architecture described in the papers regulates dq currents to control torque and flux. |
| Regulation and modulation | PI regulators and third-harmonic PWM. | The classical DTC reference uses hysteresis regulation and a switching table. Other DTC and FOC implementations can differ. |
| Startup and observation | Closed-loop startup and a dual-model sensorless observer. | Startup and low-speed behavior depend on the observer and startup strategy of the implementation being compared. |
| High-speed operation | Equation-based flux weakening with integrated MTPA/MTPV operating strategies. | Assess the motor parameters, supply-voltage limit, inverter, load, and high-speed operating envelope. |
This is an architecture comparison, not a universal ranking of every FOC or DTC implementation. A measured comparison needs a defined motor, inverter, control settings, and operating conditions.
The papers describe access to estimated torque, flux, speed, and currents at control steps. Those signals can feed physical models or AI-derived application functions.
Explore torque and current signatures for abnormal-operation detection, including fan imbalance, filter restriction, and changes in operating load.
Explore load signatures for friction, imbalance, and possible bearing or starting issues.
Evaluate estimated torque for load-unbalance analysis and for understanding the progress of water extraction.
Explore torque and current patterns for distinguishing normal operation from friction changes or possible obstruction. Any safety-related function needs its own verification.
These are application examples from the supplied AI material. A deployed model needs representative operating data, training where applicable, validation, and defined detection criteria. The examples do not establish guaranteed fault detection or certified safety functions.
Evaluate the architecture in the context of your requirements and operating conditions.
Conceptual system diagram. Architecture and implementation are defined for each application.
Bring your requirements. Let’s explore the engineering together.