Design and implementation of remote wireless monitoring system based on ARM

With the development of computer, network and communication technology, as well as the continuous improvement of multimedia video technology, the third generation of remote network video monitoring system based on the network has made great progress. The new generation of monitoring system is based on the network, with the compression, transmission, storage and playback of digital video as the core. The system adopts an embedded multi-task operating system, an efficient video compression chip and a powerful embedded processor, and all the video compression and transmission processing work is built into the chip. The video signal sent by the front-end camera is digitized and compressed and packaged to become a video stream of the basic network protocol. The video stream is sent to the receiving end through the network transmission. The video receiving end can use software to decode and display and process it on the PC.

System hardware platform
This system is composed of an ARM development platform with PXA270 as the microprocessor. PXA270 is a 32-bit processor that can run at four different clock frequencies: 312MHz, 416MHz, 520MHz and 624MHz. It is used in high-performance, low-power, portable and handheld devices. It incorporates Intel Xscale technology, has the ability to adjust dynamic voltage and frequency and perfect power management functions, and provides industry-leading MIPS/mw performance. The external network card interface is directly connected to the processor to achieve Ethernet communication, and the kernel and root file system images can be quickly downloaded using the TFTP protocol. There are 3 UARTs, namely standard, Bluetooth and full-function UARTs, which can be connected to GPRS DTU for signal transmission through the full-function UART. There are 3 USB interfaces that can be connected to USB cameras for image acquisition. The USB camera uses the Mesh V2000 camera with OV511 as the chip.

GPRS DTU is a wireless data transmission terminal device based on GPRS network, providing a fully transparent data channel. The network coverage is wide and can be used wherever a mobile phone can be used. It supports transparent data transmission and protocol conversion, backup data center, point-to-point interconnection function, and three working modes: always online, idle offline and idle power off. It has SMS and phone wake-up functions and supports automatic reconnection after disconnection.

Overall system design
The entire monitoring system is mainly composed of ARM, GPRS DTU, USB camera and PC. The ARM development board is driven by the Linux operating system. The USB camera is used for image acquisition through instruction scheduling. The acquired images are wirelessly transmitted through GPRS DTU. The PC is connected to the Internet and receives the images transmitted by GPRS DTU. The host computer is written through VC++, and the images transmitted by the monitoring point can be seen. The operator can control the monitoring terminal through SMS or phone calls, and the monitoring terminal can be in working or closed at any time. In this way, the monitoring terminal can be controlled at will and traffic can be saved. It is economical and affordable, especially suitable for some environments that do not require dynamic images. The system structure diagram is shown in Figure 1.

Figure 1 System structure diagram


System software design
This system uses Linux as the operating system, which is a multi-user, multi-tasking operating system; it has good openness and follows world standards, especially the international standards of Open System Interconnection (OSI). It has a complete built-in network. Linux is superior to other operating systems in terms of communication and network functions. It provides users with powerful and complete network functions. According to the needs of program development, the Linux operating system is cut and compiled, and the prepared Linux operating system is downloaded to the ARM development board through JTAG, and then arm-linux can be used to control the ARM development board.

Image acquisition is performed by scheduling Video4Linux and image device drivers through ARM-Linux. Video4Linux is the basis of Linux image system and embedded image, and is a set of APIs in the Linux kernel that support image devices. The application of Linux in multimedia is currently a very popular research field, and the most critical technology is Linux's Video4Linux. Configure Video4Linux in the Linux kernel, as shown in Figure 2. After configuration, download it to ARM-Linux through the bootloader. The USB camera uses the Mesh V2000 camera with the OV511 chip. Configure the driver of the OV511 chip in the Linux operating system, as shown in Figure 3.

Figure 2 Configuring Video for Linux

Figure 3 Configuring the USB OV511 camera

Download it to ARM-Linux through the bootloader, so that you can use the USB camera to capture images. The image capture process is shown in Figure 4.
The captured image is in BMP format. The image is too large to be transmitted over the network, so it needs to be compressed by JPEG. JPEG compression technology is very advanced. It uses lossy compression to remove redundant image data. While achieving a high compression rate, it can also display very rich and vivid images, which is very suitable for video network transmission. The basic JPEG algorithm is completed by the following steps: (1) eliminate data redundancy through discrete cosine transform (DCT); (2) use the quantization coefficient matrix to quantize the discrete cosine change coefficients; (3) encode the quantized coefficients to minimize their entropy. Entropy coding usually uses Huffman variable word length coding. The reason for lossy image compression mainly occurs in the second step. The JPEG standard is based on transform coding and combines DCT and Huffman coding to achieve a good image compression effect. The coding method based on discrete cosine transform DCT is the core content of the JPEG algorithm [5]. The JPEG library is needed when capturing images, so you need to install the JPEG library first.

Figure 4 Image acquisition flow chart

