Development of audio control subsystem in intelligent acoustic prevention system for harmful animals

In addition to being affected by meteorological disasters and conventional pests and diseases, crops are also greatly harmed by animals such as voles, sparrows, hares, pheasants, and wild boars. Directly using the calls of natural enemies of harmful animals or the screams they make when they are captured to drive away harmful animals from crops (hereinafter referred to as sound control) can avoid the pollution of the water and soil environment caused by the use of chemical drugs and possible accidental injuries to humans and animals. It is easier to implement and has a better driving effect than other driving methods such as ultrasonic driving and water spraying. The existing commercial sound protection devices in China generally have the disadvantages of simple control mode, poor sound quality, small storage capacity, and inconvenient upgrade and expansion of sound protection audio files. The use of embedded technology to improve and enhance the various performance of sound protection devices has become one of the trends in the development of sound protection technology. The research group of the author proposed an intelligent sound prevention system for agricultural harmful animals. In order to ensure the reliability and optimal performance of the system design, two design schemes were adopted in the construction of its audio control subsystem, realizing audio control with large-capacity hot-swappable storage, high-fidelity audio output and multi-mode playback, and comparing the performance, implementation difficulty and cost of embedded solutions based on different hardware platforms.
1 Principle of intelligent sound prevention system
As shown in Figure 1, the structure of the intelligent sound prevention system is divided into three layers. The bottom layer is the detection node with pyroelectric sensors, which is responsible for detecting the location of harmful animals in the farmland; the middle layer is the actuator node, which is responsible for storing and playing sound prevention audio files; the upper layer is the main controller, which is responsible for monitoring the operation of the entire system. The various layers of the system communicate wirelessly. The main controller collects environmental information (such as temperature and light) at a regular interval, combines the geographical location of the farmland, crop types and other information, and queries the internal database to use the two most likely harmful animals at the time as the sound prevention target, and then sends it to the actuator node at a regular interval. The actuator node has two working modes: trigger and random. In trigger mode, after the detection node detects harmful animals, it sends a command to the nearest actuator node. The actuator node plays the corresponding audio file according to the most recently updated sound protection target. In random mode, the actuator node automatically plays the sound protection audio file according to the regularly updated sound protection target. Before each playback, an interval time is randomly generated within the time range determined by the working parameters, and the delay is performed according to it, so that different actuator nodes in the sound protection system have randomness when executing sound protection, thereby reducing the adaptability of harmful animals to the sound protection system.

The actuator node is composed of wireless communication module, audio control subsystem, speaker and power supply module. Except for the audio control subsystem, other functional modules are mature products.
The main function of the actuator node is completed by the audio control subsystem. Considering the realization of functions, it should include large-capacity high-fidelity digital audio signal storage, decoding output and multiple playback mode selection and control. In order to achieve high-fidelity sound quality requirements, the sampling rate of the sound protection audio signal is selected as 44 kHz, the sampling bit is determined to be 16 bits, and its storage format adopts the MP3 format that can better balance the compression ratio and sound quality; in order to facilitate the upgrade of the sound protection audio file, the storage device uses a hot-swappable SD card or USB flash drive.
The existing audio decoding schemes are hardware decoding and software decoding. Commonly used hardware decoding chips include ST's ST016 and SANYO's LC82310G, which are often used with a single-chip microcomputer to realize the control function. To facilitate development, some manufacturers have developed SoC chips that integrate hardware decoders with single-chip microcomputers and other peripheral devices, such as ATMEL's AT89C51SND1.
The software decoding solution is mainly built on the DSP platform and the ARM platform. The ARM platform can be used with an embedded operating system, which can better manage and support the underlying hardware devices. There are a large number of open source decoding software to choose from, and software transplantation is relatively easier than the DSP platform.
2 Construction and implementation of solution
1 2.1 Hardware composition and implementation of solution 1
Compared with the use of a separate hardware decoding chip with other control chips, the "single-chip microcomputer + hardware decoding" construction of the audio control subsystem has great advantages in circuit structure and development cost. AT89C51SND1 is one of the most used SoC chips in MP3 decoding applications. It is essentially a C51 microcontroller with an integrated DSP hardware decoder, providing device interfaces such as USB DEVICE and SPI, and 54 I/O ports for users to use. The hardware structure of the audio control subsystem based on AT89C51SND1 is shown in Figure 2.

