36  Hardware Platform Selection

In 60 Seconds

Match hardware to power and complexity: ESP32 (, 10uA deep sleep) for battery-powered sensors lasting years; Raspberry Pi (5, 2.5W continuous) only when full OS, vision, or ML is needed. At 1,000 units, this choice means K vs 5K in hardware costs alone.

Sensor Squad: Choosing the Right Brain

The Sensor Squad was building a new project, and they needed to pick a “brain” for their device!

Sammy the Sensor said: “I just need to check the temperature every minute and send a tiny message. That’s super easy!”

Max the Microcontroller volunteered: “Pick me! I’m like a bicycle – simple, efficient, and I can run for YEARS on Bella the Battery’s power. I cost only $5!”

But then Lila the LED said: “Wait, I need to analyze video from a camera and recognize faces. That’s really complicated!”

A Raspberry Pi stepped forward: “That’s MY job! I’m like a car – more powerful, can run complex programs, but I need a lot more energy. I cost $50 and need to be plugged in.”

Bella the Battery was relieved: “Please use Max for simple sensors! With the Raspberry Pi, I’d be drained in just 5 days. With Max in deep sleep mode, I can last 5 YEARS!”

The lesson: Use the smallest brain that gets the job done. A bicycle is perfect for a trip to the store – you don’t need a truck!

36.1 Learning Objectives

By the end of this chapter, you will be able to:

• Compare Hardware Platforms: Evaluate microcontrollers vs single-board computers for IoT applications
• Apply Selection Criteria: Use power, cost, and complexity factors to choose appropriate hardware
• Implement Device Selection Logic: Build automated systems for matching requirements to hardware
• Calculate Power Budgets: Determine battery life and energy requirements for IoT deployments

36.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Edge, Fog, and Cloud Overview: Understanding the differences between microcontrollers (edge nodes), single-board computers (fog nodes), and cloud platforms helps inform hardware selection decisions based on processing requirements
• Wireless Sensor Networks: Familiarity with sensor node characteristics, energy constraints, and network requirements provides context for choosing low-power MCUs versus more capable processors

Cross-Hub Connections

Enhance your learning by exploring related resources:

• Simulations Hub: Try interactive tools for protocol comparison, power budget calculations, and ADC resolution analysis
• Videos Hub: Watch development environment setup tutorials, Arduino programming guides, and Raspberry Pi configuration videos
• Knowledge Gaps Hub: Clarify common misconceptions about MCU vs SBC selection and power budget calculations

For Beginners: IoT Development Platforms

Imagine building a smart home project. You need to choose between different “brains” for your devices - like choosing between a basic calculator (microcontroller) or a laptop (single-board computer). The right choice depends on what you’re trying to do.

Everyday Analogy: Think of IoT development platforms as different types of vehicles. An Arduino (microcontroller) is like a bicycle - simple, energy-efficient, perfect for basic tasks like reading a temperature sensor. A Raspberry Pi (single-board computer) is like a car - more powerful, can run complex applications, but needs more energy. Your choice depends on the journey ahead.

Term	Simple Explanation
Microcontroller (MCU)	A tiny computer on a chip, runs one program at a time (like Arduino, ESP32)
Single-Board Computer (SBC)	A complete computer on one board that runs an OS like Linux (like Raspberry Pi)
ADC (Analog-to-Digital Converter)	Converts real-world signals (temperature, light) into digital numbers the computer understands
GPIO Pins	General-purpose input/output connections where you attach sensors and actuators
Power Budget	How much battery life you have - every feature uses energy

Why This Matters for IoT: A temperature sensor reading every minute needs only a $5 Arduino running on batteries for years. But a security camera analyzing video for face detection needs a $50 Raspberry Pi with constant power. Choosing the wrong platform wastes money, power, or performance - understanding the trade-offs is crucial for successful IoT projects.

Common Misconception: “More Processing Power is Always Better”

Misconception: Many beginners assume that choosing the most powerful processor (like Raspberry Pi) is always the best choice for IoT projects.

