The Discovery: JLCPCB and the Modern PCB Ecosystem

When I first outlined this project in Part 1, I thought custom PCB manufacturing would be expensive and complex. After some research, I discovered JLCPCB - a game-changing service that offers:

• Custom PCB Manufacturing: Professional-grade PCBs at incredibly low prices
• Bill of Materials (BOM) Management: They can source and purchase components
• PCBA (PCB Assembly) Services: End-to-end assembly for complete prototyping
• EasyEDA Integration: A free, web-based PCB design tool

The combination of affordable manufacturing and accessible design tools has truly democratized hardware development for individual makers like myself.

Step 1: Schematic Design with EasyEDA

The first step was creating a circuit schematic using EasyEDA, JLCPCB’s online PCB design tool. What impressed me most was how comprehensive their component library is - I could easily find all the components I was using:

• NodeMCU ESP32 Development Board
• SCD41 CO2/Temperature/Humidity Sensor
• SH1106 OLED Display
• Various connectors and passive components

The schematic design process was surprisingly intuitive. EasyEDA’s interface made it easy to:

• Search for components in their extensive library
• Connect pins with simple click-and-drag operations
• Validate electrical connections and detect potential issues
• Add labels and annotations for clarity

The schematic captures our refined design from the previous iterations, with all the lessons learned about power distribution, I2C connections, and proper grounding integrated into the layout.

Step 2: PCB Layout and Routing

Once the schematic was complete, EasyEDA’s most impressive feature came into play: automatic schematic-to-PCB conversion. With a single click, the tool generated an initial PCB layout with all components placed and basic routing suggestions.

While the auto-layout provided an excellent starting point, I still needed to make manual adjustments:

• Trace Routing: Ensuring signal traces don’t run too close to each other to prevent interference
• Component Placement: Optimizing for both electrical performance and mechanical constraints
• Ground Plane: Creating proper ground planes for stable operation
• Via Placement: Connecting different layers efficiently

The learning curve was gentle enough for a beginner like me, yet the tool provided professional-grade capabilities.

The final design achieved our goals of compactness while maintaining proper electrical design practices. The two-layer board keeps costs low while providing sufficient routing flexibility.

Step 3: Manufacturing - Surprisingly Affordable!

After finalizing the PCB design, I submitted it to JLCPCB for manufacturing. The pricing was genuinely shocking - in the best possible way:

Final Cost Breakdown:

• 10 pieces of custom PCB
• Professional quality with soldermask and silkscreen
• International shipping included
• Total: ~$4 USD (with new customer coupon)

This price point makes experimentation and iteration incredibly accessible. Even if the first design had issues, the cost of multiple revisions would still be minimal.

Manufacturing Progress and Delivery

After placing the order, JLCPCB provided regular updates on the manufacturing progress:

The entire process from order placement to delivery took just 4 days - remarkable considering this included:

• Design review and validation
• PCB fabrication with multiple layers
• Quality control testing
• International shipping from China

When the package arrived, I was impressed by the professional packaging and the quality of the finished PCBs:

The manufacturing quality exceeded my expectations. The silkscreen was crisp, the soldermask was uniform, and the dimensional accuracy was perfect.

Assembly and Testing

With the custom PCBs in hand, it was time for the moment of truth: soldering the components and testing functionality. Thanks to the improved layout and proper pad sizing, the soldering process was much more manageable than my earlier attempts in Part 5.

After carefully soldering each component:

• ESP32 development board
• SCD41 sensor module
• SGP40 sensor module
• SH1106 display

I flashed the same firmware we developed in previous parts and… it worked perfectly on the first try!

All sensors responded correctly, and the display showed proper readings The months of iterative development and testing with breadboards had paid off - the transition to a custom PCB was seamless.

New 3D Printed Enclosure

With the custom PCB validated, I designed a new enclosure specifically tailored to its dimensions. Using the same OnShape CAD skills developed in Part 5, I created a much more compact design:

The new enclosure design benefits from:

• Precise Fit: Designed exactly around the PCB dimensions
• Reduced Volume: Significantly smaller than the breadboard version
• Improved Aesthetics: Cleaner lines and professional appearance

Size Comparison: The Transformation

The difference between our original breadboard prototype and the final custom PCB version is dramatic:

The miniaturization achieved through custom PCB design represents roughly a 60% reduction in volume while maintaining all functionality. This transformation demonstrates the power of moving from prototype to production-ready design.

Modules vs. ICs: Understanding the Trade-offs

While this custom PCB represents a significant improvement, there’s still room for further optimization. Currently, I’m using pre-packaged modules rather than bare ICs:

Current Approach - Using Modules:

• ESP32 Development Board: Includes the ESP32-WROOM-32 module plus USB-to-serial conversion, voltage regulation, and breakout pins
• SCD41/SGP40 Sensor Module: The sensor IC mounted on a small PCB with necessary support components
• SH1106 Display Module: Display controller with integrated voltage regulation and I2C interface

Future Approach - Using Bare ICs:

• ESP32-WROOM-32 Module: Integrate directly onto PCB with custom power regulation and USB interface
• SCD41/SGP40 IC: Mount the bare sensor with custom analog front-end circuitry
• SH1106 Controller: Integrate with custom display driver circuit

Why I Didn’t Use PCBA Service This Time:

Availability: JLCPCB’s component sourcing partner (LCSC Electronics) has excellent stock of common ICs but limited availability of the specific development modules I was using. The variety of form factors and pinouts for modules makes standardization challenging.

Complexity: Moving to bare ICs requires designing additional support circuitry - voltage regulators, crystal oscillators, and protection circuits. While this reduces cost and size, it significantly increases design complexity.

Time to Market: Using modules allowed me to focus on the core functionality rather than getting bogged down in power supply design and RF engineering.

Next Steps: Toward True Production Readiness

This custom PCB version represents a major milestone, but the journey toward a truly production-ready design continues:

1. IC Integration: Redesign using bare ICs instead of modules for cost and size optimization
2. PCBA Services: Leverage JLCPCB’s assembly services for automated component placement and soldering
3. Design for Manufacturing (DFM): Optimize the design for high-volume production

Looking Ahead

As we wrap up this phase of the project, we’ve successfully achieved the core goals outlined in Part 1:

✅ Accuracy First: SCD41 NDIR sensor provides reliable CO2 measurements
✅ Internet Connectivity: WiFi-enabled with Prometheus metrics endpoint
✅ Data Logging & Visualization: Grafana dashboard for historical analysis
✅ Custom Hardware: Professional PCB design with 3D printed enclosure

The next phases will focus on smart home integration and scaling the design for potential small-batch production. Whether you’re interested in IoT development, PCB design, or just following along with this maker journey, the adventure continues!

The Soldering Reality Check

Initially, I planned to solder everything onto a general-purpose PCB board to create a more permanent and compact solution. However, reality quickly set in when I attempted this approach.

The challenges were immediate and overwhelming:

• Poor Soldering Skills: Despite watching countless YouTube tutorials, my soldering technique was clearly inadequate for creating reliable connections
• Excessive Fumes: The soldering process generated far more fumes than expected, making it uncomfortable to work indoors
• Scalability Issues: Even if I could improve my technique, hand-soldering every device wasn’t practical for making multiple units
• Reliability Concerns: The messy connections were prone to shorts and intermittent failures

After this humbling experience, I realized that a different approach was needed.

Switching to Mini Breadboards

Instead of fighting with traditional PCB soldering, I decided to embrace a more modular approach using small breadboards. This solution offered several advantages:

• No Soldering Required: All connections use jumper wires and breadboard pins
• Easy Modifications: Changes to the circuit can be made quickly without desoldering
• Reliable Connections: Breadboard connections, while temporary, are actually quite reliable for prototyping
• Compact Form Factor: Mini breadboards are much smaller than full-size ones while still accommodating our components

