The first is general-purpose computing, where they handle a wide range of tasks, including running diverse applications and programs. Examples include laptops, desktops, servers, and supercomputers.

The second is embedded systems, which are specialized computers designed for specific functions. Commonly found in devices such as thermostats, refrigerators, cars, and other smart appliances, they rely on sensors to collect environmental data and execute their tasks efficiently.

The Role of Sensors

Sensors play a critical role in both types of computing. In embedded systems, sensors gather environmental data to help devices like autonomous vehicles, home appliances, and industrial machines perform tasks. In general-purpose computers, sensors primarily monitor internal conditions such as temperature and voltage, ensuring safe operation and preventing issues like overheating or electrical faults.

As Artificial Intelligence (AI) and the Internet of Things (IoT) evolve, sensors have become indispensable for gathering real-world data to support intelligent decision-making. Embedded systems leverage sensors to perceive their environment, transforming raw data into actionable insights that power automation and improve efficiency across industries.

This means that understanding sensor interfacing and designing robust sensor-driven software has become a vital skill for engineers and hobbyists alike.

Whether you're a beginner or experienced engineer, this guide will help you build a solid understanding of sensor interfacing software.

What You’ll Learn and Article Scope

In this article, you’ll learn how to connect sensors to microcontrollers (MCUs) and design sensor software pipelines that turn raw data into meaningful, usable information. You’ll also explore practical techniques for processing sensor data accurately and efficiently in embedded systems.

Here’s a breakdown of what we’ll cover:

• What sensors are and how they work – An introduction to sensors, common types, and how sensor pipelines help process sensor data.

• Key sensor characteristics – Important parameters like sensitivity, accuracy, precision, range, drift, and response time to help you choose the right sensor for your project.

• How to interface sensors with microcontrollers – Hardware connections and communication protocols like SPI, I²C, and GPIO that allow microcontrollers to read sensor data.

• Software architecture for sensor data – A high-level overview of the software pipeline that processes sensor data, including drivers, ADC support, scaling, calibration, and post-processing.

• Detailed design of pipeline components – A closer look at each step in the pipeline, focusing on scaling raw data, calibrating sensors, and applying filters to clean up noisy signals.

• Practical tips for power management – Best practices for handling power efficiently using low-power modes, FIFO buffers, and DMA when working with sensor data in embedded systems.

By the end of this article, you’ll know how to design and implement a complete sensor data pipeline for an embedded system, from reading raw sensor data to preparing it for real-world use in intelligent, connected devices.

Note: Advanced data processing, high-resolution ADCs, and hardware circuit design for sensors are outside the scope of this article.

Prerequisites

To get the most out of this article, you should have:

1. Basic knowledge of microcontrollers: Understanding of common peripherals like ADCs (Analog-to-Digital Converters), SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit) and GPIO (General Purpose Input/Output). If you’re new to these protocols, this article provides a great overview.

2. Basic knowledge of electronics: Familiarity with circuits and signals, including analog and digital interfaces.

3. Programming in C: Familiarity in embedded software development, including driver development.

4. (Optional) Basic knowledge of sensors: Understanding different types of sensors (like temperature, pressure, motion) is helpful but not required.

Also, this article assumes the following:

• You are working with a microcontroller equipped with the peripherals needed for sensor integration. The details of microcontroller peripherals can be found in a reference manual for example for an STM32F4 series microcontroller will have all the details :

• You are familiar with compilers, debuggers, and IDEs used in embedded systems. Some common tools include:

  • Compilers: GCC, Clang,

  • Debuggers: GDB, LLDB

  • IDEs: Visual Studio Code (VSCode) is a popular choice, especially with extensions for embedded development and debugging.

• You aim to build reliable, sensor-driven embedded systems, capable of collecting and processing real-world data efficiently.

Table of Contents

• What is a Sensor and Sensor Pipeline?

• Sensor Characteristics

• How to Interface with a Microcontroller

• Software Architecture

  • High-Level Overview of Components

  • Accessing Data from the Sensor

  • Sensor Power Management

• Detailed Design of Components

  • 1. Sensor Driver

  • 2. ADC Support

  • 3. Scaling

  • 4. Calibration

  • 5. Data Post-Processing

• Conclusion

What is a Sensor and Sensor Pipeline?

A sensor detects changes in physical properties such as temperature, pressure, or light and converts them into electrical signals that can be measured or interpreted. For example, a thermistor is a type of resistor whose resistance changes with temperature. As the temperature varies, the resistance of the thermistor changes, altering the voltage across it. The system then interprets this voltage change to determine the temperature.

To better understand sensors, consider the natural sensors in the human body: the eyes, ears, skin, nose, and tongue. These natural sensors constantly send signals about the environment to the brain for processing. Different regions of the brain interpret these signals and use the information to drive actions and responses. Just like the brain processes signals from natural sensors, a microcontroller processes signals from electronic sensors using a sensor pipeline.

Sensors come in many types, each designed to detect specific physical properties. Some sensors have a sensing element that changes its properties in response to conditions like heat, light, or pressure. Examples include thermistors, infrared receivers, and photodiodes.

For detecting movement, such as acceleration and rotation, MEMS (Microelectromechanical Systems) sensors—like accelerometers and gyroscopes—are widely used.

To measure distance, sensors like sonars, ultrasonic sensors, and radars are common. These are just a few examples of the many types of sensors available.

Beyond the types of physical properties they detect, sensors also differ in their levels of integration. Some sensors are raw sensors, consisting only of a sensing element and a transducer with simple leads for direct connection to an external circuit.

Others, known as smart sensors, include additional components such as an ADC (analog-to-digital converter) and onboard processing capabilities, enabling them to handle more of the data processing independently.

The choice between a raw sensor and a smart sensor depends on your application requirements, including factors like cost, size, and the processing load on the interfacing microcontroller.

Returning to our human analogy, consider how vision works as a sensor pipeline. When light enters our eyes, photoreceptor cells (rods and cones) in the retina act as sensing elements, converting the light into electrical signals. These signals travel via the optic nerve to the brain’s visual cortex, where they undergo processing to form a recognizable image. The brain then interprets this information and initiates a response, like smiling when you see a beautiful scenery.

Similarly, a sensor pipeline for an embedded system can be defined as shown in the picture below:

Each of these steps may have different requirements based on the application. Creating a requirements document for the sensor is helpful when selecting the appropriate sensor and configuring the pipeline.

Sensor Characteristics

Before you dive into the blocks of the sensor pipeline, let’s review some important characteristics of a sensor.

Sensitivity

Sensitivity is the ability of a sensor to detect small changes in the physical property it’s designed to measure.

Sensitivity can vary based on factors like manufacturing processes, cost, and the design of the sensing element.

Sensors designed for a specific property often come in different sensitivity levels, allowing users to select an appropriate sensitivity based on the application requirements.

Accuracy

Accuracy is the degree to which a sensor’s measurement matches the true value of the physical property it’s measuring. Testing a sensor’s accuracy typically requires comparing its readings to those of a reference instrument.

A sensor may have gain and offset errors—issues that calibration can help correct. Calibration adjusts for these systematic errors, which are often due to manufacturing tolerances or design factors.

Once calibrated, the sensor’s output can be verified against a reference to confirm its accuracy. The required level of accuracy should be determined based on the application’s needs.

Precision

Precision refers to the consistency or repeatability of a sensor's measurements, regardless of how close those measurements are to the true value. It indicates the sensor's ability to produce the same output under identical conditions and how finely it can resolve and report values.

For example, if the true temperature of an object is 12.53°C:

• A precise sensor will consistently measure values like 12.52°C, 12.53°C, or 12.54°C, even if those values are slightly offset from the true temperature.

• A highly accurate sensor, on the other hand, will measure values close to 12.53°C but may lack precision if those readings vary widely (e.g., 12.50°C, 12.53°C, and 12.56°C).

For applications requiring exact measurements, a sensor with both high accuracy (closeness to the true value) and high precision (low variability) is essential. This is especially important in distinguishing small differences, such as between 12.5°C and 12.53°C.

In contrast, applications with less stringent requirements might use sensors with broader tolerances, such as ±1°C, which are sufficient for general monitoring purposes.

Range

The range of a sensor refers to the span between the maximum and minimum values of the physical property it can measure while maintaining its specified precision and accuracy. A sensor's operating range may extend beyond its measurement range, but the measurement range defines the limits within which the sensor reliably adheres to its specified sensitivity, accuracy, and response time.

Drift

Drift is when a sensor's output changes over time due to conditions like temperature or humidity. Components within the sensor, including the sensing element, may be sensitive to these conditions, leading to gradual shifts in measurements.

For example, many components are affected by temperature and humidity changes, which can alter sensor readings. Also, sensors with internal oscillators may experience time-based drift, impacting accuracy.

Regular calibration with an accurate external reference (such as a precise clock) can help correct for drift and maintain reliable measurements. For certain applications, selecting a sensor with acceptable drift characteristics is crucial.

Response Time

Response time is the duration a sensor takes to detect and reflect a change in the measured physical property. For example, if the temperature rises by 5°C, the response time indicates how long the temperature sensor takes to reflect this change in its output.

Response time depends on the sensor’s design, manufacturing quality, and internal components, such as the ADC (Analog-to-Digital Converter), averaging circuits, and filters within the sensor pipeline.

All the parameters mentioned above are thoroughly documented in the sensor’s data-sheet. In practice, it’s a good idea to create a sensor requirements document for each specific application, detailing these key parameters as a baseline for sensor selection.

Now that you’ve examined the key characteristics of sensors, let’s explore how you can connect them to a microcontroller for real-world applications.

How to Interface with a Microcontroller

Choosing a Communication Protocol

Another essential aspect of sensor requirements is specifying the communication interface between the sensor and the MCU or processor in the system. It’s important to understand how the sensor will be interfaced based on its output signal type and the available pins on the microcontroller.

For instance, certain sensors may connect directly to an analog or digital input pin on a microcontroller. A raw sensor, such as a temperature sensor, typically connects to an analog input pin, which is then read by the microcontroller’s internal ADC (Analog-to-Digital Converter).

In contrast, a digital-output sensor connects to a digital GPIO (General Purpose Input/Output) pin. For instance, speed sensors generate square waves with variable pulse widths to indicate speed. These signals are usually connected to a GPIO pin configured as an external interrupt or timer capture input, allowing the microcontroller to measure pulse width accurately.

A smart sensor, on the other hand, often supports communication protocols like SPI (Serial Peripheral Interface) or I2C (Inter-Integrated Circuit). These interfaces enable the microcontroller to configure the sensor, check its status, and retrieve data through register reads and writes.

Choosing the appropriate communication protocol for interfacing a sensor depends on the available pins in the system and the specific requirements of the application.

Tip: When working with protocols like I²C or SPI, using tools such as Saleae logic analyzers can greatly simplify debugging and validation. Logic analyzers capture and visualize communication signals, and tools like Saleae offer built-in protocol interpreters to help you decode sensor communication in real time. This can be especially helpful when troubleshooting configuration issues, timing problems, or communication errors during sensor interfacing.

Figure 2 below shows an example of a microcontroller connected to 4 sensors having different interfaces.

Determining Power Requirements

Power requirements are another key consideration when interfacing a sensor. Sensors may operate at different voltages (for example, 3.3V or 5V), so ensuring the microcontroller can accommodate these levels is essential. Level converters can bridge voltage mismatches, ensuring compatibility between the sensor and microcontroller voltage levels.

Timing and sampling requirements must also be evaluated, especially for sensors generating high-frequency data. Configuring external interrupts on GPIO pins can ensure timely data capture, while techniques like using DMA can streamline data transfer for sensors sampling at high frequencies without CPU involvement.

Now that you’ve learned about communication protocols and hardware connections, let’s focus on designing the software architecture that acquires, processes, and prepares sensor data for use. Designing effective software is crucial for obtaining clean, reliable data from the sensor.

Software Architecture

Now that we’ve chosen the sensor and communication protocol, let’s design the software architecture for the sensor pipeline. This software runs on the microcontroller connected to the sensor and processes raw data to make it clean and usable.

While application-level data processing is beyond the scope of this article, let’s focus on interfacing with the sensor and preparing the data for application use.

The sensor processing pipeline can be broken into the following components:

1. Sensor Driver

2. Analog-to-Digital Conversion (ADC) Support

3. Scaling

4. Calibration

5. Data Post-Processing

Let’s examine a high-level overview of these components for both smart and raw sensors.

