Project 3: Multi-Sensor Data Logger with Deep Sleep

A battery-powered remote sensor node that wakes up periodically, reads sensors, transmits data over WiFi or ESP-NOW, then goes back to deep sleep—lasting weeks on a single battery.

Quick Reference

Attribute Value
Difficulty Level 3: Advanced (The Engineer)
Time Estimate 1-2 weeks
Language C (Alternatives: MicroPython, Rust, Arduino C++)
Prerequisites Basic programming and system fundamentals
Key Topics ESP32 Sleep Modes, RTC Memory, Low-Power Design, ESP-NOW Protocol

1. Learning Objectives

By completing this project, you will:

  1. Explain the core behavior and constraints of multi-sensor data logger with deep sleep.
  2. Implement a working solution and validate it with test vectors.
  3. Reason about edge cases and timing or state transitions.

2. Theoretical Foundation

2.1 Core Concepts

  • **ESP32 Sleep Modes**: Define the governing rules and expected behavior.
  • **RTC Memory**: Understand how signals or states change over time.
  • **Low-Power Design**: Translate requirements to implementation choices.

2.2 Why This Matters

This project confronts you with the hardest embedded challenge: power management. You’ll learn deep sleep modes, RTC memory persistence, wake-up sources, and the trade-offs between connectivity and battery life.

2.3 Historical Context / Background

This class of design appears in real systems because it is a minimal, reliable way to encode behavior at the hardware level.

2.4 Common Misconceptions

  • “If simulation passes, hardware is always correct” ignores timing and integration.
  • “All input combinations are equivalent” ignores edge conditions and invalid states.

3. Project Specification

3.1 What You Will Build

A battery-powered remote sensor node that wakes up periodically, reads sensors, transmits data over WiFi or ESP-NOW, then goes back to deep sleep—lasting weeks on a single battery.

3.2 Functional Requirements

  1. Configuring deep sleep and various wake-up sources (timer, GPIO, touch) (maps to power management).
  2. Preserving data across sleep cycles using RTC memory (maps to memory architecture).
  3. Fast WiFi reconnection to minimize awake time (maps to wireless optimization).

3.3 Non-Functional Requirements

  • Performance: Stable operation at expected clock rates.
  • Reliability: Deterministic outputs for all valid inputs.
  • Usability: Clear module interfaces and documented signals.

3.4 Example Usage / Output

The simulation should demonstrate correct behavior across representative test vectors.

3.5 Real World Outcome

You will verify the design by inspecting waveforms or live hardware indicators. You will see the expected output pattern or response when you apply known inputs.

Example Output:

Project: Multi-Sensor Data Logger with Deep Sleep
Status: PASS (all test vectors)
Observed: Output matches expected transitions

4. Solution Architecture

4.1 High-Level Design

Inputs -> Core Logic -> Outputs

4.2 Key Components

Component Responsibility Key Decisions
Input Stage Capture and align signals Choose widths and encodings
Logic Core Implement multi-sensor data logger with deep sleep Decide combinational vs sequential logic
Output Stage Drive external outputs Ensure stable timing

4.3 Data Structures

Define signal buses and state registers with clear widths and naming. Document how each signal maps to behavior.

4.4 Algorithm Overview

Key Algorithm: Signal Evaluation

  1. Interpret inputs according to spec.
  2. Update internal state or compute outputs.
  3. Validate outputs against expected behavior.

Complexity Analysis:

  • Time: O(1) per evaluation
  • Space: O(1)

5. Implementation Guide

5.1 Development Environment Setup

Set up your HDL simulator and waveform viewer. Create a minimal project with a top module and testbench.

5.2 Project Structure

project-root/
├── rtl/
│   └── module.v
├── sim/
│   └── module_tb.v
└── README.md

5.3 The Core Question You’re Answering

“How do I translate a formal spec into reliable hardware behavior?”

Before you write any code, sit with this question. The entire design lives or dies on the accuracy of this translation.

5.4 Concepts You Must Understand First

Stop and research these before coding:

  1. Truth Tables and State Models
    • What are all valid input combinations?
    • Which states must never occur?
    • Book Reference: “Digital Design and Computer Architecture” Ch. 2-3
  2. Timing and Synchronization
    • When do signals update relative to the clock?
    • How do you avoid metastability?
    • Book Reference: “Digital Design and Computer Architecture” Ch. 3

5.5 Questions to Guide Your Design