The trade-off was a slightly larger final size compared to a custom PCB, but the benefits far outweighed this limitation for a DIY project.

Learning CAD Design with OnShape

To create a proper enclosure, I needed to learn 3D modeling. After researching various options, I chose OnShape for several reasons:

• Cloud-Based: No software installation required, works on any computer
• Free for Personal Use: Full professional features available at no cost
• Excellent Tutorials: Comprehensive learning resources available
• Browser-Based: Works seamlessly across different operating systems

Enter the Bambu Lab A1 Mini

To bring my digital designs into the physical world, I invested in a Bambu Lab A1 Mini 3D printer. This compact, budget-friendly printer turned out to be a game-changer:

Key Features:

• Automatic Calibration: Minimal setup required for consistent prints
• Quiet Operation: Can run overnight without disturbing anyone
• Reliable Performance: Consistent quality across multiple prints
• Compact Size: Fits perfectly on a desk without taking up too much space

The 3D Printing Rabbit Hole

What started as a simple need for an enclosure quickly spiraled into a full-blown 3D printing obsession! Once I had the printer set up and working reliably, I found myself designing and printing all sorts of items:

• Custom cable organizers for my desk
• Replacement parts for broken household items
• Tool holders for my workshop
• Decorative items and gifts for family
• Prototypes for completely unrelated project ideas

The ability to go from idea to physical object in just a few hours is incredibly addictive. I now understand why 3D printing enthusiasts are so passionate about their hobby!

Designing the Perfect Enclosure

After getting comfortable with both OnShape and 3D printing, I focused on creating the ideal enclosure for our CO2 monitor. The design requirements were:

Functional Requirements:

• Accommodate the mini breadboard and all components
• Provide access to the display screen
• Allow for ventilation (critical for CO2 sensing)
• Easy assembly without tools
• Accessible USB port for programming and power

Aesthetic Goals:

• Clean, modern appearance
• Compact footprint
• Professional finish

Printing and Assembly

The printing process took about 1.5 hours for both pieces, using PLA filament for its ease of use and good surface finish. The snap-fit design worked perfectly on the first try – a testament to the precision achievable with modern 3D printing.

Assembly was straightforward:

1. Mount the mini breadboard in the bottom enclosure
2. Route the display and sensor wires through the designated channels
3. Snap the top piece into place
4. Connect the USB cable for power

The Final Result

While the transition from breadboard prototype to a finalized product has considerable room for improvement, it’s nonetheless an interesting development.

A black version of the enclosure:

Next Steps: Toward a Production-Ready Design

With our 3D printed enclosure complete, the next major milestones are designing a custom PCB to reduce size and manual work to connect the wires and implementing smart home integration. The final stage will bring Google Home integration, automated HVAC triggers, and multi-room monitoring capabilities as originally envisioned in Part 1.

Reflections on the Journey

This project has evolved from a simple air quality monitoring need into a comprehensive learning experience spanning:

• Electronics Design: From basic breadboard prototyping to planning custom PCBs
• Software Development: ESP-IDF programming, data visualization, and IoT protocols
• Mechanical Design: CAD modeling and 3D printing techniques
• Manufacturing: Understanding the path from prototype to producible design

The most rewarding aspect has been the hands-on learning across multiple disciplines. Each challenge – from poor soldering skills to CAD modeling – has opened up new areas of knowledge and capability.

Most importantly, this project demonstrates that with modern tools and a willingness to learn, individual makers can create sophisticated devices that compete with commercial products. The combination of affordable development boards, accessible CAD software, desktop 3D printing, and AI-assisted programming has democratized hardware development in unprecedented ways.

Hardware Cost Optimization

For this iteration, I made strategic component choices to reduce costs while improving functionality:

NodeMCU ESP32 vs ESP32-S3 DevKit

