Audible Noise-Based Hardware System for Acoustic Monitoring in Wind Turbines

Abstract

This paper presents a robust hardware system designed for future detection of faults in wind turbines by analyzing audible noise signals. Predictive maintenance strategies have increasingly relied on acoustic monitoring as a non-invasive method for identifying anomalies that may indicate component wear, misalignment, or impending mechanical failures. The proposed device captures and processes sound signals in real-time using strategically positioned microphones, ensuring high-fidelity data acquisition without interfering with turbine operation. Signal processing techniques are applied to extract relevant acoustic features, facilitating future identification of abnormal sound patterns that may indicate mechanical issues. The system’s effectiveness was validated through rigorous field tests, demonstrating its capability to enhance the reliability and efficiency of wind turbine maintenance. Experimental results showed an average transmission latency of 131.8 milliseconds, validating the system’s applicability for near real-time audible noise monitoring in wind turbines operating under limited connectivity conditions.

1. Introduction

Wind energy is key in the global transition to sustainable power generation. However, wind turbines operate under harsh environmental conditions, leading to potential failures. Ensuring the reliability and efficiency of these systems requires predictive maintenance strategies that can detect early-stage anomalies and prevent unexpected downtime [1].

Rotating machinery, such as wind turbine generators and gearboxes, produces characteristic sound patterns during regular operation. However, when components experience wear, misalignment, or insufficient lubrication, these sound patterns change, signaling potential mechanical issues [2]. Therefore, integrating a device capable of capturing and analyzing these sound variations in a non-invasive manner becomes a valuable solution for predictive maintenance.

Traditional fault detection techniques rely mainly on vibration analysis, where sensors are attached to rotating components to monitor structural integrity [3,4]. While effective, these methods can be costly and impractical in specific scenarios, when turbines are located in remote or offshore areas [5].

An alternative approach is using acoustic analysis, which enables non-invasive monitoring of rotating machinery. Various signal processing techniques (such as Short-Time Fourier Transform (STFT), Envelope Analysis (EA), and Fast Fourier Transform (FFT)) can be applied to detect and classify audible anomalies [3,4]. However, the effectiveness of these techniques depends significantly on the quality of the collected acoustic data. Then, taking these aspects into account, a well-designed hardware system that ensures high-fidelity audio capture, robust data transmission, and efficient signal processing is essential for reliable fault detection.

1.1. Related Work and State of the Art

The current turbine health monitoring methods in literature include vibration sensors, temperature sensors, and acoustic detectors face several challenges like high complexity to integrate various sensor types; moderate to elevated costs of implementation depending on the range of parameters captured; and also difficulties of integration, many sensors could require data management solutions [6]. While traditional sensors require precise installation at specific locations of the wind turbine—such as for blade tip monitoring [7]—sound-based detection operates with a single, highly sensitive sensor that can be flexibly positioned anywhere inside the nacelle.

Then, the monitoring of audible anomalies in rotating machinery has become an increasingly relevant research topic in recent years. This innovative approach provides an effective solution for predictive maintenance, enabling faster and more accurate decision-making. By employing acoustic signal analysis, it is possible to identify patterns and anomalies that indicate imminent failures, allowing preventive interventions before severe damage occurs [5].

Since this is a non-invasive technique, acoustic monitoring offers greater accessibility to complex machinery. Studies such as those conducted by Altaf et al. [5] demonstrate that traditional monitoring methods (such as vibration and acoustic emission analysis for machine components like bearings) often face challenges in complex environments where sensor installation may be costly or impractical.

By utilizing a single microphone to capture the machine’s emitted sounds and applying statistical analysis and machine learning techniques to classify different fault types, the monitoring possibilities for rotating machinery are expanded. This methodology suggests that audio-based analysis can be a viable and cost-effective solution for industrial predictive maintenance, improving operational efficiency and reducing maintenance-related costs [4].

The work presented by Saimurugan and Nithesh [4] extracts audio signal features through statistical methods and histogram analysis. In this context, the most relevant sound characteristics are identified using a decision tree algorithm and fed into a classifier based on an artificial neural network.

In feature extraction, additional advances can be made by performing pattern classification using image-based approaches with artificial intelligence. The study conducted by Zaheer et al. [8] demonstrated that, beyond directly analyzing audio data, it is possible to classify sound signals using spectrogram images. This approach leverages deep learning techniques, broadening the possibilities for analyzing and interpreting acoustic data. The research highlights that integrating visual techniques enhances the classification of sound signals, providing a deeper and more precise understanding of the patterns present in audio data.

Additionally, implementing cost-effective devices for fault detection is always a key research focus. Studies such as Vaimann et al. [9] showed that even smartphones can be used effectively to detect faults in induction machines by recording audible noise, achieving an impressive 96.4% fault detection rate using a simple neural network. The study also suggests automating the diagnostic process for electric machines, streamlining and accelerating predictive maintenance tasks.