High-Level Overview of Components

1. Sensor Driver

   1. Smart sensors: The driver configures the sensor, manages power, and handles read and write operations to the sensor registers over a communication protocol like SPI, I2C.

   2. Raw sensors: The driver may only control GPIOs for power management, as raw sensors typically lack registers.

2. Analog-to-Digital Conversion (ADC) Support

   1. Smart sensors: Include an onboard ADC, which is configured through the sensor driver.

   2. Raw sensors: Requires an external ADC, an ADC driver implemented in software to configure the ADC, initiate conversions, and retrieve data.

3. Scaling: Scaling is necessary for both smart and raw sensors. It converts digital counts after the analog to digital conversion into meaningful physical quantities using formulas provided in the sensor data sheet. For example, a temperature sensor will use a formula to convert digital counts to degree Celsius.

4. Calibration: Once the measured physical quantity is obtained, calibration adjusts the value by applying offsets, gains, or both to correct errors. This process ensures the sensor output aligns with reference values across its entire measurement range. A detailed discussion of the calibration process will follow in the next section.

5. Data Post-Processing: Post-processing techniques, such as filtering are applied to improve data quality and reduce noise. Common filters such as low-pass or high-pass filters can remove unwanted frequency components.

Accessing Data from the Sensor

The method of accessing data depends on the whether it’s a raw sensor or a smart sensor. Smart sensors will have onboard ADCs and FIFOs. Before delving into how data is accessed, it’s important to first understand sampling frequency.

Sampling Frequency:

The frequency of taking a measurement from the sensor must follow the Nyquist-Shannon sampling theorem. It states that the sampling rate must be twice the highest frequency component of the signal to be measured to accurately reconstruct the measured data.

The sampling frequency defines how often the sensor captures data, which affects how the data is accessed. Depending on whether the sensor is a raw sensor or a smart sensor, the approach to handling this sampled data varies.

Smart Sensors:

1. Data register: The sensor writes sampled data directly into a register based on the set sample frequency updated during setup. The microcontroller reads this data register based on a data conversion completion interrupt.

2. FIFObBuffer: Some sensors include FIFO (First-In, First-Out) buffers to store multiple data points. When enabled, the FIFO updates at the configured sampling frequency and trigger interrupts when it becomes full or reaches a predefined level.
   The benefits of FIFO include:

   1. Power efficiency: The MCU can process data in batches, reducing CPU overhead and allowing it to enter low-power mode during data collection.

   2. Sampling and processing rate matching: FIFO buffers help reconcile differences between the sensor’s sampling rate and the MCU’s data processing rate.

   3. For MCUs with Direct Memory Access (DMA), data transfer from the sensor to MCU memory can occur without CPU intervention, further reducing power consumption.

Raw Sensors:

For raw sensors, the MCU triggers ADC conversions at the sampling frequency, often using a timer interrupt. Data is read upon the ADC conversion complete interrupt, allowing the MCU to sleep during conversions and between samples to save power.

Sensor Power Management

Power management is critical for energy-sensitive applications. Strategies include:

1. Low-power modes: Many sensors support low-power modes configurable through sensor registers.

2. GPIO-controlled power cycling (Duty-Cycling): For sensors without built-in low-power modes, the microcontroller can toggle the sensor’s power line using a GPIO pin, reducing power consumption further. Figure 3 below shows the diagram of a raw temperature sensor whose power is controlled using a GPIO from the MCU. For example, a temperature sensor in sleep mode can be activated only when temperature readings are required.

The above techniques ensure efficient use of power while maintaining the required data sampling rate and sensor responsiveness.

With the high-level architecture in mind, we’ll now dive into the detailed design of each pipeline component.

Detailed Design of Components

In this section, you’ll delve into the key components of the sensor pipeline outlined in the Software Architecture section.

1. Sensor Driver

The sensor driver is responsible for managing communication, configuration, power, and data acquisition for both smart and raw sensors.

Smart Sensor Driver:

1. Communication driver: Generic I2C or SPI drivers on the MCU can be adapted using wrapper functions to handle sensor-specific requirements, such as 1-byte, 2-byte, or 4-byte transfers.

2. Configuration: Typical tasks include setting the sampling rate, configuring interrupts, managing FIFO buffers, and, if needed, clock settings.

3. Power management: APIs should allow higher software layers to transition sensors between power modes by writing to specific registers or controlling GPIO lines for sensors without built-in power modes.

Raw Sensor Driver:

For raw sensors, the driver primarily manages power, often through GPIO-controlled toggling.

2. ADC Support

ADC support is required only for raw sensors. In this article, we’re focusing on SAR ADCs, which are commonly embedded in microcontrollers.

How SAR ADCs Work?

A SAR ADC converts an analog signal to a digital value over multiple clock cycles, with the number of cycles equal to its bit resolution (for example, 10 cycles for a 10-bit ADC).

Key terms related to ADCs:

1. Reference Voltage (VRef): Represents the maximum voltage the ADC can measure. Analog signals exceeding this limit must be scaled down.

2. Resolution: Determines the smallest detectable voltage change. For example, a 10-bit ADC with a 3.3V VRef has a resolution of 3.22 mV

$$V_{\text{Res}} = V_{\text{Ref}} /2^{10}$$

The ADC result is stored in a data register, which can then be scaled to meaningful physical units.

3. Scaling

Scaling converts ADC counts into meaningful physical values, such as temperature (°C) or acceleration (g) depending on the sensor type. Sensor datasheets typically provide the necessary formulas or lookup tables.

For example, the method to convert a voltage measured by a raw temperature sensor to temperature value is shown below:

$$V_{\text{Measured}} = Counts_{\text{ADC}} / 2^{10} * V_{\text{Ref}} \quad \text{(Get V_Measured from ADC Counts)}$$

$$Temperature_{\text{Measured}} = V_{\text{Measured}} * T_{\text{C/mV}} \quad \text{(Get Temperature physical value)}$$

Similarly, a 3-axis accelerometer maps counts on the X, Y, and Z axes to acceleration values in g or milli-g.

4. Calibration

The figure above on the left (4a) is showing Calibration with gain and offset, while the figure above on the right (4b) is showing calibration with fixed offset.

$$x_{\text{calibrated}} = Gain * x_{\text{raw}} + Offset \quad \text{(Figure 4a - Linear Calibration)}$$

$$x_{\text{calibrated}} = x_{\text{raw}} + Offset \quad \text{(Figure 4b - Fixed offset Calibration)}$$

Calibration ensures the sensor’s output aligns with reference measurements, correcting for errors introduced by design, materials, or manufacturing.

Types of Errors:

1. Offset error: A constant deviation of the sensor’s output from the true reference value, regardless of input magnitude.

2. Gain error: A proportional error where the sensor’s output scale deviates from the expected value, causing the output to increase or decrease incorrectly relative to the input.

Calibration Methods:

1. 2/3-Point calibration: This type of calibration may involve either applying a fixed offset to the raw value or applying both gain and offset. Figure 4a illustrates an example of a gain/offset calibration, while Figure 4b depicts offset calibration. In both figures, the y-axis represents the reference value measured by an accurate instrument, while the x-axis represents the raw value measured by the sensor after ADC.

2. N-Point calibration: Involves multiple points for more complex, non-linear error correction.

Implementation:

1. Calibration points shall cover the sensor’s entire measurement range for accuracy.

2. Parameters like gain and offset once estimated shall be stored in a non-volatile memory in the system for persistence to be used across power cycles.

5. Data Post-Processing

Post-processing covered in this section talks about removing noise and unwanted signal components, which improves data reliability.

Filtering

Filtering is the process of removing unwanted frequency components from a signal to improve data quality. There are several different types of filters:

• Low-Pass Filters: Allows low-frequency signals to pass while attenuating high-frequency noise.

• High-Pass Filters: Allows high-frequency signals to pass while attenuating low-frequency noise. (for example, gravitational acceleration in accelerometer data).

• Band-Pass Filters: Retains only signals within a specific frequency range, removing both lower and higher frequencies outside the desired band.

These filters are often implemented as FIR (Finite Impulse Response) or IIR (Infinite Impulse Response) filters. IIR filters are easy to implement and computationally efficient while FIR filters are computationally intensive but have better control over the frequency response.

Here, we will explore a simple low-pass filter known as the Exponential Moving Average (EMA), a type of IIR filter. A moving average filter is a mathematical technique that smooths short-term fluctuations while highlighting longer-term trends.

Unlike other moving average filters, EMA does not require maintaining a buffer, making it more memory-efficient. It is also more responsive to data changes while still providing smoothing, making it well-suited for real-time filtering. EMA assigns greater weight to recent data samples than older ones, allowing it to adapt quickly to changes in sensor readings.

EMA can be calculated like this:

$$EMA_{\text{t}} = \alpha * x_{\text{t}} + (1 - \alpha) * EMA_{\text{t - 1}}$$

$$\alpha = 2 / (N + 1) \quad \text{(Smoothening Factor, N - filter window size)}$$

$$EMA_{\text{t}} \quad \text{(Exponential Moving Average in current iteration)}$$

$$x_{\text{t}} \quad \text{(New Data Sample in Current Iteration)}$$

$$EMA_{\text{t - 1}} \quad \text{(Exponential Moving Average in the last iteration)}$$

Now that we understand the Exponential Moving Average (EMA) filter, here are two key factors to consider when tuning it for an application:

• Smoothing vs. Responsiveness: A higher smoothing factor (closer to 1, smaller filter window size) gives more weight to recent data, making the filter more responsive to changes but less effective at noise reduction. A lower smoothing factor (closer to 0, larger filter window size) provides better noise reduction but reacts more slowly to data changes.

• Application-Specific Tuning: The smoothing factor should be chosen based on the sampling rate, sensor sensitivity, and application requirements. Real-time systems often require a balance between quick responsiveness and stable output.

Here’s a code sample for EMA:

#include <stdio.h>
#include <stdint.h>

// Exponential Moving Average (EMA) filter implementation
#define FILTER_WINDOW 5

// Function to calculate EMA
float calculateEMA(float ema, float new_value, float alpha) {
    return (alpha * new_value) + (1 - alpha) * ema;
}

int main() {
    float sensorReadings[] = {26.0, 27.5, 28.2, 27.0, 26.8, 26.5, 27.2};
    int numReadings = sizeof(sensorReadings) / sizeof(sensorReadings[0]);

    float alpha = 2.0f / (FILTER_WINDOW + 1); // Standard EMA formula
    float ema = sensorReadings[0];  // Initialize EMA with the first reading

    printf("EMA Filtered Sensor Data:\n");

    for (int i = 0; i < numReadings; i++) {
        ema = calculateEMA(ema, sensorReadings[i], alpha);
        printf("Reading %d: Raw = %.2f, EMA = %.2f\n", i + 1, sensorReadings[i], ema);
    }

    return 0;
}

Conclusion

In summary, sensors are the backbone of modern smart devices, bridging the gap between the physical world and digital systems. From consumer electronics to industrial automation and medical devices, they enable devices to perceive and interact with their environments.

Understanding how sensors work, the components of their data pipeline, and their integration with microcontrollers is essential for engineers and hobbyists alike. By designing effective pipelines, developers can ensure accurate, clean, and reliable data, enabling systems to meet performance and power efficiency goals.

If you have questions or want to talk more about this topic, feel free to reach out on Twitter or LinkedIn. Always happy to connect.

By the end of the project, you will code your own LED light, have the knowledge to manipulate the LED to on/off in intervals you choose, and learn basic principles of hardware.

The Elegoo Uno starter kit has all the hardware as well as instructions you need to make a simple LED Light. The LED Light is the first project offered with their kit.

Elegoo Uno comes with many other projects and takes you through from beginner to advanced projects. Each project in the box advances your skills in a simple, easy to follow way.

Components You'll Need

Elegoo Uno R3

Elegoo Uno R3

The Elogoo Uno R3 is a microcontroller board. Microcontrollers are embedded inside devices to control the actions and features of a product. They are compact integrated circuits designed to control operations.

The microcontroller that is included in the Elogoo Uno R3 has 14 digital input/output pins, 6 analog inputs, a USB connection, a power jack, and a reset button. This board has everything you need to support the microcontroller. Simply plug in the USB Cable to turn the microcontroller on.

USB Cable

USB Cable

You need a USB Cable to connect the Elegoo Uno R3 to your computer and turn it on. USB stands for Universal Serial Bus. The USB is used to connect your computer to devices such as digital cameras, printers, scanners, and external hard drives.