As shown in Figure 2, AT89C51SND1 is connected to the wireless communication module through the RS-232 serial port, and uses a custom protocol to communicate with it to achieve wireless communication between the actuator node and the detection node and the master controller. Because AT89C51SND1 does not integrate a USB HOST interface, the USB interface chip CH375 is selected to read and write the USB flash drive. However, in actual tests, it was found that CH375 cannot recognize the USB flash drives produced by some manufacturers. Therefore, in order to ensure the reliability of storage, an SD card is selected as the storage medium. The reading and writing of the SD card are divided into SD and SPI modes, and AT89C51SND1 only provides an MMC interface and is not compatible with the SD mode, so the SPI mode is used to read and write the SD card. The AT89C51SND1 integrates an audio output interface, which can output the decoded audio data in PCM format or I2S format to the low-power audio digital-to-analog conversion chip PCM1770 of the subsequent stage. AT89C51SND1 is connected to the computer as a USB slave device through the USB DEVICE interface for burning application programs. AT89C51SND1 can also be connected to a dot-matrix LCD through an I/O port to output relevant information.
2.2 Software design of solution 1
Figure 3 is the software flow of solution 1 for the audio control subsystem. After power-on, the audio control subsystem first completes the detection and initialization of various peripheral devices (including SD card, DAC chip, LCD, etc.), and then enters the working cycle. First, the working mode variable is judged. If it is a trigger mode, it returns to redo the judgment; if it is a random mode, the random number generation subroutine is called to randomly generate a waiting time and delay the waiting, and then read the audio file specified by the sound protection target variable from the memory and decode and play it. During the entire working cycle, the audio control subsystem opens the serial port interrupt. When the serial port receives information from the wireless communication module, a serial port interrupt is generated. The interrupt handler judges the received information. If it is a sound protection command from the detection node and it is currently in the trigger working mode, it will play the corresponding audio file according to the most recently updated sound protection target, and then return an execution record to the main controller through the wireless communication module for statistics on the appearance patterns of harmful animals in the area; if it is not a sound protection command, but information from the main controller, the corresponding control variables will be updated, such as working mode, interval time range, sound protection target file, volume, etc.

The software of audio control subsystem construction scheme 1 is mainly divided into five parts from the functional point of view, including random number generation, SD card driver, FAT file management, serial communication and decoding control.
The random number generation subroutine generates a random number and executes a delay within the range determined by the interval time variable by calling the library function rand().
The SD card driver implements the reading and writing of data on the SD card in sectors (512 B) in SPI mode.
Since the FAT file format is generally used to store and manage files on the memory, the FAT file management subroutine can manage the file directory and data storage location on the memory, as well as read the data of the specified file under the SD card driver.
The serial communication subroutine implements serial port initialization and data transmission and reception in bytes, and on this basis, implements serial communication in frames with data verification. In the serial port protocol of this scheme, 1 frame of data includes 8 bytes. Among them, the first byte is the agreed start flag; the second byte is the sender address; the third byte is the message type (such as "update sound protection target", "change volume", etc.); the fourth to seventh bytes are message parameters; the eighth byte is the sum of the first seven bytes, which is used to verify the correctness of data transmission to ensure the reliability of communication.
The decoding control subroutine is an important part of the audio control subsystem software. Since the MP3 hardware decoder is integrated on the single-chip microcomputer, the user does not need to care about the specific decoding process, as long as the decoder parameters are set and the data is sent to the decoding buffer in time. The content of the MP3 audio file is divided into three parts. The first and last parts are used to record the audio file name, producer and other information; the middle part stores compressed audio data in frames, and the frame header contains the file type, sampling rate, bit rate, number of channels and other information of the audio file. When playing the specified MP3 audio file, the single-chip microcomputer first reads the data of a sector of the specified file through the FAT file management subroutine, and sets the relevant parameters of the hardware decoder based on this; then, the audio data is written into the decoder buffer in sequence, and the decoder automatically decodes the MP3 data and sends the decoded data to the DAC. To achieve continuous playback, the decoding control subroutine needs to ensure that the data to be decoded is written in time when the decoding data buffer is idle.
3 Construction and implementation of Scheme 2
3.1 Hardware structure and implementation of
Scheme 2 Scheme 2 is the "ARM microprocessor + software decoding" construction of the audio control subsystem. The hardware structure of this scheme is shown in Figure 4. The ARM microprocessor uses the S3C2440 chip produced by Samsung and expands 64 MB FLASH to store boot programs and operating system kernels. At the same time, it also expands 64 MB SDRAM as the program running space. S3C2440 is based on the ARM920T core, with an operating frequency of 400 MHz. It integrates a variety of peripheral interfaces such as SD, USB Host, LCD, audio, and video, and provides 130 I/O ports. It is a high-performance, low-power microprocessor chip [3]. The wireless communication module is connected to the microprocessor through the RS-232 serial port. Since the USB HOST interface on the S3C2440 only supports the USB1.1 protocol, considering compatibility, this scheme still selects the SD card as the storage and reads and writes it in SD mode. S3C2440 integrates LCD and touch screen controller, and can select corresponding human-computer interaction devices, such as dot matrix LCD, according to needs. S3C2440 is connected to the low-power audio processing chip UDA1341 with A/D and D/A functions through the I2S audio interface to realize the acquisition and output of audio signals. The system is connected to Ethernet via the Ethernet control chip DM9000A, which is used to connect to the microcomputer for development and debugging. In order to improve the electromagnetic compatibility and scalability of the system hardware, the hardware design adopts a modular structure of core board + expansion board. The core board includes S3C2440, FLASH and SDRAM chips, which are connected to the expansion board with the help of pins. The expansion board integrates various peripheral chips and interfaces, and the design scheme can be changed according to actual needs, which is convenient for the expansion and upgrade of the system hardware.

