11  Online Hardware Simulators

11.1 Learning Objectives

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

  • Configure Wokwi projects for Arduino and ESP32 simulation with sensors and Wi-Fi
  • Navigate Tinkercad Circuits for beginner-friendly visual programming
  • Compare SimulIDE capabilities for desktop-based real-time simulation
  • Evaluate Proteus Design Suite for professional embedded development
  • Choose the right simulator based on your project requirements
In 60 Seconds

Online hardware simulators like Wokwi and Tinkercad enable browser-based IoT prototyping without physical hardware, supporting ESP32, Arduino, and Raspberry Pi Pico with simulated sensors, displays, and communication peripherals. These tools are ideal for: initial firmware prototyping, educational exercises, collaborative debugging, and quick concept validation. Limitations include: no real-time constraints, simplified peripheral models, and no RF simulation for wireless protocols.

11.2 For Beginners: Online Hardware Simulators

Testing and validation ensure your IoT device works correctly and reliably in the real world, not just on your workbench. Think of it like test-driving a car in rain, snow, and heavy traffic before buying it. Thorough testing catches problems before your devices are deployed to thousands of locations where fixing them becomes expensive and disruptive.

“Let me introduce you to your new favorite tool – Wokwi!” said Max the Microcontroller excitedly. “It is a free online simulator where you can build Arduino and ESP32 projects right in your browser. Drag in components, write code, and click Run. No hardware needed!”

Sammy the Sensor demonstrated. “Watch – I drag in a DHT22 temperature sensor, connect it to Max’s GPIO pin, write three lines of code, and boom! The simulator shows a realistic temperature reading. I can even change the simulated temperature to test edge cases like freezing or boiling.”

Lila the LED loved Tinkercad Circuits. “For absolute beginners, Tinkercad is even simpler. It uses visual block programming – like Scratch for electronics. You drag blocks that say ‘turn LED on’ and ‘wait 1 second’ without writing any text code. Perfect for learning the basics.” Bella the Battery compared them. “Wokwi is best for real Arduino and ESP32 projects with Wi-Fi simulation. Tinkercad is best for learning basics with a visual approach. SimulIDE is a desktop app for real-time circuit simulation. And Proteus is the professional tool used in industry. Pick the one that matches your skill level and project needs!”

11.3 Prerequisites

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

11.4 Wokwi

Estimated time: ~20 min | Intermediate | P13.C03.U02

Description: Free online simulator for Arduino, ESP32, Raspberry Pi Pico, and other microcontrollers with extensive component library.

Key Features:

  • Web-based (no installation)
  • Real-time simulation
  • Visual circuit editor
  • Extensive component library (LEDs, sensors, displays, motors)
  • Wi-Fi simulation (ESP32)
  • Serial monitor and plotter
  • Debugging support (GDB)
  • Shareable links

Supported Platforms:

  • Arduino (Uno, Mega, Nano)
  • ESP32 (Wi-Fi + Bluetooth)
  • Raspberry Pi Pico (RP2040)
  • STM32
  • Attiny85

11.4.3 Interactive Simulator: ESP32 Wi-Fi + DHT22 Sensor

This simulation demonstrates ESP32 Wi-Fi connectivity with a real sensor! Click Start Simulation to see it work:

Advanced Features Demonstrated

What this simulation shows:

  • ESP32 Wi-Fi connection (connects to Wokwi-GUEST network automatically)
  • DHT22 sensor reading (temperature and humidity)
  • Serial monitor output (view real-time readings)
  • Real firmware execution (actual ESP32 code running)

Code Explanation:

#include <WiFi.h>
#include <DHTesp.h>

const char* ssid = "Wokwi-GUEST";     // Wokwi test network (free)
const char* password = "";            // No password needed

DHTesp dht;                           // DHT22 sensor object

void setup() {
  Serial.begin(115200);               // Start serial communication
  dht.setup(15, DHTesp::DHT22);       // DHT22 on pin 15

  WiFi.begin(ssid, password);         // Connect to Wi-Fi
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");                // Print dots while connecting
  }
  Serial.println("\nWi-Fi connected");
  Serial.print("IP address: ");
  Serial.println(WiFi.localIP());     // Show assigned IP
}

void loop() {
  float temp = dht.getTemperature();       // Read temperature
  float humidity = dht.getHumidity();      // Read humidity

  Serial.printf("Temp: %.1f°C, Humidity: %.1f%%\n", temp, humidity);
  delay(2000);                             // Update every 2 seconds
}

Circuit Wiring:

  • DHT22 VCC -> ESP32 3.3V
  • DHT22 DATA -> ESP32 GPIO 15
  • DHT22 GND -> ESP32 GND

Try This:

  1. Open serial monitor (click “Serial Monitor” tab)
  2. Watch Wi-Fi connection messages
  3. See temperature/humidity readings every 2 seconds
  4. Change delay(2000) to delay(5000) for slower updates
  5. Adjust virtual DHT22 temperature slider to see readings change