Reality: The optimal hardware depends on your specific requirements - power consumption, cost, and complexity matter as much as processing capability.

Why This Matters:

• Battery Life Impact: A Raspberry Pi consumes 2.5W (500mA @ 5V), while an ESP32 in deep sleep uses only 10μA - that’s a 250,000× difference! For battery-powered sensors, an MCU lasting 5 years beats a powerful SBC lasting 5 days.
• Cost at Scale: Deploying 1,000 door sensors with $5 ESP32s costs $5,000. Using $50 Raspberry Pis costs $50,000 - a 10× difference that makes or breaks commercial IoT deployments.
• Unnecessary Complexity: Running Linux on a sensor that just reads temperature every minute adds boot time, security vulnerabilities, and maintenance overhead with no benefit.

Example: A smart agriculture project tried using Raspberry Pis for soil moisture sensors. Battery life was only 3 days. Switching to ESP32 MCUs extended battery life to 2+ years and reduced per-node cost from $50 to $8 - same functionality, drastically better economics.

Rule of Thumb: Use MCUs (Arduino, ESP32) for simple, battery-powered sensors and actuators. Use SBCs (Raspberry Pi) only when you need an operating system, computer vision, AI/ML, or serve as a gateway aggregating data from multiple sensors.

Pitfall: Testing Only on Development Board USB Power

The Mistake: Developers test their IoT firmware exclusively with the development board powered via USB, then deploy to battery-powered production devices expecting identical behavior.

Why It Happens: USB provides stable 5V at 500mA+ regardless of load. During development, brownout resets, voltage sags during Wi-Fi transmission, and low-battery conditions never occur. The code “works perfectly” in the lab.

The Fix: Test with actual deployment power source early and often. Use a variable power supply to simulate battery voltage drop (4.2V fresh to 3.0V depleted for LiPo). Add brownout detection handlers in firmware. Test Wi-Fi/BLE transmission at minimum battery voltage - radios often fail before the MCU does. Include voltage monitoring in telemetry to catch field issues before complete failure.

Key Takeaway

In one sentence: Match the development platform to your power and complexity needs - a $5 ESP32 running for years on batteries beats a $50 Raspberry Pi that dies in days, unless you actually need Linux.

Remember this: For 1,000 battery sensors, choosing ESP32 over Raspberry Pi saves $45,000 in hardware and potentially millions in battery replacement labor over 5 years.

36.3 Device Selection Decision Tree

Figure 36.1: IoT Hardware Selection Decision Tree: MCU vs SBC by Power and Processing

import { InlineKnowledgeCheck } from "../assets/js/iotclass-inline-kc.js"

viewof kc_hardware_1 = InlineKnowledgeCheck({
  id: "kc-hardware-1",
  question: "A smart home hub needs to run Docker containers, host a web server, perform computer vision on camera streams, and run multiple Python applications. Which processor type is most appropriate?",
  choices: [
    "8-bit microcontroller (Arduino ATmega328) - low cost and power efficient",
    "Single-board computer (Raspberry Pi) - runs full Linux OS with containers",
    "32-bit microcontroller (ESP32) - has Wi-Fi and Bluetooth built-in",
    "FPGA (Field Programmable Gate Array) - most flexible hardware"
  ],
  correctIndex: 1,
  explanation: "Requirements need an SBC: Docker, web servers, Python, and computer vision require a full operating system (Linux) with gigabytes of RAM - only SBCs like Raspberry Pi provide this. MCU limitations: 8-bit/32-bit MCUs have KB of RAM (not GB), can't run Linux or Docker, and lack processing power for vision. ESP32: Great for sensors/actuators but limited to FreeRTOS and simple tasks. FPGA: For specialized hardware acceleration, not general computing. Architecture match: Use MCU for sensors, SBC for gateways/hubs, cloud for heavy analytics."
})

