The AquaPing is not a flow meter…

…it’s a leak detector. There is an important difference. A flow meter makes a quantitative measurement. It reports in units such as gallons-per-minute or liters-per-hour. A "smart" flow meter keeps a time-series record of measured rates and — with this accumulated history — attempts to deduce an anomalous condition that might correspond to a leak. A flow meter requires that some sort of transducer be placed on or in the plumbing to generate this data.

The AquaPing, in contrast, is listening for a persistent acoustic signal that indicates the possible presence of a leak. It doesn’t really care about the leak rate — only whether or not one is present. It has been designed to detect the smallest leaks, below flow rates where utility meters may not even respond.

The essential premise of the AquaPing design is that the acoustics produced by small leaks will be steady and persistent. This is not anticipated to be the situation with large leaks, which are likely going to be loud and erratic like this gushing fire hydrant.

Statistics and noise mitigation

The AquaPing attempts to determine the presence of a leak by collecting frequency-filtered acoustic energy as time-series data (described in a previous update) and performing a statistical analysis. The first step is to learn about the nominally quiet, ambient background in a short training session. The background dataset establishes a baseline signal level characterized by an average \(\bar{x}_B\) and standard deviation \(\sigma_B\). The analysis does not involve the cloud; all data and statistics are processed on the sensor.

When training completes, the device transitions to monitor mode, recording events in three counting arrays designated quiet, leak, and noise.

The polling period can be set in the range from 1 to 30 seconds; default is 2 seconds. Each polling cycle starts with an 8 ms audio capture. If ADC overload is detected, a noise event is recorded and the sensor enters sleep mode to wait for the next polling iteration. If no overload occurs, an FFT is performed on the time-sampled data to produce an acoustic energy level \(x_1\). If \(x_1 < \bar{x}_B + \sigma_B\), a quiet event is recorded and the sensor re-enters sleep mode to wait for the next polling cycle. When sleeping, the CPU and 8 MHz ADC clock are disabled to save power; only the 32768 Hz timer remains active. This is Low Power Mode 3 of the MSP430 with current draw < 4 μA.

If \(x_1 > \bar{x}_B + \sigma_B\), four additional 8 ms measurements are made \((x_2, x_3, x_4, x_5)\) separated by 45 ms corresponding to a sampling rate of about 22 Hz. If any of these measurements saturates the ADC, a noise event is recorded. If all five energies are within the dynamic range of the ADC, their average \((\bar{x})\) and standard deviation \((\sigma)\) are calculated. If \(2\sigma > \bar{x}\), excessive fluctuations are present in the data set. This indicates an unacceptable level of environmental noise that prevents reliable leak detection. The polling loop iteration is recorded as a noise event.

If the acoustic energy fluctuations are sufficiently small \((2\sigma < \bar{x})\), the next step is to check if all five spectral energies \((x_i : i = 1-5)\) exceed the leak signal threshold: \(x_i > \bar{x}_B + \sigma_B\). When this occurs, a leak event is recorded. Otherwise, this loop iteration is associated with impulse noise, but recorded as a quiet event.

The preceding analysis is summarized in the following flow chart:

Raising the alarm flag: Counting Arrays

Each polling cycle assigns the acoustic signal to one of the following three events: quiet, leak, or noise. These events are accumulated in three separate data arrays. The value 1 is entered if that specific event occurs; otherwise it is counted as 0. For example: if a leak signal is detected, a 1 is added to the leak array while 0 is placed in the quiet and noise arrays. As new events are added, the oldest events are removed, i.e., the fixed-size data arrays slide in time. Analysis of these three data sets allows the AquaPing to determine if a persistent leak is present.

All counting arrays are the same size and contain elements that are either 0 or 1. The array size is configured in the range 10–255; the default is 20. Size and polling rate determine the time over which a full data set is acquired. The default 0.5 Hz polling rate and event set size of 20 define a 40 second data accumulation window. This time sampling window will depend on the application and should be adjusted by the user as necessary. These modifications are made with a simple command set and uploaded to the sensor on the I2C bus.

If leak events become an appreciable portion of the time sampling window, an alarm condition may exist. Ideally, all events in the window will be identified as leaks. In practice, environmental noise, irregularities in water flow, pressure fluctuations, the presence of bubbles, or other acoustic disturbances may be recorded as quiet or noise events – not leaks. To account for non-ideal signals, the alarm trigger size can be independently set below the event set size. The trigger value is not critical; testing has shown that 80–90 percent of the event set size is a good choice. The default values are 18 for the trigger size and 20 for the event size.

When a potential leak is identified, the AquaPing provides an immediate alert by switching the digital ALARM line from low to high. The controller can monitor this line with an interrupt. The corresponding status byte is also set. The real-time count of quiet, leak, and noise events are available at any time by querying the sensor via I2C. If noise events become significant, the noise status byte is set. This is important, as leak detection is compromised when ongoing noise is present. The counts in the quiet, leak, and noise arrays sum to the event set size.

The firmware used to perform the above operations is open-source and available in this repository. Questions and comments about the code or any aspect of the design are welcome. Use the link below to send a direct email.