System Selection Justification Currently, general alarm issuing systems are half-duplex point-to-multipoint antenna-specific remote control networks based on PC/microcontroller technology. The control center in these systems is a PC/industrial computer, and each execution terminal uses a microcontroller-based controller to perform control functions. From the perspectives of usage, management, and construction, there are the following shortcomings: the PC/industrial computer-based control center has a large unit size and high equipment cost, and its efficiency is low due to the relatively simple tasks it undertakes. While the microcontroller-based control execution terminals can perform decoding control functions well, they cannot meet the needs of information interaction improvement and operation management in alarm issuing technology. For example, achieving high-quality, high-efficiency audio encoding/decoding, recording, and restoration to realize information interaction functions using a microcontroller is a challenging problem. The purpose of this paper is to address these needs by using embedded technology, which has abundant hardware and software resources, powerful data processing capabilities that can be easily scaled up, and general microcontroller control functions. This design aims to create a small, low-cost, powerful, and short-development-cycle embedded central controller and terminal controller to improve the existing alarm issuing system. System Overview The improved system consists of a control center and multiple terminals. A wireless data transmission module forms a wireless data path between the control center and the terminals. Each terminal is configured with a unique address. When an alarm is issued, the control center can either issue the alarm content in a group or issue a specific alarm content to a designated terminal host in a point-to-point manner by specifying the terminal address. The audio output port of the terminal controller is connected to the power amplifier. When a terminal receives an alarm command belonging to itself, it calls different audio files according to different alarm content, and finally the audio output unit and power amplifier distribute the alarm. To ensure the reliability of the controller, it needs to be tested periodically. During testing, the main control center checks each terminal serially. The testing includes the operation of the wireless data path between the center and the terminals and the audio distribution equipment. To accurately understand the operation of the terminal equipment, a microphone is equipped on the terminal's audio input interface to collect the issued alarm sound. The collected sound compressed file is then returned to the main control center via the wireless network for processing and analysis to determine whether the entire terminal equipment is working properly. Generally speaking, embedded controllers are designed for a specific function; they can be considered as dedicated computers with specific functions. In this system, the main tasks for both the control center and terminal controllers are data transmission and audio processing. Therefore, the same hardware can be used for both the center and terminals. When networking the system, only different application software needs to be installed on the central controller and terminal controllers to meet the system requirements. Therefore, once the control center's functions are implemented, the terminal design is essentially complete. System Hardware and Software Resource Selection To facilitate audio processing and accelerate system development, Windows CE was chosen as the controller's operating system. Although Windows CE is a soft real-time operating system, it fully meets the real-time requirements of this system. Furthermore, Windows CE features an excellent graphical user interface, powerful multimedia capabilities, and good communication capabilities. The user-friendly embedded platform tool Platform Builder facilitates the development of Windows CE. The application development tool Embedded Visual C++, with features essentially the same as Visual C++, provides a shortcut for developers familiar with Windows programming. Therefore, using the Windows CE operating system with its comprehensive API function library gives the system significant advantages. Hardware Structure Currently, many CPU cores support the WinCE operating system, such as ARM, x86, MIPS, PowerPC, and SH. MIPS and ARM architecture CPUs currently dominate the market. The CPU selected for the system's control center is the Intel @XScale PXA255 microcontroller, which follows the ARM 5V.TE architecture, operates at speeds up to 400MHz, and features Intel's Super Pipeline technology and unique dynamic power management technology, giving it both high performance and low power consumption. To meet the requirements of embedding the Win CE operating system, the system is equipped with 64MB SDRAM and 32MB Flash. The system also includes an LCD display and a touchscreen. The audio controller uses TI's TSC2301 Audio Codec chip, which supports AC'97 standard 20-bit stereo encoding/decoding, programmable sampling rate, input/output gain, and digital audio processing functions, while also integrating touchscreen control functionality. It is also an important component of this system's hardware. The serial communication-based wireless data transmission module is mature in practical applications, and various products are available on the market. This article will not describe it in detail. The following is the system hardware structure diagram. Windows CE Operating System and Applications Each Windows CE operating system is designed to run on a specific hardware platform. A complete Windows CE operating system typically includes the following components: 1. Bootloader: The program that loads the Windows CE operating system; 2. CPU initialization code: Based on a specific CPU series; 3. Drivers: Includes keyboard, mouse, sound card, COM, etc. Different hardware devices may have different settings. Drivers are provided by both Windows CE and the hardware manufacturer; 4. User interface; 5. Applications that perform specific functions. WinCE is developed using Platform Builder. This process requires selecting a specific development board support package (BSP) and corresponding applications and service components. To conserve hardware resources and keep the kernel as small as possible while still meeting requirements, applications and components need to be streamlined. After writing the applications, to make them part of the image system, a custom CEC file can be created in Platform Builder, making it a new feature and adding it to the system feature directory. Once the system is developed, it can be compiled to generate a system kernel image and an Eboot file. First, download the Eboot file via JTAG, then download the system image file via Ethernet. Based on this, system debugging and firmware installation can be completed. Application Program The application program mainly draws the human-computer interaction interface, implements serial communication functionality, and has sound acquisition, encoding, and playback functions. The application program is edited in the Embedded Visual C++ environment. Like desktop Windows, Win CE is a graphical user interface operating system that helps us design rich graphical interfaces. Win CE provides a powerful Graphics Device Interface (GDI), which allows for easy drawing of points, lines, rectangles, polygons, ellipses, bitmaps, and text. Like Visual C++, embedded Visual C++ also provides many commonly used controls, making the drawing of the human-computer interaction interface relatively simple. Windows CE Serial Communication Program While serial communication can be easily implemented in Visual C++ using the MSCOMM control, this control is not available in Embedded Visual C++, making serial port implementation relatively complex. However, Win CE provides a rich API function library, which can be used in the EVC editing environment to implement communication between the embedded system controller and the wireless data transmission module. The specific process involves first initializing the serial port, which includes using the `CreateFile` function to open an existing, unused serial port resource and setting device properties such as baud rate, data bits, and parity. Then, the serial port read/write times are set, and the event set for port monitoring is specified. During serial port read/write operations, since writing is controllable, but reading data is unpredictable, data can be written in the main thread of the program, while an auxiliary thread is created specifically for reading data. When data needs to be sent, the `WriteFile` function is used to write the data to be sent to the opened serial port. In the auxiliary thread, `WaitCommEvent` is used to detect the line status. When an event indicating the receipt of a character is detected, the `ReadFile` function is called to read data from the serial port. After reading the data, to trigger an event response and complete data processing, a custom message can be sent to the application's main form class using the `PostMessageBox` function in the auxiliary thread. This allows the message response process to be completed in the main thread. It's worth noting that the Win CE operating system is a UNICODE environment, supporting only UNICODE applications and controls. This explains why, even though both are 32-bit machines with similar API functions, many controls or classes that run on Windows won't function correctly in the Win CE environment. Therefore, when sending serial data, the data needs to be converted from a UNICODE string to an ANSI string, which can be done using the API function WideCharToMulitByte. Furthermore, the Win CE operating system doesn't support overlapped I/O mode, so when opening the serial port, it needs to be opened in non-overlapping I/O mode. However, in synchronous mode, if one communication API is operating, another will be blocked until the previous operation completes. Therefore, when the data reading thread is stuck in WaitCommEvent, WritFile cannot continue execution. To solve this problem, the TerminateThread function needs to be used to terminate the write thread before calling the WritFile function, and the same write thread needs to be recreated after sending the data to wait for the data reception event. Since the wireless data transmission module is designed to use half-duplex data transmission, using non-overlapping mode is reasonable. When the system issues an alarm, the control center sends a data packet to the terminal. The data packet is defined in the following format: [align=left] After receiving the data header, the terminal determines whether the device address is its own address. If it is, it reads the command and sends different alarms based on the command words. If the address is not its own address, the data packet is discarded. Implementation of the sound playback program in Windows CE During system detection, the system needs to play and record sound on the terminal, and then transmit the recorded sound file to the control center via a wireless network. In the application, sound recording and playback are implemented using a waveform audio programming interface. This interface allows audio to be compressed and encoded using pulse code modulation (PCM), and enables the application to precisely control the input and output devices of the waveform audio. The sound recording process is as follows: 1. Open an audio input device using the `waveInOpen` function; 2. Allocate the memory required for sound recording using the `WAVEHDR` structure, and then prepare an audio input header using the `waveInPrepareHeader` function; 3. Call the `waveInAddBuff` function to prepare a buffer block for the audio input device; 4. Start recording audio using the `waveInStart` function; 5. Release the audio input buffer using the `waveInUnprepareHeader` function and close the audio device using the `waveInClose` function when recording ends. The audio playback process is as follows: 1. Open an audio output device using the `waveOutOpen` function; 2. Allocate the memory required for sound recording using the `WAVEHDR` structure, and then prepare an audio output header using the `waveOutPrepareHeader` function; 3. Send the data block to the audio output device using the `waveOutWrite` function; 4. Release the audio input buffer using the `waveInUnprepareHeader` function and close the audio device using the `waveInClose` function when recording ends. Relatively speaking, audio input is more complex than output. The process of digitizing (discretizing) analog (continuous) sound waveforms mainly includes two aspects: sampling and quantization. The quality of digital audio also primarily depends on two important parameters: sampling frequency and quantization bit depth. Furthermore, the number of channels and the corresponding audio equipment also affect audio quality. In PCM speech compression coding: Data volume = (sampling frequency × quantization bit depth) / 8 (bytes) × number of channels. The Wave file recorded by the application also has several important parameters defining the sound data format: sampling method, sampling bit depth, sampling frequency, and number of channels. Common sampling frequencies are 8kHz, 11kHz, 22kHz, and 44kHz. Higher sampling frequencies result in better sound fidelity, but also increase the amount of audio data storage. In this design, sound acquisition is only for detecting device operation, so the sound quality requirement is not very high. To reduce network load and improve detection speed, the data format is set to 8kHz sampling frequency, 8-bit quantization, and mono. Experiments show that the sampled sound quality is slightly reduced, but the alarm type can still be clearly distinguished. Assuming our test time is three seconds, the data volume is 8000 × 8 ÷ 8 × 1 × 3 = 24KB. With a serial port baud rate of 76800bps, including the packet header and length, it takes approximately 3-4 seconds to complete the detection of one terminal device. This design completed the hardware structure design of the central controller for a remote control and telemetry alarm system. Based on an embedded hardware platform, application programs for the control center and terminals were developed. The new system better meets user needs, while the controller size is smaller and reliability is increased. However, because the wireless communication module in the system cannot achieve a very high baud rate, the system detection time is relatively long, which needs further improvement. References: 1 Nick. Grattan and Marshall. Brain. 1. Windows CE 3.0 Application Programming, Prentice Hall PTR, 2000. 2. Eric J. Braude. Solid Engineering: An Object-oriented Perspective. John Wiley & Sans Inc. 2001. 3. Zhou Yulin, Ning Yang, Lu Guiqiang, Fu Linlin. Windows CE.NET Kernel Development and Application Development. Electronic Industry Press, 2005. 4. Tian Dongfeng. Windows CE Application Design. Machinery Industry Press, 2003. 5. Gong Jianwei. Visual C++/Turbo C Serial Communication Programming Practice. Electronic Industry Press, 2004. Editor: He Shiping