Real-World Application: This is the foundation for IoT weather stations, greenhouse monitors, and smart home climate control systems. Next step: Send data to cloud (MQTT, HTTP) for remote monitoring!

Strengths:

  • Free and unlimited
  • Fast simulation
  • Great for learning and sharing
  • Active community
  • Regular updates

Limitations:

  • Some advanced peripherals not available
  • Network simulation simplified
  • Timing not cycle-accurate

Typical Use Cases:

  • Learning embedded programming
  • Prototyping IoT devices
  • Code sharing and troubleshooting
  • Remote teaching

11.4.4 Interactive Simulator: Arduino Ultrasonic Distance Sensor

Practical Application: Parking sensor, obstacle detection robot, smart trash bin level monitor

Ultrasonic Sensor Explained

How it works:

  1. Send ultrasonic pulse (40 kHz sound wave) via TRIGGER pin
  2. Sound wave bounces off object
  3. ECHO pin receives reflected wave
  4. Measure time delay
  5. Calculate distance: distance = (time x speed_of_sound) / 2

Code to add to simulator:

const int TRIG_PIN = 9;
const int ECHO_PIN = 10;
const int LED_PIN = 13;

void setup() {
  Serial.begin(9600);
  pinMode(TRIG_PIN, OUTPUT);
  pinMode(ECHO_PIN, INPUT);
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  // Send 10μs pulse
  digitalWrite(TRIG_PIN, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIG_PIN, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);

  // Measure echo time (microseconds)
  long duration = pulseIn(ECHO_PIN, HIGH);

  // Calculate distance (cm)
  // Speed of sound = 343 m/s = 0.0343 cm/μs
  float distance = (duration * 0.0343) / 2;

  Serial.print("Distance: ");
  Serial.print(distance);
  Serial.println(" cm");

  // Turn on LED if object < 10 cm (proximity alert)
  if (distance < 10) {
    digitalWrite(LED_PIN, HIGH);
  } else {
    digitalWrite(LED_PIN, LOW);
  }

  delay(500);
}

Circuit Wiring:

  • HC-SR04 VCC -> Arduino 5V
  • HC-SR04 TRIG -> Arduino pin 9
  • HC-SR04 ECHO -> Arduino pin 10
  • HC-SR04 GND -> Arduino GND
  • LED -> Arduino pin 13

Real-World Projects:

  • Smart trash bin: Alert when full (distance < threshold)
  • Parking sensor: Beep when car too close to wall
  • Obstacle avoidance robot: Turn when object detected
  • Water level monitor: Measure tank depth (ultrasonic sensor above water)

11.4.5 Interactive Ultrasonic Distance Calculator

Experiment: Try different echo durations to simulate objects at various distances. Notice how temperature affects the speed of sound!

11.4.6 Interactive Simulator: ESP32 Multi-Sensor IoT Station

Advanced Example: Weather station with temperature, humidity, and light sensors

Multi-Sensor Integration

This simulation combines:

  • DHT22 (temperature and humidity)
  • LDR photoresistor (light level)
  • OLED display (real-time data visualization)
  • Wi-Fi (ready for cloud integration)

Complete code for simulator:

#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#include <DHTesp.h>

#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 64
#define OLED_RESET -1

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);
DHTesp dht;

const int DHT_PIN = 15;
const int LDR_PIN = 34;  // Analog pin

void setup() {
  Serial.begin(115200);

  // Initialize DHT22
  dht.setup(DHT_PIN, DHTesp::DHT22);

  // Initialize OLED
  if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) {
    Serial.println("OLED init failed!");
    for(;;);
  }

  display.clearDisplay();
  display.setTextSize(1);
  display.setTextColor(SSD1306_WHITE);
  display.setCursor(0,0);
  display.println("IoT Station Ready!");
  display.display();
  delay(2000);
}

void loop() {
  // Read sensors
  float temp = dht.getTemperature();
  float humidity = dht.getHumidity();
  int lightLevel = analogRead(LDR_PIN);
  int lightPercent = map(lightLevel, 0, 4095, 0, 100);

  // Display on OLED
  display.clearDisplay();
  display.setCursor(0,0);
  display.setTextSize(1);
  display.println("IoT Weather Station");
  display.println("-------------------");

  display.print("Temp: ");
  display.print(temp, 1);
  display.println(" C");

  display.print("Humidity: ");
  display.print(humidity, 1);
  display.println(" %");

  display.print("Light: ");
  display.print(lightPercent);
  display.println(" %");

  display.display();

  // Serial output for debugging
  Serial.printf("T:%.1fC H:%.1f%% L:%d%%\n", temp, humidity, lightPercent);

  delay(2000);
}

Circuit Components:

  • ESP32 DevKit v1
  • DHT22 on GPIO 15
  • LDR (photoresistor) on GPIO 34 (ADC)
  • SSD1306 OLED display (I2C: SDA=GPIO21, SCL=GPIO22)