In summary, this paper builds upon previous research in early fault detection for rotating machinery through acoustic signal analysis, representing a significant advancement in predictive maintenance. While works such as those from Saimurugan and Nithesh [4], Altaf et al. [5], and Zaheer et al. [8] explore different approaches and demonstrate the effectiveness of sound signal analysis for fault detection, this work distinguishes itself by emphasizing automation and practical implementation, as proposed in Vaimann et al. [9]. Integrating machine learning techniques with accessible and cost-effective devices enhances the feasibility and applicability of the proposed solution in industrial settings.

1.2. Objectives and Main Contributions

This work presents the development of an audible noise-based hardware system for future detection of faults in wind turbines. The device captures and processes acoustic signals using strategically positioned microphones, applying advanced signal processing techniques to identify anomalies.

The key contributions of this invention are:

• Development of a robust and portable hardware system for real-time acoustic monitoring in wind turbines;
• Implementation of an adaptive threshold method to optimize the detection of abnormal sound patterns;
• Validation of the system through field experiments, demonstrating its effectiveness and readiness for future integration with fault detection techniques.

2. Background

This section presents the theoretical foundation necessary to understand the development of the proposed system, providing a solid basis for its implementation. The discussion covers fundamental concepts related to audio signal acquisition, which is essential for ensuring the quality and effectiveness of collected data. The principles of microphone operation, types of directional patterns, and frequency response characteristics are introduced to support the selection of an appropriate microphone for the system.

Additionally, this section addresses concepts related to embedded software development, including using Application Programming Interfaces (APIs) for data communication and integration. Parallel processing techniques are also discussed, as they are critical in real-time data acquisition and processing. Finally, the principles of remote access are explained, highlighting its importance for maintaining and monitoring the device efficiently.

2.1. Microphones

Since microphones are the primary sensors for capturing sound signals emitted by rotating machinery, understanding their operation and characteristics is crucial to ensure optimal system performance. The choice of an appropriate microphone directly influences the quality of sound capture and, consequently, the fault detection accuracy.

A microphone is a transducer that converts sound waves into electrical signals. Various microphones exist, each designed for specific applications, ranging from studio recordings to environmental noise monitoring [10]. The key factors differentiating microphones include their operating principle, directional pickup pattern, and frequency response.

2.1.1. Operating Principle

A microphone’s operating principle is how it converts acoustic sound into an electrical signal [10]. The most common types are dynamic microphones (which operate through magnetic induction) and condenser microphones (which function electrostatically) [11]. For this project, the condenser microphone was chosen due to its ability to capture subtle details in a broader frequency range. In contrast, while robust, dynamic microphones tend to have a limited frequency response and lower sensitivity.

The condenser microphone operates similarly to a capacitor, consisting of a setup with fixed and moving plates, which act as a diaphragm, as illustrated in Figure 1:

When a sound wave reaches the moving plate (flexible), the distance between the plates varies minimally. As a result, the voltage between these plates also changes. Due to this characteristic, this type of microphone is often referred to as a capacitive microphone [10].

The sensitivity of condenser microphones is considered high due to the lightness and flexibility of the diaphragm used. This allows the microphone to respond to low-intensity sounds and capture finer details of the sound spectrum. Furthermore, the microphone does not emphasize or attenuate specific frequencies, providing faithful sound recording [10].

2.1.2. Pickup Patterns

In addition to the operating principle, microphones are also classified according to their pickup patterns, which define the area where they effectively capture sound signals [12]. Several pickup patterns exist, each with characteristics tailored to specific applications.

In this work, two types of microphone designs were selected: omnidirectional and cardioid. Omnidirectional microphones capture sound uniformly from all directions, offering full 360-degree coverage around their axis. They typically feature spherical diaphragms or symmetrically circular capsules, enabling a consistent response to sound pressure regardless of the source’s direction. In contrast, cardioid microphones (named after their heart-shaped polar pattern) are optimized to capture sound primarily from the front, while significantly attenuating sounds from the sides and rear. This directional sensitivity makes them particularly suitable for focused audio acquisition in noisy environments [13].

2.1.3. Frequency Response

The frequency response of a microphone is one of its most essential characteristics and is typically expressed in decibels (dB). Most microphones cover the human-audible range (from 20 Hz up to 20 KHz) [12]. Ideally, a microphone should have a flat frequency response, meaning it reproduces frequencies uniformly without significant variations or attenuation across the sound spectrum. This ensures accurate and high-fidelity audio capture [13].

Furthermore, the tests were conducted at a wind farm located in a remote area with limited internet infrastructure. This scenario imposed restrictions on the available bandwidth, requiring an efficient compression strategy to ensure the delivery of data to the monitoring server without significant losses.

Although frequencies outside the human audible spectrum (20 Hz–20 kHz) could, in theory, capture additional acoustic information, the use of sensors operating in these ranges would require high-cost components that are less available in the market. One of the project’s premises is to develop a low-cost acoustic monitoring solution based on widely available components.

2.2. Parallel Processing