In our project, we will use a USB cable to connect our microcontroller to our computer.

LEDs

LED Light

LED stands for light emitting diode. It has a positive and negative lead. The longer side is the positive lead.

How to assemble the components

In this project, we are only going to make the LED blink.

First, we need to plug in the USB Cable to the board and then the computer.

Then we need to plug in the LED to GND (GND is the reference point in an electrical circuit from which voltages are measured, and is a common return path for electric current) and the 13 input on the board.

Code to make the LED flash on/off:

After the microcontroller board is plugged into the computer and the LED is on the board itself, we need to write some simple code to make the LED blink.

// the setup function runs once when you press reset or power the board

void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on 
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off
  delay(1000);                       // wait for a second
}

The code above basically turns the LED on for 1 second and then turns it off for one second.

This function is in a continuous loop. The digitalWrite is a function that takes in 2 parameters, LED_BUILTIN and HIGH || LOW . The loop basically takes in the LED, and then turns the volt to HIGH which turns it on. Then after 1 second it turns the same LED off by turning the volt to LOW .

Here's the Final Product:

The goal of this little LED Light Coding project was to introduce you to elementary principles of how hardware and software can be combined. I hope you enjoyed it!

This post is originally from www.jaredwolff.com

There’s something that always goes wrong with a first revision circuit board design. No matter how long you spend imagining how a circuit will work, it will bork in the most unexpected ways.

In the case of my latest project, I overlooked a critical pice of circuitry. My revelation? Turns out you can’t reliably shunt 375mW of power into a 100mW resistor. ? Unfortunately, as you guessed it, this would require rework.

So, in my quest to make the right prototyping solution, I thought: “Why not share the things going through my head right now”

And thus, this blog post was born. ?

The (Solder-less) Breadboard

When you are time constrained the solder-less breadboard is a go-to. This type of electronic prototyping is painless but there are some drawbacks. Most notably, it does not play well with analog optimization. I’ll get into that a little later in this post.

I recently assembled an indoor air quality PM2.5 sensor and interfaced it with a Particle Argon. I assembled it using wire wrap. but it was a complete disaster. In comparison, the solder-less breadboard kept things organized and good looking to boot.

Electrical engineers come to love (or hate) bread boards early in their educational pursuits. For some it can be an outlet to get creative and make beautiful layouts. Many first year computer engineering students take pride in their breadboard designs. So much so that their breadboards looked as if assembled by a robot.

These days though, I don’t wire together huge digital logic circuits like in college. I do use solder-less breadboards though to make solid connections to development modules. As you can see int the above picture, I’ve used 3 separate boards which are all available across the web. Connecting them together took approximately 10 minutes as most. It took me approximately 15 minutes to assemble the wire wrap version.

The Breadboard ?

Sometimes a solder-less breadboard is great but it isn’t meant for every situation. What if you need something to be reliable? What if you’re working with high voltages? If you’re looking for more but don’t want to jump to making your own PCB, this is your next stop.

Creating a solderable breadboard is not too dissimilar to a solder-less version. It took me about 20 minutes to assemble the circuit in the picture below.

The breadboard above is the replacement zero-cross circuit mentioned earlier. Considering I was working with line voltage I was very cautious about the assembly.

So after triple checking my work. I plugged it in and you know what?

It worked like a charm.

Breadboards take some time to plan but when you get them right, they’re as good as a normal circuit board.

Furthermore, you don’t always have to solder every single connection together. I created this JTAG level shifter board about a year ago. That way I could run my circuit boards in ranges from 1.8V to 5V and have it work with the standard 3.3V programmer.

In this case, I used solder and wire wrap. connections. For future projects I plan on using the JTAG level shifter board I designed not too long ago. It’s 1/5 the size and as functional as the one above.

Going Beyond The Breadboard

I am definitely not afraid of assembling my own circuit boards. There’s a time and a place for that. There are still some things you can do before ever having to open up your schematic capture program.

Always consider the use of circuits and development platforms that already exist!

Being smart about your design process pays dividends to your future self. It helps you focus on the sticky problems rather than the trivial distraction. If you are in need of a pre-designed circuit board Sparkfun and Adafruit are great resources. They’ve already created the breakout boards for ICs that interest most makers.

To put the icing on the cake, in most cases, these circuit boards are diiiiirt cheap.

Companies like TI also make development boards. The board are reasonably priced and usually in stock on Digikey and their web store. Some of my favorite manufacturer development boards include the NRF52DK and the LT3092EDD. I use them both often and for some very good reasons.

The LT3092EDD is my go to for regulating current from a variable voltage source. No mater what the input voltage, it will shunt the current anywhere from 0-200mA. You can place several LT3092 in parallel increasing the current capability. I use it for static discharge tests and validation that have a need for constant current sinks.

As for the NRF52DK, not only can I develop on this board but I can use it as a programmer too. With tons of ways to expand off the board, it’s doesn’t leave my desk very often.

But what if there isn’t a development board?

Sometimes neither type of breadboard is great. This is especially true if you’re prototyping is dependent on the shape and form of the copper on your board. I’d expect if you did breadboard a switching power supply you may get some very unintended operation.

Laying out a power supply circuitry tends to be a bit more complex than say a digital signal. Yes, it will work with a tiny trace connecting two parts, will it work well? Unlikely.

Below is a design which allows for current transfer to the inner power layer. As you could imagine, a skinny trace and one via may work. In reality, they’d act more like a resistor high current situations.

Although you may get better connections, you run the risk of higher costs. Plus is much harder to change your circuitry down the road. Things get more complicated when the parts get smaller and the signals pushed inside. It’s not impossible though..

When changes are necessary, my most used tools are wire wrap wire or coil wire and my trusty X-acto knife. You can use the former to make the connections and the later to break connections. This does require a steady hand and patience but it’s possible.

In the picture above, I cut away thermal traces around pads and reconnected to another set of traces. You may have to take my word on this one considering it’s hard to tell from the picture! I did all the work under a microscope to avoid error.

You can du it ?

There’s a handful of ways to assemble a circuit. It’s all up to you how you want to get it done. I’ve seen some very cool circuit art out there that accomplishes the same thing as a bread board.

If you haven't already noticed, I ended up going with a breadboard design. It was faster to assemble and test versus ordering a whole new circuit board. I will likely spin another board in the future. In the meantime this little breadboard should do fine.

I use all these techniques when it comes to working with my clients. No technique is off the table and it always usually benefits everyone. In reality, a breadboard always evolves into a circuitboard of some kind. It’s good to know though that the circuit will work before turning it into a costly prototype.

So until next time, when you find yourself with the same quandry remember your options.

Have fun!

Jared

Self assembling circuit boards is the cheapest way to get components on circuit boards.

Period.

Don’t believe me? Believe these screenshots:

Self assembled: $143.84 + Tax & Shipping

Professionally assembled: $362.83 + Tax & Shipping

That’s about $50 per board versus $120 per board. That’s huge. Plus 18 days is a long time to wait for three circuit boards.

In this post, I’m going to to talk about the biggest tips and tricks I’ve learned over the years on how to assemble my own circuit boards. I have no doubt they’ll be immediately useful for your current and future projects.

So, to start with let’s talk about CAD.

Export Your CAD

The golden standard for the industry is the Gerber file. Gerber files are the translation of all the pretty shapes, traces, pads, silkscreen and drills into something useful for a board fabricator. There are other formats out there like ODB++. If you’ve ever looked inside an ODB++ file though, it’s just a bunch of Gerbers packaged up. ?‍♂️

If you’re interested in learning more about Gerbers and my process of checking them, go watch this video and then come back. No worries, I’ll be right here.

Fortunately, most vendors will take the raw CAD files especially if you use something like Eagle CAD. For instance, when I go to purchase a circuit board on OSH Park, I’ll upload my .brd file. In most cases, it gets promptly processed, and spits a price back.

These same files can also be used for the purchase of a solder paste stencil. Solder paste stencils allow you to applicate solder paste only to the openings in the solder mask on your circuit board. Yes, you can assemble a circuitboard without using solder paste or a solder stencil but I highly recommend it especially if you care about the aesthetics of your board.

A side note about aesthetics: I recommend for early prototypes to include reference designators that can be visible when the board is fully assembled. It makes hand placement of parts 1000 times easier. See what I’m talking about below:

See all the reference designators in white? They’ll come in handy very soon..

For stencils, my go-to is OSH Stencils. Their cost is reasonable and saves a ton of time when assembly is underway. Plus, as you may have guessed, circuit board assembly lines use large metal stencils to accomplish the same thing.

Finally, you want to export your bill of materials. I use the bom.ulp script that comes with Eagle. I always export by value so all the parts of the same attributes get binned together. This results in a clean and compact BOM that can be easily imported into something like Octopart. I often use Octopart to research prices. If it’s a particularly large bill of materials, I may split orders between say Mouser and Digikey. Sometimes even Arrow has parts for dollars less than the other two.

When ordering, all vendors allow you to import a .xlsx file or .csv. When importing, sometimes you get choice of putting in a customer part number (or similar). You can use this to store the reference designator. That will get printed out onto the label that they stick to the bag.

As long as your parts are not too heavy you can typically use the First Class mail option that Digikey offers. It looks like they have recently raised their shipping prices (used to be $3.5 now it’s ~$4.5 to Connecticut) Parts usually arrive within 2-3 business days. Which is not to bad! ??

Pro tip: Once you get the parts, double check your inventory. I’ve made the mistake of not ordering enough parts for multiple assemblies. If you do find yourself short, just make another order. If you don’t you could be unpleasantly surprised when build day comes and your short components.

Placing Parts On Your Board

Set up your assembly location. Use the plastic cutouts and place them around your circuit board. Then tape them down as a permanent frame to your desktop. You can make them yourself by using a service like Ponoko or just buy the ones that OSH Stencils offers.

Then, tape the stencil over the top aligning all the holes. This takes some time and finesse. Make sure you tape it down so it doesn’t move.

Place the stencil flat on the board. Then, take your solder syringe and glob some solder across the top of the stencil. Use an old credit card or the plastic card that comes with a stencil to spread the solder. Try to spread away from where the stencil is attached to your work surface. Otherwise if you move the stencil you’ll make a mess and have to start over.

Once the paste is down, like the picture above, place the board on a flat surface. There is nothing to hold the parts on the board so it’s best to place it on a larger unpopulated circuit board. That way you have a movable base and there is less risk of destroying your hard work. Plus it protects the surface underneath once you get to the next step.

Remember, use the reference designators on the circuit board and compare with the reference designator on the packaging of your parts. As long as you exported your BOM correctly there’s no reason to go back and check part numbers. See an example of packaging with the reference designator below:

Finally, bake your circuit board. I typically using my hot air gun at about 380°C and slowly go around the whole board soldering all the parts. My airflow is set to very low when I do this otherwise the parts go flying. This applies to any hot air gun setup.

This also can be accomplished by using a hot plate or old toaster oven. Remember, you do not want to use the same oven that you use to toast your toast!

Extra precaution: some salty engineers out there think there’s nothing wrong with breathing in fumes from soldering. I’m very much so in the opposite camp. Not only are you handling heavy metals (less of an issue with lead free solder) one way or another but the fumes from the solder flux are noxious. Best way to fix this is to run a fan out the window or use a fume extractor.

Time to Play

So you’ve ordered all your parts, stencils and boards. You’ve patiently and dutifully assembled and soldered all the components. Congrats, you’ve made it to the big times! Next stop is testing, firmware development or whatever else you need to do with your design.

Also, to be fair, I actually have nothing against companies like Macrofab. They provide a great service and I’ve actually used them before for other projects. Just remind yourself of the cost/time benefit of someone else doing the work for you. Is it worth it? Only you can decide.

Building your own circuit board on the cheep no only saves money but it’s rewarding when it’s all done. When building new devices and prototypes for my clients, I always keep this process as an option. It allows me to get a better idea of how a circuit may work before ever having to plunk down a ton of cash for a machine assembled board.

Looking for some help on your project? Got to the bottom of this page and send me a line.

You can also check out my other articles on my blog at www.jaredwolff.com.

This post is originally from www.jaredwolff.com

I got my hands on some of the mesh based Particle boards not too long ago. I’ve been itching to try them out but haven’t quite figured out the project.

One thing has been bothering me though: air quality. I spend a good amount of time in my office tinkering, soldering, coding and writing. I sneeze occasionally so I always wondered, how bad is it? The house is also prone to mold exposure during the hot months which had me concerned.