Scaling to Production:

  1. Add MQTT publishing -> Send data to cloud
  2. Add deep sleep -> Battery-powered operation (1-year battery life)
  3. Add SD card logging -> Local data storage
  4. Add web server -> Local dashboard access
  5. Add OTA updates -> Remote firmware updates

Real-World Deployment:

  • Greenhouse monitoring
  • Smart home environmental control
  • Outdoor weather station network
  • Office climate tracking

11.5 Tinkercad Circuits

Description: Autodesk’s free online circuit simulator with Arduino support and educational focus.

Key Features:

  • Visual circuit builder (drag-and-drop)
  • Arduino simulation
  • Block-based and text coding
  • Component library (breadboard, resistors, sensors, etc.)
  • Interactive simulation
  • Circuit export
  • Educational tutorials

Example Workflow:

  1. Drag Arduino Uno to canvas
  2. Add LED and resistor
  3. Wire components
  4. Write code (blocks or text)
  5. Start simulation

Code Blocks vs. Text: Tinkercad offers visual block-based programming (like Scratch) for beginners and text-based Arduino code for advanced users.

Strengths:

  • Very beginner-friendly
  • Visual block programming
  • Good tutorials
  • Free (Autodesk account required)

Limitations:

  • Arduino-focused (limited ESP32 support)
  • Slower simulation than Wokwi
  • Basic component library
  • No Wi-Fi simulation

Typical Use Cases:

  • K-12 and higher education
  • Absolute beginners
  • Quick circuit validation
Try It: Simulator Feature Comparison Matrix

Select the features most important to your project and see how each simulator scores. Toggle features on/off to see the rankings update in real time.

11.6 SimulIDE

Description: Open-source real-time electronic circuit simulator with microcontroller support.

Key Features:

  • Desktop application (Windows, Linux, macOS)
  • Real-time simulation
  • PIC, AVR, Arduino support
  • Circuit schematic editor
  • Oscilloscope, voltmeter, logic analyzer
  • VHDL/Verilog support

Installation:

Download from: https://simulide.com

Strengths:

  • Real-time fast simulation
  • Advanced measurement tools
  • Open source
  • Detailed analog simulation

Limitations:

  • Desktop only (no web)
  • Steeper learning curve
  • Limited modern MCU support (no ESP32)

Typical Use Cases:

  • Circuit design and validation
  • Electronics education
  • AVR/PIC development

11.7 Network and IoT Simulation Visualizations

The following AI-generated diagrams illustrate advanced simulation tools and concepts for IoT development.

Contiki-NG operating system and Cooja network simulator architecture showing multiple simulated sensor nodes running 6LoWPAN and RPL protocols, timeline visualization of packet transmissions, and radio medium modeling for realistic wireless communication testing.

Contiki-NG and Cooja Simulator
Figure 11.1: Contiki-NG and Cooja enable testing of complete wireless sensor networks before hardware deployment. This visualization shows how Cooja simulates multiple sensor nodes with realistic radio propagation, enabling protocol debugging and performance analysis of mesh networking code.

Duty cycle timing diagram showing wake periods for sensing and transmission separated by long sleep intervals, with power consumption overlay demonstrating how 1 percent duty cycle extends battery life from days to years while maintaining required data collection rates.

Duty Cycle Simulation
Figure 11.2: Duty cycle simulation enables battery life prediction. This visualization shows the timing relationship between wake and sleep periods, demonstrating how a 1% duty cycle (10 seconds active per 1000 seconds) reduces average current by 99%, extending battery life proportionally.

Interactive battery sizing worksheet showing step-by-step calculation from sensor reading frequency through average current calculation to battery capacity selection, with worked example for a soil moisture sensor targeting 2-year operation.

Battery Sizing Exercise
Figure 11.3: Battery sizing exercises bridge theory and practice. This visualization provides a systematic approach to calculating required battery capacity from sensor duty cycle, transmission frequency, and target lifetime, enabling students to validate designs before hardware investment.

Historical graph of battery energy density improvement showing approximately 5-8 percent annual improvement for lithium-ion technology compared to Moore's Law doubling every 18 months, emphasizing why energy efficiency in firmware is more impactful than waiting for better batteries.

Battery Technology Evolution
Figure 11.4: Battery technology improves slowly compared to computing. This visualization shows the 5-8% annual energy density improvement for lithium-ion, emphasizing that firmware efficiency gains of 50-90% through duty cycling and optimization are more impactful than waiting for battery improvements.
Try It: IoT Duty Cycle and Battery Life Explorer

Explore how duty cycle percentage, sensor read frequency, and transmission patterns affect the total battery life of an IoT sensor node. Adjust parameters to find the sweet spot between data freshness and longevity.

11.8 Proteus Design Suite

Description: Professional electronic design automation (EDA) software with simulation.

