Compressed Air Leak Monitor.

Project Overview

Finds the compressed-air leaks that silently waste a huge share of a factory's energy — by watching pressure decay when nothing should be running, and listening for the ultrasonic hiss of escaping air.

Compressed air is often called the "fourth utility", and it is one of the most expensive forms of energy in a factory — most of the electricity a compressor consumes ends up as heat, so every cubic metre of compressed air is dear. The dirty secret is that a large fraction of it — commonly 20-30% — leaks away through worn fittings, cracked hoses and stuck drains, wasting money continuously, day and night, for years, because a leak makes no obvious sign on the production floor. This project builds a monitor that finds that waste: it detects when the system is leaking, quantifies how much, and helps locate leaks so they can be fixed — turning an invisible, permanent energy drain into a fixable, measurable problem.

It attacks the problem two complementary ways. The system-level method watches the receiver pressure during no-demand periods — nights, weekends, breaks — when, with all tools off, a sealed system should hold pressure. If it does not, the rate of pressure decay reveals the total leakage, and the frequency with which the compressor kicks in to top up an idle system (the "load/unload" cycling with no demand) directly quantifies the leak load and its energy cost. This needs only a pressure sensor on the receiver and knowledge of the demand schedule, and it gives the headline number: how much air, and money, is leaking.

The local method helps find where: escaping compressed air generates a characteristic ultrasonic hiss (turbulent flow radiates strongly above human hearing), so an ultrasonic microphone can detect a leak by ear that is silent to a person, pointing a technician to the exact fitting. Combined, the system-level monitor says "you are leaking X and it is costing Y", and the ultrasonic aid helps hunt the leaks down. The monitor logs and trends the leakage so a growing leak load is caught and the savings from repairs are verified. It is honest that quantification depends on the compressor/system specifics and that ultrasonic hunting is an aid, not magic — but as a leak monitor that makes an invisible, expensive waste visible and actionable, it typically pays for itself many times over in the energy it recovers.

What this project does

• Detects compressed-air leaks at the system level via pressure decay in no-demand periods
• Quantifies leakage from pressure-decay rate and no-demand compressor cycling
• Estimates the energy and money cost of the leak load
• Detects/locates leaks acoustically via ultrasonic hiss
• Logs and trends leakage so a growing leak load is caught
• Verifies the savings from leak repairs
• Turns invisible, permanent air waste into a measurable, fixable problem

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• No-demand pressure-decay leak detection (system level)
• Leakage and cost quantification from decay/cycling
• Ultrasonic leak location (hear the silent hiss)
• Trending to catch a worsening leak load
• Repair savings verification
• Compressor-cycling energy insight
• Honest quantification tied to system specifics

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Pressure sensing on a compressed-air receiver
• No-demand pressure-decay analysis and leakage quantification
• Ultrasonic acoustic leak detection
• Compressor-cycling and energy-cost estimation
• Trending and repair verification

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹5,330, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 3282.9 mA. With a 1.5× design margin the supply should deliver at least 5000 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Fit the pressure transducer on the receiver/main to read system pressure; this is the core system-level sensor.
• Add a compressor-state input (or CT) to count load/unload cycles, which quantify no-demand leakage.
• For acoustic location, use a dedicated ultrasonic sensor (~40 kHz) — an audio MEMS mic has limited ultrasonic range.
• Know the plant's demand schedule so the monitor can analyse pressure decay during genuine no-demand periods.
• Work safely around pressurised lines; do not create injury hazards during leak hunting.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

Compressed air deserves special attention because it is expensive energy that leaks invisibly. A compressor is an inefficient converter — most of the electrical energy it draws becomes waste heat, so the usable compressed air is costly per unit — and leaks bleed that costly air away continuously, unseen and unheard, through fittings and hoses across a plant. Because a leak produces no visible effect on production and often no audible sound to human ears, it can waste energy for years unnoticed. The monitor's job is to make this waste visible and quantified, because a leak you can measure and cost is a leak that gets fixed, while an invisible one is tolerated forever.