Six files, cjpeg.l, djpeg.l, jpegtran.l, rdjpgcom.l, wrjpgcom.l, snapscreenshop.l, will be generated in the /usr/local/man/manl directory. Five function libraries, libjpeg.a, libjpeg.la, libjpeg.so, libjpeg.so.62, libjpeg.so.0.0, will be generated in the /usr/local/arm/3.4.3/arm-linux/lib directory. libjpeg.so.62 and libjpeg.so.0.0 are the libraries we need. Copy them to arm-linux, so that ARM supports images in JPEG compression format. Some important functions of image compression are as follows:

char *filename = "first.jpeg";//Specify the target file where the compressed image is stored
struct jpeg_compress_struct cinfo;//Apply for and initialize the JPEG compression object
struct jpeg_error_mgr jerr; // Declare error handler
JSAMPROW row_pointer[1]; // A row of bitmap
int row_stride; // Number of bytes in each row
int line; // Number of bytes in each column
jpeg_create_compress(&cinfo);
cinfo.image_width = width; // Image width, height and depth
cinfo.image_height = height;
cinfo.input_components = depth;
cinfo.in_color_space=JCS_RGB;// Color image
jpeg_set_quality(&cinfo, JPEG_QUALITY, TRUE ); // Set compression quality
cinfo.dct_method=JDCT_FASTEST; // DCT discrete cosine transform
jpeg_start_compress(&cinfo, TRUE); //Start JPEG image compression
while (cinfo.next_scanline < cinfo.image_height) //Compress each line
jpeg_destroy_compress(&cinfo); //Release the resources requested during the compression process
The captured image is shown in Figure 5. If continuous frame capture is required, the number of frames to be captured is determined by grab_fd.frams, and a maximum of 32 frames can be captured at a time.

Figure 5: The collected images

GPRS DTU is connected to the ARM development board through a full-function serial port. Under the instruction scheduling of arm-linux, the image collected by ARM is transmitted to GPRS DTU through serial communication. arm-linux accesses the serial port through device files. When accessing a specific serial port, you only need to open the corresponding device file. The device files corresponding to serial ports Port1 and Port2 are /dev/ttyS0 and /dev/ttyS1 respectively. If you want to use the serial port for communication, you must set the properties of the serial port at both ends of the communication, including the baud rate of data transmission, the format of the transmitted data, whether there is a parity bit, flow control mode, etc. Setting the serial port under Linux involves an important data structure struct termios, setting the serial port baud rate struct termios Opt, setting the serial port data bit
struct termios Opt;
Opt.c_cflag &= ~CSIZE; //Shield the character size bit
Opt.c_cflag |= ~CS8; //Select 8 data bits
Setting the serial port parity bit The macro definitions related to this are:
#define PARENB 0000400 //PARENB controls whether to enable parity check
#define PARODD 0001000 //PARODD controls whether to use odd or even parity
Setting the serial port stop bit The only macro definition related to the stop bit is CSTOPB, which can be set by setting the .c_cflag member of the termios structure.
#define CSTOPB 0000100
Opt.c_cflag &= ~CSTOPB; //1 stop bit
Opt.c_cflag |= ~CSTOPB; //2 stop bits
Set the serial port baud rate:
The serial port uses the open function to perform the open operation. The open() function has two parameters, where parameter 1 is the device file name to be opened and parameter 2 is the opening method. Their meanings are as follows.

O_RDWR: Both readable and writable.

O_NOCTTY: Tells embedded Linux that the program does not want to be the "controlling terminal" of this port. If the application does not emphasize this, then any input will affect the execution of the program.

O_NDELAY: Indicates that the program does not care about the state of the DCD signal line, that is, it does not matter whether the other device is running or suspended. If this flag is not set, the program will be set to sleep until the DCD signal is low.

Use the close(fd) system call to close the serial port. Closing a serial port usually sets the DTR signal to a low level. If an external GPRS DTU is connected, the GPRS DTU will be suspended. Use the write() function to write data to the serial port. If the write call is correct, it returns the number of bytes sent, otherwise it returns -1. Read data from the serial port If the port is operated in raw data mode, the read() function call will return all the data in the serial port input buffer. If there is no data, the process will be blocked and wait until data arrives, or until the specified time is reached or an error occurs. The following method can make the read() function call return immediately.

Implementation of the system
The monitoring center server of this system is implemented by PC, using Windows operating system, using VC++ to write the host computer program, using TCP/IP communication, after entering the IP address of the monitoring terminal, the host computer can communicate with the monitoring terminal and receive the transmitted image, as shown in Figure 6. The system transmits an image in about 3 to 5 seconds.

Figure 6 Received image

This monitoring system supports SMS and phone wake-up functions, that is, the monitoring system can be remotely controlled through SMS and phone dialing, so that it can enter the working state and transmit information. It has a controllable connection timing function and supports three working modes: always online, idle offline and idle power off. When no data transmission is performed, the monitoring system can enter the offline state, which greatly saves communication costs. When data transmission needs to be restarted, you can use your mobile phone to send SMS to the monitoring system or call to wake it up and restore the connection with the data center. You can also send SMS to configure the monitoring system anytime and anywhere for easy management.