Cross measurement process with a ZigBee sensor network

Transcription

1 Cross measurement process with a ZigBee sensor network Javier Rodas, Carlos J. Escudero Departamento de Electronica y Sistemas. Universidade da Coruña. A Coruña. Spain jrodas@udc.es, escudero@udc.es Abstract Location systems based on Wireless Sensor Networks (WSN) and Receiver Signal Strength () mainly depend on how the measurements are obtained. Usually, there are some mobile nodes to be located that periodically send beacon frames, which are captured by an anchor sensor network. After combining this information, the system estimates node positions. However, it is well-known that these systems suffer from big inaccuracy problems due to environmental changes (obstacles, people, loose of line-of-sight, etc.), that produce fluctuations on level. We introduce a cross measurement process to obtain more data, getting information among the anchors and making possible to detect these changes, to perform appropriate fixes and calibrations. I. INTRODUCCIÓN WSN are an effective mechanism to build location systems [][]. According to the used technology to implement the WSN, it is necessary to capture different physical parameters. These parameters are needed to estimate distances and, therefore, to predict a device position. In this paper we used the ZigBee technology to implement a WSN, due to the ultralow power consumption mode it offers. Therefore, location is based on Received Signal Strength () information. The performance of location systems based on WSN and information crucially depends on the quality of the obtained measurements and how these levels adapt to a particular propagation model []. It is well known that these power levels randomly vary according to environmental conditions (obstacles, moving people, loss of the line-of-sight, etc.). However, this variations can be statistically modelled using small and large scale propagation models []. Even if we use a propagation model that fits well enough the environmental propagation conditions, there are factors such as loss of line-of-sight among nodes, which produce significant changes in the propagation conditions [4]. These factors make the multipath components acquired great importance and, therefore, used models may be no longer valid. These systems are typically based on periodic transmissions of pilot packets from mobile nodes, which are captured by an anchor node network. Typically, signal levels among the mobile node and the anchors are the only used, because they are enough to estimate the mobile node position by means of a more or less advanced location technique (multi-lateration [], particle filtering [5][6], etc.). All of these techniques always An anchor nodes is a node whose position is fixed and known. suffer some problems when the measurements do not adapt to the raised propagation model. As a possible improvement to the problems faced by these systems due to environmental changes, we propose an increment of available measurements, to better detect these changes. If some changes among several anchor nodes were detected, we could make all kind of decisions: measurement correction with respect to any node, recalibrate the location algorithm, give more or less weight to some of the network nodes, etc. In this paper we introduced an easy and economical way to build a ZigBee network, for obtaining cross measurements among all network nodes, not only among mobile and anchor nodes. The proposed system has the following features: An efficiency and simplicity. Small and efficient code, with low computational cost. A cheap and small-sized hardware by using XBee modules from manufacturer [7] and Arduino boards [8]. A high immunity to collisions by sending packets aperiodically. The ability to increase the number of anchor nodes on the fly and thus improve the system accuracy. Without reprogramming mobile or anchor nodes, or relaunching the location application. A high autonomy for mobile nodes powered by batteries taking advantage of ZigBee sleep modes. It is a completely wireless packet relaying system by using the WSN. This article is divided into the following sections: In Section II we describe the hardware structure and the role played by each node of the WSN. In Section III we explain in depth the packet relay process among the different nodes of the system. In Section IV we show how the packet relay algorithm is implemented in the anchors. In Section V we explain how the host processes the received frames via UART and how creates the table with the cross measurements among all the WSN nodes. inally, we expound some conclusions in Section VI. II. HARDWARE The raised system consists of three types of nodes: Mobile node: It sends beacon frames aperiodically in order to avoid collisions with other mobile nodes. It falls

