# Design and Performance of a XBee 900 MHz Acquisition System Aimed at Industrial Applications
## 3 Design of a Wireless Monitoring System
### Implementation of the Monitoring System  
This subsection describes the hardware and software used to implement the wireless monitoring system. Figure 7 illustrates the hardware used. Figure 6: Chronogram for distributed monitoring operation. Processing of the nodes and exchanged messages when multiple sampling operation is used. Figure 7: Hardware implementation of the monitoring system. At the core of the monitoring system, a National Instruments (NI) myRIO 1900 device was used as Coordinator Node. This is a real-time embedded board made by National Instruments powered with a dual-core ARM Cortex-A9 and a Xilinx FPGA. It may be used to develop real-time embedded applications since it provides several analog and digital inputs/outputs. It runs on top of a Linux RTOS, and it is programmed in LabVIEW. The Linux RTOS supports a filesystem which has been used foratalogging. Although the NI myRIO is aimed primarily at education, it is a very powerful device which mimics other devices of the CompactRIO series, also developed by National Instruments. These provide powerful computing platforms which allow for the combination of different modules, including controllers and different reconfigurable IO modules to create real-time embedded industrial control systems. Controllers work over a Linux-based RTOS and can be programmed with LabVIEW, C, C++ or Java. They are robust devices, which are widely used in industrial applications. Thus, the presented implementation could be exported easily to these industrial devices. As Figure 7 shows, one XBee module is connected to the Coordinator Node by means of a serial link. The serial communication between the XBee module and the NI myRIO can be easily programmed from LabVIEW by means of the NI VISA device. The LabVIEW application realizes the following operations: (1) configure the XBee modules at start up; (2) periodically send the broadcast/unicast measurement commands, according to the planned schedule; (3) collect the frames sent by the Smart Measuring Nodes; (4) detect the integrity of the frames issued by the Smart Measuring Nodes and discard the wrong or late packages; (5) extract the sensor data from the frames and (6) save monitoring values to disk for offline analysis. A prototype board for the Smart Measuring Node was designed based on commercial off-the-shelf components in order to simplify the construction of the board (see Figure 8). An Arduino MKR Zero board, based on a 32-bit SAMD microcontroller, was selected for processing purposes. The Arduino MKR Zero may be easily programmed by means of the open-source ArduinoIDE, which makes it easy to write code and upload it. Among other peripherals, it features seven channels of twelve bits analog to digital converters and supports a Li-Po single cell, 3.7 V battery along with an expansion connector compatible with the small form-factor Arduino pinout. Wireless communications are implemented by means of XBee Pro S3B modules, which communicates with the Arduino MKR board by means of an asynchronous (UART) port. An original printed circuit board (PCB) was specifically designed and manufactured to assemble both components. It also features a low-power input to the microcontroller along with a reference voltage, to increase the voltage resolution of the ADC, and four analogue inputs fitted with simple RC low pass filters. This board eases the connectivity of the analogue sensors, which should be in the range of 0-3.3 V, while keeping the expansion port of the Arduino board free to connect other boards as long as they do not interfere with the signals used in this project. Figure 8: Detail of the Smart Measuring Node prototype board. The microcontroller application is responsible for: (1) configuring the Smart Measuring Nodes according to configuration frames issued at system start up; (2) receiving the multicast/unicast measurement orders; (3) reading the values of the connected sensors accordingly; (4) sending the frames with the readings of the sensors; and (5) identifying wrong or late frames sent by the Coordinator Node.