Dust sensors are supposed to measure micro-particles of very fine dust as a concentrate in the air. It is deemed that inhaling these dust particles is unhealthy. The most common sensor it seems, is a sensor that uses an infrared diode and a receptor to measure light that has not been refracted by dust particles between two points and from there derive, based on design and calibrated values, the concentration of micro-dust particles in the air.

Lots of these dust sensors are available on the market, with varying brands and many variations, based on a design made by Sharp, mostly all originating in China and with the general serial number starting with GP2Y.

The sensor is terrible to work with, there is an additional mini-circuit that must be created when connecting the GP2Y to the ESP, which requires some extra soldering.

The datasheet extensively goes into the physics of the measurement but unfortunately does not provide all too much information on what to do with the measured value. Then, the actual measurement consists in an entire sequence described as:

• turn the measurement LED on,
• wait a given amount of micro-seconds ,
• perform the measurement,
• wait a given amount of micro-seconds ,
• turn the LED off,
• wait a given amount of micro-seconds

all of which could or should be coalesced into just a single PWM and/or analog signal on its own with a preset or configurable resolution instead of making the user go through all of this just to get a measured value (like, every other sensor out there). To add to the pain, these micro-delays might seem fine when dealing with synchronous programming, but if the user is using some asynchronicity or, dare they, parallelism, the micro-delays would do nothing but bother the rest of the semantics. Iff. all of , and are well-designed and non-free variables then there is absolutely no reason to leave it up to the user to go through all of this ordeal; as said, these values are fixed and clearly defined within the spreadsheet, such that waiting where is a random number, immediately leads to undefined behavior as per the specification.

On the other hand, perhaps one of the best uses for this type of sensor, would be in areas that are prone to dust storms, due to the sensor being specifically designed for detecting particle concentrations that might be precursors to a dust storm. Similarly, it may be the case that the sensor will also detect forming thunderstorms due to the wind blowing dust into the air. However, that is to be determined as we keep measuring.

Even if the user has to extensively go through an ordeal to get a measurement out of the sensor, there are very many formulas spread across the Internet that all lead to different values that do not seem to align or corroborate with each other, such that providing an accurate measurement is also an ordeal.

Fortunately there exists a library, namely GP2YDustSensor that seems to yield some believable values.

#include <GP2YDustSensor.h>
 
 
// GP2Y1014AU0F is the sensor serial, 
// DUST_LED_PIN corresponds to the GPIO pin leading to the LED on the sensor, 
// DUST_PIN_ANALOG corresponds to the analog GPIO pin leading to the measurement wire on the sensor.
// Note that DUST_LED_PIN can be a digital GPIO pin and DUST_PIN_ANALOG and analog GPIO pin.
GP2YDustSensor dustSensor(GP2YDustSensorType::GP2Y1014AU0F, DUST_LED_PIN, DUST_PIN_ANALOG);
 
void setup() {
    Serial.begin(9600);
    dustSensor.begin();
}
 
void loop() {
    float dustDensity = dustSensor.getDustDensity();
    float dustAverage = dustSensor.getRunningAverage();
 
    Serial.printf("Dust density: " + dustDensity + " dust average: " + dustAverage);
    delay(1000);
}