viewof kc_hardware_2 = InlineKnowledgeCheck({
  id: "kc-hardware-2",
  question: "You need to deploy 1,000 battery-powered door sensors that wake once per minute to read a reed switch and send a tiny status update. Which platform best matches the power and cost constraints?",
  choices: [
    "Single-board computer (Raspberry Pi) running Linux for flexibility",
    "Industrial PC with x86 CPU for reliability",
    "Low-power microcontroller (Arduino/ESP32-class) with deep sleep",
    "Cloud-only design (no device-side compute)"
  ],
  correctIndex: 2,
  explanation: "Battery sensors need microamp-level sleep currents and simple real-time logic. MCUs can duty-cycle aggressively and run for years on batteries, while SBCs/PCs consume watts continuously. 'Cloud-only' can't read a physical switch without an edge device."
})

viewof kc_hardware_3 = InlineKnowledgeCheck({
  id: "kc-hardware-3",
  question: "You're prototyping a smart irrigation controller that needs to: read 4 soil moisture sensors (analog), control 4 solenoid valves (relay), display status on OLED (I2C), connect to Wi-Fi for remote monitoring, and run for 3 days on battery between charges. Which prototyping platform best matches these requirements?",
  choices: [
    "Arduino Uno (ATmega328, 5V, 6 analog pins, no built-in Wi-Fi)",
    "ESP32 DevKit (dual-core, Wi-Fi/BLE, 18 analog pins, 3.3V, low power modes)",
    "Raspberry Pi Zero W (Linux, Wi-Fi, no analog inputs, 500mA idle current)",
    "BBC micro:bit (limited GPIO, designed for education, no Wi-Fi)"
  ],
  correctIndex: 1,
  explanation: "ESP32 DevKit is ideal for this application: (1) Built-in Wi-Fi - connect to cloud/mobile app without external modules; (2) 18 ADC channels (12-bit) - easily read 4 moisture sensors with room for expansion; (3) 30+ GPIO pins - control 4 relays, I2C OLED, plus future sensors; (4) Deep sleep mode - 10μA sleep current enables 3-day battery life (wake every 30 min, read sensors, transmit, sleep); (5) Dual-core - dedicate core 0 to sensor reading, core 1 to Wi-Fi without blocking; (6) FreeRTOS - task scheduler for reliable control; (7) 520KB RAM - buffer sensor history for batch upload. Cost: $5-10. Real example: Thousands of ESP32-based irrigation controllers deployed in commercial agriculture with 5+ years field experience. Battery calculation: 2000mAh battery, 50mA active × 30s per wake + 10μA sleep × 30min = ~85 hours = 3.5 days. Arduino Uno lacks Wi-Fi and low power. Raspberry Pi can't achieve 3-day battery life. micro:bit is educational only."
})

36.4 Platform Evolution by Project Phase

Alternative View: Platform Selection by Project Phase

This variant shows how development platform choices evolve from prototype to production, helping practitioners understand when to upgrade hardware.

Figure 36.2: Alternative view: Development platforms evolve with project maturity. Prototyping prioritizes speed and flexibility (development boards, USB power). Pilot deployments test battery life and environmental factors with semi-custom designs. Production requires cost optimization through custom PCBs and regulatory certification.

36.5 Hands-On Lab: IoT Device Selection for Smart Home

Objective: Select appropriate processors for various smart home devices.

Scenario: You are designing a smart home system with the following devices:

1. Door Sensor: Detects door open/close, sends alert via Wi-Fi
   • Requirements: Very low power (battery), Wi-Fi, simple logic, 5 GPIO pins
   • Budget: $5, 50mW average power
2. Smart Thermostat: Controls HVAC, displays temperature, connects to cloud
   • Requirements: Display interface, Wi-Fi, temperature sensing, moderate processing
   • Budget: $20, 500mW power
3. Security Camera: Video processing, motion detection, cloud storage
   • Requirements: Video encoding, AI for motion detection, Ethernet/Wi-Fi
   • Budget: $50, 2W power

Tasks:

