AM32 is fully open-source and auditable. BLHeli_32 is proprietary and closed-source. Both run on compatible hardware and support Dshot, but for federal drone programs requiring firmware security review, that auditability difference is decisive. This guide covers the technical and compliance tradeoffs.
For defense UAV programs, AM32 is preferred over BLHeli_32 primarily because of auditability: AM32's complete source code is publicly available and can be reviewed by security teams or DoD auditors, while BLHeli_32's proprietary codebase cannot be independently inspected for vulnerabilities or backdoors. Both firmware options run on similar hardware, support Dshot 300/600 and bidirectional telemetry, and neither originates from a covered foreign entity under NDAA definitions. The Lirith QuadDrive 80A ships with AM32 as default and also supports BLHeli_32.
An ESC runs a tight control loop: it reads a throttle command from the flight controller, synthesizes a 3-phase AC waveform, and drives the motor. The firmware executing that loop has direct authority over motor torque, timing, and current draw. It also handles telemetry reporting — RPM, current, temperature — back to the flight controller.
A compromised or malicious firmware could: delay commutation to reduce motor efficiency, report falsified telemetry to the autopilot, refuse a motor command at a critical moment, or gradually overcurrent a motor to induce thermal failure. The fact that ESC firmware executes at the lowest level of the propulsion chain — below the autopilot, below the flight controller — makes it a high-value target for supply-chain attacks.
For defense programs, the question is not just "what entity wrote this firmware?" but "can we verify what this firmware does?" Open-source firmware answers that question. Closed-source firmware cannot.
AM32 is an open-source ESC firmware for STM32-based hardware, developed by AlkaMotors and maintained by a distributed contributor community. The full source code is available on GitHub under an open license. No corporate entity owns AM32, and its development is not controlled by any covered foreign entity under NDAA definitions.
BLHeli_32 is a proprietary ESC firmware with a closed-source codebase, developed originally by Steffen Skaug (a Norwegian developer) and subsequently licensed commercially to ESC manufacturers. It is widely used in commercial and racing drone platforms. Its developer is not a covered foreign entity under NDAA definitions, but its codebase cannot be independently audited.
| Feature | AM32 | BLHeli_32 |
|---|---|---|
| Source code | Open-source (GitHub) | Closed-source / proprietary |
| Independent security audit | Yes — full codebase available | No |
| Covered-entity origin | None | None |
| Dshot 300/600 support | Yes | Yes |
| Dshot 1200 | No | Yes |
| Bidirectional telemetry | Yes | Yes |
| CAN bus support | Yes (hardware-dependent) | Limited |
| Customer-controlled versioning | Yes — forkable | No |
| Commercial licensing dependency | None | Yes — licensor required |
| Preferred for federal programs | Yes | With caveats |
The NDAA covered-component definition explicitly includes "operating software" embedded in a UAS component. Firmware IP that originates from — or is substantially licensed from — a covered foreign entity would implicate NDAA compliance. Neither AM32 nor BLHeli_32 originates from a covered entity, so both satisfy this specific statutory requirement.
However, DoD programs increasingly operate under broader supply-chain security requirements — some formalized in contract language, others in program security reviews — that go beyond the statutory NDAA minimum. These requirements often include: independent firmware audit capability, documented firmware provenance, and the ability to produce a reproducible build. AM32 satisfies all three. BLHeli_32 satisfies none.
For programs operating under a CMMC framework, supply-chain risk management requirements may explicitly require auditable software in critical systems. ESC firmware in a defense platform is exactly the kind of embedded software these requirements are designed to address.
What is AM32?
AM32 is an open-source ESC firmware for STM32-based hardware. It supports Dshot 300/600, bidirectional telemetry, CAN bus, and PWM. The full source code is publicly available on GitHub, enabling independent security audit.
Is AM32 suitable for defense UAVs?
Yes. AM32 is preferred for defense programs because its open-source codebase is fully auditable, it has no covered-entity IP, and programs can fork and version-control the firmware independently. The QuadDrive 80A ships with AM32 as default.
Does BLHeli_32 violate the NDAA?
No — BLHeli_32 does not originate from a covered foreign entity and does not violate NDAA statutory requirements on its own. The concern is auditability: its closed-source code cannot be independently verified for supply-chain security purposes.
Can the QuadDrive 80A run BLHeli_32?
Yes. The QuadDrive 80A supports both AM32 (default) and BLHeli_32. BLHeli_32 is available for customers who have existing tooling or integrations that depend on it. Contact sales@lirith.com for details.
Which firmware does ArduPilot/PX4 prefer?
Both AM32 and BLHeli_32 are compatible with ArduPilot and PX4 via Dshot and bidirectional telemetry. Neither flight stack has a hard requirement for one over the other at the autopilot level, though AM32 is increasingly common in new defense-oriented designs.