So why not cook something up?

What’s needed

The most important sensor is the Honeywell HPM series PM2.5/PM10 sensor. This tells you how many micrograms of material is floating around in a cubic volume of space. i.e. it counts the little particles flying around in your air.

Second to that, is the AMS CCS811. This sensor tells you the total amount of volatile organic compounds are in the air along with things like C02. It’s another datapoint which is interesting to see. I’ve previously placed this sensor in our basement only to be surprised and see huge spikes in VOC and C02 levels from our (oil burning) furnace turning on in the morning. Time for better ventilation!

Finally, the Silicon Labs Si7021 temperature and humidity sensor. These two bits of environmental data are useful. More importantly they’re used by the algorithm in the CCS811 to compute the TVOC and C02. Considering the cost of the CCS811, I’m surprised it doesn’t have these measurements on board but maybe in their next revision..

Wiring it all together

It’s time to wire everything together. At the very least you’ll need:

1. Solder-less breadboard hookup wire
2. A solder-less breadboard
3. A CCS811 breakout board from Adafruit (more details here)
4. A Si7021 breakout from Adafruit(more details here)
5. A Particle board of your choice.
6. A HPMA115 Particle sensor
7. Pre assembled Molex cable for the HPMA115 (Molex P/N 0151340803 or similar)
8. Some 0.1” pitch headers

I’ve included a Fritzing example with this project. There’s also a hookup image below:

Note: the original Fritzing diagram was incorrect. Both Vin of the CCS811 and Si7021 should be connected to the 3.3V on the Particle

An Adafruit Feather is used to represent the Particle Argon. Particle does not have Fritzing models quite yet.

As you can see everything is hooked up except for the PM2.5 sensor. The pinout is included below.

The most important pins are the 5V, GND, RX and TX pins. The other ones can stay disconnected if you choose. Here are the connections called out:

5V -> USB GND -> GND RX -> TX (on the Argon) TX -> RX (on the Argon).

Here’s a picture of everything assembled on a solder-less breadboard.

Another important note is that I modified the cable for the HPMA so they had male pins on the end. That made it easy to insert into the solder-less breadboard. Here’s a zoomed in shot:

When you purchase the cable for the PM2.5 sensor it came pre-populated with 8 wires. To make things simpler, you can remove 4 of the wires that are not used. The best way to do that is take a sharp tipped tool (dental pick, sewing needle, etc) and stick it under the clips I’ve pointed out in red below:

Then, once you have your sharp implement underneath, tug on the wire and it should slide out.

Now you have less wire and less headache. You can use this technique to modify any Molex-like connector.

Plumbing the firmware

For this project I decided to keep my code consistent with the Wiring/Arduino-like API. That means object oriented C++. It’s been a while where I’ve coded in C++ so when you’re looking at the codebase and wondering “why the hell did he do that!?” Sorry, not sorry. ?

The best way to get started is to use Visual Code with the Particle plugins for this project. Click here to get started if you're not already setup.

Si7021

The Si7021 is super simple. It only has 4 active pins out of the 6 on the chip.

(Copied directly from the Si7021 documentation)

The best say to read the temperature/humidity sensor is to issue a blocking read command. In an embedded world, this is not ideal. Unfortunately, there’s no way to know when the readings are ready because there is no interrupt pin.

As described in the data-sheet, you first write the command and then attempt to read directly from the device. The code looks something like this:

    // Si7021 Temperature
    Wire.beginTransmission(SI7021_ADDRESS);
    Wire.write(SI7021_TEMP_HOLD_CMD); // sends one byte
    Wire.endTransmission();           // stop transaction
    Wire.requestFrom(SI7021_ADDRESS, 2);

    // Get the raw temperature from the device
    uint16_t temp_code = (Wire.read() & 0x00ff) << 8 | (Wire.read() & 0x00ff);

Wire the address of the device, write the command and then subsequently read the number of bytes necessary (Two in this case) The Si7021 will then stretch the clock until the reading has completed.

I didn’t mess around with other settings. Depending on your environment you may have to tweak how much current to feed the heater. You’re mileage may vary so prepare accordingly!

Finally, these readings are read on a reoccurring timer. I originally was using the millis() call and calculating the different of the start and current time but this eventually breaks (in 50 or so days). Instead I decided to use a system timer (similar to if not the same as the APP_TIMER in the NRF SDK)

Timer timer(MEASUREMENT_DELAY_MS, timer_handler);

That way you get your interrupt always at MEASUREMENT_DELAY_MS no matter what! (In my case MEASUREMENT_DELAY_MS = 60000 ms == 60s)

The CCS811

The CCS811 gives you a bit more freedom to play but it comes with it’s own specialness.

In most cases the ADDR pin is set low. This pin modifies one bit of the address. This is useful if you have two of the same device or two devices with the same address on the same I2C bus.

The CCS811 also has a few handy input and output pins. The most important is the interrupt pin. Whenever a reading is complete, this open drain pin will be pulled low. It will only get reset once you read the status register. This is great for asynchronous reads that way you’re not locking up your MCU.

One important point is that the CCS811 does require you to issue a “start” command. This forces the internal MCU to start executing the TVOC/CO2 sensing algorithm. If you attempt to read the data registers before the application is started you will get bogus data. (The command is 0x90)

In the firmware, the CSS811 is processed in the same loop as the Si7021. The code pulls the available data from the CSS811 asynchronous readings. No blocking code!

The HPMA115

The particle sensor is a bit more tricky. When it is turned on, the device starts sending particulate data on a regular interval. i.e. it’s in auto-send mode every time it powers up.

I tried previously to configure the device but sometimes I wouldn’t get a response back. It was always hit and miss. It drove me crazy.

So, in order to turn the device off wen you’re not using it I highly suggest using a load switch of some kind. Not only will this save power but according to Honeywell, it will also increase the lifespan of the fan.

The flow of the readings:

• Every minute turn it on
• Wait for data to be sent
• Read the reading asynchronously via UART
• Turn it off
• Bundle that data into the JSON blob to be sent to the server

This way there’s no need to mess with any registers. All the more reason why I2C and even SPI are better data buses than UART. I just want it to work!

I originally chose this sensor a while back for it’s enclosed nature. In my option, it’s easier to integrate. My electrical engineer brain doesn’t want to deal with complex stuff. Give me a box and lets go.

Getting everything working

During the development phase of this project I happened to be traveling abroad. The crappy wifi was not cutting it and it was taking forever to iterate on the code. The Argon also had a hard time connected to my iPhone’s AP so I gave up on that idea early on.

So, in order to develop the code that didn’t require the internet I placed the device into manual mode. What does manual mode do? It allows the code to start execution despite not being connected to the Particle cloud. That way you can take readings all day but you don’t have to be connected to Wifi. You can put the device in manual mode by putting this define in your .ino file:

SYSTEM_MODE(MANUAL);

In battery powered applications, this is ideal. Wifi is expensive power-wise and you don’t need to be running it if you don’t have to!

In a previous experiment, I found that it took about 10-15 seconds from nothing to sending data to the Particle cloud. That’s a long time in the embedded world. That’s one of the main reasons I suspect Particle came out with their mesh system. This allows sleepy end nodes (or nodes that are taking data and periodically sending it to a central point) to run much longer than their Wifi based cousins.

Remember you will have to run the Particle.connect() function in order to connect to wifi in manual mode. Or if you’re ready for it to re-connect, remove SYSTEM_MODE(MANUAL); from your .ino file.

Changing Wifi Credentials

During my experiment in trying to get my wifi to work I did discover a few handy Particle tools to change wifi credentials etc. By holding the mode button during operation, the device eventually starts blinking blue. Once blinking blue, you can issue a particle serial wifi which will walk you through the process of changing the credentials.

The above process is light years faster than using the iPhone/Android app. I thought the app was cool at first but man does it take a long time to scan and get your devices connected.

More info on this procedure go here.

Recovering when things go awry

I had to recover my Argon during my development process. I did some digging and found that re-programming the OS, App and Bootloader seemed to do the trick.

Get the files here: Release 0.9.0 (Gen 3) · particle-iot/device-os · GitHub (As of this writing the latest is 0.9.0)

Then program these files in DFU mode by holding the mode button after tapping the reset button once.

particle flash --usb system-part1-0.9.0-argon.bin
particle flash --usb tinker-0.9.0-argon.bin

Program this one in Listening mode:

particle flash --serial bootloader-0.9.0-argon.bin

Note: the -argon suffix may be different depending on what you’re programming to. Other options are -boron and -xenon.

Monitoring on the command line

Finally, one of the most useful commands is this one:

particle serial monitor --follow

This allows you to use the USB Serial interface to receive debug messages from he device. This is akin to connecting an FTDI device to an Arduino.

For instance, I may be debugging part of the code so I want to see some data. In the Setup() function I’ll be sure to run Serial.begin(), then later on I’ll make a Serial.printf(“data: %d”,data.tvoc); in order for it to be sent over the USB Serial interface.

Serial UART for debugging, it’s a beautiful thing.

Publishing

One thing I did discover during the development process was the publishing limits of the Particle platform. For a single device, you cannot Particle.Publish more than 4 pieces of data in one second. Even though I was taking data every minute, I was sending 6 pieces of individual data to the server at the same time. After testing I soon started to wonder why the heck my C02 and TVOC readings disappeared.

I had found the culprit.

So, in order to make things work, I had to format it as a JSON blob. See how I did it exactly below:

String out = String::format("{\"temperature\":%.2f,\"humidity\":%.2f,\"pm25\":%d,\"pm10\":%d,\"tvoc\":%d,\"c02\":%d}",si7021_data.temperature,si7021_data.humidity,hpma115_data.pm25,hpma115_data.pm10,ccs811_data.tvoc,ccs811_data.c02);
Particle.publish("blob", out , PRIVATE, WITH_ACK);

I created a JSON structure and then used String::format to insert each piece where they needed to be. If you are running your device over LTE this will cause you to send more data than necessary. There are better options like Protocol Buffers or using MessagePack. If you’re dealing with complex data, I recommend the former because of its programatic nature. Plus, you can use it with just about any programming language. So web to embedded? No problem.

After every minute, I only send the data when all three sensors have been read. I use three separate boolean values to determine the state of the sensor readings. Once they have all been set to true do I invoke the Particle.Publishcall.

Then after publishing, I reset all variables like so:

ccs811_data_ready = false;
si7021_data_ready = false;
hpma115_data_ready = false;

Then, everything starts all over again. You can also create a status struct which has each of these flags neatly inside. Considering I only have three data points, I didn’t go the extra mile there.

Using Adafruit IO

One way to publish is by using Adafruits IO platform. Here's how to get started.

1. Create an account here: https://io.adafruit.com

2. Next is to create feeds for each of the data types. We’ll need 6 in total.

3. For each feed, add a Webhook.

4. Take each webhook address and create a new Webhook in the Particle console
5. Change the Request format to JSON
6. Then under Advanced Settings click on Custom for the JSON DATA

7. Replace what’s there using mustache templates. Adafruit IO is looking for a JSON key called value. So set it like this:

   {
    “value”:”{{{c02}}}”
   }
   

   You can replace c02 with any of the keys in your JSON blob. As a reminder the current JSON blob looks something like this:

   {
    “temperature”:21.2,
    “humidity”:30,
    “pm10”:2,
    “pm25”:1,
    “tvoc”:650,
    “c02”:1001
   }
   

8. Repeat this as necessary until all feeds have a corresponding Webhook configured.
9. Finally, you can create a dashboard to see them all in one place. This is straight forward just follow the on screen prompts. :)

You can check out my live dashboard here. It’s nifty and just another way to display your data.

Sidenote: My first impressions on Adafruit IO are good. It was easy to setup and start using. The main drawback that it’s tedious especially if you have more than a handful of data points. But maybe they’ll fix that in the future!

Update: If you have multiple pieces of data. You can point your Particle integration to a single endpoint. Just make sure the data is in the same group! Here's an example of multiple values sent to the same group:

{
  "feeds": [
    {
      "key": "tvoc",
      "value": "{{{tvoc}}}"
    },
    {
      "key": "c02",
      "value": "{{{c02}}}"
    },
    {
      "key": "temperature",
      "value": "{{{temperature}}}"
    },
    {
      "key": "humidity",
      "value": "{{{humidity}}}"
    },
    {
      "key": "pm2-dot-5",
      "value": "{{{pm25}}}"
    },
    {
      "key": "pm10",
      "value": "{{{pm10}}}"
    }
  ]
}