1. For each device, define an IoTApplicationProfile
2. Use the IoTDeviceSelector to find suitable processors
3. Compare the top 2 candidates for each device
4. Calculate total system cost
5. Identify any common processors that could be reused

Deliverables:

• Selection justification for each device
• Cost comparison table
• Power budget spreadsheet

36.6 Hands-On Lab: Power Budget Optimization

36.6.1 Interactive: IoT Battery Life Calculator

viewof battery_cap = Inputs.range([500, 10000], {value: 3000, step: 100, label: "Battery Capacity (mAh)"})

viewof events_per_day = Inputs.range([1, 1000], {value: 20, step: 1, label: "Active Events per Day"})

viewof tx_current_ma = Inputs.range([10, 300], {value: 180, step: 10, label: "Transmission Current (mA)"})

viewof tx_duration_ms = Inputs.range([100, 10000], {value: 3000, step: 100, label: "Transmission Duration (ms)"})

sleep_ua = 10  // ESP32 deep sleep
sense_ma = 20
sense_ms = 100

energy_per_event_mah = (sense_ma * (sense_ms / 3600000)) + (tx_current_ma * (tx_duration_ms / 3600000))
daily_active_mah = events_per_day * energy_per_event_mah
daily_sleep_mah = sleep_ua / 1000 * 24
total_daily_mah = daily_active_mah + daily_sleep_mah
battery_life_days = battery_cap / total_daily_mah

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
  <p><strong>Energy per Event:</strong> ${(energy_per_event_mah * 1000).toFixed(2)} µAh</p>
  <p><strong>Daily Active Consumption:</strong> ${daily_active_mah.toFixed(3)} mAh/day</p>
  <p><strong>Daily Sleep Consumption:</strong> ${daily_sleep_mah.toFixed(3)} mAh/day</p>
  <p><strong>Estimated Battery Life:</strong> <strong>${battery_life_days.toFixed(0)} days (${(battery_life_days / 365).toFixed(1)} years)</strong></p>
  <p style="font-size:0.85em; color:#555;">Assumes ESP32 deep sleep at 10µA, sensor read at 20mA for 100ms, user-defined TX parameters.</p>