Key Features:

  • Schematic capture
  • PCB layout
  • Mixed-mode SPICE simulation
  • Microcontroller simulation (8051, PIC, AVR, ARM)
  • VSM (Virtual System Modeling)
  • Component library (50,000+ parts)

Strengths:

  • Professional-grade
  • Extensive library
  • PCB design integration
  • Accurate simulation

Limitations:

  • Expensive (licenses start at ~$200)
  • Windows only
  • Complex interface
  • Steep learning curve

Typical Use Cases:

  • Professional embedded development
  • PCB design with simulation validation
  • Commercial product development
Try It: Simulator Selection Advisor

Answer a few questions about your project requirements and this widget will recommend which simulator is the best fit for your needs.

11.9 Video Resources

Learn the basics of Tinkercad for circuit design, 3D modeling, and Arduino simulation - all in your browser without installing software.

Build and simulate a practical parking sensor system using Tinkercad’s Arduino simulator and ultrasonic sensors.

Learn how to simulate accelerometer sensors in Tinkercad for motion detection and orientation sensing applications.

Build a tilt sensor project in Tinkercad that logs timestamps, demonstrating sensor data collection and time-based logging.

Scenario: Design a smart parking sensor using ESP32 + ultrasonic sensor + MQTT for real-time occupancy detection. Validate the design in Wokwi before ordering hardware.

Requirements:

  • Detect vehicle presence (distance < 50 cm = occupied)
  • Publish to MQTT broker every 5 seconds
  • Use ESP32 deep sleep between readings (battery-powered)
  • Provide visual feedback with LED (green = available, red = occupied)

Wokwi Implementation:

Components:

  • ESP32 DevKit v1
  • HC-SR04 ultrasonic sensor
  • Red LED + 220Ω resistor
  • Green LED + 220Ω resistor

Circuit Wiring:

HC-SR04:
├─ VCC → ESP32 5V
├─ TRIG → ESP32 GPIO 12
├─ ECHO → ESP32 GPIO 14
└─ GND → ESP32 GND

LEDs:
├─ Green LED anode → ESP32 GPIO 25 (via 220Ω)
├─ Green LED cathode → GND
├─ Red LED anode → ESP32 GPIO 26 (via 220Ω)
└─ Red LED cathode → GND

Complete Code:

#include <WiFi.h>
#include <PubSubClient.h>

// Pin definitions
#define TRIG_PIN 12
#define ECHO_PIN 14
#define LED_GREEN 25
#define LED_RED 26

// Network credentials
const char* ssid = "Wokwi-GUEST";
const char* password = "";

// MQTT broker (test.mosquitto.org for testing)
const char* mqtt_server = "test.mosquitto.org";
const char* mqtt_topic = "parking/spot001/status";

WiFiClient espClient;
PubSubClient mqtt(espClient);

// Parking state
bool isOccupied = false;

void setup() {
  Serial.begin(115200);

  // Configure pins
  pinMode(TRIG_PIN, OUTPUT);
  pinMode(ECHO_PIN, INPUT);
  pinMode(LED_GREEN, OUTPUT);
  pinMode(LED_RED, OUTPUT);

  // Connect Wi-Fi
  Serial.print("Connecting to WiFi");
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("\nWiFi connected");

  // Connect MQTT
  mqtt.setServer(mqtt_server, 1883);
  reconnectMQTT();
}

void loop() {
  if (!mqtt.connected()) {
    reconnectMQTT();
  }
  mqtt.loop();

  // Measure distance
  float distance = readUltrasonic();
  Serial.printf("Distance: %.1f cm\n", distance);

  // Determine occupancy
  bool currentState = (distance < 50);

  // Update only if state changed
  if (currentState != isOccupied) {
    isOccupied = currentState;

    // Update LEDs
    digitalWrite(LED_GREEN, !isOccupied);
    digitalWrite(LED_RED, isOccupied);

    // Publish to MQTT
    String message = isOccupied ? "OCCUPIED" : "AVAILABLE";
    mqtt.publish(mqtt_topic, message.c_str());
    Serial.printf("Published: %s\n", message.c_str());
  }

  delay(5000);  // Check every 5 seconds
}

float readUltrasonic() {
  // Send 10μs pulse
  digitalWrite(TRIG_PIN, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIG_PIN, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);

  // Read echo duration
  long duration = pulseIn(ECHO_PIN, HIGH, 30000);  // 30ms timeout

  // Calculate distance (speed of sound = 343 m/s)
  float distance = (duration * 0.0343) / 2;

  // Validate reading
  if (duration == 0 || distance > 400) {
    return 999;  // Invalid reading
  }

  return distance;
}

void reconnectMQTT() {
  while (!mqtt.connected()) {
    Serial.print("Connecting to MQTT...");
    if (mqtt.connect("ESP32_ParkingSensor")) {
      Serial.println("connected");
    } else {
      Serial.printf("failed, rc=%d, retrying in 5s\n", mqtt.state());
      delay(5000);
    }
  }
}