For the system to efficiently capture audio from multiple microphones, process information, and manage all monitoring tasks simultaneously, parallel processing is required. However, a process in computing is defined as an instance of a program running on a computer. It includes the program’s code, execution state, and associated resources such as memory, registers, and variables. Each process operates independently, managing its memory and execution space [14].

Modern operating systems support multithreading, where multiple execution threads run within the same process. These threads share the same memory and resources, enabling efficient real-time data processing [15]. Multithreading applications improve performance by allowing different tasks, such as audio capture and remote communication, to execute simultaneously [16].

2.3. Remote Access

Remote access is essential to ensure proper system maintenance and updates. One of the most effective ways to achieve this in Linux-based systems is through Secure SHell (SSH), a protocol that enables secure remote communication, which uses strong encryption algorithms to protect transmitted data from unauthorized access [17]. Furthermore, tunneling techniques can be employed for devices located behind network firewalls to establish a secure SSH connection. This method redirects TCP/IP connections through a SSH tunnel, allowing remote management without exposing the device to security risks [17].

3. Hardware Architecture

The hardware development was structured into four main phases, planned and executed to ensure the system’s functionality and efficiency:

• Component selection: Identifying and choosing the most suitable hardware components;
• Assembly: Integrating selected components into a functional prototype;
• Software integration: Implementing embedded software for data acquisition and communication;
• Testing and validation: Conducting laboratory and field tests to ensure system reliability.

Each phase was designed to reach the required performance, durability, and operational robustness, ensuring effective real-time monitoring of rotating machinery.

Based on the proposed hardware architecture, Figure 2 illustrates the installation place of the device within the wind turbine, which is a Suzlon S9x model, featuring a rotor diameter between 95 and 97 m and a rated power capacity of 2.1 MW:

3.1. Project Requirements

To define the system architecture and select appropriate components, several design constraints were established:

• The device must operate on 110 or 220 V AC power;
• It must be dust and particle-resistant, allowing it to function inside a wind turbine;
• The system must support Ethernet, Wi-Fi, or 4 G mobile connectivity;
• It must incorporate two microphones: an external for primary sound capture and an internal for redundancy;
• Microphones must be positioned close to the noise source for optimal signal acquisition;
• The system must include local storage to buffer data during network failures;
• The device must be fully autonomous, requiring no human intervention.

Based on these requirements, the following hardware components were chosen after extensive market research:

• Raspberry Pi 4B (4 GB RAM): An embedded computing platform running Raspberry Pi OS (Linux-based). Equipped with a quad-core processor, it can process real-time acoustic data while supporting remote access capabilities;
• Cooling System: The Raspberry Pi 4 generates significant heat, impacting system stability. To mitigate overheating, an aluminum enclosure with dual cooling fans was selected;
• ARCANO AM-BLACK-1N (External Microphone): A cardioid condenser microphone with a flat frequency response (from 20 Hz up to 20 KHz) designed to minimize background noise and capture directional acoustic signals;
• BOYA BY-M1S (Internal Microphone): An omnidirectional condenser microphone (from 20 Hz up to 20 KHz) installed inside the enclosure to provide redundancy in case of external microphone failure;
• Universal Serial Bus (USB) Sound Adapter: The BOYA microphone uses a P3 connector, which is not directly compatible with the Raspberry Pi. A USB audio interface was incorporated to ensure proper signal conversion;
• MicroSD Card (64GB, Class 10 A2 U3): Functions as the primary storage unit, housing the operating system, software, and recorded data;
• 4 G LTE Modem: Enables wireless communication, allowing data to be transmitted remotely;
• 5 V 3 A Power Supply: Ensures stable power delivery to the system;
• Sealed Enclosure: A weatherproof enclosure protects the system from dust, moisture, and external contaminants while providing adequate ventilation.

3.2. Hardware Integration

The hardware integration is directly connected to its architecture. Then, it was developed to efficiently integrate power management, data acquisition, and communication components. A simplified circuit schematic illustrating the system’s electrical connections is shown in Figure 3:

The power distribution system ensures that the Raspberry Pi, microphones, and wireless module receive a stable power supply, preventing voltage fluctuations that could affect system performance. Then, to ensure adequate component placement, a custom enclosure was designed, providing spatial organization of internal hardware components, as shown in Figure 4a–c:

Figure 5 presents the final assembled system, highlighting the external microphone, protective casing, and power connections:

3.3. Embedded Software and Communication Protocols

The system’s firmware was developed in Python 3.11.2 and optimized for real-time execution on a Linux-based embedded system. The software is responsible for:

• Continuous audio recording using a multi-threaded architecture;
• Local storage management, ensuring data integrity;
• Real-time data transmission through a REST api;
• Remote system monitoring and maintenance via SSH and secure tunnels.

The system supports multiple network protocols to enhance data reliability and connectivity, ensuring data is transmitted securely, even in low-bandwidth environments.

4. Software Architecture

With the device adequately assembled, its components can be integrated with the application software. The system consists of a program that manages all audio capture and transmission tasks and executes scheduled tasks. An internal routine is responsible for periodically establishing a connection with a remote access server.