Where your URL should look something like:

https://io.adafruit.com/api/v2/<USERNAME>/groups/<GROUPNAME>/data

That should keep your Particle integration page a little more sane!

Making sense of the readings

The readings can be confusing. Here’s the breakdown of how they work:

1. Humidity is showing in relative percentage points. This is the relative humidity we know and love. Remember it may differ with what’s outside. This depends on if your house is air conditioned or if you’re running a heater etc.
2. Temperature is in degrees C (can be modified in firmware if you so choose)
3. TVOC is in ppb (parts per billion). VOCs can be in the form of harmful chemicals you have around the house. More information about VOCs check out thislink from the EPA.
4. C02 is in ppm (parts per million). We breathe in oxygen and exhale carbon dioxide. You may find your VOC and C02 levels rising when you’re in the room. C02 does correlate to VOCs as well. More info in the data sheet.
5. PM10. Is in µg/m3 (micrograms per meter cubed). The particle sensor uses a scattered laser when then shines across the air chamber to a sensor on the other side. The more the rays are blocked, the more particles in the air. The particle sensor then does some calculations to determine the amount of particles in a certain volume and thus your µg/m3.
6. PM2.5 is the same as above but it tracks much smaller particles. (Less than or equal to 2.5µm in size!) More information on the EPA’s website here.

Don't care for something you have no control over?

Check out my tutorial on creating your own amazing looking IoT dashboard.

You did it!

Congrats. You've made it this far. You deserve a day at the spa. Or maybe some chocolate ice cream. Or if you're really feeling adventurous, both, at the same time?? ?

After building one of these you may feel like your time is worth investing elsewhere. Maybe you want to build a cool web backend with fancier charts and algorithms. Maybe even use some machine learning (why not!)

If you want something already assembled and available you should check out the Particle^2 (Pronounced Particle Squared). It has everything here including the ability to switch on and off the HPM particle sensor. You can even run it on batteries! So put that sucker anywhere you want. Check it out here.

Here's the full video on the Particle Squared.

Code and Source

This whole project is released under the Creative Commons Share-Alike license. Get the source code and hardware files here.

Get Ready for the Ultimate Guide

This post is an excerpt from my upcoming Ultimate Guide on Particle Mesh. Early subscribers get a discount when it becomes available! Click here to get signed up.

With a Raspberry Pi, low-cost gas sensors, and a remote-controlled switch, you can control the air quality in your house.

The air we breathe indoors is not always healthier than the air outside.

According to a study of the E.U. Joint Research Centre, you can find a wide range of air pollutants indoors. Some of them are toxic, or can cause genetic mutations or cancer. Factors that influence indoor air quality are:

• ambient air, or the air outdoors
• air tightness and ventilation of the building
• indoor sources like tobacco smoke, heating gases, consumer products, etc.

Do you know how much time you spend indoors? According to the Environmental Protection Agency, Americans spend 87% of their time indoors. In Europe, this average percentage is 90%, according to the JRC. And the more time we spent indoors, the more pollutants we inhale.

So it would be interesting if we track the indoor air quality. In this article, I will explain how I did this with a Raspberry Pi, a GrovePi and some sensors. We will upload the sensor data to a Firebase database and visualize trends with Dash.

When pollutant levels reach an unhealthy level, we can send an alert notification to warn us.

Moreover, it would be great if we could automatically start up the ventilation to purify the air. This can be done with a remote-controlled switch from Energenie.

Raspberry Pi and GrovePi

Raspberry Pi model 2B

In this project, I will use a Raspberry Pi model 2B. The Raspberry Pi is a low-cost small computer. It enables programmers and makers to build anything they can imagine.

GrovePi (blue board) attached to a Raspberry Pi

The GrovePi is an electronics board that we attach to the Raspberry Pi. It makes connecting a wide range of sensors easy. As such, you don’t need to bother about a breadboard, resistors, soldering or jumper wires. You can plug in a connector and start working with it.

Data flow

In the illustration below you see how the sensor data will flow from the sensors to the charts on a web page. We’ll be using Python to do all that.

Data flow from a GrovePi and a Raspberry Pi to Firebase to a web page hosted on PythonAnywhere.

The first step is to pull in the data from the Grove sensors. Then we process the data on the Raspberry Pi and send them to a Firebase database. This data is also used to switch on or off a ventilation unit via a remote controlled switch.

We can get the stored data with a script running on PythonAnywhere.com. With the Dash package, we can build a dashboard to follow up the indoor air quality.

Gas sensors

We will use a set of three different gas sensors for this project. I use Grove gas sensors and connect them to the GrovePi.

It is not necessary to use all three sensors in your own project. Feel free to choose sensors that fit your needs. You can do that in the config.py file by keeping the sensors you need in the Python dictionary MQ_SENSORS.

Grove gas sensors

Each sensor detects a specific set of gases. There is quite some overlap between the sensors with regard to the gases they detect. But, the range in which the sensors detect a gas can differ. You can find the ranges on the website of Seeedstudio.

Gases detected per sensor type

Temperature and Humidity sensor

Temperature and humidity influence the readings from the gas sensors. So, it is interesting to measure temperature and humidity as well. We use the Grove BME680 sensor for that.

Grove BME680 to measure temperature and humidity

Working with sensor data

In short, a gas sensor will output a higher voltage when the concentration of a gas is higher. This is because the built-in resistor varies its resistance (Rs) according to the concentration of the gas.

The sensor value only reflects an approximation of a trend in the gas concentration. This means that you can use it to show whether the gas concentration increases or decreases. It does not give the exact gas concentration. If you want to measure the actual concentration, you would need a more expensive sensor.

For learning purposes, we will use the sensor value to approximate the gas concentration. You should keep that in mind. You should not use these scripts in real-life situations to prevent intoxication by these gases!

On the datasheets listed below, you find a graph with the relation between the gas concentration and sensor resistor values. The gas concentration is expressed in parts per million (ppm). The resistor values as the ratio Rs/R0.

• MQ2 datasheet
• MQ5 datasheet
• MQ9 datasheet

The curves below correspond to the standard conditions of:

• a temperature of 20°C
• a humidity of 65%
• an oxygen concentration of 21%
• a load resistance of 5 kilo-Ohm. The load resistance is the total resistance of an electronic circuit.

Curves displaying the relation between gas concentrations and sensor resistance values. Both the x-axis and y-axis are on a log scale.

We can assume that the load resistance and oxygen concentration are stable over time. Yet, the temperature and humidity indoors can vary. Both factors have an influence on the sensor readings, as you can see in the graph below.

Influence of different temperatures and humidities (RH) on sensor resistance values in the MQ2 sensor for a hydrogen (H2) concentration of 1.000 ppm.

To get accurate readings, you should have a graph or look-up table for various temperature-humidity combinations. Unfortunately, these graphs are not provided by the manufacturer.

Another approach is to correct the sensor readings for the temperature-humidity influence.

We can do this with artificial neural networks, as proposed in the paper by Nenova & Dimchev. That approach requires ground-truth measurements of the gas concentrations. This is out of scope for this article.

Defining the R0 value

First, we need to compute the R0 value. R0 stands for the sensor resistance value of 1.000 ppm of hydrogen (H2)in clean air. The ratio for clean air (black line with blue crosses) is constant. It remains at 9.8 regardless of the concentration of clean air. So, we can compute R0 by reading the sensor value (Rs) in clean air and dividing it by 9.8.

The value we get from the sensor is a value between 0 and 1.023 and has no measurement unit. So, to get the output voltage we divide the sensor value by 1.023. We multiply this value with the circuit voltage, which is usually 5V.

From the sensor voltage, we can derive the sensor resistance by applying Ohm’s law. The sensor resistance is equal to

Vc is the circuit voltage and Vs is the sensor voltage

Let’s see how we do that with Python. The complete code and more documentation can be found on Github in the script get_R0_values.py.

import config as cfg
import grovepi
import time

First, we import some packages. The config package is a Python script I made to store all configuration parameters.

Throughout the code, you’ll notice that I sometimes refer to cfg.PARAMETER_NAME. We set thePARAMETER_NAME value in that config.py file. It also contains some passwords and API tokens.

For security reasons, I will not save that file on Github. Instead, I’ll provide a clean template config_template.py that you can use for your own project.

Next, we import the grovepi package. You can install it from the Github page of Dexter Industries on your Raspberry Pi. It allows us to work with the GrovePi and the connected sensors.

Finally, we use the time package to pause the program during sensor readings.

mq_values = {}

for sensor, data in cfg.MQ_SENSORS.items():
    grovepi.pinMode(data['pin'],"INPUT")
    mq_values[sensor] = 0

We will store the sensor values for the different sensors in the dictionary mq_values. But first, we initialize the values to zero in a loop over the sensors defined in MQ_SENSORS.

With the pinMode method, you can define the pin as INPUT or OUTPUT. In our case, we’ll use it as INPUT.

The pin tells us to which pin on the GrovePi the sensor is connected. We use the analog pins (or ports) which are labeled as A0, A1 and A2 on the GrovePi. Make sure you connect the right sensor to the port described in the config.py file.

for i in range(cfg.NB_R0_READ):
    for sensor, value in mq_values.items():
        mq_values[sensor] += grovepi.analogRead(cfg.MQ_SENSORS[sensor]['pin'])
    time.sleep(cfg.R0_INTERVAL)

We then read the sensor value in a loop for cfg.NB_R0_READ times and sum it up in mq_value[sensor]. We read the sensor value with the analogRead method of the grovepi package.

As described in the documentation, this will return a value between 0 and 1.023. In fact, it converts an analog sensor value to a digital value.

After one reading for all sensors, we pause the program at cfg.R0_INTERVAL seconds. To get the average value, we divide the cumulated value by cfg.NB_RO_READ.

for sensor, value in mq_values.items():
    mq_values[sensor] = mq_values[sensor]/cfg.NB_R0_READ
    mq_values[sensor] = mq_values[sensor]/cfg.AR_MAX * cfg.VC
    mq_values[sensor] = (cfg.VC - mq_values[sensor])/mq_values[sensor]
    mq_values[sensor] = mq_values[sensor]/cfg.MQ_SENSORS[sensor]['r0_rs_air']

We compute the sensor voltage by dividing the averaged sensor value by cfg.AR_MAX. Then we multiply it by the circuit voltage cfg.VC.

From that voltage, we can apply Ohm’s law and compute the sensor resistance value. Dividing that by the ratio for clean air cfg.MQ_SENSORS[sensor]['r0_rs_air'] gives us R0.

It is better to have the sensor working at least for 24 hours before you measure the R0 value. This will give more stable sensor readings.

Linear interpolation of gas concentration

Now that we know the R0 value, we can compute the Rs/R0 ratio with the sensor value. With that ratio, we can derive the gas concentration with linear interpolation.

For that, we assume that we are working in the standard conditions described for the first graph. In that case, the curves are nearly linear.

For linear interpolation, we need two known points of each curve to calculate its slope. Suppose we have two points with the coordinates (x1, y1) and (x2, y2). The y-values stand for the Rs/R0 values and the x-values for the gas concentrations. For a linear curve, the slope is then calculated as:

When we know the slope, we can find the gas concentration(x) for any given Rs/R0 value (y). The formula for this is:

The code snippets below come from the script get_sensor_values.py which you can find on Github.

We put the formula in a function get_ppm. curve['y'] and curve['x'] are the known points on the curve for a gas. curve['slope'] is what we calculated with the previous formula.

You can find these values in the config_template.py file. I derived these values with Webplotdigitizer from the graphs on the data sheets. As a result, these values are not completely accurate. Use them with caution.

Note the use of np.log10 and np.power. This reason for this is that the axes on the graph are in a log-scale.

def get_ppm(Rs_R0_ratio, curve):
    x_val = (np.log10(Rs_R0_ratio) - curve['y'])/curve['slope'] + curve['x']
    ppm_val = np.power(x_val, 10)
    return ppm_val

We calculate the Rs_R0_ratio in the same manner as when calculating the R0 value. So I will not repeat this. To calculate this ratio, we loop over all gases and sensors and store this in ppm_values[mq_sensor][gas].

for gas, curve in cfg.CURVES[mq_sensor].items():
                ppm_values[mq_sensor][gas] = get_ppm(mq_values[mq_sensor], curve)

Temperature, humidity and pressure

Besides the gas sensors, we read the temperature, humidity and pressure with the BME680 sensor. The BME680 sensor is connected to the GrovePi via an I2C port. To use the sensor, we import the package which can be installed from the Pimoroni repo on Github.