I switched from the ESP32-S3 DevKit to a NodeMCU ESP32 development board, reducing the microcontroller cost from around $12 to just $3. While we lose some of the advanced features of the S3, the standard ESP32 provides all the capabilities we need for this project.

Display Change: SH1106 to SSD1306

I also switched from the SH1106 OLED display to an SSD1306 display, reducing the display cost from $4 to $2. The SSD1306 is smaller (0.96” vs 1.3”) but offers the same 128x64 resolution and is more widely supported in libraries.

While the smaller screen real estate requires more careful UI design, the cost savings make it worthwhile for a production design.

The SCD41: A Game-Changing Sensor

The star of this upgrade is the Sensirion SCD41 sensor ($20). Unlike the SGP30 which estimates CO2 based on volatile organic compounds, the SCD41 uses NDIR (Non-Dispersive Infrared) technology to directly measure CO2 concentration, providing much more accurate readings.

Soldering Challenge and AI Assistant

The SCD41 I received came without pre-soldered header pins. I turned to Gemini for soldering guidance and managed to get it connected, though admittedly not with the most beautiful results!

Code Development with Copilot Pro and Claude Sonnet 4

For this iteration, I upgraded to Copilot Pro and started using Claude Sonnet 4 (Preview) for more complex code generation tasks. The difference in capability is remarkable.

Creating the SCD41 Driver

The most impressive part of this development was that the SCD41 driver wasn’t available in the ESP-IDF component registry. I asked the AI to help, and it:

1. Found the datasheet: Automatically located the SCD41 datasheet online
2. Generated a complete driver: Created a full I2C driver implementation from scratch
3. Worked on first run: The generated code compiled and functioned perfectly immediately

The magic of modern AI development tools continues to amaze me. The driver worked so well that I decided to package it as a reusable component and published it to the ESP-IDF Component Registry: https://components.espressif.com/components/chiehmin/scd41

Side-by-Side Comparison: SGP30 vs SCD41

With both sensors running simultaneously, the accuracy difference is striking:

Detection Method Comparison

The fundamental difference in detection methods explains the accuracy gap:

SGP30 (MOX - Metal Oxide Semiconductor):

• Estimates CO2 based on TVOC measurements
• Highly temperature-dependent
• Requires calibration and warm-up time
• Good for relative changes, poor absolute accuracy

SCD41 (NDIR - Non-Dispersive Infrared):

• Directly measures CO2 absorption at specific infrared wavelengths
• Temperature-compensated internally
• Provides absolute CO2 measurements
• Industry-standard accuracy (±40 ppm + 5% of reading)

Real-World Testing Results

Through manual testing, the differences are clear:

• Temperature Independence: The SCD41 maintains consistent readings regardless of ambient temperature, while the SGP30 shows significant drift with temperature changes
• Response Time: Both sensors respond to window opening/closing, but the SCD41 shows more predictable and linear changes
• Absolute Values: The SCD41 readings align much better with expected indoor CO2 levels (400-1000 ppm), while SGP30 values seemed arbitrary

The SCD41 also provides temperature and humidity readings as bonus features, eliminating the need for the separate DHT11 sensor and simplifying our design.

Next Steps: Moving Toward Production

With the sensor upgrade complete and cost optimization achieved, the next phase involves:

1. PCB Design: Moving from breadboard to a custom PCB for better reliability and compact form factor
2. 3D Printed Enclosure: Designing and printing a protective case for the final assembly
3. Power Optimization: Implementing deep sleep modes for battery operation
4. Final Testing: Long-term accuracy validation and environmental testing

The total component cost for this iteration:

• NodeMCU ESP32: $3
• SSD1306 Display: $2
• SCD41 Sensor: $20
• Total: $25
  • The price for this version is similar to the previous one, but incorporates a more accurate sensor.

Stay tuned for next parts, where we’ll create a soldered PCB and 3D printed case for our smart CO2 monitor!