3.2 Software Design of Solution 2
The software structure of Solution 2 is divided into three layers, as shown in Figure 5. The software development platform uses the embedded Linux operating system. Linux is a stable, efficient, free, open source operating system that not only supports multiple architectures and a large number of hardware devices, but also its kernel can be tailored according to actual needs.

In the Linux environment, the application's access to hardware devices relies on the driver running in the kernel as a bridge. The driver layer at the bottom of the software provides the operating interface of all hardware devices in the system, including RS-232 serial port driver, SD card driver in SD mode, OSS (Open Sound System) audio driver compatible with UDA1341 audio chip, and LCD driver, etc. Almost all drivers are directly provided by Linux, without the need for developers to write them themselves.
The middle layer of the software is the application layer, including audio decoding subroutines, serial port communication subroutines, random number generation subroutines, etc. In the embedded Linux environment, there are more abundant system functions and open source software to support, making the implementation of applications easier. For example, the MP3 decoding subroutine is written using the high-level API provided by the audio decoding library libmad. libmad is an open source high-precision MPEG audio decoding library that supports audio decoding in Layer I, Layer II, and LayerIII (i.e. MP3) formats in the MPEG-1 standard, and the decoding process uses fixed-point calculations, which is very suitable for platforms without floating-point operation support (such as ARM platforms). Using the high-level API provided by libmad, it is easy to decode MP3 data. The process only needs to open the corresponding audio device file, map the audio file to be decoded on the SD card to the memory, and then call the decoding function of libmad. In the implementation of solution 1, the functions of FAT file format processing, audio parameter extraction and setting, and decoding data read and write control that the developer needs to implement by himself are all automatically completed by the operating system driver and the library functions in the libmad decoding library in this solution. In addition, with the support of the OSS audio driver and the SD card driver, the compilation of the WAV audio file playback subroutine can be easily realized. Since the WAV audio file directly stores the PCM-encoded audio data, although the file is large, there is no compression distortion, and its sound quality is better than MP3.
The upper layer of the software is the process control layer. Since the functions implemented by solution 2 and solution 1 are basically the same, there is no essential difference in the software process. The specific functions can still be seen in Figure 3. Embedded Linux has a multi-task management function, that is, it can "simultaneously" process multiple processes in a time-sharing multiplexing manner, and provides a variety of communication and coordination mechanisms between processes, such as signal mechanisms. The signal mechanism is used for communication between multiple tasks, and its essence is a simulation of the interrupt mechanism at the software level. Unlike solution 1, in the embedded Linux environment, the use of the signal mechanism can easily implement interrupt control. In the program, it is set that when the serial port receives data, a signal is sent to the system process. After receiving the signal, the system process turns to execute the pre-specified processing program, thereby realizing interrupt control.
4 Experimental test and comparison of two implementation schemes
According to the above two schemes, an audio control subsystem for realizing the intelligent sound protection system for crop pests was constructed. The experimental test results show that the audio control subsystems developed by the two schemes have achieved the expected goals, can accurately and reliably communicate with the wireless communication module, and adjust various working parameters in real time under the control of the master controller. The audio control subsystem can accurately and clearly play the audio file corresponding to the current sound protection target in both trigger and random working modes. The use of a hot-swappable SD card ensures that the sound protection audio file is easy to update. Moreover, based on the adopted FAT16 file format, the subsystem can support SD cards with a maximum capacity of 2 GB, realizing reliable storage of large-capacity audio files.
Since they are built on different hardware platforms, the two audio control subsystem implementation schemes differ in terms of functions, development difficulty, and construction cost.
In terms of functions, Scheme 1 can smoothly decode and play MP3 files with a bit rate of 192 kb/s or less, but when playing files with higher bit rates, the continuity of data written into the decoding buffer cannot be guaranteed due to the processing speed of AT89C51SND1 and the data reading and writing efficiency of the existing program, resulting in discontinuities in the output sound. Moreover, due to the limitation of hardware decoding, audio files of other formats cannot be decoded and played. Scheme 2 uses software decoding, and the main frequency of the selected microprocessor S3C2440 is 400 MHz. In theory, as long as the corresponding decoding subroutine is transplanted, audio files of any format can be decoded and played. The test of Scheme 2 found that it can indeed decode and play audio files of MP3 and WAV formats of any bit rate. Moreover, in Solution 2, the system is fully capable of handling more complex tasks while completing the audio decoding task (the MP3 decoding program only occupies about 7% of the processing power of S3C2440), and has strong scalability. For example, the audio control subsystem can collect sound or video after the detector node finds harmful animals, and run the voice recognition subroutine or judge the type of detected harmful animals through visual detection, so that the sound protection target of the entire sound protection system is more accurate and achieves better sound protection effect. In addition, due to the shielding of the embedded operating system to the hardware, the software implementing Solution 2 is easy to port to other hardware platforms.
In the software development process, Solution 1 needs to pay attention to the operating details of each hardware device, and its software programming is relatively large. Solution 2 is relatively easy to develop because the selected Linux operating system directly provides hardware drivers and there are also a large number of open source software resources available for application programming. However, Solution 2 needs to port the embedded operating system as a software development platform, including establishing the BootLoader boot program, configuring, compiling and porting the operating system kernel and file system, etc. This is slightly more difficult to develop than Solution 1, which uses direct programming of the program to the microcontroller. In terms of software debugging, each change of the microcontroller program in Scheme 1 needs to be rewritten into the ROM. Scheme 2 can use the network function of Linux to mount the programming directory on the microcomputer in the embedded Linux file system in NFS mode, so as to realize the writing and modification of the program on the microcomputer side, and directly "remotely" run the modified program on the embedded Linux system, which is more convenient for debugging.
In terms of construction cost, the hardware cost of Scheme 1 is lower. However, with the continuous advancement of manufacturing technology, the cost of 32-bit microprocessors will be further reduced. Considering the cost of peripheral devices, the cost performance of the audio control subsystem built with Scheme 2 is superior to that built based on Scheme 1.
Digitalization and intelligence are the inevitable trends of agricultural modernization. In order to ensure the best reliability and performance, this paper uses embedded technology and adopts two technical solutions to develop and realize the audio control subsystem that plays an important role in the intelligent sound prevention system of crop pests. Experimental tests show that the "single-chip microcomputer + hardware decoding" construction scheme can basically meet the functional requirements, but its system performance and upgrade and expansion capabilities are limited by hardware; while the "ARM microprocessor + software decoding" construction scheme can fully meet the functional requirements and has strong scalability and portability.