2 in sleep mode after sending each packet to ensure a high autonomy of its batteries. The sleep period is set randomly between a minimum and a maximum values. Anchor node: It has a fixed and a known position. It listens for packets sent by mobile and anchor nodes, which must be relayed by means of the logic explained later in this article in Sections III and IV. It is mandatory to main power it because this kind of node never sleeps and it should always be ready for relaying packets. Gateway: It is and special anchor node, which only listens for packets sent by the other nodes. It never relays packets and it is connected to a host where a location algorithm will be running. ig.. Mobile node hardware ig.. Anchor node hardware ig. 4. Arduino board on the left, and XBee-Shield on the right. standard. Their PHY and MAC layers are enough for the location proposes. All network nodes use the same hardware, which simplifies the deployment. It only changes the program that runs in the Atmel microcontroller of each node, except for the Gateway node that does not need the microcontroller. The Gateway redirects all incoming data (wirelessly received) to a Host via USB, by using its [9] transceiver. A photo of these two parts is shown in igure 4. igures, and show the scheme of interconnection among the different parts (Atmel microcontroller, XBee module and transceiver), of the three types of nodes. The anchor nodes must be main powered so their parts (Atmel microcontroller and XBee) never enter into a low power mode (sleep). The mobile nodes, however, configures its XBee module to enter in a cyclic sleep process by means of a sleep period marked by the Atmel microcontroller. Instead, the microcontroller also enters in sleep mode when it finishes to send the configuration data to the XBee module via UART. Therefore, it must be added a line between the XBee module ( pin) and the microcontroller (IN T pin), so that the XBee can wake up the microcontroller when his cyclic sleep period expires. This will provide a high autonomy to the batteries of mobile nodes, although it is not an optimal autonomy due to the wrong design of the Arduino power supply. inally, the gateway node can do without the microcontroller as shown in igure. It wirelessly receives data and passes they to the Host via USB in real time. In Section V we will explain in detail the format of the received frames and how we unpack them in the Host to obtain the desired data. III. ig.. Gateway hardware To implement the WSN we have chosen the combination of Arduino [8] boards (which contain an Atmel microcontroller) and XBee series modules [7], mainly due to their low cost. Actually, the XBee series module version does not implement the ZigBee layers, only the layers of the IEEE PACKET RELAY PROCESS The raised cross measuring process is divided into three easy steps and their operation is independent of the number of anchor nodes present in the WSN. igure 5 illustrates these steps when a WSN composed of 4 anchors is used. or simplicity, the raised process is presented in a situation where all nodes have direct access among them. However, it is not difficult to extrapolate this behavior to a larger network, where data of closest nodes is collected.