Simulation Testing:

Test 1: Vehicle Detection

Simulator Action: Move "distance" slider on HC-SR04 to 30 cm
Expected Result:
├─ Serial: "Distance: 30.0 cm"
├─ Red LED turns ON
├─ Green LED turns OFF
└─ MQTT message: "OCCUPIED"

✓ PASS: All behaviors correct

Test 2: Vehicle Departure

Simulator Action: Move "distance" slider to 200 cm
Expected Result:
├─ Serial: "Distance: 200.0 cm"
├─ Red LED turns OFF
├─ Green LED turns ON
└─ MQTT message: "AVAILABLE"

✓ PASS: State transition works

Test 3: Edge Case (Exactly 50 cm)

Simulator Action: Move slider to 50 cm
Expected Result: Should still show AVAILABLE (threshold is < 50)

✓ PASS: Boundary condition handled correctly

Test 4: MQTT Connectivity Loss

Simulator Action: Disconnect virtual network
Expected Result:
├─ Serial: "Connecting to MQTT... failed, rc=-2, retrying in 5s"
├─ Device keeps measuring but doesn't publish
└─ Reconnects automatically when network restored

✓ PASS: Graceful degradation

Power Optimization (Add Deep Sleep):

// At end of loop():
  delay(5000);  // Replace with deep sleep

  // Enter deep sleep for 5 seconds
  Serial.println("Entering deep sleep for 5 seconds");
  esp_sleep_enable_timer_wakeup(5 * 1000000);  // 5 seconds in microseconds
  esp_deep_sleep_start();
}

Simulation Results:

Without Deep Sleep:

  • Average current: 80 mA (Wi-Fi active)
  • Battery life (2000 mAh): 25 hours

With Deep Sleep:

  • Active current: 80 mA for 0.5s every 5s
  • Sleep current: 0.01 mA (simulated)
  • Average current: (80×0.5 + 0.01×4.5) / 5 = 8.01 mA
  • Battery life (2000 mAh): 250 hours (10× improvement!)

11.9.1 Interactive Deep Sleep Battery Calculator

Experiment: Adjust the sleep time and cycle duration to see how deep sleep dramatically extends battery life. Try a 1% duty cycle (0.5s active, 50s sleep) to see month-long battery life!

Validation Results:

After 2 hours in Wokwi simulator: - Detected 24 “vehicle arrivals” (distance < 50 cm) - Detected 24 “vehicle departures” (distance > 50 cm) - Zero false positives (no spurious triggers) - MQTT messages: 48 (all delivered successfully) - Average response time: 150 ms (detection to MQTT publish)

Benefits of Wokwi Prototyping:

  1. Validated algorithm before hardware: Found and fixed 3 bugs in code
  2. Tested MQTT integration: Confirmed message format works with broker
  3. Estimated battery life: Confirmed 10-day battery life feasible with deep sleep
  4. Shareable design: Sent Wokwi link to team for review (no hardware needed)
  5. Zero cost: All testing done free, saved $50 in prototype hardware
  6. Time saved: 3 days iteration in Wokwi vs 2 weeks waiting for hardware

Next Steps After Wokwi Validation:

  1. Order hardware components ($15 per unit)
  2. Build physical prototype on breadboard
  3. Test in actual parking spot (validate ultrasonic range in real environment)
  4. Design PCB and 3D-printed enclosure
  5. Deploy pilot of 10 sensors

Key Takeaway: Wokwi caught 3 firmware bugs and validated the entire system architecture in 6 hours. Without simulation, these bugs would have been found after $150 in hardware and 2 weeks of waiting for components.

Decision Matrix:

Stage Tool Purpose When to Use
Concept Validation Wokwi / Tinkercad Prove algorithm works Early design, no hardware yet
Firmware Development Wokwi Iterate code fast Writing and testing firmware logic
Hardware Integration SimulIDE / Proteus Validate circuit design Testing voltage levels, pull-ups, etc.
Timing Validation Physical Hardware Verify real-world timing I2C clock stretching, interrupt latency
Production Testing Physical Hardware Environmental testing Temperature, vibration, EMI, etc.

Decision Process:

Question 1: Do you have hardware available?

  • NO → Start with online simulator (Wokwi)
  • YES → Use simulator anyway for fast iteration, hardware for validation

Question 2: What are you testing?

Algorithm Logic (if/else, calculations, state machines): - ✓ Wokwi or Tinkercad (sufficient) - Time: Hours to validate

Sensor Reading (I2C, SPI communication): - ✓ Wokwi (good approximation) - ⚠️ Physical validation recommended (sensors have quirks) - Time: 1-2 days in Wokwi, 1 week with hardware

Precise Timing (microsecond accuracy, RTOS): - ❌ Wokwi (not cycle-accurate) - ✓ Physical hardware required - Time: 2-3 weeks with hardware + oscilloscope