import bme680

The set_..._oversample methods specify how many samples we take to calculate the average value. We also did that for the gases. With get_sensor_data we read the sensor values.

bme680_sensor = bme680.BME680(bme680.I2C_ADDR_PRIMARY)
bme680_sensor.set_humidity_oversample(bme680.OS_2X)
bme680_sensor.set_pressure_oversample(bme680.OS_4X)
bme680_sensor.set_temperature_oversample(bme680.OS_8X)
bme680_sensor.get_sensor_data()

bme680_sensor.get_sensor_data()

Storing and retrieving sensor data in Cloud Firestore

Some sensors provide new readings very fast. Other (less expensive) sensors will take more time. For this project, we will read the data every minute. This is set in the config file with FIREBASE_INTERVAL = 60.

In the free Spark plan of Firebase, the Cloud Firestore quota allow for 20K writes per day. With a one-minute interval, we will be well below that quota. The limit for reading documents in the Firestore is 50K per day.

You’ll need to create a Firebase project and create a Cloud Firestore. After that, make sure to generate the credentials to authenticate your application. Save the credentials file in a secure location.

To work with Firebase via Python, we need to import the firebase_admin package. This package needs to be installed on your Raspberry Pi first, if needed.

import firebase_admin
from firebase_admin import credentials
from firebase_admin import firestore

After that, we can initialize the Firebase app with credentials. I store the location to the credentials file in cfg.FIREBASE_CREDS_JSON. When the app is initialized, we create a Firestore object db.

firebase_path = Path.cwd() / cfg.FIREBASE_CREDS_JSON
cred = credentials.Certificate(str(firebase_path))
firebase_admin.initialize_app(cred)

After processing the gas values, it is time to store them in the Cloud Firestore. We will create a dictionary firebase_values to gather all the data. With a dict comprehension, we add the values for all gases for all MQ sensors. The BME680 values and timestamp are also added.

With the add method of the Firestore object db, it is easy to store the data in the Firestore.

The name of the collection in the Firestore is cfg.FIREBASE_DB_NAME. Learn more about the data model of Firestore on the Firebase website.

firebase_values = {mq_sensor + '_' + gas + '_ppm': ppm
                            for mq_sensor, gases in ppm_values.items()
                            for gas, ppm in gases.items()
                          }
firebase_values['temperature'] = bme680_sensor.data.temperature
firebase_values['pressure'] = bme680_sensor.data.pressure
firebase_values['humidity'] = bme680_sensor.data.humidity
firebase_values['date'] = datetime.now()
db.collection(cfg.FIREBASE_DB_NAME).add(firebase_values)

After storing the data, we wait a minute to start over with the following line of code.

time.sleep(cfg.FIREBASE_INTERVAL)

Improving the air quality

If the air quality indoors is not good we should take measures to improve it. Before we can do that, we need to be notified about critical gas concentrations.

One possibility is to send an alert notification by email, which we’ll discuss below.

Sometimes the source of indoor air pollution comes from outdoor air. For example, when your neighbors have wood-burning stoves or when you live near a factory.

In that case, you could install your measurement station outside and turn off the ventilation unit in your house if outdoor air quality is bad. With a remote-controlled switch, this can be done easily.

All code for this section is in improve_air_quality.py on Github.

Sending notifications when air quality reaches a critical level

We do not want to send an email each time the sensor outputs critical values (here, each minute).

Let’s say we want to check each hour whether there were critical values in the last hour. For that, we need to keep track of a reference_time. We initialize this when the program for readings sensor values starts. The interval at which we check again for critical gas concentrations is defined in cfg.ALERT_INTERVAL.

reference_time = datetime.now()

When an hour has passed since reference_time, we can start to check if there were critical air pollutant values. We update reference_time with the current time.

With the pytz package, we can take into account our timezone. In my case, that is Europe/Brussels. We compute one_hour_ago by subtracting 60 minutes from the current time.

if datetime.now() > reference_time + timedelta(minutes=cfg.ALERT_INTERVAL):
    reference_time = datetime.now()
    brussels_tz = pytz.timezone('Europe/Brussels')
    prev_check_time = brussels_tz.localize(datetime.now()) - timedelta(minutes=cfg.ALERT_INTERVAL)

With prev_check_time we extract the sensor readings from Firebase of the last hour. We do that by applying a where clause to the data that we get from the Cloud Firestore.

In this script, we will only use one gas sensor and a limited set of gases. The sensor is selected in cfg.ALERT_SENSOR. The gases are selected in cfg.ALERT_GASES. The data per gas is appended to ppm_vals as well as the timestamps.

timestamps = []
ppm_vals = {}
for gas in cfg.ALERT_GASES:
    ppm_vals[gas] = []

docs = db.collection(cfg.FIREBASE_DB_NAME).order_by(u'date').where(u'date', '>=', one_hour_ago).get()

for doc in docs:
    data = doc.to_dict()
    for gas in cfg.ALERT_GASES:
        ppm_vals[gas].append(data[cfg.ALERT_SENSOR + gas + '_ppm'])

    timestamps.append(data['date'].strftime('%H:%M:%S'))

We look for critical values with the function find_crit_val. We will only check if the value surpassed an upper bound ubound. These upper bounds need to be specified in the config file.

The data are in ascending chronological order. Thus, we can use the next method to find the first timestamp for which v > ubound. We return a tuple containing the timestamp of the critical value and the critical value itself.

If there is no critical value, we return the tuple (None, None).

def find_crit_val(timestamps, val_list, ubound):
    try:
        (crit_time, crit_value) = next(((i,v) for i, v in zip(timestamps, val_list) if v > ubound))          
    except:
        (crit_time, crit_value) = (None,None)
    return (crit_time, crit_value)

The critical tuples are stored in a dictionary crit_dict. As the key, we use the gas name. We then check for gas-sensor combinations with a critical timestamp and critical value. In that case, we add an alert message to critical_msg.

crit_dict = {}
for gas in cfg.ALERT_GASES:
    (crit_time, crit_value) = find_crit_val(timestamps, ppm_vals[gas], cfg.UPPERBOUNDS[gas])
    crit_dict[gas] = (crit_time, crit_value)
critical_msg = ''
    for k, v in crit_dict.items():
        if v[0] is not None and v[1] is not None:
            critical_msg += '\nCritical value for ' + k + ' of ' + str(v[1]) + cfg.UNITS[k] + ' at ' + str(v[0])

If critical_msg is not empty, we send an email. Sending an email is done with the smtplib package. How to send an email with Python is explained on AutomateThe BoringStuff.com.

You need to generate an application-specific password for your email if you are using Google’s two-factor authentication.

if critical_msg != '':
    try:
        msg = MIMEText(critical_msg, _charset='utf-8')
        msg['Subject'] = Header('Air Quality Alert', 'utf-8')
        smtpObj = smtplib.SMTP('smtp.gmail.com', 587)
        smtpObj.ehlo()
        smtpObj.starttls()
        smtpObj.login(cfg.EMAIL, cfg.EMAIL_PW)
        smtpObj.sendmail(cfg.EMAIL, cfg.EMAIL, msg.as_string())
        smtpObj.quit()  
    except smtplib.SMTPException:
        print('Something went wrong while sending the email')

Automatically control your ventilation unit

With a remote-controlled switch, we can turn on or off any device that is connected to it. Thus, also a ventilation unit. Energenie creates the PiMote add-on specifically for the Raspberry Pi. To control the Energenie switch, you need to install the energenie package and import it.

Note that you can not attach the PiMote on top of the GrovePi. So you’ll need a second Raspberry Pi.

When starting the script, the first thing we do is define a boolean variable ventilation_on. We set it to False because this is the first time we run the script.

import energenie
ventilation_on = False

If critical_msg is not empty, there was a critical gas concentration in the last alert interval. In that case, we turn on the ventilation with the switch_on method of the energenie package.

If there was no critical gas concentration and the ventilation was switched on in the last alert interval, we can switch it off.

You might need to set another interval before switching your ventilation off. That depends on the flow rate of your ventilation unit, the gases measured and whether the pollution source has been disabled.

if critical_msg != '':
    if not ventilation_on:
        energenie.switch_on(1)
        ventilation_on = True
else:
    if ventilation_on:
        energenie.switch_off(1)
        ventilation_on = False

Visualization of air quality with Dash

A notification with critical gas concentrations can help to take immediate action. But it is also interesting to track the gas concentrations over time. By visualizing the sensor values in a dashboard, we can look at the trend of the gas concentrations. This can be done with Dash. On the website of Dash, you can find a great tutorial on how to get started.

In this project, we will build a dashboard and host it on PythonAnyWhere.com. To use Dash on PythonAnywhere, you need to create a virtual environment. You can follow the steps of this demo on how to set-up a Dash app on PythonAnyWhere.

Below I will show how I built the dashboard for our air quality station. The full script can be found in plot_sensor_values.py on Github.

First of all, you need to import the dash package.

import dash
import dash_core_components as dcc
import dash_html_components as html

In the demo on the Dash website, they use a link to a Cascading Style Sheet (CSS) to provide a nice page design. If you want to use a local CSS on your laptop or web server, you can add an assets folder. In that folder you can add your CSS and Dash will pick it up from there.

Then you’ll need to get the data from Firebase. This can be done similarly as we did for sending the alert notifications. So we will not go over that again.

With the data collected from Firebase, we can fill the graphs in our dashboard. We first create a Dash object app and give it a title.

app = dash.Dash(__name__)
app.title = 'Indoor Air Quality Dashboard'

Then we create the layout of the dashboard. A H1 heading component, a container div and a div containing the graphs.

app.layout = html.Div([
    html.H1(style={'textAlign':'center'}, children='Indoor Air Quality Dashboard'),
    html.Div(id='container'),
    html.Div(graphs)
])

graphs is a list that contains the info per graph. Below you can see how the graph for temperature is set up. You can add the dcc.Graph for humidity and pressure as well by appending them to graphs.

graphs = [
    dcc.Graph(
        id='temperature',
        figure={
            'data':[{
                'x':timestamps,
                'y':temperatures,
                'type':'line',
                'name': 'Temperature',
                'line': {'width':2, 'color': '#542788'}
                }],
            'layout':{
                'title': 'Temperature',
                'yaxis': {'title': 'Celsius'},
                'xaxis': {'title': 'Timestamp', 'tickvals':timestamps}
            }
        }
    )
]

The graphs for the MQ sensors can be appended in a for loop.

for mq_sensor in cfg.MQ_SENSORS.keys():
    for gas in cfg.CURVES[mq_sensor].keys():
        sensor_gas_key = mq_sensor + '_' + gas + '_ppm'
        title = gas + ' concentration on '+ mq_sensor + ' sensor'
        data = ppm_values[mq_sensor][gas]
        data.reverse()

        graphs.append(dcc.Graph(
            id=sensor_gas_key,
            figure={
                'data': [{
                    'x': timestamps,
                    'y': data,
                    'type':'line',
                    'name': title,
                    'line': {'width':2}
                }],
                'layout': {
                    'title': title,
                    'yaxis': {'title': 'ppm'},
                    'xaxis': {'title': 'Timestamp', 'tickvals':timestamps}
                }
            }
        ))

As a result, you will have a dashboard with graphs like the one below.

Graph with MQ2 sensor data for methane (ch4)

Conclusion

With a few low-cost gas sensors and a Raspberry Pi (and GrovePi) it is easy to build an air quality measurement station. You can then act on the data by sending alert notifications when air quality is bad or switch on the ventilation. With Dash you can build beautiful visualizations to monitor the air quality over time.

Below I noted some ideas to take this project further.

• make a mobile app for the visualizations and receiving notifications
• add LEDs, a buzzer and an OLED display to the Raspberry Pi to get instant feedback on air quality
• install measurement stations at your family and friends' place and visualize it on an interactive map.
• once you have enough data, build a time-series model to predict the indoor air quality

Hopefully, this story motivates you to start building your own measurement station. If you have questions or suggestions let me know.

I am a big fan of science toys. I have been looking for one that combines the elegance of math and programming for a while. However, there was not much success in the search. So, I decided to make one myself.

Here is a demo. The flashing LEDs are used to illustrate a mathematical identity visually.

Math

The mathematical identity is the following. The left side of the equation is an arithmetic sum from 1 to n-1 and the right side of the equation is “n choose 2”, the number of unique ways to choose 2 items from n items.

