How IoT Devices Work: Sensors, Processors, and Connectivity Explained

Every IoT device — whether it’s a $10 smart plug or a $500 industrial vibration analyzer — is built from the same fundamental hardware building blocks. Understanding these layers isn’t just academic: the choices made about processors, sensors, radios, and power supplies determine whether a product ships on time, lasts in the field, and succeeds commercially. This guide walks through the complete hardware anatomy of an IoT device, explains how each layer contributes to the whole, and highlights the engineering decisions that separate good IoT products from great ones.

The Microcontroller Unit (MCU): The Brain of Every IoT Device

At the heart of virtually every IoT device sits a microcontroller unit (MCU) — a compact integrated circuit that contains a processor core, memory, and programmable peripherals all on a single chip.

Unlike the microprocessors in smartphones and computers, MCUs are optimized for:

• Low power consumption — many can operate at microamperes in sleep mode
• Real-time operation — deterministic response to external events
• Peripheral integration — GPIO pins, SPI, I2C, UART, ADC, PWM all on-chip
• Cost efficiency — capable MCUs start under $1 in volume

The MCU landscape for IoT is dominated by a few architectural families:

ARM Cortex-M series powers the vast majority of IoT products. The Cortex-M0/M0+ is the lowest-power option (used in devices like coin-cell sensors), while Cortex-M4 (with FPU) and Cortex-M33 handle more demanding signal processing workloads. Silicon vendors including STMicroelectronics, Nordic Semiconductor, NXP, and Microchip all build MCUs on ARM Cortex-M cores.

RISC-V is an increasingly important open-source alternative. Espressif’s ESP32-C series and a growing number of industrial MCUs now use RISC-V cores, attracted by the royalty-free instruction set architecture and active open-source toolchain.

Xtensa LX7 powers the popular ESP32-S3 from Espressif, delivering strong Wi-Fi+BLE performance in a very cost-effective package.

Key MCU parameters that IoT engineers evaluate when selecting a chip:

• Clock speed (MHz) — affects processing throughput and power consumption
• Flash storage — where firmware is stored; typically 256KB to several MB
• RAM — working memory for the application; often 32KB to 512KB in constrained devices
• Sleep current — microamperes matter enormously in battery-powered devices
• Peripheral set — available communication interfaces, hardware cryptography accelerators, ADC channels

Sensors: Translating Physics Into Data

Sensors are the IoT system’s connection to physical reality. They convert a physical phenomenon — light, temperature, motion, pressure, chemical concentration, magnetic field — into an electrical signal that the MCU can read.

Common sensor categories in IoT:

Sensor Type	Measurement	Common Examples
Temperature/humidity	Ambient environment	DHT22, SHT4x, BME280
Inertial (IMU)	Acceleration, gyroscope	MPU-6050, ICM-42688
Pressure	Atmospheric, liquid pressure	BMP390, MS5611
Optical	Light level, color, proximity	APDS-9960, OPT3001
Gas/chemical	CO2, VOC, particulates	SCD40, BME688
Current/voltage	Power monitoring	INA226, ACS712
GNSS	Position	u-blox M10, Quectel LC86G

Sensors communicate with the MCU over standard interfaces:

• I2C (Inter-Integrated Circuit) — two-wire bus, ideal for multiple sensors sharing a bus, speeds to 400kHz or 1MHz
• SPI (Serial Peripheral Interface) — four-wire, faster (up to 50MHz+), better for high-throughput sensors like displays or ADCs
• UART — serial communication, common for GPS modules and gas sensors
• Analog — direct voltage output, read by the MCU’s ADC (analog-to-digital converter)
• 1-Wire — single-wire protocol used by Dallas/Maxim temperature sensors like the DS18B20

Sensor fusion — combining data from multiple sensors to derive higher-level insights — is a key firmware challenge. Combining accelerometer and gyroscope data with a complementary filter, for instance, produces stable orientation estimates that neither sensor could provide alone.

Connectivity Hardware: Getting Data Off the Device

An IoT device that can’t communicate its data is just a sensor logger. The connectivity stack is what makes a device truly “IoT.”

Short-range wireless:

• Wi-Fi 802.11b/g/n/ax — high bandwidth, existing infrastructure, but power-hungry. Best for mains-powered devices. Wi-Fi 6 (802.11ax) brings Target Wake Time (TWT), dramatically reducing power for battery devices.
• Bluetooth Low Energy (BLE) — optimized for intermittent, low-volume data. BLE 5.x supports mesh networking and long-range modes. Common in wearables, beacons, and asset tracking.
• Zigbee — mesh networking protocol at 2.4GHz, widely used in smart home (Philips Hue, Amazon Sidewalk). Now underpinned by the Matter/Thread ecosystem.
• Thread — IPv6-based mesh built on 802.15.4. Used in Matter-compliant smart home devices.

Long-range wireless:

• LoRa/LoRaWAN — sub-GHz chirp spread spectrum, range up to 15km in rural areas, extremely low power. Ideal for outdoor agricultural or infrastructure sensors. The Things Network operates a global public LoRaWAN network.
• NB-IoT / LTE-M — cellular IoT standards for low-bandwidth, long-range, low-power applications. Operates on licensed spectrum; better for applications requiring guaranteed connectivity.
• 5G NR-RedCap — emerging cellular category targeting IoT devices that need more bandwidth than NB-IoT but less than full 5G.

