IoT hardware design guide — sub-100uA sleep architecture, BLE vs WiFi vs LoRa vs 433MHz vs cellular selection, antenna design, and battery math. Lessons from Apollo2 terminals, ESP32 sensors, smart locks, and a 7-day smartwatch.
Strip away the dashboards and the cloud platforms, and every IoT hardware project is judged on two numbers: how long the battery lasts, and whether the wireless link works where the device actually gets installed. Get both right and the software team gets to be heroes; get either wrong and no amount of firmware cleverness saves the product. A sensor that dies in three months or drops off the network behind a concrete wall is not a product — it is a support ticket generator.
We have designed IoT hardware from Apollo2-based ultra-low-power terminals to ESP32 sensor nodes, smart locks, and tracking modules. This guide covers the two numbers: the low-power architecture that gets you to years of battery life, and the wireless selection framework that keeps devices connected.
The most common low-power mistake is reading the MCU's sleep current from the datasheet and declaring victory. The datasheet number is real, but your product's battery life is determined by the duty cycle — what fraction of time the device spends awake, and how much everything else on the board draws while the MCU sleeps.
The Apollo2 low-power IoT terminal (Wuhan_Apollo2) shows the full discipline: Deep Sleep modes with driver code for GPRS, GPS, RTC, ADC, Flash, and watchdog, supporting multiple toolchains (Keil/IAR/GCC). The Apollo2 MCU is famous for its sub-threshold operation — sleep currents measured in microamps — but the project still had to manage every peripheral: the GPS that draws milliamps if left on, the GPRS module with its amp-scale transmit bursts, the RTC that must keep time through it all.
The low-power design method we apply to every IoT board:
The low-power smartwatch project (smartwatch) set brutal targets and hit them: 100µA standby current, 7-day battery life, heart-rate accuracy ±2bpm, 50+ sport modes, 5ATM waterproofing. Hitting 100µA standby with an always-on display-capable device required every trick in the book — the Apollo2-class MCU philosophy applied to a consumer product: aggressive clock gating, display memory that holds the frame without the MCU, sensor sampling scheduled in bursts, and a radio that spends 99.9% of its life asleep.
The lesson generalizes: the difference between a 1-day and a 7-day device is rarely one big win. It is twenty small wins — each peripheral's sleep mode, each wake-up source, each millisecond shaved off the transmit window — compounded.
Engineers tend to have a favorite radio. Resist it. The right wireless technology falls out of five questions:
Our projects span the whole map. The gas sensor IoT terminal (HH_GasSensor) uses ESP32 with WiFi — the right call for a mains-or-large-battery device that needs OTA firmware upgrades and cloud device management. The ESP32 air quality collector (env_monitor) similarly leans on WiFi for straightforward data upload. The multi-sensor tracking module (BLE_GSENSOR_GPS_GSM) combines BLE, G-sensor, GPS, and GSM on the QMS7926 platform — short-range phone connectivity plus wide-area cellular tracking, because a tracker that only works near a phone is not a tracker.
And sometimes the unfashionable choice wins: the marine data transmission unit (BOAT_DTU) uses 433MHz wireless with an STM32F1 for shipboard data aggregation — sub-GHz penetrates the steel environment better than 2.4GHz, the modules cost almost nothing, and the data rate fits the application. The 433MHz security linkage system (433_IPC) pairs STC32G-based 433MHz terminals with cameras and a Flutter mobile app — proving sub-GHz still earns its place in 2026.
A perfect radio with a bad antenna is a bad radio. Antenna mistakes we see repeatedly:
Battery capacity is not what the label says. Derate for temperature (cold kills capacity), for discharge rate (pulse loads reduce usable capacity), for self-discharge over the product's lifetime, and for the cutoff voltage of your regulators. Then add margin. The smart lock (smart_lock) — with fingerprint, face, password, IC card, WiFi remote control, and temporary passwords — has to budget for the motor-driven bolt (the pulse load), the always-listening touch wake, and the WiFi bursts, all from batteries the user replaces. Getting the battery math right is what separates a lock that warns "low battery" gracefully from one that strands someone outside.
Wireless products need radio certification (FCC, CE, SRRC/MIC/TELEC depending on market), and most markets also require EMC and safety testing. Certification is slow — lab slots book weeks out, failures require redesign and retest — so it belongs in the project plan from the start, not as a surprise at the end. Using pre-certified radio modules dramatically simplifies radio certification (in many regimes the module grant transfers), though the final product still needs EMC testing as a complete system. We schedule pre-scan EMC testing on EVT boards: catching a radiated-emissions failure on a $500 pre-scan beats discovering it during the $15,000 formal test.
Electrical engineers obsess over schematics and forget that the enclosure is part of the circuit. A sealed outdoor enclosure turns into a greenhouse — internal temperatures 20°C above ambient are normal in direct sun, which derates battery capacity, shifts crystal frequencies, and pushes regulators toward thermal shutdown. Venting helps, but every vent is a path for water and dust; Gore-style breathable membranes balance the two for genuinely outdoor products.
Material choice matters for the radio too. A metal enclosure around a 2.4GHz antenna is a Faraday cage with extra steps — either the antenna goes outside the metal, or the enclosure gets a plastic RF window. We specify the enclosure material alongside the PCB stackup, not after the mechanical design is "done," because moving an antenna late means re-tuning, re-testing, and sometimes re-certifying. The smart doorbell (smart_doorbell), with its camera, PIR sensor, and WiFi living behind a weather-exposed faceplate, is a good example of a product where the enclosure, the optics, and the RF design had to be solved as one problem.
IoT hardware design is applied physics: duty-cycle the power budget until the battery math closes, pick the radio from requirements rather than habit, design the antenna as a first-class citizen, and derate the battery like a pessimist. The devices that survive the field — the 7-day watch, the terminal that sleeps at microamps, the tracker that roams on cellular — all share the same trait: their two numbers were computed before the schematic was drawn.
If you are designing a connected device — sensor node, tracker, smart home product — our IoT development service covers hardware, firmware, and cloud together. For the system-level view, see our IoT system architecture guide; for the AI-on-device angle, see AI meets IoT.
Contact us for customized solutions and quotes