The most reliable system-level signal is what happens during no demand. When every tool and machine is off — overnight, at weekends, during a break — a leak-free system, once charged, should hold its pressure indefinitely; the compressor should not need to run at all. A real system does not: its pressure decays, and the compressor periodically cycles (loads and unloads) just to keep the idle system topped up. Both are pure leakage. The rate of pressure decay in a known system volume gives the leak flow directly, and the fraction of no-demand time the compressor spends loaded (or the number of load cycles per hour with no demand) quantifies the leak load as a share of compressor capacity — which converts straight into wasted energy and money using the compressor's power. This is the headline the monitor delivers: not "there are leaks" but "you are leaking X m³/h, costing ₹Y per year".

Finding where the leaks are is the complementary local problem, and physics helps: air escaping through a small orifice becomes turbulent and radiates strongly in the ultrasonic range, well above human hearing. An ultrasonic detector "hears" this hiss and, especially with a directional/parabolic pickup, points a technician straight to a leak that is completely silent to the ear. This turns leak hunting from a hopeless walk-around into a directed search. The monitor can use ultrasonic sensing to flag and help localise leaks, though it is honest that ultrasonic hunting is a skilled aid — reflections and background ultrasonic noise exist — rather than an automatic map.

What ties it together is trending and verification. Logging the quantified leak load over time catches a worsening system (leaks grow, new ones appear) before the bill balloons, and — crucially — lets you verify repairs: fix a batch of leaks and the no-demand decay slows, the no-demand cycling drops, and the monitor shows the recovered air and money, proving the maintenance paid off and justifying the next round. The design is candid about its dependencies: quantification needs the compressor and system specifics (capacity, power, volume) to convert decay/cycling into real energy, and precise leak location is a technician-assisted process. But within that, it does something with unusually high ROI — it exposes and measures one of the largest, most ignored energy wastes in a factory, and turns it into a prioritised, verifiable repair list. Compressed-air leak repair is famously one of the cheapest energy savings available; this monitor is what makes a plant actually go and get it.

The maths behind it

Leakage from no-demand pressure decay

Sealed system volume V, pressure falls p1→p2 in time t
with no demand (isothermal approx):

  leaked_free_air ≈ V·(p1 − p2)/p_atm
  leak_flow ≈ leaked_free_air / t   (free air / time)

A faster decay = a larger leak. Needs the system volume.

Leakage from no-demand compressor cycling

With no demand, all compressor output serves leaks:

  leak_fraction = loaded_time / total_time (no-demand)
  leak_flow ≈ leak_fraction · compressor_capacity

  wasted_power ≈ leak_fraction · compressor_power
  annual_cost ≈ wasted_power · hours · tariff

Ultrasonic leak signature

Turbulent flow through a leak radiates ultrasound (~20–50 kHz):

  ultrasonic level rises sharply near a leak
  directional pickup → localise the leak

Silent to the ear, loud in ultrasound → detectable/locatable.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Fit the pressure and compressor sensing

   Install the pressure transducer on the receiver/main and a compressor-state input (or CT). Establish the system volume and the compressor's capacity/power for quantification.

2. Add ultrasonic leak detection

   Add a dedicated ultrasonic sensor (directional if possible) for acoustic leak location, and learn the background ultrasonic level so a real leak stands out.

3. Set up analysis and reporting

   Configure the no-demand schedule, decay/cycling analysis, cost model, and dashboard/logging for trending and repair verification.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Quantify leakage in no-demand periods

   During genuine no-demand periods, measure the pressure decay rate (and/or no-demand compressor cycling), convert to leak flow, and estimate the energy and money cost.

   cppleak-quantify.ino Copy Download

   // System-level leak quantification during a no-demand period.
   struct System { float volume_m3; float compCapacity_m3min; float compPower_kW; };
   
   // From pressure decay p1->p2 over t seconds (no demand).
   float leakFlowFromDecay(float p1_bar, float p2_bar, float t_s,
                           const System &s) {
     float freeAirLost = s.volume_m3 * (p1_bar - p2_bar);   // ~ m3 free air
     return (freeAirLost / (t_s/60.0f));                    // m3/min
   }
   
   // From no-demand compressor loaded fraction.
   float leakFlowFromCycling(float loadedFraction, const System &s) {
     return loadedFraction * s.compCapacity_m3min;          // m3/min
   }
   
   float annualLeakCost(float loadedFraction, const System &s,
                        float hoursPerYear, float tariff) {
     float wastedKW = loadedFraction * s.compPower_kW;
     return wastedKW * hoursPerYear * tariff;               // currency/year
   }

   float freeAirLost = s.volume_m3 * (p1_bar - p2_bar)The pressure drop in the known system volume during no demand gives the free air lost, and dividing by time gives the leak flow.

   return loadedFraction * s.compCapacity_m3minDuring no demand, the fraction of time the compressor runs loaded times its capacity is the leak flow — a second, independent quantification.

   float wastedKW = loadedFraction * s.compPower_kWThat same loaded fraction times the compressor power is the wasted electrical power feeding the leaks.

   return wastedKW * hoursPerYear * tariffMultiplying by run hours and tariff turns the leak into an annual cost — the number that justifies the repair.