3 (( )- (( ) -) - (( ) -) - (( )RS - ( ) - ( )- ( ) - ( ) t(ms) Node Node Node Node Node (( )-)- (( )-)- (( )-)- Period = Period = 95!(7,)!(7,) (( )-)- (( ) -) - (( )-)- (( ) -) - (( )-)- (( )-)- - Period = 5 -!(7,) ((( )-)-) - ((( ) -)-) - ((( ) -) -) - ((( ) -) -) - ((( ) -) -) - ((( ) -) -) ((( )-)-) - ((( ) -)-) - (( )-)- (( )-)- (( )-)- (( ) -) - ((( ) -) -) - ((( ) -) -) - (( )-)- (( ) -) - (( )-)- (( )-) ig. 5. s, and respectively. ((( )-)-) - ((( )-)-) - ((( ) -) -) - ((( ) -) -) - - III-A. - (( ) -) A mobile node that is in a sleep state automatically wakes - up when his XBee cyclic sleep period - expires. - - irst, the - XBee wakes up the Atmel microcontroller (also - in sleep state) by posting an interruption (using the INT input). This is automatically done by the XBee pin after a wake up. The Atmel microcontroller resumes its execution at the same point where it left before to sleep. Then, the microcontroller sends a small broadcast packet (destination x) to the network, with byte in the Payload. This packet will be received by all nodes in the network (if III-B. there are no collisions). Afterwards, it calculates the new pseudo-random sleep period for the XBee module, between a predetermined minimum and maximum values fixed in the code. It passes ((( )-)-) - it to the XBee module by sending a ATSP - ((( ) - -) -) - ( Period) command [], with possible values between - ms and 68 sec. And finally the Atmel himself switches off - - all the hardware parts unneeded (ADCs, IC and SPI ports), - and enters into Power-down mode []. This is the most - deepest - way of saving energy, getting a power consumption of less than 5 µw for the microcontroller. Start Delimiter Length rame Data Checksum x7e MSB LSB API-Specific Structure Byte Source Addr. (bytes 5-6) MSB LSB API Identifier x8 I (byte 7) Received Signal Strength Indicator Hex. equivalent of (-dbm) value. i.e. x8 (4 decimal) => -4 dbm Identifier-specific Data cmddata Options (byte 8) bit, -7 [reserved] bit : Address broadcast bit : PAN broadcast ig. 6. RX (Receive) packet: 6-bit Address Payload (byte(s) 9-n) Up to Bytes/packet ((( ) -) -) - ((( ) -) -) - When this step is completed, each anchor node close to the mobile node should have detected detected the same receive packet (RX) but with different level. Note that, if the Gateway (address ) and the mobile nodes are in range, we will get the information about the link, denoted by (between the transmitter and the receiver ). igure 6 shows the structure of each RX (Receive, API Id.=x8) frame, where the byte 7 contains the level (in dbm) and the bytes 5 and 6 contain the Source Address, which identifies the broadcast transmitter node. The Length field includes the total length of rame Data so that we can easily calculate the length of the Payload by computing Length 5 (minus byte of API Id., bytes of Source Addr., byte of I and byte of Options). The closest anchor nodes to the mobile node that received the packet from the previous step, detect that the received packet has the right length to be relayed. This is explained in depth in Section IV. They create a new packet by putting into a new Payload the following information: Source Addr. + ( + Payload + ) + I Note that the length of new Payload is always equal to the size of the previous Payload+5, because we add bytes of Source Addr.), other characters ( and ), and byte of the I to be relayed. or simplicity, we will use the Payload RX notation to refer to the Payload of the received packet and Payload TX for the new expanded Payload. They wait a pseudo-random period of time (between a minimum and maximum default values) and simply re-broadcast the new composed packet. This pseudo-random time value is also set to avoid collisions with other anchors. All nodes in the network will receive N a packets after this step, with N a the number of anchor nodes (not including the Gateway node). After this second step, the Gateway has information of the links among the mobile node () and all the anchor nodes in range. In addition, it also has cross information of the anchors that are -hop from him, but it still has no information of the links among the other anchors (links, and ).

4 III-C. The anchor nodes detect that the received packets in the previous step has the right length to be relayed. They create a new packet identically than in the previous step, by putting the Source Addr. in front of the previous Payload and the detected I behind. They wait another pseudo-random period of time and simply transmit the new packet. This time, instead of broadcasting it, they sent it directly to the address, which it is always the Gateway node. Since we are considering direct connection among nodes, upon completion of this step, the Gateway has information passed among all the nodes. It has this information duplicated for all the links at more than -hop from it ( x y and y x links) and N a times replicated for the direct links at -hop from it ( x ). Note that each intermediate relay brings a new level, and there are relay in and N a relays in. When the mobile node is re-awakening all this process will start again, as shown in igure 9. void loop ( ) { i f ( S e r i a l. a v a i l a b l e ( ) ) { / P acket d e t e c t i o n / Read one b y t e i f ( t h e f i r s t b y t e!= S t a r t D e l i m i t e r x7e ) { Wrong s t a r t d e l i m i t e r => Empty s e r i a l b u f f e r e l s e { Read rame Data Length ( b y t e s ) Read API I d e n t i f i e r ( b y t e 4) i f ( API I d e n t i f i e r!= RX Packet x8 ) { Wrong API Id. => Empty s e r i a l b u f f e r e l s e { Read Source Addr ( b y t e s 5 6) Read I ( b y t e 7) Read O p t i o n s ( b y t e 8) f o r ( i =; i<length 5; i ++) { Read Payload RX [ i ] Read Checksum ( b y t e ) / P acket r e l a y / P a c k e t r e l a y code ig. 7. Packet detection code / P a c k e t r e l a y / The p o s s i b l e p a c k e t l e n g h t s are : 6 = 5 + [ b y t e in Payload ] < in = 5 + [+()+ b y t e in Payload ] < in We compose t h e new Payload as : Source Addr + ( + Payload RX + ) + I Length 5 New payload l e n g t h : ++( Length 5)++ = ( Length ) New p a c k e t l e n g t h : ( Length )+5 Length TX = Length +5; We compose t h e new Payload TX as : Source Addr + ( + Payload RX + ) + I Payload TX [ ] = ( b y t e ) ( Source Addr >>8); Payload TX [ ] = ( byte ) Source Addr ; Payload TX [ ] = ( ; f o r ( i =; i<length 5; i ++) { Payload TX [+ i ] = Payload RX [ i ] ; Payload TX [+ i ] = ) ; Payload TX [4+ i ] = I ; We c a l c u l a t e t h e new Checksum : Not i n c l u d i n g frame d e l i m i t e r s and l e n g t h, add a l l b y t e s k e e p i n g o n l y t h e l o w e s t b y t e o f t h e r e s u l t, and s u b s t r a c t from x. The new TX p a c k e t have t h i s s t r u c t u r e : API ID =, rame ID =, Destination Addr, O p t i o n s = and Payload Checksum = (++ D e s t i n a t i o n A d d r ++Payload ) & I f Length==6 then We are in > Send r e l a y i f ( Length ==6) { D e s t i n a t i o n A d d r = x ; accu = x ; b y t e accu = x + x + x e l s e { E l s e We are in > Send r e l a y to Gateway D e s t i n a t i o n A d d r = x ; accu = x ; b y t e accu = x + x + x f o r ( i =; i<length ; i ++) { accu += Payload TX [ i ] ; Checksum TX = x accu ; Small random d e l a y t o a v o i d c o l l i s i o n s d e l a y ( random (, 5 ) ) ; We r e l a y t h e new p a c k e t send packet TX ( ) ; ig. 8. Packet relay code IV. ANCHORS PACKET RELAY ALGORITHM The pseudocode in igure 7 represents the overall structure of the code stored in the anchor nodes, which act as packet relayers. The code is contained within a infinite loop (loop()), which is divided into simple parts that are processed each time some bytes appear in the UART [] (pin ) of Atmel microcontroller, sent from the XBee radio module (pin ):. Packet detection: We read the header data of RX (Receive, API ID = x8) received packets. If something wrong is detected then it empties the input buffer and waits for more bytes (new packets).. Packet relay: We detect if the received packet must be relayed. According to the Length of the packet, we know if we are in the or and, therefore, if we have to broadcast or unicast (to the node Gateway) the new packet. The Payload TX is composed (with the format explained in the ) and the new Checksum. Then we send the new TX (Transmit, API ID = x) [] packet. This is achieved simply by writing the new frame bytes out to the Atmel UART with an extra Carriage Return (x) byte to mark the end of the packet. These bytes will go from the Atmel pin to the XBee pin.

5 V. RAME PROCESSING IN THE HOST The Gateway node is directly connected to the Host by USB, but the Host actually communicates with a UART (standard ( ) - ( ) - RS- serial port). This is transparently done through the transceiver [9] integrated in the Arduino board. The XBee module of the Gateway must be simply configured in API mode [] with an UART bitrate high enough to process many frames that can come from multiple mobile nodes. We used an 5 bps port speed. All received packets by the Gateway XBee module will go out via pin directly to the Host and through the transceiver, which makes the timely UART USB conversion. The Host must perform the following tasks in order to get the final ( ) - table with the cross( ) measurements - among all network nodes. The goal is to print this table to the standard output (stdout), according to the following format: Timestamp TransmitterID ReceiverID T xid RxID rom the Host, we open a connection at 5 bps with the according serial port and we enter in an infinite loop where we perform the following steps:. We decode RX (API Id.=x8) frames as explained in - the pseudocode (( ) in - ) the - previous section, extracting the rame-data Length (byte -), Source Addr (bytes 5-6), I (byte 7) and Payload (Length-5 bytes).. We get the current system time in UNIX timestamp format [] (in miliseconds).. We write to stdout: Timestamp Source Addr I, where the Source Addr at this level corresponds to the (( )-)- (( ) - ) - transmitter and the Gateway () to the receiver. 4. We switch according to the Length the reveived packet. The length can be 6, or 6, as explained in the ((( )-)-) - previous section, to detect if we are in, or. a) Length=6: We do not have to decode anything since the Payload is byte length and the packet was directly sent from a mobile node. (( ) - ) - (( )-)- b) Length=: ) We extract the first bytes of the Payload RX that corresponds to TransmitterID of the previous hop. ) We extract the last byte of the Payload RX ((( )-)-) - (( ) - ) - (( ) - ) - that ((( ) corresponds - ) - ) to - the observed I of the ((( ) - ) - ) - previous hop. ) We write to stdout: Timestamp TransmitterID Source Addr I where, in this case, the Source Addr corresponds to the ReceiverID of the previous hop. 4) We do not have to decode anything more because the remaining Payload is byte length. c) Length=6: We follow the same process as in ((( ) - ) - ) - ((( ) - ) - ) - point b) until the remaining Payload length is. We unpack the Payload of each packet by removing the first and last bytes of the previous Payload and assign at each step Source Addr TransmitterID of the previous step. (( ) - ) - (( )-)- Node Node Node Node Node t(ms) Period = Period = 95!(7,)!(7,) ig. 9. Runtime chart VI. CONCLUSIONS Period = 5!(7,) This paper introduces a new method to obtain cross data among all the nodes of a ZigBee sensor network. Although the main information is given by the links among mobile and anchor nodes, our method gives us a richer information taking into account the links among the anchors. This extra information can be used by a location algorithm to recalibrate its parameters or adapt to propagation changes in the environment. This paper explains how this method can be implemented in only three steps, indicating the basis of the ZigBee packets used to implement it. VII. ACKNOWLEDGEMENTS This work has been supported by: 7TIC95PR (Xunta de Galicia, Spain) and TSI--8- (Ministerio de Industria, Turismo y Comercio, Spain). REERENCES [] A. Boukerche, H. A. B.. Oliveira, E.. Nakamura, A. A.. Loureiro, Localization Systems for Wireless Sensor Networks, IEEE Wireless Communications, pp. 6-, Dec. 7. [] J. Hightower, G. Borriello, Location Systems for Ubiquitous Computing, IEEE Computer Magazine, pp , Aug.. [] T. S. Rappaport, Wireless Communications: principles and practice, nd edition, Prentice Hall,. [4] J. Rodas, and C. J. Escudero, Joint Estimation of Position and Channel Propagation Model Parameters in a Bluetooth Network, IEEE International Conference on Communications (ICC), Dresden, Germany, June 9. [5] A. Doucet, S. Godsill, C. Adrieu, On Sequential Monte Carlo Sampling Methods for Bayesian iltering, Statistics and Computing, no., pp. 97-8,. [6] S. Arulampalam, S. Maskell, N. Gordon and T. Clapp, A Tutorial on Particle ilters for On-line Non-linear/Non-Gaussian Bayesian Tracking, IEEE Transactions of Signal Processing, Vol. 5, pp , eb.. [7] International, [8] Aduino, [9] USB Uart Ic, [] UNIX Timestamp format, [] XBee Series, /ds xbeemultipointmodules.pdf [] Atmel ATmega68 AVR MCU, documents /doc86.pdf