Mathematical identity

It is not the identity itself that is elegant, but the visual proof itself. Let’s look at the diagram below. There are n=4 green dots in the illustration.

LED illustration

For every two green dots on the bottom row, there is always a unique red dot in the triangle above that corresponds to them. That red dot is the tip of an equilateral triangle with the base specified by the green dots.

Therefore, the number of ways to choose 2 green dots out of n green dots is equal to the sum of the red dots, 1 +2 + 3 + … + (n-1).

In this case, it is 1 + 2 + (4 –1) = 6.

This observation was originally made by Loren C. Larson in this article.

Programming

While it is easy to trace the red dot from the green dots visually, it is more fun and challenging to specify the relationship in code.

Let us assume that we know the indices of the green dots (say, i and j). The programming challenge is to specify the corresponding index of the red dot that forms the equilateral triangle with the green dots.

It looks difficult at first glance.

But the problem can be simplified a lot when we tweak the way that we label the red dots. We can label the red dots from bottom-up instead of top-down.

With that indexing scheme, we can then specify the index of the red dots by the following formula.

An illustration of how to index the red dots using the indices of the green dots.

Here is the complete code used to flash the LEDs using Arduino.

Electronics

I solder the LEDs on a board and connect the LEDs to Arduino output pins through 1k resistors. It is very important to use the resistors because they protect the LEDs.

The connection is as follows.

Schematics

And when you put them together and load the software to Arduino, it will start flashing like below.

Final result

Hope you enjoy this gadget!

Last year, I created Crypto Price Tracker (an app which was acquired by Redwood City Ventures this year). A back end member of my team had been using an Arduino setup to check web server response statuses continuously to get updates all the time. I found that setup to be pretty useful and interesting.

I researched about it and recreated the setup for myself. In this article, I’ll show you how you can build it yourself, too.

Things that you need:

1. Arduino Uno
2. Ethernet Shield for Arduino (to connect the Arduino to the Internet)
3. Ethernet Cable
4. A/B Type USB 2.0 Cable (Power cable for Arduino)
5. Male-to-Male Jumper Cables (x2)
6. Breadboard
7. LED (x1, any color)
8. Resistor (x1, >100 ohms works)

Setting It Up

1. Mount/Insert the Ethernet shield on the Arduino.
2. Insert the positive (longer) end of the LED into the breadboard slot 6a and the negative (shorter) end into slot 5a.
3. Insert one end of the resistor into the breadboard slot 1b and the other into slot 5b.
4. Insert one end of the first jumper cable into the breadboard slot 1e. Insert the other end into the GND slot of the Ethernet shield.
5. Insert one end of the second jumper cable into the breadboard slot 6e. Insert the other end into pin slot 2 of the Ethernet shield.
6. Connect the Ethernet cable from your router to your Ethernet shield.

This is what my setup looks like:

7. Open a command line interface on your machine and check and note your default gateway. This can be done using ipconfig command on Windows or the netstat -nr | grep default command on Linux/Mac.

8. Download and install the Arduino IDE if you haven’t already.

9. Open the IDE and go to Files -&gt; Examples -> Ethernet -> WebClientRepeating. You should see the following code:

10. Edit the line 37 to be an IP address in the range (1–254) of your default gateway IP. So for example, if my default gateway is 10.0.0.1, then I can use an IP address from 10.0.0.2 to 10.0.0.254. It is, however, important to make sure that the IP that you’re using doesn’t conflict with any other IP addresses on your network.

For this example, I changed the line of code to be:

**IPAddress ip(10, 0, 0, 2);**

11. Change the DNS in line 40 to be 8.8.8.8 (this is the Google Public DNS and is just something I prefer, you may use a DNS that you prefer).

For this example, I changed the line of code to be:

**IPAddress myDns(8, 8, 8, 8);**

12. Change the URL in line 45 to a URL matching your web server. If you would like to use an IP address instead, then comment line 45 and uncomment line 46. Since I am using a web server that I’m hosting locally, for this example, I will use an IP address.

For this example, I changed the line of code to be:

//char server[] = “[www.arduino.cc](http://www.arduino.cc)";
IPAddress server(127,0,0,1);

Note that the port or the path here is not important yet. Just the IP Address
is needed. If you would like to change the port that is used for the GET
request, you may change it on line 94.

For this example, I have hosted my local webserver on port 3000. Thus, I will change the code in line 94 to something like this:

if (client.connect(server, 3000)) {

13. Edit the GET request that is pre-written in lines 97 - 100 to follow this pattern:

client.println(“GET /path_to_url HTTP/1.1”);
client.println(“Host: 127.0.0.1”);
client.println(“Connection: close”);
client.println();

14. We can now start programming the behaviour of the LED depending on the web server status and response. To do this, we must first declare the pin we’re using for the LED on our Ethernet shield.

Add the following line of code after the first two include statements of the program:

int LED = 2;

15. Add the following lines of code at the beginning of the setup() function.

pinMode(LED, OUTPUT);

digitalWrite(LED, LOW); //program starts with the LED turned off

16. Add the following line of code after the GET request line that we previously edited:

digitalWrite(LED, LOW);

17. Finally, add this line of code at the beginning of the else statement of the same conditional:

digitalWrite(LED, HIGH);

And voilà, you’re done!

Upload the program to your Arduino. Open the serial monitor from the top right part of the IDE and watch the response. If your server doesn’t respond, the LED glows, if it does, the LED stays off :)

You can check out my final code here.

Checking Response

If you would also like to validate the response that you receive from your
web server, then you may add them inside the following conditional of the
program.

if (client.available()) {
char c = client.read();
Serial.write(c);
}

The variable c is where the response is stored.
You could check it like this:

if (client.available()) {

char c = client.read();
if(c == “arduino is great”){
digitalWrite(LED, LOW); //correct response
}
else{
digitalWrite(LED, HIGH); //wrong response
}
Serial.write(c);
}

Do note that, if you’re trying to do this, then it’s best to get rid of the
digitalWrite statement after the GET request. Depending on your response,
you may also have to parse JSON values. There are several ways to do this
and plenty of tutorials/articles around for it too! Make sure to check them
out!

Have fun! Feel free to email me at harshita (at) harshitaapps.com for any questions, feedback, or ideas!

Make sure to check out Crypto Price Tracker app if you’re interested/invested in cryptocurrencies! :)

Last Sunday, while I was explaining the basics of electronics and Arduino to my roommate, she challenged me to understand how a voltmeter works and build one from scratch just using the stuff I own already. I accepted the challenge, started hacking, coding, testing, re-coding, and re-testing, and finally I had my voltmeter ready and working by dinner time!

I used Arduino Uno (to collect voltage in analog and to power the LCD), a small LCD screen that I got in my Arduino starter kit (to display the voltage), a breadboard (to connect everything), and jumper wires.

If you’re looking for an easy project to learn electronics, then making a digital voltmeter will be fun. Let’s get started!

The Electric Circuit

Step 1

Take a breadboard (I used a small one with 30 rows) and connect an LCD screen to it. Then using a wire, connect one wire from the GND pin (ground state) on the Arduino to the negative charge on breadboard, and one wire from the 5V pin to the positive charge. This provides electric current to the columns on the breadboard, which we can now connect to the LCD.

This is the basic setup after Step 1.

Step 2

Now we’ll connect the pins on the LCD to the breadboard so we can get current to it. Connect Pin 1 of the LCD to a negative charge, Pin 2 to a positive charge, Pin 3 to a negative charge, Pin 5 to a negative charge, Pin 15 to a positive charge, and Pin 16 to a negative charge. Plug in your Arduino to test and see if the LCD turns on!

The LCD lights up!

Step 3

Let’s connect the LCD to the Arduino so that we can display the voltage (which we will collect from an analog pin) on the LCD. Connect Pins 4, 6, 11, 12, 13, and 14 of the LCD to any digital pin on Arduino (for example, Pin 2). Then put a wire in the GND and another in an analog pin, like A5. The two wires are now your probe leads.

Finished electric circuit!

We’re now done with the electronics/hardware. Let’s move on to the code.

The Code

The code is pretty simple. We just want to collect the analog signal that the Arduino receives at Pin A5 (or any other analog pin) and convert it to digital. We then want to display the results on the LCD screen.

This is the code that you can copy-paste.

#include <LiquidCrystal.h> int Vpin=A5;float voltage;float volts;LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

void setup() {Serial.begin(9600);lcd.begin(16,2);}

void loop() {

voltage = analogRead(Vpin); volts = voltage/1023*5.0; Serial.println(volts);lcd.print(“voltage = “);lcd.print(volts);delay(200);lcd.clear();}

What’s going on here?

So we’re first importing the LCD library, then creating a variable named Vpin (which will be the voltage collected from A5). Next, we create two more variables for the voltage, and then a variable of type LiquidCrystal. Finally, we do setup with the Serial monitor (which is a really useful tool in Arduino! Sort of like debug console), convert the analog voltage to digital voltage, and print (display) that value to the LCD screen.

And that’s it! Go and test out various batteries and points! Here are photos from some tests I did:

Neutral wires.

Testing a 1.5V AA battery.

Also, if you want to make the reading on the LCD more legible, put a 1k ohm resistor in the path to Pin 3 (which is for contrast adjustments). By limiting the electric current flowing to that pin, you’ll improve the contrast of the screen.

Also important note: In this voltmeter, whatever voltage you test will go as a direct input to the Arduino, so you should only test stuff that is in the range of volts that Arduino can safely handle (0–5V). Testing with a 9V battery will fry your Arduino.

Thanks to this video tutorial for helping me figure out the electric circuit. Special thanks to my friends Nick Arner and Johnny Wang for helping me fix stuff. And thanks to Laura Deming for the challenge! :)

More articles and tutorials on electronics/hardware and brain-computer interfaces on the way! :D

If you have feedback to share, feel free to email me at harshita@harshitaapps.com. I look forward to hearing from you!

Otto is a monkey plush that we found in a highway store during a trip with my girlfriend in February 2017.

Its ability, while being extremely cute, was to listen to you, then walk and repeat all things with a higher pitch.

My goal was to make it more powerful by transforming it into a vocal assistant.

SkeletOtto and Otto

This is the first part of a series about Otto.

Originally, it was composed by the following hardware:

• A motor connected to his legs for allowing him to walk
• A simple, closed (for modifications), built-in board
• A microphone and a speaker
• A push button to start the listening phase
• Four AA batteries
• A switch to completely power off the circuit

I wanted to replace all these things with fresh and programmable hardware.

The real challenge here was to find the rights components that fitted in the original enclosure. The available space wasn’t much, so every choice had to be done conscientiously.

Base board

The preferred hardware for this project are Raspberry PI boards.

They are tiny and powerful enough to allow developers to use a high-level programming language and built-in libraries without flashing the software every-time.

Furthermore, you can debug your application in a more comfortable environment.

The best hardware at the time was the Raspberry Pi Zero W. Launched at the end of February 2017, the Pi Zero W has all the functionality of the original Pi Zero but with added connectivity.

Raspberry Pi Zero W

The board was not enough for such a project, so I added additional hardware.

Audio components

To build a vocal assistant, we need audio components. The requirements for these components are, of course, a speaker and a microphone.

For the microphone, I tried a USB microphone. The problem with this accessory was that it was not sensible as I wished. Furthermore an additional USB hub was required to connect it.

Moreover, I couldn’t connect a raw speaker easily.

For this reason, I opted to buy an additional board that accomplished this task very well: ReSpeaker 2-Mics Pi HAT.

ReSpeaker 2-Mics Pi HAT is a dual-microphone expansion board for Raspberry Pi designed for AI and voice applications.

The board is developed based on WM8960, a low power stereo codec. There are 2 microphones on both sides of the board for collecting sounds. It also provides 3 APA102 RGB LEDs, 1 User Button and 2 on-board Grove interfaces.

I did not plan to connect LEDs to my board, but the fact that this HAT has built-in LEDs made me think to use them.

ReSpeaker 2-Mics Pi HAT — Hardware specifications

Then I took an old Bluetooth mini-speaker, disassembled it, and connected it to the JST 2.0 Speaker Out port.

To make it work, you have to install their drivers on your board. Drivers are also used to control LEDs within your application via a standard protocol.

ReSpeaker 2-Mics Pi HAT

Hint: when you install a shield, all your GPIO pins are covered. It’s useful to know which pins are really used by your board. To accomplish that, use https://pinout.xyz/