4.1. System Overview

The system architecture is structured into two routines that operate simultaneously, leveraging multithreading resources: audio recording and scheduled task execution. Figure 6 illustrates an overview of the architecture, which will be detailed in the following sections:

The software was developed to run on a Linux-based Operating System (OS), specifically Raspberry Pi OS Lite. This choice is justified by the fact that this OS was created by the same company responsible for the Raspberry Pi mini-computer. As a result, Raspberry Pi OS Lite is optimized to effectively meet the hardware’s specific requirements, providing adequate performance and a smoother user experience.

The programming language chosen for developing the main program (which includes the audio recording routines and scheduled task execution) was Python. This choice was made due to Python’s versatility and its ease of integration between hardware and embedded software. Furthermore, Python offers a wide variety of libraries and robust documentation, facilitating the development and implementation of complex functionalities.

Remote system access is performed through a public and open-source repository known as Chisel [18]. This tool allows the creation of TCP/IP tunnels, enabling connections via the HTTP protocol with the security of SSH encryption. With this configuration, it is possible to manage both the client and the server and expose the necessary ports for remote SSH access to the device.

The main program and remote access are automated using a service natively available in the operating system, which leverages the systemd feature. This feature manages processes and services from system startup to shutdown. Thus, every time the device is powered on, the monitoring system is automatically activated, ensuring continuous execution without manual intervention.

4.2. Audio Recording Routine

The audio recording routine encompasses several methods that ensure automated and independent audio capture and handling. Before starting this routine, the first task consists of mapping the USB ports of the Raspberry Pi and identifying the connected microphones. If one or more microphones are connected, the routine is initialized, creating independent recording, storage, and transmission methods for each microphone. Suppose a microphone is later connected or disconnected. In that case, the system will detect it and take the necessary action, either terminating its recording session or starting the recording routine for the new device. Figure 7 illustrates the flowchart of this process:

4.2.1. Recording Routine

The recording routine is responsible for processing audio data in real-time, generally operating at a sampling rate of 44,100 Hz, although this rate may vary depending on the microphone’s specifications. Raw audio data is collected in small packets (chunks) instead of handling the entire audio stream at once. By splitting audio into chunks, the system can process audio in regular intervals rather than waiting for the whole recording to complete. This approach ensures more refined control and greater accuracy in data handling, resulting in more efficient processing.

The microphones are programmed to capture and record audio synchronously. Once the first microphone begins recording, all other microphones connected to the system will start simultaneously. This strategy ensures precise synchronization of recordings, guaranteeing that all audio sources remain aligned.

Additionally, a recording threshold calculation was implemented to prevent unnecessary recordings, optimize audio capture, and ensure that only relevant sounds are stored for anomaly analysis. The interest lies in capturing machine operating sounds while discarding recordings when the machine is inactive or under maintenance. This filtering approach optimizes storage and reduces network bandwidth consumption.

The recording threshold method works by calculating the absolute mean amplitude of the audio signal within a specific time window, which is then compared to a predefined minimum value. If, during a given period, the absolute mean amplitude exceeds the threshold, audio recording is initiated. Conversely, if the recording is already in progress and the absolute mean amplitude falls below the threshold, the recording is stopped.

The flowchart shown in Figure 8 clearly illustrates the detailed operation of the recording process. The red block marks the starting point of the workflow. The process begins with the microphones capturing ambient sound in small data packets, allowing for pre-processing before storage:

By default, a time window is selected to accumulate captured audio samples and compute their absolute mean amplitude. Once a predefined number of samples is collected, the absolute mean amplitude is calculated, serving as a reference for threshold evaluation.

After computing the mean amplitude, the result is compared to the predefined threshold value. If the mean does not exceed the threshold within the time window, the microphone recording flag is checked to determine whether the recording is active (True) or inactive (False).

If the recording is inactive, the audio samples accumulated in the time window are stored in a circular buffer, allowing the system to capture the startup moment of the machine, even if the threshold was not initially exceeded. The process then returns to the starting point, repeating the cycle.

On the other hand, if the mean amplitude exceeds the threshold, the audio samples are added to the recording buffer, and recording is initiated. If the system is already recording, the samples are continuously added until reaching a predefined maximum recording duration, after which the audio is stored. Thus, the values for these parameters are user-configurable, allowing fine-tuning of: Threshold level (ranging from 0 to 1); Circular buffer duration (expressed in seconds); Total recording time (also in seconds).

4.2.2. Recording Threshold Calculation

The approach that uses a recording threshold to optimize audio capture by ensuring that only valid sound conditions are recorded is illustrated in Figure 9. A mathematical analysis based on standard deviations is performed to determine an appropriate value for this threshold, as detailed in this section:

The waveform of an audio signal is a graphical representation of the sound pressure level over time, where the distance above or below the centerline indicates the signal amplitude level. This representation can be compared to a pure sine wave, as illustrated in Figure 10 [19]. In general, the arithmetic mean of the waveform of an audio signal tends to approach zero, since positive and negative oscillations balance each other out over time:

To define an appropriate threshold value and understand the amplitude distribution of the audio signals when the rotating machine is either in operation or not, the proposed method consists of calculating the Probability Density Function (PDF) for each state and identifying an inflection point in the curve obtained by subtracting the two distributions. Although the arithmetic mean of the waveform in both states tends to zero, the standard deviation differs for each state, which becomes the basis for the calculation.

The PDF of a Gaussian distribution, denoted as N($\mu$, $\sigma$), is given by:

$$f\left(x\right|\mu ,\sigma )={\displaystyle \frac{1}{\sigma \sqrt{2\pi }}}{e}^{{\displaystyle \frac{-1}{2}}{\left({\displaystyle \frac{x-\mu }{\sigma }}\right)}^2},$$

(1)

where x is the respective threshold for a standard deviation ($\sigma$) and the mean amplitude value of the audio signal ($\mu$).

When the means of both distributions are equal, the equation that determines the point at which the two PDF functions intersect (i.e., where $(f_1\left(x\right)=f_2\left(x\right))$) can be expressed as:

$${\displaystyle \frac{1}{{\sigma }_1\sqrt{2\pi }}}{e}^{{\displaystyle \frac{-1}{2}}{\left({\displaystyle \frac{x-\mu }{{\sigma }_1}}\right)}^2}={\displaystyle \frac{1}{{\sigma }_2\sqrt{2\pi }}}{e}^{{\displaystyle \frac{-1}{2}}{\left({\displaystyle \frac{x-\mu }{{\sigma }_2}}\right)}^2},$$

(2)

where ${\sigma }_1$ is the standard deviation when the machine is off, and ${\sigma }_2$ is the standard deviation when the machine is operating.

By simplifying Equation (2), the equation used to calculate the recording threshold is given by:

$$x=\mu \pm \sqrt{{\displaystyle \frac{2{\sigma }_1^2{\sigma }_2^{2}ln\left(\frac{{\sigma }_2}{{\sigma }_1}\right)}{{\sigma }_2^2-{\sigma }_1^2}}}.$$

(3)

Thus, by comparing the amplitude distributions in both operational and idle states, it is possible to determine an inflection point that minimizes the recording of undesired audio.

4.2.3. Storage Method

The storage method uses a queue to manage audio files that have completed the recording process and are ready to be saved. The queue is released only when there are available audio files; otherwise, it remains blocked, preventing the method from running. This strategy avoids unnecessary system resource consumption, ensuring more efficient use of memory and processing. This behavior is a native feature of the queues implemented with the Multiprocessing library in Python.

Once one or more audio files are added to the queue, the method is unlocked, allowing the first inserted audio to be removed. Next, the available space on the memory card is checked. If the storage reaches a predefined limit, the oldest audio is deleted to make room for the new file to be saved. After this verification, if there is enough space, the audio is saved locally and added to the upload queue. The flowchart illustrating this storage method is shown in Figure 11:

4.2.4. Upload Method

Similar to the storage method, the audio upload process also uses a queue to receive all audio files previously saved by the storage queue, which are then sent to the cloud server. This enables more efficient control over the files to be sent, allowing the system to operate in an optimized manner.

As soon as the audio is ready for upload, it is removed from the queue, and the interaction process with the audio ingestion api begins. During this step, a token is obtained to authenticate the user credentials with the api server. Additionally, a mechanism is implemented to perform a series of retry attempts before flagging any transmission error, especially in cases of internet connection failures. This means that if the connection is interrupted during the upload process, the method will continue attempting to reconnect until the audio is successfully sent, minimizing the risk of data loss due to temporary connectivity issues. This process is illustrated in the flowchart shown in Figure 12:

4.3. Scheduled Task Routine

The scheduled task routine’s primary goal is the establishment of communication between the user and the device, enabling efficient maintenance and ensuring that the user can perform updates and maintain complete remote control of the device. For this purpose, predefined instructions are created and, through commands sent via the api, the device is able to interpret these instructions and execute a series of defined tasks.

As with data ingestion, the task api is a closed interface and proprietary to the company Robotictech. For this reason, only the consumption of this interface will be described here. Among the available tasks, the following stand out:

• System reboot;
• Software update;
• Start/stop recording from a specific microphone;
• Start/stop sending audio from a specific microphone;
• Clear memory;
• Request audio files that were not sent to the cloud server.

Each task header contains three essential pieces of information: the action, status, and creation date. The action refers to the purpose of the task, characterized by a unique name that allows the device to interpret and execute it correctly. The status is fundamental to manage the task’s progress and may assume one of four values: “CREATED”, for newly created functions that need to be executed; “EXECUTING”, when the task is currently being executed; “EXECUTED”, when the task has been completed successfully; and “FAILED”, when the task execution was unsuccessful. Lastly, the creation date is a crucial element that allows tasks to be sorted, enabling more efficient organization, especially when multiple tasks are queued for execution.

