Apollo510 Acoustic Event Detector for Industrial Equipment Development

Product Goal and Detection Scope

The purpose of the device was to serve as a small acoustic monitoring node for various equipment types, such as engines, pumps, compressors, fans, conveyors, transmissions, solenoid valves and industrial cabinets.

It was created to detect specific classes of operational sounds locally and notify a gateway, mobile application or cloud only of important events.

The system was not positioned as a universal machine-failure predictor. A responsible acoustic solution must be trained and validated for the specific assets, fault signatures, operating speeds, mounting locations, and environments in which it will run. Instead, the first release focused on clearly defined and testable classes, such as:

• Normal machine-running sound
• Idle or stopped condition
• High-impact or abnormal knocking event
• Sustained tonal change
• Air or fluid-leak-like broadband sound
• Alarm, buzzer, or warning tone
• Valve actuation or relay chatter
• Unrecognised acoustic condition requiring review

This scope created a practical pathway to field validation. Rather than making unsupported claims from limited audio samples, the engineering team could gather evidence for each event type, tune thresholds, and progressively extend the model.

Acoustic Hardware and Microphone Integration

The electronics architecture revolves round the Apollo510 MCU, which is linked to the digital MEMS microphone using a digital audio protocol such as PDM or I2S, depending on the type of microphone and the design requirements.

Because they remove the number of components in the analogue signal path and reduce the susceptibility to noise caused by the PCB, digital microphones are more beneficial for small manufacturers of products.

The hardware design considered:

• Microphone sensitivity, self-noise, dynamic range, and directionality
• Required frequency range for the target machine sounds
• Sample rate and bit depth appropriate to the classification task
• PDM or I2S clocking and data routing
• Acoustic port position and environmental sealing
• Protection against dust, oil mist, humidity, and accidental splash exposure
• Vibration isolation and enclosure resonance
• Power-supply decoupling and electromagnetic-noise control
• Debug interfaces and production-test connections
• BLE antenna placement where wireless connectivity is required

The placement of microphones is fundamental. If the microphone is placed very close to a vibrating metal body, it will pick up mechanical coupling noise without relevant airborne sound.

On the contrary, if the opening is too far from the active equipment, nearby factory noise will dominate the production.

We take into account installation distance, orientation, mounting type, cable routing, fan noise, and reflections from close walls, as well as the influence of enclosures membranes.

If better acoustic isolation or location-specific investigation is required, one may consider a multi-channel setup.

In summary, more channels lead to greater data acquisition/encryption rate, higher processing speed, more memory consumption, and greater power needs. The solution is chosen based on the specific problem and not only on the overall number of possible sensors.

Audio Capture and Signal Processing Pipeline

The embedded firmware uses a controlled audio-processing pipeline. Raw microphone samples are captured into buffers using an efficient transfer method, then processed in short time windows. The device does not need to store continuous audio in normal operation.

The standard processing flow includes:

• Microphone initialisation and audio-buffer capture
• DC removal or signal normalisation where required
• Band-pass filtering to focus on useful frequency content
• Windowing of the audio frame
• Fast Fourier Transform or filter-bank processing
• Feature generation, commonly log-mel spectrogram or MFCC-style features
• Quantised neural-network inference
• Confidence-score evaluation and event decision
• Local event storage, timestamping, and communication
• Return to low-power idle or the next monitoring interval

Because of its ability to represent changing sound waves in a form that is suitable for compact machine learning classifiers, mel-frequency features and similar forms of time-frequency representation are among the most frequently employed features.

The final choice of features is determined by the nature of the sounds that the system needs to detect.

A high-frequency noise resembling a leak, the noise from a slowly rotating gearbox, and the noise of a regularly clicking valve do not require the same frame rate, frame length or range of filtering.

The model is trained off-device using labelled recordings, being afterwards translated into the target MCU form at the prescribed efficiency level.

The inference processing operates using quantized model variations and special memory limitations. Ambiq's neuralSPOT software can be used for the implementation of edge AI on compatible Apollo platforms while being tested with the real-life audio data and the customer's hardware configuration.

Dataset Development and Classification Model

Audio classification quality begins with the dataset. A model trained only with clean recordings from one machine is unlikely to perform consistently on a production floor. Our data-collection plan captures normal and abnormal operating conditions across meaningful variation, including:

• Different units of the same machine model
• Different motor speeds, loads, and duty cycles
• Start-up, steady-state, and shutdown operation
• Near-field and installed-device microphone positions
• Background conversations, alarms, fans, forklifts, and adjacent machinery
• Room echo, metal-panel reflections, and enclosure effects
• Temperature and humidity variation where relevant
• Early, moderate, and severe examples of the selected fault signature

Every recording is annotated with information like asset, working condition, location of microphone, known event type and capturing date. The recordings are split into groups such as training, validation and hold-out tests based on each machine wherever applicable.

This serves to eliminate the false confidence resulting from the model seeing almost identical recordings during training and tests of the model.

The model can take the form of a small convolution neural networks, a temporal classifier or an anomaly-detection architecture depending on if labelled failures exist.

In most cases, anomaly detection proves useful in many industries while supervised classifiers perform better in case the different sounds are already known and repeated.

Noise Testing and Field Validation

Just a model measurement in a laboratory is insufficient for an industrial acoustic device.

To make sure of the performance of our system, we put the actual detector through rigors of testing in real-life situations and measure all relevant figures: false alarms, missed calls, latency for alerts, power performance, radio reliability, and installation sensitivity.

In regards to noise testing, we conduct our recordings under controlled conditions with some live experiments which include other equipment working nearby, air bursts, movements of a bulldozer, starting up a machine, HVAC noise, human speak, impact sounds, etc.

The purpose is to understand what the product can distinguish and when the installation should be done differently.

Event thresholds are selected with the operational cost of false alerts and missed alerts in mind. A maintenance team may accept a small number of review alerts for a high-risk asset, while a high-volume production line may require a more conservative threshold to avoid alarm fatigue.

The device can report a confidence score and a short feature summary instead of raw audio, enabling operators to review patterns while maintaining a privacy-conscious design.

Edge AI Deployment and Connectivity

The Apollo510 carries out core classification at the edge, thus preventing the need for audio streaming to the cloud and lowering the dependence on communication networks, data transfer expenditure, and enabling faster decision making.

The Apollo510 will send only relevant events, health indicators, battery and supply status, version of the model, and diagnostics.

Connectivity could occur through BLE with an app or gateway located nearby, or via an external wireless network or clouds platforms, depending on the installation.

The backend platform will allow for asset registration, event history, rule set for alerts, device functioning, user roles, maintenance issues.

Firmware is designed with watchdog protection, bounded communication retries, secure provisioning, encrypted device communication where supported, and controlled OTA update procedures. Model and firmware updates should be versioned, tested, and rolled out in a staged manner so that a field device can recover safely from a failed update.