The connectivity choice profoundly affects hardware design — antenna layout, RF interference management, and power rail design all change depending on the radio in use.

Power Management: The Engineering Challenge Nobody Talks About Enough

For mains-powered devices, power is rarely a constraint. But the majority of IoT deployments involve battery-powered devices, and power management is often the hardest engineering problem in the entire product.

Consider a device powered by two AA batteries (approximately 3,000 mAh total). To last 10 years, it must consume an average of only 34 microamperes. Achieving this requires a comprehensive power strategy:

MCU sleep modes: Modern MCUs have multiple sleep states. The STM32L4, for example, offers:

• Run — full operation, ~1-5mA
• Sleep — CPU halted, peripherals running, ~500µA
• Stop 2 — most clocks off, ~2µA, wakeup in microseconds
• Standby — near-off, ~0.5µA, wakeup from external pins or RTC

Peripheral power gating: Sensors, radios, and other peripherals should be powered down when not in use. A load switch (P-MOSFET or dedicated IC) controlled by a GPIO allows firmware to cut power to individual subsystems.

Duty cycling: Rather than continuously transmitting, devices wake up on a schedule (e.g., every 15 minutes), take a measurement, transmit it, and go back to sleep. The ratio of active time to sleep time determines average current.

Power supply efficiency: A linear regulator is simple but wastes energy as heat. A synchronous buck converter can achieve 90%+ efficiency, dramatically extending battery life.

For a deep dive into power optimization techniques, see our article on low-power IoT device design.

Firmware: The Software Layer That Runs on the Metal

Firmware is the software that runs directly on the MCU. Unlike application software running on an OS, firmware typically has no memory protection, no virtual memory, and often no filesystem — it runs in a resource-constrained environment where every byte of RAM and flash matters.

Most IoT firmware is written in C, with some use of C++ for abstraction. Key firmware responsibilities include:

Hardware abstraction layer (HAL): Code that wraps low-level register operations into higher-level functions. Most MCU vendors provide HAL libraries — STM32 HAL, Nordic nRF5 SDK, ESP-IDF for Espressif chips.

RTOS integration: For complex devices managing multiple tasks (sensor sampling, connectivity, UI, OTA updates), a Real-Time Operating System like FreeRTOS or Zephyr provides task scheduling, inter-task communication, and timing services.

Protocol stacks: Wireless protocols require substantial firmware overhead. BLE requires a SoftDevice or similar stack. MQTT requires a TCP/IP stack and an MQTT client library like Eclipse Paho.

Application logic: The actual business logic — sampling sensors at the right interval, applying calibration curves, triggering alarms, managing state machines.

OTA update capability: Production IoT firmware must be updateable in the field. A secure bootloader with A/B partition scheme (two firmware slots) enables safe updates.

From Development Board to Production Hardware

IoT products typically follow a hardware maturation path:

Development/evaluation board — Boards like the Arduino, ESP32 DevKit, or Nordic DK make it easy to validate software concepts quickly. They prioritize accessibility over production-readiness.

Custom prototype PCB — Once the concept is validated, a custom PCB eliminates unnecessary components, optimizes layout for RF performance, and implements the exact power management strategy needed.

Engineering Validation Test (EVT) — First custom PCBs go through functional testing and design validation.

Design Validation Test (DVT) — A refined board revision addresses EVT issues, adds production testability features (test points, JTAG headers), and validates against regulatory requirements.

Production Validation Test (PVT) — Final boards manufactured in a production-representative run, validated against all requirements before mass production begins.

Our guide to IoT prototyping covers this process in detail.

The Role of Modules and System-on-Module (SoM)

Building custom RF hardware is expensive, time-consuming, and requires regulatory certification. For many IoT products, using a pre-certified wireless module is more practical than designing a bare SoC into the board.

Modules like the ESP32-WROVER, Nordic nRF9160-DK, and u-blox SARA-R4 integrate the SoC, RF circuit, antenna (or connector), and regulatory certifications (FCC, CE, etc.) in a single component. This dramatically reduces the barrier to Wi-Fi, BLE, or cellular connectivity.

The trade-off: modules cost more per unit than bare chips. At low volumes, the engineering time and regulatory cost savings easily justify modules. At high volumes (100K+ units/year), the unit cost delta often justifies moving to a fully custom design.

Conclusion

An IoT device is an elegantly complex system: an MCU at its core, sensors translating the physical world into data, a radio stack carrying that data to where it needs to go, firmware orchestrating it all, and power management ensuring it keeps running. Understanding how these layers interact — and the engineering trade-offs involved at each layer — is what separates IoT hardware that just works from hardware that works reliably for years in the field.

Whether you’re starting with a simple sensor node or designing a complex multi-radio industrial device, the fundamentals covered here apply universally. Explore UABit’s firmware and embedded development services to learn how we engineer IoT devices from silicon to software.

Further reading:

• ARM Cortex-M processor overview — architecture details from ARM
• Espressif ESP-IDF documentation — full ESP32 development framework
• Nordic Semiconductor Infocenter — nRF device documentation and SDKs
• FreeRTOS kernel documentation — RTOS fundamentals
• Embedded.com — practical embedded engineering articles and case studies
• electronicdesign.com IoT section — hardware design resources