Circuit Design (voltage drops, pull-ups, capacitors): - ❌ Wokwi (simplified model) - ✓ SimulIDE or Proteus (SPICE simulation) - ✓ Physical hardware (ultimate validation)

Power Consumption (battery life estimation): - ⚠️ Wokwi (rough estimate only) - ✓ Physical hardware + ammeter (required) - Time: 1 day for 24-hour power profile

Question 3: What is your budget?

$0 Budget:

  • Phase 1: Wokwi (free, unlimited)
  • Phase 2: Borrow/buy minimal hardware ($20-50)
  • Phase 3: Build one prototype

$100 Budget:

  • Phase 1: Wokwi (validate design)
  • Phase 2: Order 2-3 dev boards + sensors ($100)
  • Phase 3: Build prototypes

$1,000+ Budget:

  • Phase 1: Wokwi (fast iteration)
  • Phase 2: Order 10 dev boards + test equipment ($500)
  • Phase 3: Professional PCB + assembly ($500)

Question 4: What is your timeline?

1 Week Deadline:

  • Wokwi ONLY (no time to wait for hardware)
  • Risk: May find hardware issues later

1 Month Deadline:

  • Week 1: Wokwi (algorithm + firmware)
  • Week 2: Order hardware, wait for delivery
  • Week 3-4: Physical validation

3+ Months (Ideal):

  • Weeks 1-2: Wokwi (design iteration)
  • Week 3: Order hardware
  • Weeks 4-6: Physical prototyping
  • Weeks 7-9: Environmental testing (temp, humidity, vibration)
  • Weeks 10-12: Pilot deployment

Hybrid Approach (Recommended):

Stage 1: Concept (Hours)
└─ Tool: Wokwi
└─ Output: Validated algorithm, working firmware

Stage 2: Hardware Prototyping (Days)
└─ Tool: Physical breadboard
└─ Output: Working prototype, confirmed sensor behavior

Stage 3: Circuit Design (Days)
└─ Tool: Proteus or KiCAD
└─ Output: Schematic + PCB layout

Stage 4: Pilot Manufacturing (Weeks)
└─ Tool: PCB fab + assembly
└─ Output: 10-100 production units

Stage 5: Field Testing (Weeks-Months)
└─ Tool: Deployed units
└─ Output: Validation in real environment

Red Flags for “Simulation Only”:

  • ❌ Shipping product based solely on Wokwi (no physical testing)
  • ❌ Trusting Wokwi power estimates (must measure with ammeter)
  • ❌ Assuming timing is exact (simulator is not cycle-accurate)
  • ❌ Skipping environmental testing (temperature, vibration, etc.)

Red Flags for “Hardware Only”:

  • ❌ Waiting 2 weeks for hardware before starting firmware (use Wokwi!)
  • ❌ Buying $500 of components before validating algorithm (simulate first!)
  • ❌ Building 100 units without pilot testing (prototype first!)

Best Practice Timeline:

Total Project: 12 weeks

Week 1-2: Simulation (Wokwi)
├─ Validate algorithm
├─ Test edge cases
├─ Estimate power consumption
└─ Share design with team

Week 3: Order Hardware
├─ Based on validated Wokwi design
└─ Cost: $50-200

Week 4-5: Breadboard Prototype
├─ Validate sensor behavior
├─ Measure actual power consumption
└─ Test I2C timing with oscilloscope

Week 6-7: PCB Design
├─ Schematic capture
├─ PCB layout
└─ Order PCB ($100, 1-week lead time)

Week 8-9: PCB Assembly & Testing
├─ Assemble 10 prototypes
├─ Functional testing
└─ Fix any issues

Week 10-12: Pilot Deployment
├─ Deploy 10 units to real environment
├─ Monitor for 2-4 weeks
└─ Iterate based on field data

The Rule: Simulation accelerates early stages (save weeks). Physical hardware validates simulation (catch issues). Both are required for production-ready IoT devices.

Common Mistake: Trusting Wokwi Power Consumption Estimates Without Measurement

The Problem: Your Wokwi simulation shows ESP32 average current of 15 mA. You design for 2-year battery life. Real hardware consumes 120 mA average. Batteries die in 2 months. What happened?

Why Wokwi Power Estimates Are Inaccurate:

1. Wokwi Models Ideal Behavior

Wokwi Simulation:

esp_deep_sleep_start();
// Wokwi assumes: 10 µA deep sleep (datasheet spec)

Reality on Physical ESP32:

  • Deep sleep current: 10 µA (ONLY if configured perfectly)
  • With USB connected: 5-15 mA (USB circuitry stays powered)
  • With built-in LED: +20 mA (often forgotten to disable)
  • With external sensor powered: +5-50 mA (not turned off)
  • Real measured current: 50-120 mA ❌

2. Wokwi Doesn’t Model External Components