In this routine, a “GET” request is made to the task api endpoint at regular intervals. If the response contains one or more tasks, each of them goes through a series of validation checks to assess their integrity and determine whether they are.

4.4. Remote Access Routine

The open-source tool Chisel was utilized to establish remote access between the device and the local computer. This tool provides a reverse network tunnel (also known as a reverse tunnel), enabling communication between two network points. When applied for remote SSH access, Chisel connects the device to a cloud-based relay server. In this implementation, an Amazon Web Services (AWS) EC2 instance was used as the remote access server due to its ease of deployment.

Server-Side Configuration:

• Create an aws EC2 instance (type t2.micro) with Ubuntu Server as the OS;
• Configure the security group to allow traffic through the necessary ports;
• Start the Chisel server, configuring authentication and network listening.

Client-Side Configuration (Device Side):

• Enable SSH on the Raspberry Pi through the system interface settings;
• Configure the Chisel client to establish a tunnel to the aws server;
• Automatically start Chisel on boot using systemd, ensuring persistent remote access.

This setup allows the Raspberry Pi to be accessed from anywhere using the aws instance’s public IP and the designated SSH port.

5. Experiments and Results

During the literature review, it was identified that there is a scarcity of works that present a complete and embedded solution for audio capture, data transmission, and automated command execution in industrial or remote monitoring environments. The proposal presented in this work differs from solutions based solely on audio capture, primarily due to its independence from commercial platforms and focus on embedded automation.

Besides, the work that presented some similarity was that of Altaf et al. [5], which uses a smartphone for audio capture with a sole focus on fault detection in induction machines. However, this work relies on a commercial device (smartphone) and does not encompass task automation or continuous embedded data transmission, as is the case in the proposed system.

Then, a series of tests were conducted under different scenarios to assess the device’s robustness. This approach allows the identification of the hardware’s strengths and weaknesses and provides a deeper understanding of its performance under diverse operating conditions, highlighting areas that may require improvement.

The first test evaluates the device’s behavior under unstable Internet connection conditions, which are especially relevant since the project is intended to rely on mobile networks that offer extended coverage in both urban and remote areas. This analysis helps verify the system’s effectiveness under many connectivity scenarios.

The second test observes the device’s behavior when the power supply is abruptly interrupted, simulating potential field power outages. This analysis assesses the performance of the system service responsible for automatically restarting it and evaluates data integrity and operational recovery without functional compromise.

Lastly, the third and fourth tests involve the installation and operation of the system on a wind turbine in collaboration with the company Robotictech. This test aims to evaluate real-world performance, allowing deeper analysis of operational conditions in the future. It helps reveal the challenges the device faces in environments where temperature fluctuations, external interference, and site-specific factors can directly impact functionality.

5.1. Scenario 1: Internet Connection Test

The objective of this first test is to observe the device’s behavior under unstable Internet conditions, in order to evaluate the functionality of the audio upload queue, which manages data transmission, and the scheduled task routine, performing user-defined actions at specific times.

It is expected that, during connection outages, audio files will be stored in the upload queue. Once the connection is reestablished, these audio files should be transmitted in the correct order, preserving the sequence of information. Additionally, scheduled tasks should accumulate in the server’s task array, as the device will not be updating each task’s status. When connectivity is restored, the device should retrieve this array and execute each task in order of creation.

To that end, audio was recorded in an uncompressed format, using Waveform Audio File (WAV). This results in relatively large file sizes, which allows for testing the robustness of data transmission. During the tests, the Internet connection was manually turned off on multiple occasions to simulate real-world connection drops.

Initially, the device was turned on and kept operating for one hour while continuously recording. After that, the Internet connection was disabled and restored only two hours later. In a second test, the device was started without an Internet connection and reconnected after two hours to observe its behavior in this scenario.

In a third instance, the device was powered on without an Internet connection. It remained in that state until the local storage reached full capacity, resulting in the deletion of the oldest audio files. A 64 GB memory card was used, providing adequate storage, with each audio file averaging 2.7 MB. Additionally, a 5 GB safety margin was reserved to maintain OS stability and avoid memory-related failures.

Results and Discussion

In the first test, once the Internet connection was lost, audio files were stored only locally, and the upload queue began accumulating files that were pending transmission. The scheduled task routine could no longer process new requests, causing the server-side task array to grow. Moreover, remote access was immediately interrupted, making external interaction with the device impossible.

After reconnecting to the Internet, all pending audio files were successfully transmitted. The accumulated tasks on the server were processed one by one, allowing system operations to return to normal. Finally, remote access was restored, enabling external interaction again.

In the second test, the device was powered on with no Internet connection. Audio files were recorded and saved locally but not uploaded, accumulating in the upload queue. During this time, the task routine failed to process new commands, and remote access remained unavailable.

After two hours, the Internet connection was restored. At this point, the audio files were transmitted in the exact order they had been queued. The scheduled tasks were executed and updated sequentially, according to their creation time. Remote access was also successfully reestablished.