WiFi Station Mode and HTTP Server Implementation

Getting our ESP32 online involves several key components working together. Let’s break down the implementation based on our actual code:

WiFi Initialization and Connection

The ESP32 connects to WiFi in station mode (WIFI_MODE_STA) using the ESP-IDF framework. Our implementation includes:

1. NVS Flash Initialization: Required for storing WiFi configuration data
2. Network Interface Setup: Initialize TCP/IP adapter and create default WiFi station interface
3. Event Handler Registration: Handle WiFi events like connection success, disconnection, and IP assignment
4. WiFi Configuration: Set SSID, password, and security mode (WPA2-PSK)

Event-Driven WiFi Management

Our WiFi event handler manages the connection lifecycle and provides user feedback through the OLED display:

• WIFI_EVENT_STA_START: Automatically attempts connection when WiFi starts
• WIFI_EVENT_STA_DISCONNECTED: Handles reconnection attempts on connection failure
• IP_EVENT_STA_GOT_IP: Displays the assigned IP address on the OLED screen

This event-driven approach ensures robust connectivity with automatic reconnection.

HTTP Server with Prometheus Endpoint

Once connected to WiFi, we start an HTTP server using ESP-IDF’s esp_http_server component. The server runs on the default port 80 and registers a single endpoint at /metrics that serves our sensor data in Prometheus format.

Thread-Safe Sensor Data Access

To ensure data consistency between the sensor reading loop and HTTP requests, we use a FreeRTOS mutex (sensor_mutex) to protect access to the shared sensor data structure. This prevents race conditions when the web server is serving metrics while sensors are being read.

Exposing Metrics in Prometheus Format

Prometheus is a popular open-source monitoring and alerting toolkit. It scrapes metrics from instrumented jobs, either directly or via an intermediary push gateway for short-lived jobs. For our ESP32, we’ll create an HTTP endpoint that Prometheus can scrape.

