Building and deploying a wireless sensor network in the Georgia Tech stadium Ghaith Matalkah ghaith@gatech.edu Version 1.0 (Sept. 2011) This document provides an outline of the project to be delivered by the SensorNets team by Oct. 28 th 2011. The goal of this project is to deploy a scalable single-hop wireless sensor network in the Georgia Tech football stadium for collecting audio and vibration data during football games. The topology of the proposed network is shown in Figure 1. The network consists of a number of peripheral sensor mote nodes (i.e., M0-M4) each interfaced with one or more sensors (i.e., S1, S2, Acc) and a central node that is a coordinator mote (CM) connected via a USB cable to a Cluster Head (CH), which is a Single Board Computer (SBC) running embedded Linux. Sensor motes communicate with the coordinator mote through an IEEE 802.15.4 radio using the SimpliciTI protocol from Texas Instruments. On the other side of the network, the cluster head is connected to the GT network via Ethernet and communicates with the estadium server through a TCP/IP connection. The combined function of the coordinator mote and the cluster head constitutes a gateway between the wireless sensor network and the GT network. Communication in this network is packet-based and happens in two directions: in the upstream, packets carrying sensor data are sent by sensor motes M0-M4 to the CH (via the CM) and then forwarded by the CH to the estadium Server. In the downstream, packets carrying application commands are sent by the CH to one or more of the sensor motes M0-M4. Command packets transmitted by the CH could be either initiated by the CH or forwarded on behalf of the estaduim server which initiates such packets on behalf of user clients (see Figure 1). Examples of application commands include inquiring about sensor values, setting sensor reporting period (e.g. report temperature every one minute), setting sensor sleeping periods, and time synchronization among sensor motes. Each sensor mote in this network is a Texas Instruments MSP-EXP430F5438 experimenter board equipped with a CC2520 radio (IEEE 802.15.4 radio). The board is made by Texas Instruments and sold as a development kit for the MSP430 microcontroller. The board is powered by two 1.5-volt batteries and has a number of built-in sensors including a microphone, a 2D tilt accelerometer, and a temperature sensor. The board also includes I/O port extensions that allow for interfacing with external sensors. This feature is quite useful because it enables the deployment of more sophisticated sensors. In some
applications as in this project-, an external sensor may have power requirements that are beyond the capabilities of the mote 1. In such instances, the sensor is equipped with its own power supply and signal conditioning board (SCB) through which it is interfaced with the mote (see M2 and M4 interfaced with an accelerometer (Acc) in Figure 1). estadium Server User Client M0 S0 SimpliciTI/ IEEE802.15.4 GT Network S1 IP/Ethernet S0 M1 SimpliciTI/ IEEE802.15.4 CM coordinator mote Serial/ USB Cluster Head (Linux) Gateway S1 SimpliciTI/ IEEE802.15.4 SimpliciTI/ IEEE802.15.4 SimpliciTI/ IEEE802.15.4 sensor S0 M2 S0 M4 S1 S1 Acc Accelerometer SCB Signal Conditioning Board S0 S1 M3 Acc SCB Signal Conditioning Board Figure 1 The topology of the wireless sensor network 1 The words mote and board are used interchangeably in this document.
The cluster head is an AMD Geode-based single board computer (SBC) PCM-5820 from Advantech. It has typical PC interfaces including USB, keyboard and mouse (PS2), VGA, Ethernet, IDE (hard drive/cd/dvd), audio, and RS-232. The operating system running on the cluster head is a simplified version of Fedora 13. The operating system is installed on a bootable USB flash memory and the cluster head is configured to boot from that flash memory. The advantage of using a USB flash memory over a hard drive is twofold: one is reduced power consumption and the other and more important is simplifying future system updates and reconfigurations. More specifically, when multiple cluster heads are deployed, upgrades can be simply performed by unplugging the USB flash memory, upgrade the system on the flash memory, and plug it back in. The work on this project will be divided into four independent, but connected, parts. The four parts are connected in the sense that they define the four stages of a data flow that starts at the sensors and ends at the estadium server, where the output of one stage is the input to the next one. Therefore, the work on these four parts should go in parallel but with close coordination among the teams working on different part. The first part of the project is data acquisition and processing. It includes using the on-board microphone for collecting audio data and interfacing the sensor mote to an external accelerometer for collecting vibration data. It also includes processing the audio data using the FFT algorithm and making decisions based on the results. The second part is wireless data transmission. It includes packetizing and reliably transmitting the acquired data or their processing results to the coordinator mote. The third part is implementing the gateway that connects the wireless sensor network to the GT network. This includes receiving data packet by the coordinator mote, identifying its origin, and translating and forwarding it to the cluster head, which in turn sends it to the estadium server. Finally, the last part is data storage and includes maintaining all acquired data and processing results on the estadium server and serving data queries sent by client users. In the following sections, the details of first and second parts of the project are outlined. Details on the third and forth parts are postponed to a later version of this document. Details on the third part are postponed because it is almost ready and need only to be integrated when the other parts are ready. And details of the forth part are postponed because it involves some technical decisions that have yet to be made. Part I: Data Acquisition and Processing In this part of the project the sensor motes will be programmed to acquire two types of data: Audio data using the on-board microphone and vibration data using an external accelerometer. The acquisition process of each type of data is different in terms of configuration parameters, sensor interfacing, and data handling. These differences are highlighted in the following two subsections. Audio Data The purpose of acquiring audio data is to evaluate the possibility of detecting sound events in the stadium during games. Examples of such events include crowd cheering and booing, glass breaking, and
other events of security concern. Since this is a detection application what only matters to the user is the detection results. Therefore, raw audio samples need not be transmitted to the estadium for processing. Instead, they are locally processed by the on-board microcontroller using various detection algorithms and the results are then transmitted and aggregated at the server. In detection applications, the size of the detection results is usually a tiny fraction of that of the raw data (e.g., 2 bytes compared to 1K bytes). Therefore, there are several advantages of locally processing the data and sending only the results over sending the entire raw bits. One significant advantage is that the amount of power consumption associated with data transmission is significantly reduced. This is obviously because much less data bits are being transmitted. This advantage, however, comes with the price of increased consumption of processing power, which results from the execution of detection algorithms on the sensor motes. Nevertheless, this increase in processing power consumption makes only a fraction of the amount of power that is saved in data transmission. The reason is that the power consumed in sending a data bit is order of magnitude of the power consumed in processing a bit. Another advantage is that the time spent is transmitting small size detection results is much less than that needed to transmit the entire raw bits which reduces the chances of packet collisions and interference. This advantage stems from the contention-based medium access scheme (i.e., CSMA) that used by the sensor motes and the fact that the motes operate in the crowded unlicensed ISM (Industrial Scientific and Medical) band. This is the same band used by other technologies such as WiFi and Blutooth. As mentioned earlier, the audio data will be acquired using the on-board microphone. Therefore, there is no hardware configuration that needs to be done to interface the microphone with the microcontroller. The microphone output is physically connected through an amplifier module to channel number 5 of the ADC module on the microcontroller. The intermediate amplifier has a cutoff frequency of 4KHz (i.e., filters all frequencies above 4KHz) which is appropriate for speech signals, and both the amplifier and microphone are powered using pin P6.4. Knowing these facts about the microphone circuitry is very useful in setting the ADC parameters. The ADC module should be configured to operate with the following settings: Sampling Rate: 8000 samples/sec Sample Size: 8 bits/sample Sampling Mode: Continuously sampling Channel 5. Because this is a detection application and events can happen anytime, the microphone must be continuously sampled during the lifetime of the application. This requires that samples be processed as soon as they are ready (i.e., in real time). To implement that, a sampling buffer must be created in the memory to hold the audio samples while they wait to be processed. The size of the sampling buffer is a very important design parameter and should be chosen to meet the requirements of the processing algorithm (e.g., FFT).
For every new audio sample, the ADC module generates an interrupt exactly at the time that sample is ready in the internal memory register. The new sample needs to be read right away and moved to the sampling buffer to avoid being overwritten by the next sample. This task must be accomplished without interruption to the ongoing processing of the samples that have already been moved to the buffer. To implement that, the interrupt generated by the ADC must be read by the Direct Memory Access (DMA) module, which can move the sampled data directly to the memory without interrupting the main CPU. Examples of such configuration can be found in the User s Experience Code. Vibration Data Vibration data will be acquired on and off game time for purposes of structural health monitoring. For such applications, time-domain vibration data is important. Therefore, unlike audio data, the vibration data will be acquired and sent as raw bits to the cluster head and then to the estadium server. As mentioned earlier, an external and very sensitive accelerometer will be used to measure the vibration data. The accelerometer is Model 2012-002 made by Silicon Designs. It requires a 5-Volt power supply to operate, which is beyond the capabilities of the sensor mote. Therefore, a custom-made power supply and a signal conditioning board (SCB) were made to interface the accelerometer with the sensor mote. The SCB includes the necessary circuit components to keep the accelerometer signal within the acceptable input range of the ADC module. It also includes an electro-mechanical switch that controls the power supply to the SCB and the accelerometer. Interfacing the SCB to the sensor motes requires three wires as shown in Figure 2: One for carrying the accelerometer signal, one for controlling the power switch, and one is for ground. Battery Accelerometer SCB Data power control GND I/O pins Mote Figure 2 Interfacing the sensor mote to an external accelerometer. To configure the ADC module for acquiring vibration data, it is important to know the requirements of the applications that will use the vibration data. For structural health monitoring applications, vibration signal of interest have frequencies between 0 and 200 Hz. Therefore, a sampling rate of 600 samples/sec should be adequate. Vibration measurements are usually in the order of hundreds of μmeters/sec 2
(acceleration) and hence very small variations in amplitude are of significance to the measurements. To capture such small variations during sampling, the sample size must be set large enough to reach the desired sampling precision. The maximum sample size that can be used in the ADC module is 12 bits/sample and this is what will be used to acquire vibration data. Writing the vibration data to the memory should be handled in the same way as the audio data. That is, the ADC must be configured to interrupt the DMA and make it send new samples to a sampling buffer in the memory. The samples can then be packetized and sent to the CH as explained in the next section. Part II: Wireless Data Transmission In this part of the project the sensor motes will be programmed to transmit the audio data processing results and the vibration data to the coordinator mote. The motes will be programmed to form a wireless network and transmit their data via the radio module that is attached to each mote. This will be implemented using the open-source wireless network protocol SimpliciTI from Texas Instruments, which provides simple and straightforward mechanisms for data transmission and network management. Before digging into the details of implementing SimpliciTI and incorporating it with the application code that run on each mote, it is very crucial to understand the relationship and interactions between SimpliciTI and the radio module of the sensor mote. Each sensor mote includes a radio module that consists of a CC2520EM daughter board from Texas Instruments and an antenna. The radio module is interfaced with the MSP430 microcontroller using a Serial Peripheral Interface (SPI) through which all wireless data and radio commands flow between the radio and the microcontroller. The CC2520EM is a 2.4-GHz radio that is compliant with the IEEE 802.15.4 protocol, which is a standard protocol intended for low-power low-rate Personal Area Networks (PAN). Basically, the IEEE802.15.4 protocol supports only single-hop networks and comprises only two layers: a physical and a Medium Access Control (MAC) layer. Most IEEE 802.15.4 PANs are configured in a star topology where the central node acts as a coordinator for the rest nodes (i.e., similar to configuration of the network in Figure 1). SimpliciTI builds on the IEEE 802.15.4 protocol 2 and defines two more layers, a network and application layers. This allows for more advanced features to be implemented in the network such as multi-hop communication and advanced network management. Figure 3 shows the overall protocol stack. 2 SimpliciTI can also be used with protocols other that IEEE 802.15.4.
Application Network Management Apps (Ping, Join, Link,..etc) User-defined Apps Network Ports: 0x01, 0x02,... Ports: 0x20, 0x21,... Routing, Addressing Minimal Radio Frequency Interface (MRFI) SimpliciTI MAC Physical CSMA, MAC addressing Modulation, Frequency IEEE 802.15.4 Figure 3 SimpliciTI/IEEE802.15.4 protocol stack. The SimpliciTI stack also includes an intermediate sub-layer defined as Minimal Radio Frequency Interface (MRFI) that conceals hardware differences from the network and application layers. This sublayer is needed because SimplicTI code runs on the main microcontroller while IEEE 802.15.4 lower layers are implemented in the radio module. The SimpliciTI library includes multiple MRFI definitions that cover up to five families of radios from TI including the CC2520 family. Two network configurations are supported by SimpliciTI: star and peer-to-peer. In a star network, a single node acts as an Access Point (AP) and all other nodes are end devices that connect to the AP. All communication in such a network is through the AP. That is, end devices do not communicate directly with each but through the AP which acts as a hub for all traffic in the network. The network can also include Range Extender (RE) nodes that extend the coverage of the AP to reach out-of-range end devices. On the other hand, in a peer-to-peer network, all devices are the same and can communicate directly with each other. From Figure 1, it is obvious that the SimpliciTI network in this project is starnet work, where the CM is the AP and all peripheral motes are end devices with no range extenders in the network. It is worth noting that the network functionality provided by the IEEE 802.15.4 protocol should be enough to implement the wireless part of the network in Figure 1. However, it is much desired that the wireless network of this project be scalable. In other words, additional sensor motes should be easily added to the network at arbitrary distances from the coordinator mote without essential modifications to the network. This can be easily achieved using the multi-hop communication capability that SimpliciTI provides.
A technical aspect of SimpliciTI that is of significance to the work in this project is the frame format. Figure 4 shows the SimpliciTI frame format and Table 1 summarizes the fields of the frame. The number in each field in Figure 4 refers to the size of the field in bytes. The fields marked as radio defined or RD are defined by the IEEE 802.15.4 specifications. The IEEE802.15.4 frame is included in the SimpliciTI frame of Figure 4. The standalone IEEE802.15.4 frame is shown in Figure 5. Figure 4 SimpliciTI frame format. (RD: radio defined) Because some of the header fields in the SimpliciTI frame are radio defined, the frame can have different payload sizes depending on the underlying radio. It is important to determine the maximum payload size of the frame when SimpliciTI is used with the CC2520 radio. Knowing this parameter is important to help improving the wireless medium utilization and reducing the power consumption associated with data transmission. To see how the payload size is related to power consumption, consider the SimpliciTI frame which comprises header fields of at least 16 bytes (i.e., sender and receiver addresses, port number, sequence number...etc). Those header fields are not part of the data but they are necessary for the correct delivery of each frame. Therefore, they are considered an overhead. When a sensor mote sends a given amount of application data, the total number of transmitted bits is equal to the application data bits plus the overhead bits coming from the header fields of each transmitted frame. Minimizing this overhead is not possible on a frame basis, because each SimpliciTI frame, regardless of its actual payload size, must contain the header fields. A practical way to minimize this overhead is to reduce the total number of frames that are needed to transmit the application data. This is achieved by increasing the payload of each transmitted frame. Reducing the number of the transmitted frames reduces the total overhead bits that are transmitted and hence reduces the power consumption associated with sending the application data. This is better illustrated through an example: Consider a sensor mote that has 100 2-byte vibration samples to be sent to the coordinator mote. Suppose that the maximum payload size of the frame is 100 bytes and the frame includes 16 bytes of header information. In the worst case scenario, the sensor mote could be programmed to send one sample per frame. In this case, the total number of frames that are sent is 100 each with a size of 18 bytes (16 header + 2 data). Thus, the total number of transmitted bytes is 1800. In the best case scenario, the sensor mote could be programmed to send the maximum number of bytes in each frame, which results in a total number of 2 frames
being transmitted, each with a size of 116 bytes. This brings the total number of transmitted bytes to 232, which is only 12.8% of the 1800 bytes sent in the previous case. Reducing the number of transmitted frames can also improve the utilization of the contention-based wireless medium. Because sensor motes contend on accessing the wireless medium on a frame-byframe basis, decreasing the number of frames results in reduced contention time and reduced number of back-offs experienced by each mote. This allows sensor motes to spend more in sending mode rather than in contention or back-off mode, which obviously improves the utilization of the wireless medium. Table 1 SimpliciTI frame field summary For the CC2520 radio, the maximum payload size of the SimpliciTI frame can be determined by knowing the maximum size of the frame and size of each header field that are labeled as RD in Figure 4. The total size of the frame is determined by the Length field. The Length header field determines the total size of the packet excluding the preamble, SYNC, and Length fields. The field has a size of one byte with the most significant always set to zero. This gives a maximum packet size of 127 bytes (2 7-1=127). The size of each header field labeled with an RD can be found from the CC2520 datasheet or the IEEE802.15.4 standard specifications. The only two fields in the SimpliciTI frame with an RD label that are included calculating the Length field are the MISC and FCS. The MISC field in the SimpliciTI frame maps to the Frame Control Filed (FCF, 2 bytes) and the Data Sequence Number (DSN, 1 byte) in the
IEEE802.15.4 frame. The FCS field is 2 bytes. The maximum payload size of the SimpliciTI frame is therefore: 127-2(FCF) - 1(DSN) 8(addresses) 1(PORT) 1(Device Info) 1 (TRAC ID) 2 (FCS) = 111 Bytes. Figure 5 IEEE 802.15.4 MAC frame format Addressing: There are three levels of addressing in a SimpliciTI network: Network, device, and application addressing. The device address as defined in the SimpliciTI specifications is a 4-byte value that uniquely identifies that device. The upper 2 bytes of the devices address identifies the network which the device belongs to while the lower 2 bytes identify the device within the network. A network in this context refers to a coordinator device and all end devices that belong to it. That is, a coordinator mote and all motes that belong to it should have the same upper 2 bytes in their addresses, while the lower two bytes of the address should be strictly unique. Sensor motes addresses are manually assigned at build time. Different applications running on the same sensor mote are identified by a 1-byte port number. For example, the audio acquisition application can use port number 0x26 while the vibration acquisition application can use the port 0x28. An application will include its port number in every frame that carries its data (see Figure 4). Implementation The following guidelines should be followed when programming the sensor motes for wireless communication: The coordinator mote must be programmed as a SimpliciTI access point and senor motes should be programmed as SimpliciTI end devices. The end device code should associate the port number 0x26 with the audio acquisition application and the port number 0x28 with the vibration acquisition application. Frames
originated or destined to any of the two applications should be carry the corresponding port number. The end device code should packetize the vibration data such that every 40 samples (= 80 bytes) are sent in a separate SimpliciTI frame. Audio data processing results should be sent every 500 msec. The access point code should be able to identify the source address and the port number of each received frame and create a separate buffer for each source address/port number combination. Every mote in the network including the coordinator must have the network address 0x1111. Again this is the upper two bytes of the device address. The lower two bytes of the address should be 0x5501 for the coordinator and chosen in order from the following set for the sensor motes {0x5502, 0x5504, 0x5508, 0x550F, 0x5510, 0x5512, 0x5514, 0x5518, 0x551F,. }. References: 1. SimpliciTI: Simple Modular RF Network Specification, V. 1.09, Texas Instruments. 2. CC2520 Datasheet 2.4 GHz IEEE 802.15.4/ZIGBEE RF Transceiver, Texas Instruments. 3. IEEE std. 802.15.4-2006: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Low Rate Wireless Personal Area Networks (LR-WPANs). Team members: Justin Carlin justincarlin@gatech.edu Jace Hall jacehall@gatech.edu Brett Toler btoler3@gatech.edu Murat Dener mdener1@student.gsu.edu Chia-Hung Fang (Canny) canny.fang@gatech.edu Jesse DuMond jdumond3@gatech.edu