In the third test, the 64 GB memory card provided 62 GB of usable space, of which 7 GB was reserved for the OS. An additional 5 GB was allocated as a safety margin to avoid system issues related to memory shortages. This left 50 GB for the monitoring software and recorded audio storage.

At the end of the test, a total of 19,625 audio files were stored, representing recordings from both the internal and external microphones. This storage capacity allows for approximately 35 days of continuous local recording, considering an average size of 2.7 MB per audio and 288 files per day per microphone. This setup ensures uninterrupted data collection even without Internet access.

In summary, after repeating this methodology multiple times, the device performed as expected. Internet connection proved to be a critical factor for the system’s proper operation. However, the use of local storage measures enabled greater system usability and continuity even in unstable connectivity scenarios.

5.2. Scenario 2: Power Loss Test

The goal of the second test is to analyze the device’s behavior when the circuit experiences power instability. This focuses on the operation of the services for each routine created under the systemd environment in the OS, which is responsible for automatically initializing the monitoring and remote access systems when the device is powered on.

It is expected that, when the power supply is suddenly interrupted, audio recording will stop and the device will shut down. Upon restoring power, the services responsible for the monitoring and remote access routines should start automatically, and the system should resume regular operation.

Initially, the device was shut down while operating normally, with all microphones recording and a stable Internet connection. In a second test, the Internet connection was turned off to allow the upload queue to accumulate audio files. After that, the device was powered off to observe its behavior when both conditions coincided.

Results and Discussion

After performing the first test, in which the device was operating normally, the behavior observed was as expected. Audio recording, task routines, and remote access were immediately interrupted, and the device remained inactive. Upon power restoration, the system rebooted, and all services were correctly initialized. Audio recording resumed, the task routine restarted, and remote access became available again.

Furthermore, it was observed that when the device was powered off, the audio being recorded (if it had not yet met the threshold criteria) was discarded. This occurs because the system only stores audio after specific criteria are met, such as a minimum amplitude or recording duration.

In the second test, each microphone’s upload queue was allowed to accumulate 50 recordings before the power was cut. Once this goal was reached, the circuit was shut down. Upon restoring power and the Internet connection, the system resumed regular operation. The unsent audio files remained stored locally in a specific folder for unsent recordings. These files were then reinserted into the upload queue and successfully transmitted. All 50 audio files per microphone were sent without issues.

In conclusion, the tests demonstrated that the device performs efficiently under the imposed conditions. Audio recording, task routines, and remote access behaved as expected. However, one critical point is the loss of audio that was being recorded at the time of shutdown, which could potentially be handled differently. In addition, the system’s ability to reintegrate locally stored files into the upload queue after power restoration and Internet reconnection demonstrated the device’s resilience.

5.3. Scenario 3: Field Test 1

For the third scenario, the device was installed inside the wind turbine nacelle. The device housing was mounted on a structure near the power source, while the external microphone was installed below the platform level, as shown in Figure 13. The objective is to test the device in real field conditions for future identification of potential problems:

The device is expected to be exposed to various conditions, ranging from continuous lack of Internet connection to unexpected shutdowns due to turbine maintenance. Thus, the device must face and overcome challenges posed by such adverse situations. In addition, metrics such as data usage and audio transmission volume were logged to assess system efficiency. These approaches enable a comprehensive evaluation of the device’s robustness, ensuring it can operate reliably in a dynamic and demanding environment.

Additionally, the wind turbine is assumed to be operating under ideal and realistic conditions, which serves as the ground truth reference for the analysis.

This test was conducted throughout September 2024. To optimize data usage and ensure adequate quality for post-processing, the audio format used was MP3 at 64 Kbps compression. Furthermore, the processed sample packet size was kept at 4% of the sampling size (1764 bits), with a target processing rate of 25 Hz, ensuring efficient data processing without system overload or data loss.

Table 1. Operating conditions for the field test scenario.

Condition	Value
Available RAM	4 GB
Available storage	60 GB
Audio recording duration	300 s
Average audio file size	2.3 MB
Recording threshold value	0.3
Sampling frequency	44,100 Hz
Internet connection type	4 G modem

lists all the conditions defined for the experiment:

Results and Discussion

The raw data collected during the field test period is critical for predictive analysis of rotating machines. Although this project did not involve post-processing for noise and anomaly detection, the quality of the recorded data is still essential. These data may serve as a valuable foundation for future analyses, enabling pattern detection and supporting maintenance planning.

Furthermore, following the continuous operation of the device in the field from 1 to 30 September 2024, the real-world dynamics of its performance were better understood beyond laboratory conditions. Overall, the device performed as expected, yielding the following insights:

• Average audio recordings per day: 508;
• Average daily data consumption: 1.2 GB;
• Total audio recordings sent in the month: 15,258;
• Total data consumption: 35.1 GB;
• Average Central Processing Unit (CPU) temperature: 50 ^∘C.

The average number of recordings was derived from both the internal and external microphones, indicating continuous operation during the entire test period. However, due to the configured recording threshold and frequent turbine maintenance (which required shutdowns), audio capture and transmission were reduced.