The Prometheus exposition format is text-based. Each metric has a help string (# HELP), a type string (# TYPE), and then the metric name with its value. Here’s an example of what our /metrics endpoint will output:

# HELP air_quality_co2_ppm CO2 concentration in parts per million
# TYPE air_quality_co2_ppm gauge
air_quality_co2_ppm 400
# HELP air_quality_tvoc_ppb Total Volatile Organic Compounds in parts per billion
# TYPE air_quality_tvoc_ppb gauge
air_quality_tvoc_ppb 142
# HELP air_quality_temperature_celsius Temperature in degrees Celsius
# TYPE air_quality_temperature_celsius gauge
air_quality_temperature_celsius 25.0
# HELP air_quality_humidity_percent Relative humidity percentage
# TYPE air_quality_humidity_percent gauge
air_quality_humidity_percent 38.0
# HELP air_quality_last_update_timestamp Unix timestamp of last sensor update
# TYPE air_quality_last_update_timestamp gauge
air_quality_last_update_timestamp 80732

When a request comes to http://<esp32_ip_address>/metrics, our ESP32 will read the latest sensor values, format them as shown above, and send them back as the HTTP response.

Docker Compose for Prometheus and Grafana

To collect, store, and visualize this data, we’ll use Prometheus and Grafana. Docker Compose is an excellent tool for defining and running multi-container Docker applications. Here’s a simplified docker-compose.yml to get Prometheus and Grafana running:

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus:/etc/prometheus/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--web.console.templates=/usr/share/prometheus/consoles'
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - prometheus
    restart: unless-stopped

volumes:
  prometheus_data: {}
  grafana_data: {}

You’ll also need a prometheus.yml configuration file (in a prometheus directory next to your docker-compose.yml) to tell Prometheus where to scrape metrics from. It would include a job definition for our ESP32:

global:
  scrape_interval: 15s # By default, scrape targets every 15 seconds.

scrape_configs:
  - job_name: 'esp32-air-quality'
    static_configs:
      - targets: ['<esp32_ip_address>:80'] # Replace <esp32_ip_address> with the actual IP

I run these Docker containers on my home NAS (Synology DS920+), which is a great way to have an always-on system for data collection and long-term storage. GitHub Copilot was a great help in drafting the initial ESP32 web server code and the Docker Compose configuration.

Visualizing the Data

Once Prometheus is scraping data from the ESP32, and Grafana is connected to Prometheus as a data source, you can create dashboards to visualize the air quality metrics over time.

Here’s a conceptual image of what the CO2 data might look like in Grafana:

The data shows interesting trends. For example, when CO2 and TVOC values spike, opening a window causes the levels to drop significantly. Closing the window leads to the values rising again. This demonstrates that the relative changes are being captured effectively.

Next Steps: Improving Accuracy

While the relative values from the SGP30 are insightful, its absolute accuracy, especially for CO2, can be limited. For more precise measurements, the next step in this project will be to integrate a more accurate sensor. I plan to use the Sensirion SCD41, which uses an NDIR (Non-Dispersive Infrared) sensor to detect CO2, known for better accuracy.

Additionally, I’ll migrate the project to a more cost-effective ESP32 board for the final PoC before considering a “Stage 2” development, which might involve a custom PCB or a more refined enclosure.

Stay tuned for Part 4, where we’ll dive into integrating the SCD41 sensor and refining our hardware setup!

For this PoC, I assembled the core components on a breadboard to test functionality and get a feel for the sensors and the ESP32 platform.

Hardware Lineup for the PoC

Here’s a quick rundown of the components I used for this initial build:

• Microcontroller: ESP32-S3 Dev Board (approx. $10 USD)
  • I opted for a higher-end ESP32-S3 for this PoC. While it’s a bit more powerful (and slightly more expensive) than strictly necessary for just a CO2 monitor, I chose it with future projects in mind that might demand more computational power or specific S3 features like AI acceleration capabilities or more I/O.
  • The ESP32 family is quite diverse:
    • Original ESP32: Still a workhorse, great for many IoT projects, very cost-effective.
    • ESP32-S2: Single-core, focused on low power and security.
    • ESP32-S3: Dual-core, adds AI instructions, more I/O, and Bluetooth 5 LE.
    • ESP32-C series (C3, C5, C6 etc.): RISC-V based, often targeting specific cost points or connectivity needs (like Wi-Fi 6 in the C6).
  • For later stages, especially if aiming for cost optimization in Stage Three (custom PCB), I’ll likely evaluate using a more basic ESP32 or an ESP32-C series chip to bring down the unit cost.
• Display: SH1106 OLED Display (1.3 inch) (approx. $4 USD)
  • A crisp monochrome display to show CO2 levels, temperature, and humidity directly on the device.
• Temperature & Humidity Sensor: DHT11 (approx. $1 USD)
  • A basic but widely available sensor to get ambient temperature and humidity readings. While not the most accurate, it’s sufficient for a PoC.
• CO2 & TVOC Sensor: Sensirion SGP30 (approx. $10 USD)
  • This sensor provides CO2 equivalent (eCO2) and Total Volatile Organic Compound (TVOC) readings. It’s a good starting point for air quality sensing.

All these components were wired up on a standard breadboard for easy iteration.

Development Environment: ESP-IDF All the Way

Instead of using the Arduino extension for ESP32, I decided to set up and use the ESP-IDF (Espressif IoT Development Framework) directly.

• Pros of ESP-IDF:
  • Direct Control: It provides much more direct access to the ESP32’s hardware features, FreeRTOS (the underlying real-time operating system), and low-level libraries.
  • Latest Features: You often get access to the newest features and bug fixes from Espressif sooner.
  • Optimization: More opportunities for fine-grained optimization of performance and memory usage.
  • Official Framework: It’s the official development framework from Espressif.
• Cons of ESP-IDF:
  • Steeper Learning Curve: Compared to Arduino’s simplified API, ESP-IDF can be more complex to get started with.
  • More Boilerplate: Setting up projects and managing components can involve more configuration.

For a project where I want to understand the nuts and bolts and potentially build custom drivers, the control and flexibility offered by ESP-IDF felt like the right choice.

Peripheral Choices & I2C Simplicity

To practice working with the ESP32 and its peripherals, I selected the SH1106, DHT11, and SGP30. A key decision here was to primarily use sensors with an I2C interface.

• I2C (Inter-Integrated Circuit):
  • Uses only two wires (SDA for data, SCL for clock) plus power and ground.
  • Simpler wiring compared to SPI, especially when connecting multiple devices (as they can share the same bus, each with a unique address).
  • Sufficient speed for many common sensors.
• SPI (Serial Peripheral Interface):
  • Generally faster than I2C.
  • Requires more wires (MOSI, MISO, SCLK, and a Chip Select for each device).

For this PoC, the simplicity and reduced wire clutter of I2C were ideal.

Coding with an AI Assistant: GitHub Copilot & Sonnet 3.5

A significant part of this PoC was leveraging AI for code generation. I used GitHub Copilot, powered by the Sonnet 3.5 model, extensively.

My experience was overwhelmingly positive:

• Rapid Prototyping: Copilot was excellent at generating initial boilerplate code for sensor initialization, reading data, and displaying it on the OLED.
• Iterative Refinement: While the first code suggestion wasn’t always perfect, the key was effective communication. By providing Copilot (running in an agent-like chat interface) with specific context, such as:
  • Datasheets for the sensors (especially for communication protocols and register maps).
  • Information about existing third-party device drivers in the ESP-IDF component registry.
  • Clear descriptions of the desired logic. …I was able to guide it to produce working code after several iterations.
• Driver Generation from Scratch: One of the most impressive feats was generating a device driver for the SGP30 sensor from scratch. At the time, I couldn’t find a readily available ESP-IDF component for it in the Espressif Component Registry that fit my needs perfectly. So, armed with the SGP30 datasheet, I worked with Copilot to generate the I2C communication logic, data processing, and the necessary C code structure for an ESP-IDF component.
• Contributing Back: I was so pleased with the generated SGP30 driver that I packaged it as a proper ESP-IDF component and published it to the Espressif Component Registry! You can find it here: chiehmin/sgp30.

The PoC in Action!

After some tinkering and coding iterations, the breadboard setup came to life! The ESP32-S3 successfully read data from the DHT11 and SGP30, displaying CO2 (eCO2), TVOC, temperature, and humidity on the SH1106 OLED screen.

Here’s a picture of the final PoC setup:

Next Steps

This Proof of Concept (PoC) phase was a fantastic learning experience, especially in leveraging ESP-IDF and AI for development. The next step involves connecting the ESP32 to the internet and exposing its metrics, allowing other services to store historical data and generate graphs.

For a while now, I’ve been looking to get a reliable CO2 monitor for my home and workspace. We all know good air quality is crucial for concentration, health, and overall well-being, especially when spending many hours indoors. However, my journey into the world of commercial CO2 monitors has been a bit of a letdown.

It seems you’re often caught between two extremes:

1. The “Too Inaccurate” Bunch: Many lower-priced CO2 monitors, like some of the generic models you might find on Amazon or other online marketplaces, often use less reliable sensing technologies. You’ll frequently see user reviews complaining about inconsistent readings, slow response times, or values that just don’t seem to reflect the actual environment. It’s hard to trust data when it’s all over the place!

1. The “Too Expensive” Crew: On the other end of the spectrum, monitors that use high-quality NDIR (Non-Dispersive Infrared) sensors and offer good accuracy, can be quite an investment (often around $200-$250), especially if you want multiple units.

This gap in the market – affordable yet accurate and smart – is what sparked my latest project idea.

My DIY Solution: A Smart, Connected, and Customizable CO2 Monitor

Why not build one myself? This way, I can ensure the accuracy I want, add the features I need, and have full control over the data.

Here are the primary goals for my DIY CO2 monitor:

• Accuracy First: Utilize a reliable NDIR CO2 sensor for trustworthy measurements.
• Internet Connectivity: Expose the CO2 (and potentially temperature/humidity) metrics over my local network and, eventually, the internet.
• Data Logging & Visualization: I want to record historical CO2 data to identify patterns and plot graphs. This will help me understand how CO2 levels change in different rooms and under various conditions (e.g., number of people, ventilation).
• Smart Home Integration: The ultimate goal is to integrate this with my Google Home ecosystem. Imagine the possibilities: automatically triggering an air circulation system or a smart fan when CO2 levels exceed a predefined threshold!

The Brains of the Operation: ESP32

After doing some initial research and considering various microcontrollers, I’ve decided to go with the ESP32 series. It’s a powerhouse for IoT projects like this because:

• Integrated Wi-Fi & Bluetooth: Essential for network connectivity.
• Sufficient Processing Power: Easily handles sensor data, network communication, and potentially a small web interface.
• Rich Peripheral Set: Plenty of I/O for sensors and other components.
• Strong Community & Ecosystem: Abundant libraries, tutorials, and community support make development much smoother.
• Cost-Effective: ESP32 development boards are very affordable.

The Development Roadmap: A Phased Approach

I’m planning to develop this project in three main stages:

Stage One: Proof of Concept (PoC) on a Breadboard

This is where the rubber meets the road (or rather, the components meet the breadboard!).

• Connect a chosen NDIR CO2 sensor (e.g., Senseair S8, Winsen MH-Z19, or Sensirion SCD30/SCD4x) to an ESP32 development board.
• Write the initial firmware to read CO2, temperature, and humidity.
• Possibly add a small OLED display for local readings.
• Implement a basic web server on the ESP32 to serve the data on my local network.

Stage Two: From Breadboard to Bespoke Enclosure

Once the PoC is validated and working reliably, the next step is to make it more permanent and presentable.

• Solder the ESP32 module, sensor, and any other necessary components (like power regulation) onto a general-purpose PCB (perfboard or stripboard).
• Design and 3D print a custom case for the monitor. This will give it a more polished, product-like feel.

Stage Three: Custom PCB & Cost Optimization for Potential “Mass Production”

This is the most advanced stage, aiming for a highly refined and potentially replicable design.

• Design a custom Printed Circuit Board (PCB) specifically tailored for this CO2 monitor. This will result in a much more compact, robust, and professional-looking device.
• Instead of using a full ESP32 development board, integrate the ESP32 IC (the chip itself, e.g., ESP32-WROOM-32 module or even the bare chip if feeling adventurous) directly onto the custom PCB. This significantly reduces the bill of materials (BOM) cost and physical footprint, unlocking the potential for easier replication or even small-scale “mass production” for friends or the local community.

What’s Next?

I’m incredibly excited to embark on this project! I’ll be sharing my progress, challenges, code snippets, design files, and any interesting discoveries right here on this blog. Expect deep dives into sensor comparisons, ESP32 programming hurdles, PCB design learnings, and the joys (and frustrations) of 3D printing.

If you’re interested in air quality, IoT, ESP32 projects, or just love a good DIY challenge, stay tuned!

Why This Blog Exists

After years developing and optimizing low-level device drivers and frameworks, I’ve witnessed firsthand how development paradigms evolve. Now, I’m exploring how AI can revolutionize software engineering - and this blog documents that journey in real-time.

The Journey Begins

This is the beginning of documenting how software development is evolving in the age of AI. Every post here represents a real experiment combining technical expertise with AI collaboration.

Join me as we explore this exciting frontier where engineering meets artificial intelligence!

Note: This blog represents a collaboration between software engineering expertise and AI assistance. Full transparency about our development process is core to this journey.