2. Detect/locate acoustically and trend

   Use ultrasonic level to flag leaks and assist location, trend the quantified leak load over time, and verify repairs by the drop in decay/cycling.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   Compressed Air Leak Monitor — ESP32

   Quantifies compressed-air leakage from no-demand pressure decay and
   compressor cycling, estimates energy cost, flags/locates leaks
   ultrasonically, and trends leakage to verify repairs.
   ══════════════════════════════════════════════════════════════════ */

#include <WiFi.h>
#include <PubSubClient.h>
#include <Wire.h>
#include <Adafruit_SSD1306.h>
#include <Preferences.h>

#define PIN_PRESSURE 34
#define PIN_ULTRA    35
#define PIN_COMP     27       // compressor loaded (HIGH)
#define PMAX_BAR     16.0f
#define VOLUME_M3    2.0f
#define COMP_CAP_M3MIN 5.0f
#define COMP_KW      37.0f
#define TARIFF       8.0f     // currency per kWh
#define HOURS_YEAR   8000.0f

Adafruit_SSD1306 oled(128,64,&Wire);
Preferences prefs; WiFiClient net; PubSubClient mqtt(net);

float readPressure(){ return analogRead(PIN_PRESSURE)/4095.0f * PMAX_BAR; }
float ultrasonicLevel(){ return analogRead(PIN_ULTRA)/4095.0f; }

// Track compressor loaded fraction during a no-demand window.
uint32_t noDemandStart=0, loadedMs=0; float p1=0; bool inNoDemand=false;

void startNoDemand(){ inNoDemand=true; noDemandStart=millis(); loadedMs=0; p1=readPressure(); }

void endNoDemand(){
  inNoDemand=false;
  uint32_t total = millis()-noDemandStart;
  float loadedFrac = total? (float)loadedMs/total : 0;
  float p2 = readPressure();
  float decayFlow = VOLUME_M3*(p1-p2) / ((total/1000.0f)/60.0f);  // m3/min
  float cycleFlow = loadedFrac * COMP_CAP_M3MIN;                   // m3/min
  float wastedKW  = loadedFrac * COMP_KW;
  float annualCost= wastedKW * HOURS_YEAR * TARIFF;

  char m[240];
  snprintf(m,sizeof m,
    "{\"leak_decay_m3min\":%.2f,\"leak_cycle_m3min\":%.2f,"
    "\"wasted_kW\":%.1f,\"annual_cost\":%.0f}",
    decayFlow, cycleFlow, wastedKW, annualCost);
  mqtt.publish("air/leak/summary", m);       // trend + verify repairs
}

void setup(){
  Serial.begin(115200);
  pinMode(PIN_COMP, INPUT);
  Wire.begin(21,22); oled.begin(SSD1306_SWITCHCAPVCC,0x3C);
  WiFi.begin(WIFI_SSID,WIFI_PASS); mqtt.setServer(MQTT_HOST,1883);
}

