Vibration sensors and thermal cameras get most of the attention in predictive maintenance conversations. Acoustic monitoring has one significant advantage over both: it can detect faults that don’t yet have a thermal or vibration signature, and it can do it from a distance. A bearing that’s starting to fail will make noise before it generates meaningful heat. A gas valve with a small leak will whistle at frequencies that aren’t visible to a camera but are absolutely detectable with the right microphone.

The challenge has always been the data volume. Raw audio generates enormous amounts of data, raises privacy concerns if it leaves the site, and requires network bandwidth that many industrial environments don’t have. Edge AI inference — running a small acoustic classification model directly on the sensor node — solves all three problems simultaneously.

What you’re actually detecting

The useful signal categories for industrial acoustic monitoring are fairly well defined.

Rotating machinery anomalies: Bearings produce characteristic frequency signatures as they wear — BPFI (ball pass frequency inner race), BPFO (outer race), and harmonics of these at predictable multiples of rotational frequency. A model trained on healthy vs. degraded bearings can detect these patterns even in noisy industrial environments, catching failures weeks before a bearing seizes.

Gas and steam leaks: High-pressure leaks generate ultrasonic noise (above 20kHz) that travels through structures. With the right microphone — MEMS mics with response to 40kHz+ — and a model trained on leak signatures, you can detect pinhole leaks before they’re visible or smellable. This is particularly valuable in process industries where gas leaks are both a safety risk and a source of significant production losses.

Glass break and intrusion detection: Classic glass-break detection for security applications is well understood, and it’s a natural fit for edge inference — you want an immediate local alert, not one that depends on cloud latency.

Animal vocalisation monitoring: In agricultural settings, detecting livestock distress calls (calves separated from mothers, poultry disease indicators, pigs under heat stress) can provide early warning of welfare issues. This is an active research area, and commercial systems are starting to appear.

Hardware for edge acoustic inference

The standard platform for getting started is the ESP32 with a MEMS microphone. MEMS microphones (the Knowles SPH0645, Vesper VM2020, or ICS-43434) connect via I2S or PDM and give clean audio from 100Hz to well above 10kHz, with a very low noise floor. The ESP32’s dual Xtensa cores and built-in DSP instructions handle spectrogram computation without breaking a sweat.

For higher-frequency work — particularly ultrasonic leak detection — you need a microphone with flat response to 40kHz+ and more processing headroom. The Nordic nRF5340 or STM32H7 series are better choices here: faster cores, more SRAM, and better ADC options.

For battery-powered deployments, the nRF5340 is significantly more power-efficient than the ESP32. That matters when you want a sensor running for months or years on a single set of batteries.

Building the model

Edge Impulse is the practical tool for most teams. The workflow: record labelled audio samples (normal operation, fault condition, background noise classes), let Edge Impulse compute MFCCs or mel spectrograms, train a 1D-CNN or MobileNet-based classifier, and export as a C++ library that drops into your microcontroller project. You can have a first working model in a day, realistically.

The training data requirement is the main challenge. You need real audio from your specific environment — generic internet datasets won’t do — because the acoustic signature of a failing bearing on your particular motor will look different from one on a different machine. The minimum viable dataset is usually a few hundred labelled clips of one to three seconds each. Getting fault examples is the hard part: you may need to introduce controlled defects in test equipment to generate training data.

For anomaly detection where you don’t have labelled fault examples, autoencoder approaches work well. Train on normal operation, then flag clips where reconstruction error exceeds a threshold. Edge Impulse supports this natively, and it’s a practical starting point before you have enough fault data for a classifier.

Deployment considerations

The biggest practical challenge is false positive rate. Acoustic environments are noisy and variable. A model that performs well in the lab may generate constant spurious alerts in a busy factory because of overlapping machinery, HVAC systems, or human activity. The mitigations are: multi-step classification (detect → confirm → alert), confidence thresholds tuned for your environment, and alert suppression windows that require the model to trigger consistently over a time window before escalating.

For LoRaWAN deployments, the compact alert (event type, timestamp, confidence score) rather than raw audio keeps packet sizes manageable and preserves battery life. A typical ESP32 acoustic monitoring node with LoRa radio, sampling at 16kHz and running inference every 500ms, achieves six to twelve months on a pair of AA batteries depending on sleep cycle configuration.

What this looks like in practice

A realistic starter deployment: MEMS microphone plus ESP32 with LoRa radio, housed in an IP67 enclosure mounted near a motor or valve. Edge Impulse model classifies audio segments continuously. On anomaly detection, an alert packet goes out via LoRaWAN to a ChirpStack or The Things Network server, which forwards to your monitoring dashboard. Maintenance team gets a notification before the bearing fails. The whole node costs under £50 in components.

That’s genuinely useful predictive maintenance at a cost that makes sense for deployments with tens or hundreds of machines. The model training takes a few days; the integration work is manageable; and the return on catching even one unexpected bearing failure covers the cost of a significant deployment.

The technology is there. The main work now is the domain-specific data collection and model tuning for each deployment environment.