</div>`

Objective: Optimize power consumption for battery-operated IoT device.

Real-World Context: This lab is based on actual deployments by The Things Network (TTN) and Helium Network where environmental sensor nodes must operate for 2-5 years on battery power. Real deployments in smart cities (Barcelona, Amsterdam) and agriculture (California vineyards, Australian farms) demonstrate these exact power optimization techniques save millions in maintenance costs by eliminating frequent battery replacements.

Scenario: Environmental sensor node powered by 2x AA batteries (3000mAh @ 3.0V).

Components:

• ESP32 MCU: 160mA active, 10μA sleep
• BME280 sensor: 3.6mA active, 0.1μA sleep
• LoRa radio: 120mA TX, 15mA RX, 1μA sleep
• Status LED: 20mA when on

Operating modes:

• Mode 1 (Always-on): MCU always active, sensor reads every second, transmit every 10 seconds
• Mode 2 (Power-saving): MCU deep sleep, wake every 5 minutes, sensor read + transmit, LED blinks on transmit
• Mode 3 (Ultra-low-power): Wake every 30 minutes, quick sensor read, transmit, no LED

Tasks:

1. Model all three modes using PowerBudgetCalculator

2. Calculate for each mode:

   • Average current consumption
   • Battery lifetime (days/months)
   • Data transmission frequency

3. Create power profile showing:

   • Component breakdown (pie chart)
   • Timeline of current consumption over typical day

4. Design hybrid mode:

   • Normal operation: Mode 2
   • Alert condition: Switch to Mode 1 for 1 hour
   • Calculate impact on battery life

5. Solar panel sizing:

   • What panel size maintains battery charge in Mode 2?
   • Assume 4 hours effective sunlight per day

Deliverables:

• Power budget table for all modes
• Battery lifetime comparison
• Solar panel recommendation
• Operational mode recommendation

36.7 Visual Reference Gallery

Visual: Basic Sensor Node Components

Basic components of a sensor node

This visualization shows the essential components that make up an IoT sensor node, providing context for hardware selection decisions covered in this chapter.

Worked Example: Power Budget Calculation for Battery-Powered Door Sensor

Scenario: Design a battery-powered door sensor that reports open/close events via Wi-Fi. Must last 2 years on 2x AA batteries (3000 mAh at 3V). Calculate if ESP32 meets requirements.

Given:

• Battery: 3000 mAh at 3V = 9000 mWh capacity
• Target life: 2 years = 17,520 hours
• Door activity: 20 open/close events per day (realistic for residential door)
• Wi-Fi: Home network available

Step 1 - Define Operating Modes:

Mode	Current	Duration per Event	Frequency
Deep sleep	10 µA	99.9% of time	Continuous
Wake + sensor read	20 mA	100 ms	20 times/day
Wi-Fi connect + transmit	180 mA	3 seconds	20 times/day

Step 2 - Calculate Energy per Event:

Sensor reading:

Energy = 20 mA × 0.1 seconds = 2 mAs = 0.00056 mAh

Wi-Fi transmission:

Energy = 180 mA × 3 seconds = 540 mAs = 0.15 mAh

Total per event: 0.00056 + 0.15 = 0.15056 mAh

Step 3 - Calculate Daily Energy:

Active energy: 20 events × 0.15056 mAh = 3.01 mAh/day
Sleep energy: 24 hours × 0.01 mA = 0.24 mAh/day
Total daily: 3.01 + 0.24 = 3.25 mAh/day

Step 4 - Calculate Battery Life:

Battery life = 3000 mAh / 3.25 mAh/day = 923 days = 2.53 years

Result: YES, ESP32 meets the 2-year requirement with 25% margin!

Putting Numbers to It

General battery life formula for duty-cycled IoT devices:

\[ L_{\text{days}} = \frac{C_{\text{battery}}}{I_{\text{sleep}} \times t_{\text{sleep}} + n \times (I_{\text{sense}} \times t_{\text{sense}} + I_{\text{TX}} \times t_{\text{TX}})} \]

Where \(n\) = events/day. For our door sensor (\(C = 3000\) mAh, \(I_{\text{sleep}} = 0.01\) mA, \(n = 20\)):

\[ L = \frac{3000}{0.01 \times 24 + 20 \times (20 \times 0.1/3600 + 180 \times 3/3600)} = 923 \text{ days} \]

Sensitivity: Doubling event frequency (\(n = 40\)) drops life to 564 days. Halving Wi-Fi TX power (\(I_{\text{TX}} = 90\) mA) extends to 1,285 days.

Step 5 - Sensitivity Analysis (What If…):

If door is busier (50 events/day instead of 20):

Daily: (50 × 0.15056) + 0.24 = 7.77 mAh/day
Life: 3000 / 7.77 = 386 days = 1.06 years (FAILS requirement)

Optimization for high-traffic scenario:

• Use BLE instead of Wi-Fi (20 mA vs 180 mA for transmission)
• BLE transmission: 20 mA × 1 sec = 0.0056 mAh per event
• Daily at 50 events: (50 × 0.0056) + 0.24 = 0.52 mAh/day
• Life: 3000 / 0.52 = 5769 days = 15.8 years

Key Insights:

1. Sleep current dominates only if active time is minimal (<0.1% duty cycle)
2. Wi-Fi is expensive: 180 mA connection cost makes it unsuitable for high-frequency battery devices
3. BLE saves 30x energy for short transmissions, enabling 10+ year battery life
4. Always add 20-30% margin for battery aging, cold temperatures, and unexpected door activity

Design Decision: Use ESP32 with BLE (not Wi-Fi) for reporting to a hub that has Wi-Fi/internet connectivity. This gives 15-year battery life even with 50 events/day.

Match: Hardware Platform Concepts

Order: Hardware Selection Decision Process

Key Concepts

• MCU (Microcontroller Unit): A single-chip computer integrating CPU, RAM, flash, and peripherals for low-power deterministic embedded control, costing $1–15 in volume
• MPU (Microprocessor Unit): A CPU-only chip requiring external RAM and storage, capable of running Linux for IoT gateways and edge applications requiring rich OS services
• ESP32: A dual-core 240 MHz Xtensa LX6 MCU with integrated Wi-Fi and Bluetooth, popular for IoT prototyping at $3–8 price point with vast community support
• Raspberry Pi: A single-board computer running Linux on ARM Cortex-A, used for IoT gateways and edge applications requiring full OS capabilities at 2–5 W power draw
• BOM (Bill of Materials): The complete list of electronic components required to build a PCB, with unit costs and quantities, used for cost estimation and procurement planning
• Supply Chain Risk: The probability that a chosen component becomes unavailable due to chip shortages, EOL notices, or single-source supply — mitigated by identifying secondary-source alternatives during design
• Power Budget: A spreadsheet or calculation summing the current draw of all components in all operating modes, weighted by duty cycle, to estimate total average power consumption and battery lifetime

Common Pitfalls

1. Selecting MCU by Familiarity Rather Than Requirements

Choosing an Arduino Uno for a project requiring Wi-Fi, only to discover it has no built-in networking and 2 KB RAM is insufficient for MQTT libraries. Always map connectivity, memory, and power requirements to MCU capabilities before evaluating familiarity.

2. Underestimating RAM for Networking Stacks

ESP32 applications using MQTT + TLS + JSON can consume 80–120 KB of heap. Choosing MCUs with only 32 KB RAM means the networking stack alone exceeds available memory. Add 50% margin to RAM estimates for networked IoT applications.

3. Ignoring Supply Chain Availability

Designing around a single MCU with unpredictable lead times — the 2021 chip shortage caused 52-week delays on popular STM32 parts. Always identify pin-compatible secondary sources during hardware design.

4. Using Development Boards in Production

Shipping products with NodeMCU or Arduino Uno development boards because prototyping worked. Development boards include USB chips, extra regulators, and exposed pads that waste power and space. Design a custom PCB or use production-grade modules for deployment.

Label the Diagram

💻 Code Challenge

36.8 Summary

This chapter explored hardware platform selection for IoT systems:

• Microcontrollers (MCU): Arduino, ESP32, and similar platforms excel for battery-powered, single-purpose devices with simple logic and real-time requirements. Deep sleep modes enable multi-year battery life.
• Single-Board Computers (SBC): Raspberry Pi and similar platforms are appropriate when you need a full operating system, computer vision, AI/ML, or gateway functionality aggregating multiple sensors.
• Selection Criteria: Power budget, cost at scale, processing requirements, and connectivity needs drive hardware decisions. A $5 ESP32 often outperforms a $50 Raspberry Pi for simple sensor applications.
• Project Phase Evolution: Hardware choices evolve from development boards (prototyping) through custom shields (pilot) to custom PCBs (production) as projects mature and scale requirements increase.
• Power Budget Planning: Understanding component power consumption across active, transmit, and sleep states is critical for battery-powered deployments.

Related Chapters

Deep Dives:

• Prototyping Hardware - Arduino, ESP32, Raspberry Pi guides
• Specialized Kits - Development boards comparison
• Energy-Aware Design - Power budget planning

Comparisons:

• Edge-Fog-Cloud Overview - MCU vs SBC vs cloud processing
• Sensor Fundamentals - ADC and sensor interfaces

36.9 Knowledge Check

Quiz: Hardware Platform Selection

36.10 What’s Next

Direction	Chapter	Description
Next	Serial Communication Protocols	I2C, SPI, and UART for connecting sensors and peripherals
Next	Development Workflow and Tooling	IDEs, CI/CD pipelines, and OTA update strategies
Back	Development and Tools Overview	Overview of the three development pillars