void loop(){
  if(!mqtt.connected()&&WiFi.status()==WL_CONNECTED) mqtt.connect("air-1");
  mqtt.loop();

  bool noDemand = isNoDemandPeriod();          // from schedule
  if (noDemand && !inNoDemand) startNoDemand();
  if (!noDemand && inNoDemand) endNoDemand();

  if (inNoDemand && digitalRead(PIN_COMP)==HIGH) loadedMs += 200;  // loaded time

  float ultra = ultrasonicLevel();
  if (ultra > ULTRA_LEAK_THRESH)                // near a leak
    mqtt.publish("air/leak/acoustic", "ultrasonic leak nearby");

  float p = readPressure();
  oled.clearDisplay(); oled.setCursor(0,0);
  oled.printf("P: %.1f bar\nUltra: %.2f\n%s", p, ultra,
              inNoDemand?"NO-DEMAND":"running");
  oled.display();

  delay(200);
}

Configuration & Calibration

Configuration steps

• Set the system volume, compressor capacity/power, tariff and run hours for quantification.
• Configure the no-demand schedule and the pressure/compressor/ultrasonic inputs.
• Set leak targets and the ultrasonic threshold.
• Configure trending/logging and repair-verification reporting.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Pressure

   Verify the pressure reading against a reference gauge; confirm the transducer range/scaling.

2. Quantification

   Confirm the system volume and compressor figures so decay/cycling convert to realistic leak flow and cost; cross-check the two methods.

3. Ultrasonic

   Learn the background ultrasonic level and set the threshold so a real leak stands out; test on a known small leak.

Network Architecture & Connectivity

Communication protocol

No-demand leak summaries (flow, wasted power, cost) publish per period; acoustic leak flags publish on detection. Trends drive repair prioritisation and verification.

Message contract between the device and the broker.

Cloud platform configuration

A dashboard/CMMS trends the leak load and cost, prioritises repairs, and verifies savings after maintenance; acoustic flags aid leak hunting.

Dashboard setup

Pressure and no-demand leak-load trend with cost, an ultrasonic leak indicator, and repair-verification comparisons.

Mobile app integration

Alerts on a rising leak load and acoustic leak detections; savings summaries after repairs.

Security considerations

• Authenticate nodes; secure the energy data.
• Keep quantification inputs (system/compressor specs) accurate for trustworthy cost figures.
• Alert on monitor silence.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

The dashboard shows current pressure, the quantified no-demand leak flow and its annual cost, an ultrasonic leak indicator, and a leak-load trend with repair markers.

{
  "leak_decay_m3min": 0.9,
  "leak_cycle_m3min": 0.95,
  "wasted_kW": 7.0,
  "annual_cost": 448000
}

The two methods agree on ~0.9 m³/min of leakage, ~7 kW of wasted power costing ~₹4.5 lakh/year — an invisible waste made visible and costed; after repairs these numbers drop, proving the saving.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Sample pressure/compressor at a modest rate; analyse over no-demand windows.
• Cross-check decay and cycling estimates for confidence.
• Trend the nightly leak metric to catch worsening leaks and verify repairs.
• Handle ultrasonic detection separately as a location aid.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Batch several samples into one MQTT publish. Radio time, not CPU time, dominates the energy budget.
• Set the MQTT keep-alive to a value that matches your reporting interval so the broker does not churn reconnections.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.

Safety Precautions

• Work safely around pressurised systems — a compressed-air jet can cause serious injury; keep leak hunting safe.
• Quantification depends on correct compressor/system specifics; label figures as estimates where inputs are uncertain.
• Ultrasonic leak location is a skilled aid, not an automatic map.
• Coordinate with maintenance/energy teams; do not interfere with compressor control.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Verify pressure calibration and quantification inputs periodically.
• Re-learn the ultrasonic background as the environment changes.
• Repair flagged leaks and log the verified savings.
• Trend the leak load and act before it grows.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Rotate the microSD card annually and keep an image of the working system. Cards used as loggers wear out silently.
• Keep the broker and dashboard containers patched, and rotate device credentials at least once a year.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add flow metering for direct leak measurement.
• Add multiple ultrasonic sensors / a scanning aid for faster location.
• Model demand to separate leaks from process use during production.
• Integrate with the CMMS to raise and track leak-repair work orders.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add over-the-air firmware updates so you never have to physically reach a deployed node again.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Compressed air energy efficiency and leaksUS DOE
2. Ultrasonic leak detectionReference
3. Compressed air systems — overviewReference
4. Compressor load/unload controlReference
5. Pressure decay leak testingReference