From SoC to Product: Engineering Low-Power AI Wearables with Ambiq Apollo
For a wearable product, SoC selection is rarely about the highest clock speed. In real projects, the tighter constraints are usually product size, battery target, sensor count, audio or display requirements, the amount of local data processing, and deciding which tasks should remain on the device.
Ambiq Apollo is one of the low-power platforms Hulin evaluates for wearable products. Across Apollo3, Apollo4, Apollo330 Plus and Apollo5, the family spans different balances of low-power sensing, BLE, graphics, audio, signal processing and edge AI.
For us, however, the datasheet is only the starting point. The real work is fitting those capabilities into a product constrained by size, battery and cost.
01 Low-power SoC selection only matters when it fits the system power budget
Wearable batteries are often measured in tens or hundreds of milliamp-hours. With a 100 mAh battery, a seven-day target allows a theoretical average current of about 595 μA. Extending the target to 14 days reduces that budget to roughly 298 μA.
100 mAh ÷ 168 h ≈ 595 μA; 100 mAh ÷ 336 h ≈ 298 μA
That budget is shared by the SoC, sensors, BLE, storage, PMIC, LEDs, haptics and other peripherals. An ultra-low-power platform creates headroom, but battery life still depends on how the complete product is scheduled.
Apollo3 Blue Plus is specified at about 6 μA/MHz while executing, with roughly 1 μA deep sleep when BLE is off and the RTC remains active. Apollo4 Blue Plus specifies CPU active power at about 29 μW/MHz. For us, these figures are not a generational ranking. They tell us how much room the platform gives firmware to manage Active, Idle, Sleep, Sampling, Sync and Storage states.
The practical questions are usually simpler: How often does the sensor sample? How long does BLE stay connected? How long is the SoC awake each time? Can flash writes be batched? How long must audio or a display remain active?
02 An Apollo SDK demo is not the same as an Apollo-based product
Getting BLE, a sensor or an audio example running on an evaluation board only proves that a function can work. A product still needs Product Definition, SoC Selection, Power Architecture, Schematic & PCB, Board Bring-up, BSP / Drivers, Sensor / Audio / BLE integration, Storage, Low-Power Firmware, OTA & Security, APP Integration, and then DV and production readiness.
These tasks are tightly coupled. Adding a sensor on the hardware side also creates firmware decisions around sampling rate, interrupts, buffering, storage, BLE synchronization and power states. The mobile side then has to handle configuration, history, sync status and OTA.
Our focus on Apollo is therefore not isolated MCU programming. It is making hardware, firmware and software work as one product architecture from the beginning.
03 Data volume often shapes the architecture before clock speed does
A wearable can be physically small and still generate a large amount of data. At 16 kHz / 16 bit / mono PCM, raw audio is about 256 kbps, or 32 KB/s. One hour is roughly 115 MB; four hours approach 460 MB.
16 kHz × 16 bit × 1 channel = 256 kbps ≈ 32 KB/s ≈ 115 MB/hour
At that point, the question is no longer whether the MCU can connect to a digital microphone. The real questions are where to buffer the data, whether to compress it, how much external storage is needed, when to write flash, when to transfer over BLE, and what happens when the phone is not available.
Health sensing creates the same issue at a different scale. A 25 Hz sensor produces 2,160,000 samples per day. At 16 bit, a single channel already represents about 4.32 MB of raw data per day.
25 Hz × 86,400 s = 2.16 million samples/day ≈ 4.32 MB/day at 16 bit
That is why we design the full data path — Sensor / Audio → Processing → Storage → BLE → APP — rather than treating the SoC as an isolated component.
04 Different Apollo families fit different product budgets
We do not treat a newer Apollo generation as automatically better. Different products need different balances of compute, memory, display, audio and connectivity.
Apollo3: sensing, BLE and low power first
Apollo3 Blue Plus uses Cortex-M4F up to 96 MHz, with up to 2 MB flash and 768 KB RAM, plus BLE, PDM and common sensor interfaces. For products centered on sensor acquisition, basic local processing and BLE, that resource profile remains relevant.
Apollo4: more graphics and memory for display-based wearables
Apollo4 Blue Plus runs up to 192 MHz and provides up to 2.75 MB RAM, 2 MB MRAM, a 2D / 2.5D GPU and display support up to roughly 500 × 500 pixels. Once a product adds watch faces, animation, dashboards and touch interaction, the SoC is no longer just a sensor controller.
Apollo330 Plus: local signal processing becomes more practical
Apollo330 Plus moves to Arm Cortex-M55 with Helium at up to 250 MHz, with 2 MB SRAM and 2 MB NVM, plus stronger audio, high-speed external-memory and connectivity options. The important change for us is not the clock speed alone, but a better foundation for DSP, audio processing, sensor fusion, TinyML and edge preprocessing.
Apollo5: the on-device AI boundary moves further forward
Apollo510 is the first Apollo5 device. It runs up to 250 MHz and increases on-chip resources to 4 MB NVM and 3.75 MB SRAM. In Ambiq’s own AI/ML benchmark framing, Apollo510 can deliver up to 10× performance and 30× power efficiency versus a typical Cortex-M4F. That is a vendor benchmark rather than a promise for every model, but it clearly shows the direction: more speech, health and sensor workloads can remain on the battery-powered endpoint.
05 We do not push AI onto the device just because the SoC can run it
If a product mainly needs to capture, store and synchronize data before sending it to an app or the cloud, more SRAM, more CPU performance and heavier edge-AI capability may not create proportional product value.
If the device needs local noise reduction, voice activity detection, sensor fusion, health-signal processing, feature extraction or selected inference tasks, the compute, memory and firmware requirements become very different.
That is why we do not read Apollo3, Apollo4, Apollo330 Plus and Apollo5 as a simple performance ladder. The real question is how much computation belongs on the device, and how much power, memory, PCB area and BOM the product is willing to spend on it.
06 What Hulin actually does on the Apollo platform
For Hulin, the Apollo capability boundary sits mainly above the SoC, in product engineering.
During product definition, we select the platform and peripheral architecture around battery, sensing, audio, display, connectivity, local processing and product size. On hardware, that continues into power architecture, schematics, PCB design, peripheral integration and board bring-up.
On firmware, we work with AmbiqSuite and public SDK / BSP resources for peripheral drivers, sensors, BLE, audio, storage, low-power states, OTA, security architecture and device protocols, then continue into device SDKs, app integration, data synchronization, prototype validation, DV and production test planning.
Our boundary is not Ambiq’s silicon design, internal RF IP or closed-source modules. When an issue reaches silicon errata, closed-source stacks or chip-level behavior, Ambiq support remains part of the engineering path.
Our job is to turn the SoC, SDK and development ecosystem into a wearable product that can be built, validated and taken toward production.
Data sources
Chip specifications and performance figures are taken from Ambiq’s public materials. Comparative AI performance figures use Ambiq’s own benchmark methodology and should not be read as a guarantee that every workload or product will achieve the same ratio.
• Ambiq — Apollo330 Plus Series
Hulin Technology
Hulin develops AI recording wearables, health wearables, display-based wearables and other new form factors, with engineering support spanning product definition, SoC and PCBA, embedded firmware, sensors, audio, BLE, mobile applications, cloud services and AI integration.
On the Ambiq Apollo platform, our focus is product engineering: selecting an architecture around size, battery life, sensing, display, audio, local processing and data flow, then taking it through Hardware → Firmware → APP → Product Validation.
Apollo is the SoC. Turning it into a product is a different engineering problem.
Contact Us
Email: allen.yue@szhulin.com
Mobile: +86 13510104324
WeChat Official Account: 虎麟科技
Hulin Technology | AI Wearables