Before implementing, think through these:

  1. Signal Definition
    • What are the required widths and encodings?
    • Which signals require reset conditions?
  2. Validation Strategy
    • Which vectors prove correctness?
    • How will you detect regressions?

5.6 Thinking Exercise

Behavior Sketch

Write a truth table or state diagram for the critical behavior of this module.

Questions while tracing:

  • Which transitions are most error-prone?
  • Where could a glitch appear?
  • What should happen on reset?

5.7 The Interview Questions They’ll Ask

Prepare to answer these:

  1. “How do you verify a hardware module for correctness?”
  2. “What is the difference between combinational and sequential logic?”
  3. “How do you avoid glitches and metastability?”
  4. “How do you define and test edge cases?”
  5. “What makes a good testbench?”

5.8 Hints in Layers

Hint 1: Start with the spec Write down expected inputs and outputs before touching the HDL.

Hint 2: Validate in small steps Simulate small subsets of behavior before full integration.

Hint 3: Use waveforms Waveform inspection reveals timing and ordering issues.

Hint 4: Check reset behavior Ensure the design starts from a known state.

5.9 Books That Will Help

Topic Book Chapter
Logic design “Digital Design and Computer Architecture” Ch. 2-3
HDL practice “Verilog HDL” by Palnitkar Ch. 1-4

5.10 Implementation Phases

Phase 1: Foundation (1-2 weeks)

Goals:

  • Define inputs/outputs
  • Model core behavior

Tasks:

  1. Document specification.
  2. Draft core logic structure.

Checkpoint: All expected behaviors are listed.

Phase 2: Core Functionality (1-2 weeks)

Goals:

  • Implement logic
  • Build testbench

Tasks:

  1. Implement the module.
  2. Add test vectors.

Checkpoint: Key vectors pass in simulation.

Phase 3: Polish & Edge Cases (1-2 weeks)

Goals:

  • Handle edge cases
  • Document design

Tasks:

  1. Add boundary and reset tests.
  2. Write usage notes.

Checkpoint: No failures across full test suite.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Encoding One-hot vs binary Binary Simpler for small designs
Verification Spot vs exhaustive Exhaustive Ensures correctness

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Verify logic Truth table coverage
Integration Tests Module + wrappers End-to-end simulation
Edge Case Tests Resets and boundaries Reset mid-cycle

6.2 Critical Test Cases

  1. All-zero and all-one inputs.
  2. Boundary transitions and rollover events.
  3. Reset behavior under load.

6.3 Test Data

Maintain a compact table of test vectors and expected outputs.

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Incorrect widths Truncated results Recalculate signal widths
Missing reset Unknown states Add explicit reset behavior
Bit ordering errors Wrong outputs Document bit positions

7.2 Debugging Strategies

  • Inspect waveforms around transitions.
  • Compare outputs against expected truth tables.

7.3 Performance Traps

Overly complex logic reduces max frequency; simplify critical paths.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Parameterize widths or counts.

8.2 Intermediate Extensions

  • Add a self-test mode.

8.3 Advanced Extensions

  • Pipeline or optimize for higher frequency.

9. Real-World Connections

9.1 Industry Applications

  • FPGA prototypes: validate logic before ASIC.
  • Embedded systems: reliable control logic.
  • Open FPGA cores: similar building blocks in open designs.

9.3 Interview Relevance

  • Hardware verification and timing reasoning.

10. Resources

10.1 Essential Reading

  • Digital Design and Computer Architecture by Harris & Harris
  • Verilog HDL by Palnitkar

10.2 Video Resources

  • HDL fundamentals lectures

10.3 Tools & Documentation

  • Verilator or Icarus Verilog
  • GTKWave for waveform viewing
  • Next projects build on these primitives.

11. Self-Assessment Checklist

11.1 Understanding

  • I can describe the truth table or state model.
  • I can explain timing constraints.
  • I can justify design decisions.

11.2 Implementation

  • All tests pass in simulation.
  • Edge cases are covered.
  • Documentation is complete.

11.3 Growth

  • I can extend the design for new requirements.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Core functionality validated with tests.

Full Completion:

  • Exhaustive verification and clear documentation.

Excellence (Going Above & Beyond):

  • Parameterized, optimized, and reusable module.

This guide was generated from ESP32_PROGRAMMING_LEARNING_PROJECTS.md. For the complete learning path, see the parent directory README.