Wokwi Circuit:

ESP32 + DHT22 sensor
Wokwi says: 25 mA average

Real Circuit:

ESP32: 80 mA (Wi-Fi active)
DHT22: 1.5 mA (when reading)
Voltage regulator: 50 µA quiescent
Pull-up resistors (2× 10kΩ): 660 µA (3.3V / 10kΩ × 2)
Status LED: 20 mA (forgot to disable in firmware!)
TOTAL: 102 mA ❌ (4× Wokwi estimate!)

3. Wokwi Doesn’t Model Dynamic Voltage

Wokwi Assumption: Stable 3.3V power supply Reality: Battery voltage drops from 4.2V (full) to 3.0V (empty) - At 3.0V: Boost converter efficiency drops from 90% to 75% - Result: 20% more current draw from battery

Real-World Disaster Example:

Wokwi Design: Solar-powered weather station

ESP32 + DHT22 + 5W solar panel + 2000 mAh battery

Wokwi Power Budget:
├─ Active (1s every 5 min): 80 mA × 1s = 80 mAs
├─ Deep sleep (299s): 0.01 mA × 299s = 3 mAs
├─ Average per 5 min: 83 mAs
├─ Average current: 83 / 300 = 0.28 mA
└─ Battery life (no solar): 2000 / 0.28 = 7,143 hours = 297 days

Wokwi Conclusion: "System will work year-round even with 3 cloudy weeks"

Physical Deployment Results:

Actual Power Consumption (measured with ammeter):
├─ Active: 150 mA × 2s (Wi-Fi connect takes 2s, not 1s)
├─ Deep sleep: 2.5 mA (USB circuitry + pull-ups + LED)
├─ Average per 5 min: 300 + 748 = 1,048 mAs
├─ Average current: 1,048 / 300 = 3.49 mA ❌
└─ Battery life: 2000 / 3.49 = 573 hours = 24 days ❌

Result: Batteries died after 3 weeks (not 10 months as Wokwi predicted)
Emergency retrofit: Larger solar panel + disable USB circuitry

What Went Wrong:

Component Wokwi Estimate Reality Difference
Deep sleep current 0.01 mA 2.5 mA 250× worse!
Active duration 1 second 2 seconds 2× longer
Total average 0.28 mA 3.49 mA 12.5× worse

How to Validate Power in Reality:

Step 1: Build Physical Prototype

  • Even a breadboard prototype is better than pure simulation

Step 2: Measure with Ammeter

# Connect ammeter in series with battery
# Use multimeter in µA mode for sleep current
# Use oscilloscope current probe for dynamic measurement

Equipment needed:
├─ Multimeter with µA range (<$50)
├─ INA219 current sensor module (<$5)
└─ Or: Oscilloscope with current probe (>$500)

Step 3: Measure Full Duty Cycle

# Measurement script (using INA219)
import board
import adafruit_ina219

ina = adafruit_ina219.INA219(board.I2C())

samples = []
for i in range(3600):  # 1 hour of measurements
    current_ma = ina.current
    samples.append(current_ma)
    time.sleep(1)

print(f"Average current: {sum(samples)/len(samples):.2f} mA")
print(f"Peak current: {max(samples):.2f} mA")
print(f"Sleep current: {min(samples):.2f} mA")
print(f"Battery life (2000mAh): {2000 / (sum(samples)/len(samples)):.0f} hours")

Step 4: Find Power Drains

Measurement procedure:
1. Measure baseline (full system)
2. Remove one component at a time
3. Measure again
4. Calculate delta (drain from that component)

Example findings:
├─ Baseline: 3.49 mA
├─ Remove status LED: 0.52 mA (LED was 2.97 mA drain!)
├─ Remove USB: 0.15 mA (USB circuitry was 0.37 mA)
├─ Configure pull-ups correctly: 0.08 mA (saved 0.07 mA)
└─ Final: 0.08 mA (43× better than initial!)

Corrected Design:

// Disable all power drains in firmware
void setup() {
    // Disable USB (if not debugging)
    #ifndef DEBUG
        USB.end();
    #endif

    // Disable status LED
    pinMode(LED_BUILTIN, INPUT);  // High-Z (not driving LED)

    // Configure unused pins as INPUT with internal pull-down
    for (int pin = 0; pin < 40; pin++) {
        if (pin != USED_PIN_LIST) {
            pinMode(pin, INPUT_PULLDOWN);
        }
    }

    // Power down ADC
    adc_power_off();

    // Enable proper deep sleep
    esp_sleep_enable_timer_wakeup(5 * 60 * 1000000);  // 5 minutes
    gpio_deep_sleep_hold_en();  // Hold GPIO state in sleep
}

Validation Results After Fixes:

Measured current: 0.08 mA average
Battery life: 2000 / 0.08 = 25,000 hours = 2.85 years ✓