The device successfully connected to the Internet, but due to the remote location, the connection was unstable, with some interruptions lasting over 6 h. Nevertheless, thanks to the strategies for local memory usage and queue organization, the stored audio was transmitted once the connection was reestablished, resulting in a total data usage of 35.1 GB.

Furthermore, the average CPU temperature remained around 50 ^∘C, confirming the efficiency of the system’s heat dissipation solutions. During the test period, several refactorings of the codebase were required to optimize performance and improve the system’s structure. Initially, remote access was used to edit the necessary files directly. Later, the scheduled task routine was employed for a more automated update process.

Due to various turbine maintenance operations (from simple preventive actions to complex corrective procedures), there were moments when the turbine had to be shut down, also stopping the device. However, every time the power was restored, the device reconnected successfully and resumed its regular operation.

Figure 14 presents a comparison between the internal and external microphones, showing both the waveform (top) and spectrogram (bottom). These representations were captured while the turbine was running:

In the waveform, the vertical axis shows amplitude (from −1 to 1), whereas in the spectrogram, the vertical axis displays frequency range (0 to 16 kHz). The horizontal axis represents time (0 to 5 min) for both graphics. Brighter colors indicate more vigorous frequency intensity; darker colors represent weaker signals. Also, the internal microphone showed a balanced waveform and a spectrogram where some frequencies stand out with more intensity (lighter colors). The external microphone (being more sensitive and closer to the sound sources) presented a waveform with maximum amplitude throughout the entire signal. For the spectrogram, there was consistently high intensity across most frequencies (evidence with high noise levels caused by motors, ventilation systems, and the turbine itself).

5.4. Scenario 4: Field Test 2

The fourth scenario takes place in parallel with the third one, where its goal is to examine the different operational states of the wind turbine and identify patterns available for the future in its behavior.

It is expected that the recordings capture moments during turbine startup, shutdown, and various responses to fluctuations in wind power. Then, it will enable a detailed future analysis of the equipment’s operational conditions, allowing the identification of patterns and trends that may influence its efficiency and performance.

Results and Discussion

As expected, the device demonstrated the ability to accurately capture various operational states of the wind turbine, even under adverse conditions. Distinct spectral patterns, corresponding to different wind intensities, were identified.

Figure 15 presents a compilation of the recorded audio data, displayed as Mel-scaled spectrograms, allowing for a clear visualization of the predominant frequencies in each analyzed scenario:

Regarding the images above, Figure 15a shows the wind turbine operation under mild wind conditions, with a wind speed of approximately 6 m/s and a rotational speed of 1600 RPM, resulting in a more stable spectral profile. Figure 15b illustrates a scenario with stronger winds, reaching 8 m/s and 1800 RPM, showing a more complex spectrum with higher frequency density. Finally, Figure 15c depicts a transitional moment in which the wind turbine was gradually decelerated until a complete stop.

6. Conclusions

This work presented a significant advancement in the field of monitoring and predictive maintenance of rotating machinery through the development of a hardware system designed for audio data capture and transmission, with a focus on detecting anomalous noise patterns in such machines. In this way, from solid image processing techniques in the literature, it became possible to identify imminent failures, resulting in a significant reduction in maintenance costs and increased operational efficiency.

The device was built using readily available off-the-shelf components, eliminating the need for custom circuit board manufacturing. This approach reduced production costs and enhanced the product’s scalability. As a result, it was possible to meet the requirements of simplicity, robustness, and ease of handling and installation, making it a practical and accessible solution.

The embedded software was designed to be fully automated, removing the need for manual user interaction. Nevertheless, it offers flexibility by allowing the user to update specific parameters and criteria, making it a versatile and adaptable solution for different needs. Furthermore, the remote access functionality enabled continuous system inspection and monitoring.

The device’s robustness was tested under a variety of conditions, including both laboratory experiments and real-world field trials. These tests made it possible to identify the system’s main weaknesses and implement significant adjustments and improvements.

As quantitative data, in field tests conducted under limited connectivity conditions, the proposed system demonstrated reliable performance, achieving an average transmission latency of 131.8 ms from audio capture to delivery at the remote server. This result demonstrates that the system meets the performance requirements for continuous acoustic monitoring in near real-time, even under adverse network conditions, such as those found in wind farms and remote industrial areas. This enables future integration with intelligent fault detection systems. The use of compressed audio at 64 Kbps enabled efficient data transmission without perceptible loss of relevant sound information, reinforcing the solution’s suitability for low-bandwidth industrial scenarios.

Overall, the device proved to be a promising solution for monitoring and predictive maintenance of rotating machinery, due to its robustness, ease of integration, and non-invasive nature. In addition, the system’s automation, combined with the use of simple resources, enhanced its practicality, making it both accessible and adaptable to a wide range of operating conditions.

For future works, some main lines of development are envisioned: implementation of post-processing algorithms for fault identification and classification, development of a dashboard for visualizing post-processing analyses, and design of a Printed Circuit Board (PCB) to reduce the size of the hardware.