For example, for this board, check out this link: https://pinout.xyz/pinout/respeaker_2_mics_phat

Powering the board

The Raspberry Pi board can be easily powered via USB 5V input. The problem with this approach is that you have to buy a battery pack and connect it via USB.

I didn’t find any battery pack small enough to fit my plush, then my unique alternative was using LiPo batteries.

LiPo Battery — 3.7V 2000mAh

You can’t connect your LiPo battery to your board, you have to use a converter. It can be powered by any 3.7V LiIon/LiPoly battery, and then it converts the battery output to 5.2V DC.

Initially I bought a LiPo SHIM, but I didn’t notice that this controller provides power to your board without charging your batteries.

For this reason I switched to Adafruit PowerBoost 500 Charger. It has a built-in battery charger circuit. You’ll be able to keep your project running even while charging the battery!

Adafruit PowerBoost 500 Charger

Additional hardware

The software uses the “hotword” concept to start the interaction. Basically, it continuously listens for an hotword, like “Hey Otto”, then you just talk and say commands.

For having an alternative method to start the interaction, I installed a push button connected directly to the GPIO board, at GPIO8 pin.

Push button

Now only one thing was missing: the power on-off switch.

I connected this simple component to the PowerBoost Charger via its ENABLE port. The purpose of the ENABLE port is to disconnect the output completely.

Power on-off switch

Connect everything together

Here you can see in details the complete circuit diagram (https://www.circuit-diagram.org/circuits/0d85ce05)

Otto Circuit diagram

And here a snapshot of the work:

The hardware behind Otto

In this post we’ll explore Raspberry Pi GPIO pins by creating a “Hello World” GPIO program that results in a blinking red LED. We’ll be using the Python programming language. I am using a headless Raspberry Pi Zero WH (wireless with soldered headers) with Raspbian Stretch Lite (Raspberry Pi operating system with a minimal image based on Debian Stretch).

I will talk to my headless Pi using ssh and transfer necessary files from my Mac to Pi using scp commands. I am assuming you have your Raspberry Pi up and running with Raspbian OS installed. If not, then there are lot of articles on the Internet describing how to setup your Pi and install Raspbian, including the official Raspberry Pi documentation.

Things you’ll need:

• 1 x Raspberry Pi (I am using the Pi Zero WH model)
• 1 x bread board
• 1 x red LED light
• 1 x 330 ohm resistor
• 2 x female to male jumper cable

GPIO pins configuration

GPIO stands for General Purpose Input Output. With the help of GPIO pins, a Raspberry Pi can connect and interact with external electronic components. Recent Raspberry Pi models (Pi 3, Pi Zero, Pi W and Pi WH models, and so on) contain 40 GPIO pins. Each pin can turn on or off, or go HIGH or LOW in electronic terms. If the pin is HIGH it outputs 3.3 volts, if the pin is LOW it is off.

In our example, we’ll be using pin 6 (ground) and pin 25. To know more about the GPIO pins in Raspberry Pi, checkout pinout.xyz.

Setting up the circuit

You should turn the Pi off while building the circuit. We’ll create a circuit as depicted in the diagram below:

Note: The resistor in the image is of 220 Ohm, but I have used 330 Ohm in my circuit.

1. Use a female to male jumper cable to connect pin 6 (Ground) (black cable in the image above) to the breadboard negative row.
2. Use another female to male jumper to connect to connect GPIO pin 25 to point represented by row A and column 12 on the breadboard as shown above (blue cable in the image above).
3. Connect one end of a 330 ohm resistor to the negative row (the row that is highlighted in green where the black cable above earlier connected) and connect the other end to the point represented by row C column 11 on the breadboard as shown above.
4. The shorter end of the LED is the negative end and the longer is the positive end. The longer end should always be connected to the point in the circuit with higher voltage (that is, higher potential). The shorter end of the LED is connected to a GPIO pin 25 (which can output 3.3V) via the blue cable and the longer end is connected to the ground pin 6 (which is 0V and acts like the negative terminal of the battery) via the black cable with a resistor in between them.

Resistor

Keeping in mind that I had taken introductory classes on electrical and electronics engineering quite some time ago (4 to 5 years approx.), I had two questions that I needed answers for. Please bear with me for being naive in this context.

1. Why do we need a resistor in our circuit?
2. How do we determine how many Ohms (the measure of electrical resistance) the resistor should be?

A resistor is required to dissipate the extra electrical energy (voltage) from the Raspberry Pi. Raspberry Pi is rated to supply 50mA at 3.3V. Let’s say our red LED can have a forward voltage (forward voltage is the “negative voltage,” used by the LED when it’s on) of around 2V and consumes 4mA current. So the remaining 1.3V should be dissipated by the resistor.

Using Ohm’s law, V = IR, R = (3.3V - 2V) / (4/1000) which comes to around 325 ohms — so I recommend using a 330 ohm resistor.

I discovered this from a Raspberry Pi forum discussion.

Making the LED blink using Python

Now that we have a complete circuit, the next part is to program the GPIO ports to make the magic happen: to get the LED to blink. We will be using the output of GPIO pin 25 to make the LED blink.

Start your Pi and connect to it using ssh. In the terminal, use the following command to install the Python library gpiozero. The gpiozero library makes working with GPIO pins and connected external components very simple.

To install the Python library, type sudo apt-get install python3-gpiozero.

Now we will run some Python code. Save the code below onto your your Pi file system in a file named blink1.py. The script basically turns on the LED connected to pin 25, sleeps for 1 second, then turns off the LED, and again sleeps for 1 second. And this is done continuously in a loop until the program is terminated (pressing ctrl + c).

Now from terminal, go the the directory where the script is saved and run it using the command: python3 blink1.py.

You will see the red LED blinking like this:

We can build lots of fun stuff using gpiozero using a similar setup. Check out the documentation for gpiozero which demonstrates some interesting examples. Try building a traffic light system.

Originally published at shahbaz.co on April 7, 2018.

Recently, I purchased a NodeMCU from AliExpress for about $4. The reason I did this was to find out what all the fuss is about with ESP8266.

NodeMCU is an open source IoT platform. It includes firmware which runs on the ESP8266 Wi-Fi SoC from Espressif Systems, and hardware which is based on the ESP-12 module.

Source: ESP8266 Datasheet

Compared to the Arduino UNO, my ESP8266 totally knocks it out of the park when it comes to CPU power and price.

The ESP8266 is 500% faster and 82% cheaper than the Arduino. The ESP8266 also has WiFi connectivity.

I was very surprised when I visited the Espressif website for the ESP8266. There’s lots of documentation and resources that you can use. For example, there’s an Android application which tells your ESP8266 to connect to your WiFi. The app sends the SSID and password as packets, the ESP8266 sniffs them, and then it connects to your WiFi. This is called SmartConfig, and was invented by Texas Instruments.

In this article, I will guide you to setup and run the Smart Config example from the Espressif RTOS SDK.

Here’s the things you’ll need:

• A modern computer.
• A NodeMCU board with ESP12-E
• VirtualBox (https://www.virtualbox.org/wiki/Downloads)
• Ubuntu Server LTS (https://www.ubuntu.com/download/server)

Configuring VirtualBox for development

1. Download VirtualBox and install Ubuntu Server. This should be easy to do, but if you don’t know how, Google it or have a look at this graphic step by step guide. Installing an OS is a nice skill to have. (Tip: When VirtualBox prompts you to select the disk, make it dynamically allocated and at least 50GB in size. This will save you some headaches further down the line.)
2. Make sure that you can access the internet from within the virtual machine and configure the DNS server:

Right click the machine then Settings -> Network

To configure the DNS server, have a look at this example.

Example: dns-nameservers 8.8.8.8 8.8.4.4 If you can ping Google, then you’re good to go!

3. (Optional) Install OpenSSH and Samba server. This will make your life much easier.

4. (Optional) Enable port forwarding. In order to SSH directly into your virtual machine, you need to enable port forwarding. For example, to map the port 2222 on your host machine to the port 22 of your virtual machine.

Enable Port forwarding: Settings -> Network -> Port Forwarding

If you have enabled port forwarding, you can now SSH into your virtual machine from your Host machine as in the figure below.

FIG1: ssh -p 2020 denis@localhost

Note: If you’re on Windows, you need Putty in order to SSH into the virtual machine.

5. Plug in your NodeMCU and execute the following command:

tail -f /var/log/kern.log

This should reveal to you that the device has been identified as /dev/ttyUSB0. If nothing happens, then you need to add the USB to the virtual machine. After adding the USB, unplug and plug your device in again.

Adding USB: Settings -> Ports -> USB

If you’ve reached this point and every thing is working, congratulations! You’re now ready to compile the SDK and run the SmartConfig example. You can even shoot me a tweet at https://twitter.com/metonymyqt

Compiling the SDK and flashing the board

1. Install the required packages (as below). This info is also available on the SDK’s readme.md.

sudo apt-get install make unrar-free autoconf automake libtool gcc g++ gperf flex bison texinfo gawk ncurses-dev libexpat-dev python-dev python python-serial sed git unzip bash help2man wget bzip2 libtool-bin

2. Create a new folder and navigate into it: mkdir Development && cd Development

3. Clone the Open SDK: https://github.com/pfalcon/esp-open-sdk

git clone --recursive https://github.com/pfalcon/esp-open-sdk.git

3. Run make: make

Warning: This step will take a while to finish so please be patient. On my virtual machine it completed after 50 minutes. On yours it might take more or less, but before you run, make make sure that you’re connected to the internet and DNS is properly configured. The best way to check this is to execute a ping to Google or some other site if Google is blocked in your region.

Successful ping command: $ ping medium.com

If your ping is successful, you can minimize the windows and watch an episode of your favorite TV show. Come back after about 40 minutes (but make sure your computer doesn’t go to sleep).

After the SDK has been built successfully, you’ll see a message telling you to put something in your path. To do so, execute the following:

echo 'export PATH=/home/denis/Development/esp-open-sdk/xtensa-lx106-elf/bin:$PATH' >> ~/.profile

The command will append the string to the ~/.profile file. Now please run the following command:

xtensa-lx106-elf-gcc --version

If the command executes successfully, then you’re good to go!

4. Test your board

Plug your NodeMCU and run lsusb to verify that your device is connected. After that, run esptool.py chip_id. You should now see the board’s chip id.

_esptool.py chipid

5. Clone ESP8266_RTOS_SDK

git clone https://github.com/espressif/ESP8266_RTOS_SDK.git

6. Export the SDK path and SDK/BIN path using the commands below.

echo 'export SDK_PATH=/home/denis/Development/ESP8266_RTOS_SDK' >> ~/.profile

echo 'export BIN_PATH=/home/denis/Development/ESP8266_RTOS_SDK/bin' >> ~/.profile

7. Compile the SmartConfig example

cd /home/denis/Development/ESP8266_RTOS_SDK/examples/smart_config/

chmod +x ./gen_misc.sh

./gen_misc.sh

Now accept the default values until you’re asked for SPI_SIZE_MAP. This is where you select 4 because the NodeMCU has a flash size of 32Mbit and this translates to 4MB. _You can also select SPISPEED 3=80Mhz

You’ll see something like this:

!!!SDK_PATH: /home/denis/Development/ESP8266_RTOS_SDKBIN_PATH: /home/denis/Development/ESP8266_RTOS_SDK/bin

No boot needed.Generate eagle.flash.bin and eagle.irom0text.bin successully in BIN_PATHeagle.flash.bin — — — →0x00000eagle.irom0text.bin — →0x20000!!!

8. Flash the board

cd $BIN_PATH

esptool.py erase_flash

esptool.py write_flash 0x00000 $BIN_PATH/eagle.flash.bin 0x20000 $BIN_PATH/eagle.irom0text.bin 0x3FC000 $BIN_PATH/esp_init_data_default.bin

Now, if you reset the board, you should see no LED blinking.

9. Use the Phone Application

10. Android Application

11. iPhone Application

ScreenShot from my Android Device

Open the Application, make sure that you’re connected to a WiFi AP, enter your password, and press confirm. After a few seconds the ESP8266 should connect to your AP. That’s it. Congratulations for reaching the end!

If you want to develop more using the ESP8266-RTOS-SDK, please visit the official websites. You’ll find a lot of resources and documentation there. Also, please take a look at the other examples found in the SDK folder.

Thank you very much for your time reading this. If you want to reach out to me, you can do so on Twitter: MetonymyQT

Resources

• ESP8266 Overview
• ESP8266 Resources
• FreeRTOS Website