Solar requirement: 0.08 mA × 24h = 1.92 mAh/day
3.3V × 1.92 mAh = 6.3 mWh/day
5W solar panel (5 peak hours) = 25 Wh/day ✓✓ (4,000× margin!)

Best Practices:

  1. Use Wokwi for algorithm validation - Not for power estimates
  2. Measure physical hardware - Always validate with ammeter
  3. Test full duty cycle - Measure for multiple sleep/wake cycles
  4. Account for all peripherals - LEDs, pull-ups, regulators, sensors
  5. Add 2× safety margin - Real deployments are worse than lab

The Rule: Wokwi is excellent for firmware development. It is terrible for power estimation. Always measure actual hardware before finalizing battery/solar sizing.

11.10 Summary

  • Wokwi is the recommended starting point for Arduino and ESP32 simulation with Wi-Fi support, extensive component libraries, and shareable project links
  • Tinkercad Circuits provides beginner-friendly visual block programming ideal for K-12 education and absolute beginners
  • SimulIDE offers desktop-based real-time simulation with advanced measurement tools for AVR/PIC development
  • Proteus Design Suite serves professional needs with PCB integration and accurate SPICE simulation
  • All simulators complement each other: start with browser-based tools, graduate to professional tools as projects mature

11.11 Knowledge Check

11.12 Concept Relationships

How This Connects

Builds on: Hardware Simulation Fundamentals explains why simulation matters; Electronics Basics provides circuit knowledge.

Relates to: Network Simulation Tools for system-level validation; Testing Fundamentals for the testing pyramid.

Leads to: Platform Emulation for OS-level simulation; HIL Testing bridges simulation and real hardware.

Part of: The rapid prototyping workflow enabling firmware development without physical hardware.

11.13 See Also

Comparison Resources:

Learning Paths:

Community Forums:

  • Wokwi Discord: wokwi.com/discord
  • Tinkercad Forum: Active beginner community
  • SimulIDE GitHub Discussions

11.14 Try It Yourself

Multi-Platform Comparison Challenge

Task: Build the same ultrasonic parking sensor in 3 different simulators and compare.

Project Spec: HC-SR04 sensor, LED distance indicator (green >20cm, yellow 10-20cm, red <10cm), serial output.

Part 1 - Tinkercad (20 minutes): - Use block-based programming for beginners - Visual circuit drag-and-drop - What to Observe: Easiest to start, limited to basic Arduino

Part 2 - Wokwi (30 minutes): - Text-based C++ code - Real ESP32 with Wi-Fi simulation - Add MQTT publish of distance readings - What to Observe: Production-ready code, works on real hardware

Part 3 - SimulIDE (30 minutes): - Desktop app with oscilloscope tools - Measure ultrasonic pulse timing on logic analyzer - What to Observe: Most detailed signal-level debugging

Deliverables:

  1. Screenshot of each working simulation
  2. Summary: “I would use [tool] for [scenario] because…”
  3. Bonus: Flash Wokwi code to real Arduino and confirm it works

Expected Learning: Understand which tool fits different development phases.

Common Pitfalls

Wokwi simulates GPIO, I2C, SPI, and UART logically correct but does not model: interrupt latency (measured in CPU cycles), DMA transfer timing, hardware timer jitter, ADC sampling noise, or power consumption. A Wokwi simulation showing 100 Hz sensor sampling rate does not validate that the production firmware achieves 100 Hz on real hardware. Use Wokwi for functional correctness validation and algorithm development; measure timing and power on actual hardware.

Wokwi simulates specific peripheral variants (BME280, not BME680; MPU-6050, not MPU-6500). Code written for a simulated BME280 may not work with a production PCB using a different sensor variant if the register maps differ. Always verify: exact component model matches production BOM, firmware HAL (Hardware Abstraction Layer) is tested on actual hardware before production, and simulation component version matches production component version.

Wokwi projects stored only in browser local storage or unshared online accounts cannot be version-controlled, peer-reviewed, or reproduced by CI. Export Wokwi projects (diagram.json + sketch files) to git alongside firmware source code. This enables: simulation state review in PRs, reproducible simulation environments across team members, and automated CI using the Wokwi GitHub Actions integration for headless simulation testing.

Online simulators run in browser JavaScript sandboxes with memory and computation limits. Complex simulations with 10+ active components, large firmware binaries, or high-frequency polling may: run slower than real-time (hiding timing bugs), crash the browser tab, or silently truncate computation. Monitor simulation performance: if simulation speed drops below 0.5× real-time, simplify the simulation model or upgrade to local QEMU/Renode simulation for complex projects.

11.15 What’s Next

Continue to Platform-Specific Emulation to learn about QEMU for Raspberry Pi emulation, Renode for multi-architecture simulation, and advanced debugging techniques including breakpoints, serial monitoring, and GDB integration.

Previous Current Next
Hardware Simulation Fundamentals Online Hardware Simulators Emulation & Debugging