Home

XMesh User's Manual

1. 2 Local parameters These are local to the procedure and they are entered directly without the name of the module N WARNING Gcc reuses registers Be careful when viewing local parameters as the values in the register may be reused for other instructions 3 8 7 Viewing Assembly Code Selecting the SRC ASM selection on the right side of the screen will display two screens one with source code and the other with the assembly code Users can single step through the assembly code by using the assembly step button on the screen toolbar PressureSensorM nc Source Window COX Fie Run View Control Preferences Help IMPE PP S amp S aA Fina ai ui ui PressureSensorM nc PressureSensorM llaitTimer fired sRc asM 7 i ee TODO Make sure cpu doesn t sleep in a state which disables counter x 185 euent result t UpdateTimer fired call CounterControl start TOSH SET SENSOR ON PIN call Leds redOn call WaitTimer start TIMER ONE SHOT WAIT_INTERUAL call Disable stop mote from sleeping during counting return SUCCESS event result_t WaitTimer fired uinti6_t currentCount currentCount call readCounter ressureDataPtr gt SensorCount gSampleCount currentCount TOSH_CLR_SENSOR_ON_PIN sensor off call CounterControl stop call Leds redOff call Enable count done enable sleep Ox442a lt PressureSensorM WaltTimer fired 26 gt ade r25 r25 5 Ox442c lt PressureSenso
2. Doc 7430 0108 01 Rev D Page 101 XMesh User s Manual Crossb w 11 XSniffer Crossbow has developed a tool XSniffer which allows users to monitor multi hop communication over XMesh This program runs on a PC and uses a MICA2 or MICAz Mote to monitor the RF packet traffic There are two applications to support XSniffer 1 XSniffer TinyOS code This code can be built for either a MICA2 or MICAz that runs on a Crossbow MIB510 or MIB520 base station The source code is located in Mote Works apps general XSniffer 2 XSniffer GUI which installs and runs on the PC The executables are installed in C Program Files Crossbow Sniffer 4 NOTE XSniffer is set for a group ID 0 and TOS LOCAL ADDRESS Oxff00 so that it should never return an acknowledgement for any radio packet meant for another Mote 11 1 Building and Starting XSniffer In the MoteWorks apps general directory build and install the application for the correct platform For a MICAz and a MIB510 this would be make install micaz mib510 dev ttySO WARNING XSniffer does not run XMesh do not use route hp or route lp variables when building XSniffer uses TOSH DATA LENGTH 64 which should accommodate the largest user data packets Start the XSniffer GUI select the correct COM port and START Network messages should start to appear in the Log tab 11 2 Using XSniffer XSniffer can be used to monitor the behavior of the mesh It will display all radio messages
3. N WARNING ELP motes can only receive downstream messages if they stay awake which increases their power consumption Users can develop a strategy where the ELP Mote wakes sends an upstream message requesting messages from the base station sleep rc sees Force _sleep 1 No Xmit Health Pkt lt Y Max Fire Health Int Timer Retries Ne PO TeS gt Timer amp Sleep Y Timer Stop Timer Fire Duration Timer gt sleep done FAIL sleep done SUCCESS Radio On Radio On Figure 8 2 ELP Logic Flow Chart The Figure 8 3 shows the sequence of events for force sleep 0 Sleep SleepDone User App Duration gt First Health Packet Sent Immediately Health Messages Hea al Figure 8 3 Sequence of Events during ELP 8 3 The XMesh ELP Interface There are two interfaces Mote Works tos interfaces to control XMesh ELP enabled Motes e ElpControll e Elpl Doc 7430 0108 01 Rev D Page 69 XMesh User s Manual Crossb w 8 3 1 ElpControll Interface Example Wiring MysappM Rlpoontroll gt xXMeshRouter a lpConeroll Example Usage call ElpControll enable Interface command result t enable Description Enables the ELP mode in this mode the mote will periodically wake and send health messages to the base as determined by the s1eep comman
4. o xg File Settings Help Lacal Pragram Remote Program Select File to be Uploaded C Program Files Crossbow Moteview emesh nicas MTS 37004 93 hp exe Select Platform shesh Type Micaz Radio Band 916 MHz Route Update 36 Sec Hex Auto Inc Hex Packet Size 36 Bytes Payload Size 28 Butes Program W OTAP Enable Stop Begin scan F sCrassBow wirelesssappsMoteLanfigsbinsD ebug aoldenlmage tapaold micaz 915 exe Made ID set as 3 Group ID set as 100 WAAR TO Baud set as 57600 Mesh Health Update set as 60 ms CC1000 Channel set az 316Hz band CHANNEL_OO channel CC10600 Tx Power set as 255 AF Power 255 E dem HF Channel CHANNEL 00 908 01 B8 MHz Converting F CragssBew wirelezssappsM oteConfigsbinsD ebug G oldenlmage Utapiold micaz 815 exe out to F CrossBow wireless Lapp oteConfigsbin Debug GoldenlmageOtapGold_mica 918 amp xe sred Crossbow Inc 2006 Platform Micaz Device mibS10 Pork com E Figure 10 4 Programming XMTS310CA OTAP enabled application using MoteConfig 4 Repeat the Step 3 for all the nodes in the network When the bootloader is installed successfully the LEDs count up twice when the node is switched on 5 Program base station Mote with XMeshBase application Mote ID 0 and OTAP Enable unchecked Page 88 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual aici File Settings Help Local Program Remote Frogram Select File to be Upl
5. 4 NOTE Also disables UARTO during the sleep time duration Sleep duration for the radio sec At the end of this interval the 30 minutes application is signaled sleep done to perform whatever tasks it needs to do such as taking data and transmitting the result NOTE this only puts the radio to sleep The mote can still execute any application required tasks health Time between sending health packets sec This time determines how o minutes interval often the mote makes sure that it is still part of the mesh Increasing the time interval will reduce power consumption Health interval should be shorter than Duration iRetries Number of times to transmit a health packet and get an 5 acknowledgement If the acknowledge fails the sleep done event will be returned with success FAIL and the node will stay awake until the next call to sleep force Sle f force sleep zero a health packet is generated immediately after the ep command is executed and every health interval during the duration interval If force sleep one then health packets are not generated until after one health interval Interface event result t sleep done result t success Description Event signaled every time the node wakes from the sleep interval The radio and UARTO will wake up when the next message 1s sent or by issuing a Doc 7430 0108 01 Rev D Page 71 XMesh User s Manual Crossb w wake command see below 4 NOTE the radio is not on at t
6. Table 3 9 Standard Battery Configurations and Operating voltages Mote Hardware Standard Battery Typical Battery Capacity Practical Operating Voltage Platform required mA hr Range V AA 2 MICAz 2000 Alkaline 3 6 to 2 5 MICA2 AA 2 2000 Alkaline 3 6 to 2 5 The battery life is dependant on which peripherals are active and their associated duty cycles The Table 3 10 shows typical operational currents for the MICA peripherals Table 3 10 Typical Operational Currents for MICA peripherals Operation MICAz MICA2 IRIS j mA mA ma Microprocessor full operation eo Ce Microprocessor sleep Radio sleep 0 001 0 001 0 001 Serial flash memory write 15 Serial flash memory sleep XMesh LP in the default configuration achieves approximately 220 uA of average current usage no sensor board with the default configuration of e One data transmission every 3 minutes e Radio period length of 128 msec listening at 8 times second The current consumption can be increased or decreased by changing the default levels Expected battery life times for this average current level is shown in Table 3 11 below Page 32 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Table 3 11 Typical Battery Life for Various Battery Types Battery Type Capacity mA hr Expected Operation yrs When a sensor board is added the average current consumption will increase Designing a low power sensor interface a
7. In TinyOS the application user is not actively aware of the power management There are no longer any explicit power management calls provided by the OS that will put the processor into sleep Instead since TinyOS is an event driven OS with tasks as the unit of execution the scheduler will put the processor to sleep once the task queue is empty The processing involved in determining the sleep mode is a series of checks on the activity of the processor peripherals The power management module will ensure that the sleep mode set will be the lowest power mode that can still accommodate the correct operations of currently active peripherals The designers of TinyOS decided that since this check will delay the sleep operation the actual checks occur before the scheduler calls the sleep command Thus it 1s the responsibility of low level drivers to call the checks before and after using peripherals For further detail consult the scheduler c and HPLPowerManagement nc source files Radio Power Modes The radio transceiver typically has two modes of operation It has a transmit state and a receive state Depending on the specific radio transceiver the TX Transmit and RX Receive operations consumes power in the range of 10 to 20 mA In addition to TX and RX the radio transceiver also has a series of low power states When the transceiver is fully powered down it consumes around 3 uW Page 62 Doc 7430 0108 01 Rev D Crossb w XMesh User s
8. pointer to the buffer to be sent length The length of the data buffer sent using this component This must be lt the maximum length provided by getBuffer message only that the message was transmitted return whether the send request was successful SUCCESS means a sendDone event will be signaled later FAIL means one will not This does not mean that the destination mote received the Interface event result t sendDone TOS MsgPtr msg result t success Description Signals when a packet sent with send completes Doc 7430 0108 01 Rev D Page 53 XMesh User s Manual Crossb w Msg pointer to the message sent Success Whether the send was successful SUCCESS the packet was transmitted and a link level acknowledge received FAIL no link level acknowledge was received after 6 transmit attempts On the y attempt a new parent was selected but no acknowledge was received The g attempt was a broadcast message return Should always return SUCCESS 5 2 2 M Receive and ReceiveAck Interface This interface allows network end points to receive a data packet or an acknowledge packet without having to know about the internal structure of the packet or the layers below them in the stack Example Wiring MyappM RcvAck gt XMeshRouter ReceiveAck appID Example Usage event TOS MsgPtr RcvAck receive TOS MsgPtr pMsg void payload uintl6 t payloadLen Interface event TOS MsgPtr receive TOS MsgPtr msg void
9. ur fuse h z xd9 jtagen wr fuse hz0x13 read rd_fuses Page 118 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 15 Appendix C TinyOS Settings and Scripts When building TinyOS applications for XMesh make sure the environment variables are set correctly If the installation was at opt Mote Works do the following at the Cygwin command line export TOSROOT opt MoteWorks export TOSDIR opt MoteWorks tos export MAKERULES opt MoteWorks make Makerules These environment variables can be checked by entering echo TOSROOT echo TOSDIR ehco MAKERULES Note these variables can be automatically set in the opt etc profile file by entering set TOS variables export TOSROOT opt MoteWorks export TOSDIR opt MoteWorks tos export MAKERULES opt MoteWorks Makerules Cygwin Profile File The profile file is executed when Cygwin starts up and 1s useful for executing scripts that set paths and other variables This file 1s usually contained in MoteWorks Suite cygwin etc e To set a path to the fuses script see previous appendix from any application directory alias fuses opt Moteworks tools bin fuses e To set the serial port as COMI export AVRICE ARGSz j dev ttySO e To invoke the avr ice jtag program for a MICAz alias jtagmicaz ice insight build micaz main exe usr local bin File Scripts can be executed directly if they re located in MoteWorks Suite cygwin usr local bin Several scripts such as location
10. 2 Cost It tells other motes in the neighborhood how much it will cost to send a message upstream to the base station 3 Hop count The number of hops to send a message to the base station 4 A list of qualified neighbors and their quality estimate Due to the TinyOS packet size each route update message will contain at most 5 neighbors A neighbor is considered qualified if its receive estimate defined below is greater than a threshold 100 for high power 10 for low power By default the size of neighbor table 1s 16 for the remote mote 40 for the base station 1f there are more than 5 qualified neighbors the node will sequence through the neighbor list and handle that in multiple sequential route update messages The Route Update Message will be broadcasted every RUI Route Update Interval defined in Multihop h By default 1t 1s set to 36 seconds for high power and 360 seconds for low power The actual number is randomized by multiplying a random number between 0 9 and 1 1 to the defined value To better understand the processes we will first define some related metrics RE Receive Estimate the radio receive quality of the link from a specific neighbor computed by applying the EWMA Exponentially Weighted Moving Average algorithm to the percentage of the received packet New Estimate 255 received received missed RE 1 alpha RE alpha New Estimate Where alpha is the EWMA factor it is a value between 0
11. How many hops away the node is from the base station Parent Parent of the node Cost Entries Cost of sending a message to the base station Number of neighbors carried in this message Id of the neighbor Estx Msg Time How long ago in second the last message was received send estimate for the neighbor Number of message received from this node Q Q Doc 7430 0108 01 Rev D Page 105 XMesh User s Manual Crossb w xsniffer eX Log All Route Health Neighbor Time Sync Options ld Seg Hops Cost Enties Idi Esti Id2 Es la3 Es3 Id4 Est Id5 Es amp Msg Time 000 30 0 1126 0 2 ib 55 o ps5 0 EN b 005 71 2 15 8 3 lob 255 0 240 15 255 19 23 o5 p n b h p b ps p po p Js ps je o5 mo fh lo 4 3 B 55 b 255 15 55 29 o Figure 11 3 XSniffer Route Screen Display 11 2 5 Health This tab displays health messages Table 11 4 XSniffer Health Tab Parameters Address of mote originating the health packet MSeq Sequence number of the health packet This is not the multihop header sequence number Each health packet from a mote has it s own incrementing sequence number LQ Link quality of neighbor send estimate and receive estimate A value of 100 means 100 of messages have been heard received CostEst Cost of sending a message to the base station Number of messages
12. Time Sync Options Euunsoussonsesesseavensseved Packet Attributes p c Standard Packets Accept AND OR Value Ranges e W E Cc 5 Gus RSSI Display Option E ic A Display as Icon E Ci Display as dBm E AEE e g 1 3 5 17 210 254 Log Numeric Format Option All Decimal BA C Headers Decimal other Hex PaleTurg XMesh a A All Hex PaleViole ne Any2Any LightSteel XMesh Filename Measure Over Most Recent E secs Skew Reference Mote ID E Control Status 2 ts 115200 baud Elapsed Time 00 41 28 PAUSE c Host liocalhost Logging No _ Cer Port Filter None Figure 11 1 XSniffer GUI Options Screen Display 11 2 2 Log Screen This screen displays all radio traffic allowed by the filter see options tab Doc 7430 0108 01 Rev D Page 103 XMesh User s Manual Crossb w Table 11 2 XSniffer Log Screen Parameters Column Column Description Timestamp of the message E stamped by the PC Pf Beast Local broadcast message broadcast Local broadcast message The destination address of the Wairoa message io base message P g Id of the receiving mote Either numerical or icon display of the radio receive strength RSSI as measured by the XSniffer mote radio AM message type Global Time Sync rr SeqNo Sequence number of the message This number is incremented by the Src mote q each time it transmits a new message for multihop messages onl
13. OTAP works by transmitting small code fragments down to a selected Mote The entire code image is broken up into these fragments As OTAP receives the fragments it will store them in the serial flash The downloading sequence is independent of the reprogram and reboot process Once code images have been stored in serial flash users can reboot to any image at any time ATmegal78L External Serial Program Flash Flash Memory Bootloader OTAP image slot Q Empty slot 1 Bootable image slot 2 Current Application Figure 10 2 OTAP image transfer Reprogramming the microprocessor from serial flash requires that bootloader code resides in the top part of the ATmega microprocessor s flash memory This code is loaded once during the initial programming of the Mote via UISP There are several components required to run OTAP e Bootloader The piece of code that is guaranteed to execute after each reset of the mote independent of the TinyOS application e XOTAPLiteM A sub component wired into the user s application by including XMesh in the Mote e OTAP code image in slot zero of serial flash e XServe running on the server e XOtap running on the server The OTAP functionality is implemented within TinyOS by a component known as XMgmt This component is responsible for storing the state of the images in the serial flash responding to any queries from the XOtap tool and de fragmenting program or data images sent from th
14. i 0x00800120 0x00 0x00 0x00 0x00 0x00 0x00 OxOO 0x00 0x00 OxOO Ox0O OxOO OxOO OxOO 0x00 0x00800130 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xOO 0x00 0x00 0x00 0x00 0x00 0x00 0x00800140 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 oxoo oxo0 oxoo 0x00 0x00 0x00 0x00800150 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00800160 0x00 0x00 0x00 0x00 OxOO 0x00 0x00 0x00 0x00 0x00 0x00 0x00 OxOO OxOO 0x00 0x00 0x00800170 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 OxOO 0x00 0x00 0x00 0x00 4 x ec uou XX eio o D o o Figure 3 13 Viewing CPU s I O Registers The ATmega128 I O registers are mapped into a high portion of memory starting at 0x800020 The Register Summary at the back of the ATmegal28 manual shows all registers and their offset from 0x800020 and 0x800000 Offset from 0x800020 m Offset from 0x800000 33 53 TCCRO FOCO WGMO00 COMO01 COMOO WGMO01 32 52 TCNTO Timer CounterO 8 Bit 31 51 OCRO Timer CounterO Output Compare Re 30 50 ASSR 2 ASO Addresses Address lox800000 Target is LITTLE endiar 0 1 2 3 4 9 B T 8 3 A B C D E F 0x00800000 Oxff 0x00 0x08 0x00 0x05 0x20 0x00 Ox3a 0x02 0x01 0x02 0x00 0x00 Ox3a 0x49 OxOc 0x00800010 0x00 0x09 0x90 0x00
15. overhead within its radio range Users can use XSniffer to e Check to see if a mote has joined the mesh When this happens the health and data packets will change from a broadcast address to either the base station address or the address of another parent Monitor the packet sequence numbers of individual mote radio packets Monitor downstream radio communication from the base station Monitor radio message retries Monitor route update and time synchronization messages N WARNING XSniffer can only hear radio messages within its radio range Normally the XSniffer Mote 1s located near the base station so that it can monitor all upstream and downstream traffic from the base station In this position it will only overhear Route Update Messages from nearby neighbors within one hop Page 102 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 11 2 1 Options Tab This page allows users to control XSniffer and set display filters for incoming messages Table 11 1 XSniffer Options parameters and iM MIL O O AND OR logic Packet Types XMesh pepe MMMEMNMEM i a packets as XMesh multihop Time Sync Computes the time skew of the global time stamp between the selected mote usually the base station and the displayed motes TimeSync tab Special Packets Allows users to display special packet types in the Log screen by editing the XSniffer configuration file e XSniffer IJ EE Log All Route Health Neighbor
16. symbol transmission begins The Time Synchronization Layer reads the current clock value and writes it into the packet as it 1s transmitted Concurrently the authority value of the packet is set to 350 until the time values of the packet are inserted into the packet This 1s to ensure that data 1s updated inside the packet before transmission If for some reason the timing values are not inserted into the bytes containing the time reading before it 1s updated the low authority value will cause other nodes to ignore the transmission The time value is transmitted as a 64 bit integer with the least significant unit representing 1024 of a second 1 ms The time synchronization service causes nodes to synchronize to the time value that reaches them in the shortest number of hops In the event that a link 1s broken and the node must receive a synchronization message that has traveled with more hops the node will wait two extra cycles before accepting the new updated path This time synchronization method also considers all equal length paths as equally accurate Page 98 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual an ad hoc time authority hierarchy Base Station Mote with global time XServe Figure 10 13 Time Synchronization in LP Network In addition to resetting the local clock to the new value the time synchronization method also calculates the difference between the new value and the existing clock value in orde
17. the color of the selected nodes turns to Orange as shown in Figure 10 10 WARNING You cannot write over the Slot 0 because it is reserved for the OTAP Image ax File Settings Help Local Program Remote Program Option Iv Check Base HeartBeat Operation Select File to be Programmed C Program Files CrossbowsMoteview 1 4 20 emesh micaz vsMD select Check Operation Timeout Select Nodes e g 1 4 7 11 12 17 Select Slot O Ready Preparing Programming Rebaating Search Prepare Query Program Reboot Stop Finished 2 motes successful 0 motes failed Made 2 iz ready to Quen Program or Reboot Made 1 is ready to Query Program or Reboot Made 2 is ready to Query Program or Reboot Made 1 is ready to Query Program or Reboot Made 2 is ready to Quem Program or Reboot Made 1 is ready to Quem Program or Reboot Made 2 is ready to Quem Program or Reboot Made 1 iz ready to Query Program or Reboot Begin scan C Program Files CrossbowsM oteview 1 4 20 mesh micaz vsMDATUOCB dU3 hp exe Mesh protocol found Converting C Program Files Crossbow Moteyiew 4 20 emesh mica M041 00CB_ SOs hp exe ta C Program Files Crossbow Moteview 4 20 meshsmicaz M041 00CB_ 90S _hp exe hex Process completed Crossbow Inc 2006 Device mib510 Port con E Figure 10 9 Select an Application for Programming the Nodes Page 92 Doc 7430 0108 01 Rev D Crossb w XMesh User
18. 115 15 Appendix C TinyOS Settings and Scripts eee Leere eee eee e eter eere eee eee e ous 119 16 Appendix D TinyOS COmMpone DS vvvvsscccccscccsicacccessssscantscnavarsavavercsssesacevsesecsedsensseesssatevets 121 17 Appendix E Computing TOS Packet CRC sssssscssccssccssccccccccccccssssssssesesssees 123 Page ii Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual About This Document The following annotations have been used to provide additional information 4 NOTE Note provides additional information about the topic M EXAMPLE Examples are given throughout the manual to help the reader understand the terminology gt IMPORTANT This symbol defines items that have significant meaning to the user A WARNING The user should pay particular attention to this symbol It means there is a chance that physical harm could happen to either the person or the equipment The following paragraph heading formatting 1s used in this manual 1 Heading 1 1 1 Heading 2 1 1 1 Heading 3 This document also uses different body text fonts listed in Table 0 1 to help you distinguish between names of files commands to be typed and output coming from the computer Table 0 1 Font types used in this document Font Type Usage Sample code and screen output Commands to be typed by the user Times New Roman Italic TinyOS files names directory names Franklin Medium Condensed
19. 1ms of each other Thus the wakeup sequence will only need to span 2 ms 7 1 2 Performance Metrics of Low power techniques Period Length The amount of time between two consecutive channel monitoring operations If a node 1s setup to monitor the channel 8 times per second then this length 1s 125ms Doc 7430 0108 01 Rev D Page 63 XMesh User s Manual Crossb w Bandwidth Since every node may only send or receive one packet per period the bandwidth is thus determined by the length of this period If the period 1s 125 ms then the bandwidth is 8 packets per second Latency The latency is determined by the duration of the listening period If the duration is 125 ms then that is the latency per link Monitoring Energy The amount of energy every node must spend to periodically monitor for channel activity Transmission Energy The amount of energy used for the transmission of every packet including the wakeup sequence Reception Energy The amount of energy used for the reception of every packet 7 1 3 Analysis of Low power techniques Period Length vs Bandwidth and Latency The period length 1s directly proportional to the Latency and inversely proportional to the bandwidth Increasing the period length will lower the bandwidth while increasing the latency Period Length vs Energy Consumption The period length is inversely proportional to the monitoring energy Thus increasing the period length will decrease the monitorin
20. A XMesh Constants The following constants defines in the XMesh code are used to set configuration parameters that affect the performance of XMesh Defines the maximum data for a tos packet If ITOSH DATA LENGTH 29 changed make sure that XMeshBase uses equal or greater value BASE STATION ADDRESS mE Bue of base station Should never be Time between route update intervals These values 60 sec for HP should not be changed If changed make sure that 600 sec for LP XMeshBase and the application use the same values HEALTH UPDATE INTERVAL Ce Time between health messages seconds Base 30 Defines maximum number of neighbors that mote can ROU LE TABLE O LAE Others is track If a mote is not in this table it will not be selected a as a parent Base 100 Defines the maximum number of children for the mote DESCENDANT IABLE SIZE Others 50 Used for downstream communication Define the maximum number of multihop messages Base 16 Others 8 the mote can queue up Once exceeded messages will Su be dropped Enables reboot if no route update messages are heard ME cand Scc De mam within a defined interval FEATURE HEARTBEAT Enable disable base station heartbeat ROUTE UPDATE INTERVAL MEOP sOURUE SLAE Mote Addresses BASE STATION ADDRESS Base station address Mote address usually assigned when loading code VUES cec UIDI via install x or reinstall x or MoteConfig TOS BCAST ADDR Oxffff Broadcast address radio messages
21. Appendix B MICA FUSE SETTINGS The ATmegal28L and ATmegal281 microprocessors used on all MICA Motes have multiple fuses that control their operation These CPU s fuses can be set with UISP when downloading code to the mote The UISP allows users to individually set the high and low byte fuse The following tables from the ATmegal28L and ATmegal281 manuals show these fuse settings The following table corresponds to bit settings in the uisp wr fuse h setting for A Tmegal28L 7 Enable OCD 4 Fuse High JTAGEN Enable JTAG 0 programmed JTAG enabled SPIEN Enable Serial Program and Data Downloading 0 programmed SPI prog enabled 1 CKOPT Oscillator options unprogrammed 3 EESAVE EEPROM memory is preserve through i4 unprogrammed EEPROM not preserved the Chip Erase 2 0 programmed PAGT SA a Select Boot Size prog Select Boot Size see Table 112 for 0 programmed details Select Reset Vector 1 unprogrammed BOOTSZ0 BOOTRST The following table corresponds to bit settings in the uisp wr_fuse_h setting for ATmegal 281 Fuse High Byte Description Default Value Enable OCD OCDEN Enable JTAG 0 programmed JTAG enabled JTAGEN SPIEN Enable Serial Program and Data Downloading 0 programmed SPI prog enabled ERSAVE OOTSAl BOOT SAU BOOTRST EEPROM memory is preserved through the Chip Erase 1 unprogrammed EEPROM not preserved 0 programmed Select Boot Size prog Select Boot
22. E XSniffer 1 0 2174 25968 Log Neighbor Health Route All Time Sync Options psedT Addr RF Type Grp e Sre Orgn Se Ho Ap 1 2 3 4 5 6 7 8 9 1011 12 di F TEACA a a SURG NIC a a F Se ee ee ee ee F Figure 8 4 Screenshot displaying XSniffer Output gt IMPORTANT Ifthe JTAG fuse Appendix B is not disabled the sleep current will be less than 3 mA Page 74 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 9 XMeshBase This chapter discusses XMeshBase which 1s the standard base station application XMesh The topics reviewed are e What is XMeshBase e XMeshBase services e How to build XMeshBase 9 1 Whatis XMeshBase All XMesh networks require a base station which acts as a gateway for a PC Stargate or other client to interface with the XMesh network Base stations consist of a MICA2 or MICAz not a MICA2DOT running XMeshBase and mounted on one of the following Crossbow interface boards 1 MIBS1O using a RS232 serial port interface to the client 2 MIB520 using a USB port to interface to the client 3 MIB600 using an Ethernet port to interface to the client 4 Directly mounted to a Stargate with a serial port interface CLIENT PC STARGATE GATEWAY XMESH NETWORK i XMesh Network IEN MICA2 MICAz Figure 9 1 Mesh Networking Architecture Usually the client runs XServe Crossbow s server interface to the base station but users can directly
23. Eo XMesh Network Base Station Mote ED we j m a Figure 10 1 XOtap Architecture 10 2 1 How does OTAP Work Every Crossbow Mote has an external serial flash memory interfaced to the microprocessor This memory can hold up to 512 kB of data and is non volatile 1 e retains its contents if no power is present OTAP uses this memory to store code It divides the serial memory into 4 slots 0 1 2 amp 3 to hold different code data images Each slot can be a user configured number of pages in 2k byte steps By default each slot is 128 kB or 64 pages wide Unused slots are available to the user for data logging Slot zero always holds the OTAP image This is the full OTAP loader that must be invoked to download new code Users can wire the OTAP components directly into their application however these components consume several hundred bytes of RAM Instead Crossbow advises users to use small component XOTAPLiteM This component uses just 30 extra bytes If an Application wires in XMesh component the XOTAPLiteM is automatically available The server can send a command to XOTAPLiteM which will then cause the Mote to reboot into the OTAP image from slot zero to do the full code download The other slots in the memory are allocated Page 82 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual for user code or data Before reprogramming users must ensure that the OTAP image resides in slot zero of the serial flash memory
24. Interface command result b senot urntlo t dest unto t mode DOS MSgEtr pMsOg urltlo lengthy Description Sends a message buffer with a data payload of a specified length dest Destination Mote Id for the message Usually BASE STATION ADDRESS for upstream messages mode MODE UPSTREAM ACK upstream with return acknowledge MODE UPSTREAM upstream no return acknowledge MODE DOWNSTREAM ACK downstream with return acknowledge MODE DOWNSTREAM downstream no return acknowledge MODE ONE HOP BROADCAST one hop broadcast pointer to the buffer to be sent length The length of the data buffer sent using this component This must be less than or equal to the maximum length provided by getBuffer return Whether the send request was successful SUCCESS means a sendDone event will be signaled later FAIL means one will not This does not mean that the destination mote received the message only that the message was transmitted Interface command result t send TOS MsgPtr msg uintl6 t length Description This Send interface uses the AM type to parameterize the command It 1s provided to maintain backward comparability with previous XMesh applications that use AM type to distinguish different applications New applications should not use this interface Send will send a message buffer with a data payload of a specific length The buffer should have its protocol fields set already either through a protocol aware component or by getBuffer
25. Manual Crossb w 7 XMesh LP Low Power This chapter discusses XMesh in the Low Power mode It will also discuss e What is Low Power Operation e Low Power Strategies 7T 1 Low Power Operation Processor Power Modes XMesh motes can be configured to listen to radio messages in two modes High Power HP and Low Power LP In High Power the nodes that make up XMesh network are always on The Mote s microprocessor and radio are continually on and consuming power The radio is normally in the receive mode so that the Motes can listen to all neighborhood traffic at any time This is the highest bandwidth mode for transmitting packets to the base station Mote A processor typically has several modes of operation that consumes different amounts of power In the fully active mode the processor consumes the maximum amount of power which is typically in the 8 mA range In the lowest power consumption mode some form of deep sleep mode the processor only consumes in the order of 15 u Amps The differences between the power modes are processor specific Users should consult Atmel s A Tmegal28 manual for the MICA2 MICAz Motes and ATmegal281 manual for the IRIS Motes http www atmel com Typically the lowest sleep mode will have no peripherals running and will only provide SRAM retention Usually an external interrupt is required to wake the processor In most applications the external 32 kHz clock is used as the source of the wake up signal
26. Technology Inc 4145 N First Street oan Jose CA 95134 Phone 408 965 3300 Fax 408 324 4840 Email info xbow com
27. XMesh Description This component is any easy way to disable leds without changing any code in the application module In the wiring file ex Myapp nc do ifdef NO LEDS MyappM Leds gt NoLeds else MyAppM Leds gt LedsC endif HPLPowerManagementM not a component Wiring Example MyAppM PowerManagement gt HPLPowerManageM MyAppM Enable gt HPLPowerManageM Enable j MyAppM Disable HPLPowerManageM Disable Usage Example call Enablet call PowerManagement adjustPower Description If enabled the call to adjustPower will put the mote into a low power state when there are no more tasks on the task que Doc 7430 0108 01 Rev D Page 121 XMesh User s Manual Crossb w L This is a parameterized interface TinyOS automatically assigns a value to the unique Timer value Page 122 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 17 Appendix E Computing TOS Packet CRC The following code is used to compute the CRC of a data packet PUDO or O EE o a oT ais c Niche GS CIT o Joy QE OO ere onic os LOr imre L O07 1i lt 3 LTF if crc amp 0x8000 0x8000 CEC Cre c UE Dc Gale elles pesca ect return Cre amp gef sus pubes tci tcs eesc kein ANE Inder Vink COUNT iit teres O DIE de while count gt 0 ere CalecByte erc Packet indext ne COUNTESS is hm RN OUS OI Doc 7430 0108 01 Rev D Page 123 Crossb w Crossbow
28. XMesh LP and XMesh ELP are normally used 4 1 1 XMesh HP In this mode the Mote radios and processors are continually powered This consumes between 15 to 30 mA depending on the type of Mote Motes can receive messages and transmit at any time Route Update Messages and Health Messages are sent at a faster rate which decreases the time it takes to form a mesh or for a new mote to join the mesh 4 1 2 XMesh LP The low power mesh can run either time synchronized or asynchronous The best power efficiency 1s achieved with time synchronization supported by XMesh LP see Section 7 1 4 In this mode all motes are time synchronized within 1 msec The motes wake up typically 8 times second time synchronized for a very short interval to see if the radio is detecting any signal over the noise background If so the radio 1s kept on to receive the signal This operation typically results in a base level current of 80 uA The total average current depends on the number of messages received and transmitted When transmitting data every three minutes the usual power in a 50 node mesh is around 220 uA The average current to acquire sensor data will increase this XMesh LP can be configured for even lower power by reducing the wake up periods and transmitting at lower rates Also route update intervals are set at a lower rate to conserve power This also results in a longer mesh formation time 4 1 3 XMesh ELP The ELP mode is only used for leaf nodes th
29. XMeshBase XMeshBase is located in the Moteworks apps X Mesh XMeshBase directory To build the application run the following command from the application directory make lt hardware platform gt base route hp for XMesh HP or XMesh ELP make hardware platform base route lp for XMesh LP gt IMPORTANT Before building the application make sure the correct build parameters are set in the build make files Chapter 2 If the ROUTE UPDATE INTERVAL has been changed from the default value make sure that XMeshBase and the application are using the same values in the Makefile Component XMeshBase s TinyOS message data size must be equal or greater to the application message size The default message size for XMeshBase 1s 55 see Makefile component If the application data packets are larger than 55 data bytes then build XMeshBase with TOSH DATA LENGTH gt a As can be seen from the following Cygwin screen XMeshBase will use about 3600 bytes out of 4096 bytes of SRAM This is due to the increased buffers allocated for the base station Since no user application runs on the base station this will not be a problem compiled AMeshBase to build micaz main exe 25746 bytes in ROM a 3642 bytes in RAM avr objcopy output target srec build micaz main exe build micaz main srec avr objcopy output target 1hex build micaz main exe build micaz main ihex writing TOS image To program the compiled code into the mote MICA2 or MICAz make mot
30. a Lithium Thionyl battery with a 1 Q output impedance due to a fuse under these transient conditions for a MICA2 running XMesh LP The battery voltage top trace was AC coupled to the oscilloscope probe so the average signal 1s centered at zero volts The bottom trace shows when the sensor is turned on and off After the sensor turns on the processor sleeps for 300 msec to let the sensor power on and stabilize During the first 80 msec there is a 20 mV drop in the battery voltage due to charging the sensor circuit After the 300 msec delay the processor measures the sensor output using an external ADC for this unit Every 125 msec the processor and radio turn on quickly to measure the RSSI of the radio signal and the battery voltage drops almost 75 mV When the radio transmits 150msec pulse the battery voltage drops by 125 mV This behavior can sometimes be eliminated by using large capacitors on the battery s output to supply the required current during the transmit cycle Sensor uP radio on to sniff Radio xmit uP sleep measure RF every 125 msec ANN Sensor Sensor lt power on mu power off Figure 3 4 Behavior of Lithium Thionyl battery under XMesh lp 3 6 A Low Power Design Example This section contains an example of an application optimized for low power using XMesh ELP The sample code is in MoteWorks apps examples TestElp The TestElp application is based on the default XMesh ELP application Mote Works apps exam
31. a faster start up time and reduces the overall power consumption for a low power mesh The high speed clock is off when the MICA is sleeping 4 Timers 4 Timers Timers two 8 bit two 8 bit two 16 bit two 16 bit External Clock High Speed Doc 7430 0108 01 Rev D Page 23 XMesh User s Manual Crossb w In ATmega128L this clock is used for TinyOS timing External Clock TIMERO in ATmega128L and TIMER2 in ATmega1281 It Low Speed is always running even when the mote is sleeping as it s used to wake up the mote after the required sleep interval 3 3 Using ATmega Resources 3 3 1 General Port Input Output GPIO Pins GPIO enables direct control of individual CPU pins Table 3 5 ATmega128L GPIO Pin Modes Set a pin high Clear a pin to low Read a pin s state high or low Output Mode Input Mode The ATmega has ports named A G each with pins named 0 7 To Osc O gt oO mna E E Ree Er orf C f u uo rr Qa iy ol Oo000000 0 or N eCUuU Oo Lo oocBcDZSZu uCc O A A GO bt WS OXG CD SES SR HE s 5 i OOwWornonwtunwo re AUVeraA lt 2 L LL LL LL LL LL LL LL IL C m d OO xdcct 0 0cc0c0ccu0cu00 uuu aa IITIELIETLE Zea aan e eO m tO e cO e eO u uU u Lu Li os 8 O PAS AD3 47 1 PA4 AD4 RXDO PDI PEO O 2 TXDO PDO PE1 C XCKO AINO PE2 O 4 45 1 PA6 AD6 OCSA AIN1 PES OC3B INT4 PE4 C 43 1 PG2 ALE T3 INT6 PEG ICP3 INT7 PE
32. addressed to this address can be received by all motes TOS UART ADDR 0x007e Us messages with this address are sent to the uart Platform Defines set when building for a specific platform Define Description O TOSH HARDWARE MICAZ Code is built for MICAz TOSH HARDWARE MICA2 Code is built for MICA2 Page 112 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual TOSH HARDWARE MICAZC Code is built for IRIS Application IDs Applicaton TD 1 127 User available AM Messages Types User applications only deal with Application ID through using the MhopSend receive interface to send receive message and XMesh decides which AM type 1s appropriate for that message AM type is internal to XMesh currently there are 20 predefined AM type in XMesh that users should never use for other purposes The most current values can be found in the message h file The following table shows some of the presently used values AM HEALTH Reserved for Health packets from the mote AM DATA2BASE em data msg from node to base no end end AM DOWNSTREAM ACK Ack message from base to node Doc 7430 0108 01 Rev D Page 113 XMesh User s Manual Crossb w MODE ONE HOP BROADCAST Single hop service via XMesh AM HEARTBEAT Base station heart beat message N WARNING Do not use the AM parameter in multihop message when sending messages this parameter is reserved by XMesh Page 114 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 14
33. batteries are good for applications that require wide temperature operations 40 to 80 C and have large capacities but are expensive NiCad These are rechargeable however have a lower cell voltage 1 2V typically so stacking 2 batteries is about 2 4 V When stacking 3 cells the initial voltage can be 4 2V which is at the maximum operating voltage of the mote NiCads also have a fairly large self discharge rate so are not optimum for infrequent recharge intervals Temperature range All batteries are temperature sensitive Users need to understand their required operational range and that of the batteries Alkaline batteries will not work over an industrial temperature range 40 C to 80 C Also at lower temperature ranges they will have several hundred mV of voltage drop Doc 7430 0108 01 Rev D Page 33 XMesh User s Manual Crossb w 3 5 2 Battery Output Impedance Batteries differ from power supplies regarding output impedance resistance Power supplies have very low output impedance but many batteries exhibit several ohms of resistance under dynamic conditions This manifests itself as a voltage drop when the battery current goes from microamps to milliamps If the voltage drop is greater than 100 s mV the radio can be affected This type of transient behavior is typical of XMesh LP as the mote wakes up many times each second going from 15 uA of current draw to over 5 30 mA The screen shot in Figure 3 4 shows the behavior of
34. breakpoint e Step through C code or assembly code 4 NOTE Stepping through the code is difficult as interrupts are usually enabled and the code flow will usually branch to an interrupt handler Setting breakpoints 1s more efficient 3 8 3 Setting Breakpoints Using breakpoint e The at the left side of the screen indicates that a breakpoint should be available Gcc optimizes the code so not all lines support breakpoint Even some lines with the mark will not support a breakpoint e After running the code if a breakpoint is encountered the line will be shown highlighted in green At this time the code has stopped execution and registers RAM etc can be examined e The ATmegal28 supports up to 4 hardware breakpoints These breakpoints are internal to the ATmegal28 CPU N WARNING Ice insight does not give any warnings if the breakpoints have been exceeded Also before running ice insight it s advisable to cycle the power to reset the hardware breakpoints since it does not reset them on power up Page 42 Doc 7430 0108 01 Rev D Crossb w PressureSensorM nc Source Window File Run View Control Preferences Help 124 break Hs 127 128 129 130 131 132 133 134 135 136 137 Figure 3 11 Debugging using ice insight GUI 3 8 4 Examining the CPU registers Z MPP PressureSensorM nc z PressureSensorM SendSamples mu Ame BFind if tbSend
35. client which receives data and sends commands into the network Figure 1 4 XMesh Network Diagram XMesh provides a TrueMesh networking service that is both self organizing and self healing see TrueMesh section below XMesh can route data from nodes to a base station upstream or downstream to individual nodes It can also broadcast within a single area of coverage or arbitrarily between any two nodes in a cluster QOS Quality of Service is provided by either a Doc 7430 0108 01 Rev D Page 5 XMesh User s Manual Crossb w best effort link level acknowledgement and guaranteed delivery end to end acknowledgement Also XMesh can be configured into various power modes including HP high power LP low power and ELP extended low power The XMesh networking protocol has various options including low power listening time synchronization sleep modes any to base and base to any routing All Crossbow sensor and data acquisition boards that can make up a wireless sensor network are supported with XMesh enabled applications The XMesh network has the following features e MICA2 MICA2DOT and MICAz support e Low power typically less than 220 uA average current without sensor board e Network time synchronization to 1 msec e Low power listening with an 8 times per second wake up interval allowing for rapid message transfer across the network The default sampling period is 3 minutes although many other sampling intervals
36. communicate to the mesh via the base station The interface between the base station Mote and the MIB or Stargate is a serial RS232 or TTL interface It uses a standard serial protocol for communication Doc 7430 0108 01 Rev D Page 75 XMesh User s Manual Crossb w 9 2 XMeshBase Services XMeshBase provides the following services 1 Itis the seed mote that forms the XMesh network It outputs route messages that inform all nearby motes that it is the base station and has zero cost to forward any message 2 For downstream communication XMeshBase automatically routes messages down the same path as the upstream communication from a mote 3 Itis compiled with a large number of TinyOS message buffers to handle more children than other motes in the network 4 It forwards all messages upstream and downstream from the client using a standard serial framer protocol 5 XMeshBase can periodically send a heartbeat message to the client If it does not get a response from the client within a predefined time it will assume the communication link has been lost and reset itself 9 2 1 Serial Protocol The base station communicates with the host through a serial bus at a baud rate of 57 600 bps The incoming and outgoing packets are framed using a PPP HDLX protocol http www faqs org rfcs rfc1662 html In XMeshBase this is handled by the FramerM TinyOS component The format of the packet 1s e The raw data packet is wrapped on both ends by a
37. data can be transmitted After the message is transmitted the code detects if it s time to send a health packet If so the sleep command is restarted with health packets enabled If not sleep is called without issuing health packets In a typical ELP mode operation for example the XMesh ELP application TestElp2 the health packets are generated automatically even when the ELP mote is asleep by ensuring that the health interval is smaller than the sleep interval In the default ELP mode the maximum health packet interval is thus constrained by the sleep interval The user may control the health packet transmission by disabling the automatic generation of health packets while the node is asleep This can be achieved by setting the health interval to be greater than the sleep interval refer PressureSensor h in TestElp application The users would now have to create their own health timer to periodically transmit health packets at intervals greater than the sleep interval Therefore in the TestElp application we use a separate health timer to initiate periodic health packet transmission Fire Update Timer Repetitive Fire Update Timer one shot Measure Sensor d P gt Yes m Call Elplwake Elplwake_done B XmitData Z O No sleep force sleep 1 Yes Sleep force sleep 0 3 7 Estimating the
38. displayed in the tree view control as shown in Figure 10 6 Doc 7430 0108 01 Rev D Page 89 Crossb w XMesh User s Manual eles File Settings Help LacalPragram Remote Program Operation Option Select File to be Programmed v Check Base HeartBeat Select Check Operation Timeout Select Slot LI Ready Preparing Programming LJ Rebaoting Search Prepare Query Program Reboot Stop Searching network Select Nodes e g 1 3 7 11 12 17 serve Connected to XServe Crossbow Inc 2006 Device mib510 Pork com Search 00 00 12 x Figure 10 6 Searching for nodes within the mesh network 4 NOTE The base node will periodically blink with a magenta background This indicates that heartbeat packets sent by the base firmware are being received by the PC This verifies that the base station has been correctly configures 4 The Motes can now be rebooted to the OTAP image OtapGold exe by selecting nodes from the tree view control and pressing the Prepare button Nodes can also be selected by entering their IDs into the Select Nodestextbox During this process the Prepare button will be disabled and the selected node will turn blue 4 NOTE The node IDs entered in the Select Nodes textbox override the node selection in the tree view control When the nodes have rebooted into the OTAP image their background color will turn gold as shown in Figure 10 7 Page 90 D
39. environment 1 MoteConfig dialog window can be started from MoteView by clicking on Tools gt Program Mote or by double clicking icon on your Desktop This will bring up a window shown in Figure 12 1 Click Local Program on tab motetontio MNT File Settings Help Platform Type Radio Band MHz Addresses MOTE ID o Hex Auto Ine Route Update a Sec GROUP ID 100 Hex Badin Packet Size Butes Las 7 gn Payload Size HF Channel MHz Head Fuses Clear Text View Details Pragram OTAP Enable Shop m MM MMM Bytes Crossbow Inc 2006 Device mib510 Port com Figure 12 1 Screenshot of MoteConfig GUI Window 2 Click on Settings gt Interface Board Settings and choose the proper MIB gateway and check that the port settings are correct M EXAMPLE 5 1 Left screenshot shows Interface Board Settings for an MIB510 on COM port 1 Right screenshot shows Interface Board Settings for an MIB600 with IP address 10 1 1 248 and on the same LAN as that of the PC Doc 7430 0108 01 Rev D Page 109 XMesh User s Manual Crossb w Interface Board Settings Interface Board Settings Parameters MIB510 Serial Port come 57600 MIB520 s First Serial Port Prog Comm MIESO Host 10 1 1 88 10007 10002 com a 57600 C MIB520 s First Serial Port Prog Comm MIBGO0 Host localhost 10007 10002 3 Right click on the Select button on t
40. frame synchronization byte of 0x7E This 1s used to detect the start and end of a packet from the stream e The raw data packet uses an escape byte of 0x7D This is needed in case a byte of payload data is the same as a reserved byte code such as the frame synch byte 0x7E In such a case the payload data will be preceded by the escape byte and the payload data itself will be exclusively OR ed with 0x20 For example a payload data byte of 0x7E would appear in the data packet as 0x7D Ox5E e Ona Windows XP machine multiple byte values are byte swapped in the data stream For example the 2 byte UART Address field 0x007E will appear as 7E 00 in the byte stream The Table 9 1 describes the raw data packet Table 9 1 Raw Data Packet Structure Sync Type Data Data CRC Sync Ox7E 0x42 TOS Msg Header Payload OxAFE2 Ox7E 0 Ssynch byte Always 0x7E P PACKET NO ACK 0x42 User packet with no ACK required User packet ACK required Includes a P PACKET ACK 0x41 prefix byte Receiver must send a P ACK response with prefix byte as contents Page 76 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Byte Field Description P ACK 0x40 The ACK response to a P PACKET ACK packet Includes the prefix byte as its contents P UNKNOWN OxFF An unknown packet type 2 n 1 Payload Data In most cases will be a TinyOS Message of varying length which is described below SYNC BYTE Always Ox7E 9 3 Building
41. input Page 26 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual ce a amp B en POO O RFIN c4 VSNSR gee 8 T zm J FF _OLT 47 CHF_OLT bor Toe OUT RESI Cx a A xasc i XOSc2 d THERM PWR gt The ADC uses the battery voltage as a full scale reference This means the full scale of the ADC 10 bit or 1023 is proportional to the battery voltage For example when the battery voltage 1s at 3 2V an ADC value of 1023 will be measure for a full scale voltage input voltage of 3 2V But when the battery voltage changes to 2 7 volts the full scale will now correspond to this battery voltage 3 34 3 SPI Bus The SPI ports are master slave synchronous serial ports The SPI bus on both the MICA2 and MICAz are dedicated to the radio interfaces They are also used during programming to load code 3 35 12C This port is a low speed serial interface that supported by many sensor and devices It is available to users and supported by several Crossbow sensor boards 3 3 6 Thehardware h File In the Mote Works tos platform directory there are other directories for each hardware platform such as MICAz MICA2 supported by MoteWorks This file mainly maps the processors I O pins to signal names used by the application and TinyOS code For example TOSH ASSIGN PIN RED LED A 2 assigns the red led control pin of the ATmegal28 Port A Pin2 to the name RED LED This allows the red led to ca
42. invoked While the node is in ELP sleep mode health packets are periodically 1nterval specified by the user sent to the base station and with an expected acknowledgement from the base station If the acknowledge does not return within a set time it will try again with up to iRetries After the iRetries it will return a sleepdone with failed and not try again until ElpI sleep 1s called again If an acknowledgement is received then the service will stop XMesh start a timer health interval and put the radio to sleep After the health interval the ELP node will wake up and send another health packet waiting for an acknowledgement It uses the same timeout strategy as previously described After the duration time interval has elapsed the sleepDone event will be issued with SUCCEED with the radio powered on This service can optionally go into the sleep mode with or without sending the initial health packet The parameter force sleep is used to control this behavior if it is set to 1 the ELP node will go to sleep immediately after ElpI sleep is called without sending the initial probing health packet if it is set to 0 the ELP node first sends a health packet to the base and Page 68 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual won t sleep until the acknowledgement is received Note that in either case the node will send health packets to the base station periodically and will do iRetries if no acknowledgement is received
43. it will use the same parent but if it s not successful it will try to use another parent from the table e They will periodically user defined power up and transmit a health message to the base station using end end acknowledge If they receive an acknowledgement they will go back to sleep If no acknowledge 1s received the ELP node will try several times again before giving up ELP motes transmit route updates but advertise their cost as infinite which means that no other mote will pick them as a parent ELP motes assume that the network topology regarding their parents 1s static If the neighborhood experiences drastic changes eg all parents are turned off then the ELP mote will start a fast formation process to pick a new parent before it goes back to sleep This generally means the ELP node will stay awake for 2 3 route update interval 8 2 Operational Theory of ELP On start up the mote needs to join the mesh This is done by calling ElpI route discover rui The service will wait up to rui ROUTE UPDATE INTERVALS to join the mesh The event ElpI route discover done success parent signals the result 1f success is TRUE then the ELP node has successfully joined the mesh and parent parameter contains the ID of the parent If success 1s FAIL the node has failed to join the mesh and parent contains broadcast address And the user needs to decide whether to try again or sleep After the mote has joined the mesh the E1p1 sleep can be
44. lightweight batteries such as a coin cell battery for long periods of time e Ease of Use The network protocol allows the sensor network to initialize itself in a highly ad hoc self organizing manner e Scalability The network must support the number of nodes required immediately and must also be able to support future growth without causing exponential growth of overhead e Responsiveness Topology discover and re discovery must be efficient especially for applications where sensor nodes are mobile such as in mobile machines or equipment or for wearable sensors e Range It is more power efficient to emit low strength RF singles to travel a short distance and be relayed a number of times than to transmit higher strength signals for longer range Repeaters form a network using a protocol that supports multi hop routing so that data packets can be relayed from one repeater to another when the mobile RF terminal 1s far away from the base station Doc 7430 0108 01 Rev D Page 1 XMesh User s Manual Crossb w e Bi directional communication Communication between the gateway and sensor is bi directional to enable the base station to transmit signals to adjust certain operating parameters in addition to receiving signals transmitting sensor data e Reliability While data reliability is always important 1t becomes a critical requirement for many applications for example in medical monitoring e Small module form factor
45. of XMesh except XMesh ELP Motes act as FFDs e Gateways Aggregate the data from the network interface to the host LAN or the Internet and act as a portal to monitor performance and configure network parameters e System Software provides the networking protocol to enable the self configuring self healing ad hoc network Crossbow XMesh networks make no distinction between RFDs and FFDs except for XMesh ELP All Motes can have integrated sensors and also forward messages upstream and downstream Topology refers to the configuration of the hardware components and how the data is transmitted through that configuration The three most common topologies are star mesh and star mesh hybrid Each topology presents its own set of challenges advantages and disadvantages and each topology is appropriate under some circumstances but may be unsuitable in others 12 1 Star Topology A star topology is a single hop system in which all wireless sensor nodes are within direct communication range usually 30 to 100 meters to the gateway All sensor nodes are identical they are all endpoints and the gateway serves to communicate data and Page 2 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual commands to the sensor endpoints The gateway is also used to transmit data to a higher level control or monitoring system The endpoints do not pass data or commands to each others they use the gateway as a coordination po
46. rate Data bits Stop Bits Handshaking ETT C eoo 9600 C 56000 C 5 9 a none _ Disconnect C 1200 C 14400 amp S7600 C6 ae A Tee About EM F 2400 f 319200 Tian f 7 RTS CTS XON XOFF Quit C 4800 38400 256000 8 ES fre ere Settings Auto Diz Connect Set fort Time CHe LF Receive Reset Counter 13 Counter 27 HEX Shing StartLog Dec Hex Bin OSCDPERF Debug GrouplD 103 Mode 4 i OSCOPERF Debug Groupo 103 Mode 4 dataTask readinalumber 10 dataTask readingMumber 20 dataTask readingNumber 30 dataTask readingMumber 40 dataTask readingNumber 50 dataTask readinaMumber 60 Figure 3 16 Terminal Program showing SODbug A WARNING sopbug takes over control of UARTO Be careful of conflicts between SODbug and any UART messaging TinyOS may be doing Page 46 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 4 XMesh Overview This section gives a general overview of XMesh and discusses e The different power configurations for XMesh e An overview on how XMesh forms an ad hoc network 4 1 XMesh Power Configurations Crossbow sensor networks can run several power strategies Each strategy 1s a trade off between power and data rates For systems that have continuous power XMesh HP 1s the best solution This offers the highest message rate typically proportional to the baud rate of the radio For battery operated systems that require multi month or multi year life
47. s Manual Peles File Settings Help Local Program Remote Program Operations Option W Check Base Heartbeat Select File to be Programmed C Program Files Crossbow MoteYiew 4 20 meshsmicazsesMD select Select Nodes amp e g 1 4 7 11 12 17 Select Slot Ready Preparing 2 Check Operation Timeout J Programming Rebooting Begin scan C Program Files Crossbow Moteview 4 2D mesh micazvsMDATUDEB a 903 hp exe Mesh protocol found Converting C Program FilessCrossbowM oteVview 4 20 Smeshsmicaz esM DAT UDCB SU hp exe to C Program FilessCrassbow M oteVview T 4 z US s meshSmicazsMDATUDCB 903 _hp eee thes Process completed Made 2 iz ready ta Quem Program or Reboot Node 1 is ready ta Query Program or Reboot xnLap exe sf localhost 9001 2 F C Program Files CrossbowsMoteview 4 20 emesh Wicas M041 00CB_ S3 hp exe hex 1 2 Downloading Page 6 of 13 Crossbow Inc 2006 Device mib510 Port cam Programe 00 00 45 x Figure 10 10 Programming the nodes in the network via XOTAP Open the Process Messages window by clicking on File View Process Details to trace all downloading steps as shown in Figure 10 11 When all the selected nodes are successfully programmed the color of the selected nodes turns back to gold Process Messages Starting download Page 1 mote 1 128 fragments throttle 30 msec Page 1 mote 1 29 fragments throttle 3
48. s Manual Crossb w 8 3 The XMesh ELP Interlace 2 2 carnorecsparnadsnapsaussaoutbuntearedesasasmnemansaucaaontteatpannadaaaans 69 Sob Bolding A Mes E EP eeu atte woo tutto aso CIR M EIE 72 Be desti X MESME LP s o bui aeina A Ro ANE to n uou edic s doa ud Mus e DEDE 73 8 6 Monitoring the Network with XSniffer oiscosotisastu usu tee uv tu xou deua bu Diana Eua uma o uM eU 73 EP SUCCI PL e 75 Oil WHAT CS VICSIS ASC dT TERR T3 9 2 AMeshBase SONICS eeo O dc tUD DIES 76 95 Burdine AVES BASS enrian N buda o NNN 77 OA Usno the TICartDe at coii Messed totes t te ota ties an redes 78 IU MIMIESI SEF VICES oorsien aene aT EE EE 79 10 1 FIC AIT S FatlsEle Scis tt aneca ds E Ua dessus Dodo Maec lees tap diatt Ua dan d 79 10 2 Over the Air Programming OTAP cccccccccccccccceeceeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeees 82 10 3 OTAP usine MoreConfig Utility 5 eet tro ttes 89 IOA iM RT P E 977 10 5 Time Synchronization for Low Power 32d rete eth e iet a n 977 E EE S E LEID 102 11 1 Building and starting XSnlfier soe o UB M EM E 102 li 2 ENSIS XSA ON a na dede idoneo deett pu dn red Oba seeder ee 102 12 Moe oni ciao oid p ern desea Edit Web D ditus 109 I3 Appendix A XMesh Constants 5o iter i Reese Erd Ee RR RE EENL EE EE TIS RR a Einnar RM Roo EY RR AVR 112 14 Appendix B MICA FUSE SETTINGS eee ee eee eee eee eee eee e eee sensa ss e teens
49. same radio band and channel yet filter communication by group id The Table 2 2 shows the available radio channels for the MICAZ 802 15 4 radio USA FCC amp Canada regions have 27 total channels allocated Channels 11 to 26 are in the 2 4 GHz band Page 10 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Table 2 2 IEEE 802 15 4 Channels All frequencies are in GHz pere ERR an a0 2 474 2 475 2 476 2 479 2 480 2 481 2 1 2 Makefile The Makefile contains build specific parameters Most importantly it defines high level services which should be included for the particular application by way of a list of goals The file is located in Mote Works apps specific app name gt An example Makefile 1s Users can either edit the Makefile for these parameters or include them in the command line The command line will override any parameters set in the Makefile M EXAMPLE e To force XMesh HP for a MICAz make micaz route hp e To force a base station build for a MICAz and XMesh HP make micaz base route hp An example of a Makefile 1s include Makefile component include e a Maker bowloc cal Automatically add certain command line goals GOALS basic freq route hp Doc 7430 0108 01 Rev D Page 11 XMesh User s Manual Crossb w Table 2 3 Makefile Services basic Responsible for including the standard Crossbow services This service should be included in all XMesh applica
50. the Application Timer Period Type Description sec UpdateTimer 1 Repeat Sets sampling interval fires WaitTimer 1 One shot Sensor power is turned on and a measurement made HealthTimer Fires to signal that a health packet should be transmitted When the mote is powered on it must join the mesh It does this by calling Elpl route discover conma nN reS ulte Ee ME SI OL QIENA ODE e EE EIE NE call UpdateTimer start TIMER REPEAT gSampleInterval eoculueskecubiedetibstitu e esserci db dU ME edente dele as a P I E ono Meee LES call xMeshl ontrol start call boContro ll enable eal Ei poo onem sc e EDI TES UTET OES COVERIN E pressureDataPtr pressureMsg call COMM getBuffer dataMsgPtr amp Len Pee ns WSC ENS ON During this time the mote will be on all the time users could modify this to put the mote to sleep for a period of time then try again if the E1pI route discover done returns with a fail Any data message transmitted during this time will default to the broadcast address Oxffff and not be forwarded to the base Doc 7430 0108 01 Rev D Page 35 XMesh User s Manual Crossb w N WARNING When joining the mesh the ELP Mote needs to stay awake for several route updates ROUTE_UPDATE_INTERVAL to join the mesh Once the Mote has joined the mesh the normal data transmissions can start Before each data transmission the radio 1s forced out of the sleep mode Once XMesh signals that the radio is on
51. upstream message from the mote gt IMPORTANT For downstream communication the base station Mote must have received at least one upstream message from the node data health or any other type of upstream message Messages can be sent with two QOS Quality of Service levels 1 Link level acknowledgement This QOS provides transmission retries between a sender and receiver mote if an acknowledge message is not received by the sender This QOS does not guarantee that a multihop message was successfully transmitted from the originator to the base station or downstream Using link level acknowledgement is the best QOS for low energy and is appropriate for systems that require the lowest energy and don t require 100 delivery of data 2 End to End acknowledgement This QOS combines link level acknowledges with an end to end acknowledge For upstream messages the base station will return an acknowledgement to the originator For downstream messages the base station will receive and acknowledge from the intended source The XMesh API allows the user to determine 1f the message should be resent This QOS consumes more power than just link level acknowledges and also consumes more of the RF bandwidth Users can for any transmission use either link level or end to end acknowledgement with link level acknowledgement XMesh provides a set of TinyOS data and interfaces that allow users to wire TinyOS components and call them from their applicatio
52. 0x00 0x00 OxOb OxeG 0x00 0x00 0x00 0x00 Oxdd Ox1b Oxb1 0x01 0x00800020 0x00 0x43 0x00 0x09 0x00 0x00 OxGe 0x00 Ox10 OxOf Oxd8 0x22 0x00 0x50 0x00 OxOO 0x00800030 0x44 0x28 0x00 0x00 Oxff 0x00 OxOd 0x07 0x01 OxGf OxGf OxGf 0x00 0x00 OxOO OxOd 0x00800050 0x00 0x00 0x00 0x00 0x00 0x00 0x00 OxGO 0x00 OxOO 0x00 OxOO 0x00 0x00 0x00 0x00 0x00800050 0x08 Oxe6 0x00 OxOb 0x13 0x20 0x00 0x02 0x00 0x40 0x00 0x00 0x00 Oxf3 Ox10 0x82 n naganaacna avis avann a an lavan laenn lavan lavan lavan lasni lasni laenn laenn lavan avan lavan Ava Figure 3 14 Viewing CPU Registers ASSR is at 0x800050 When viewing the assembly code see Figure 3 15 the instructions show just the offset from 0x800020 3 8 6 Viewing Variables Selecting the View gt Watch Expressions allows users to enter the names of variables to monitor There are two types of variables to monitor 1 Global parameters These are global to the module To enter these parameters in the watch window requires entering the name of the module name of variable For Page 44 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual example to watch gSampleCount in the PressureSensorM module enter PressureSensorM gSampleCount in the watch window and Add entry OX PressureSensorM gSampleCount uint8_t 0 X0 msg TOS MsgPtr Ox8008ab
53. 1n its route update messages XMesh executes a parent selection task every 8 RUIS it 1s assumed that a node needs this duration to be long enough to gather information about its neighbor and make good decisions based on the information XMesh speeds up the Mesh formation time by introducing a fast formation mode Once a node enters this mode for example the node just boots up or loses its old parent etc it executes the fast formation algorithm and picks a suboptimal parent in order to join the mesh quickly it will switch to the best parent later Since a potential parent has to be part of the Mesh to be considered as a parent candidate the time for a node to join the Mesh is a function of RUI and hop count As a rule of thumb the nodes one hop away from the base station will join the Mesh in 1 RUI nodes two hops away will join the Mesh in 2 RUD so on and so forth and it will take 8 RUIs for the Mesh to get stable Page 50 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 5 Sending and Receiving XMesh Messages This section discusses how to send and receive messages from an application via the XMesh network It includes e Description of XMesh multihop messages e XMesh Messaging API e Using the XMesh API 5 1 TinyOS Multihop Messages XMesh messages are TinyOS messages with additional information about the message routing Table 5 1 XMesh Message Structure Header Composed of standard TOS header and XMesh multihop heade
54. 27 3 9 Usine A Timo a RESOURCES dieta att a aita ibant mds 24 34 Low Power CC RAO Mis aie E UU UU N Sees eens 30 35 Optimizine Tor Battery Operation i o e Rit et ota du 32 3 6 JAXLowPowerDesign Example iei o eine Rio RR ees 34 3 7 Estimating the Average CUITeDU o rii Hb e ma re ta Mus nA aus 36 z8 Hardware Debuppmg Techitques aue oe Here one ii nee het tie po ptu eni tet aepo ge 38 NEP SUL ubi auam M Ad Mesh Power Con ouros 5 odae eit ee tette buoni bebe fentit bit AA 47 4 2 Forming a Multi hop Mesh Network d ee e perta ertt ertn teer pte re MS 48 5 Sending and Receiving XMesh Messages cce eee eee eee eee ee eee eee ettet eese es ssssssne 5d TinyOS WiulttBop MeSSaBeSu qo OG P S UN P o tut 51 52 eesti Wess cin XNDIT ooi et D rao T a P 51 5 9 Usmo the Messa me APlus topi sana A N 55 X Mesh Route CONtOIS i ccssesasesdevcacctscccassedscatacdseetaawadeveateddssbeadsnasaswadssshacdsassaaseadssacesseueasss XMesh LP Low POWeE oec etedeesbs esvevevekuso Iba diver a Ju OU POWOFODOROGUOHisdicetesatece n edaseddtu ani uo Se oce rbr heu eoru ue ate ue PURA TN 62 8 XMesh ELP Extended Low Powe 2 ccccccccscsccscccssccscsccscccsccccccccscccccsccscccscccsesces SE Wiame GPO Je aut aei A N autc etat gcdet iue qd Apc E AAEE 67 82 Operational Theory ob DP uoo M OU Mace E M Ss uM E 68 Doc 7430 0108 01 Rev D Page XMesh User
55. 3F Ner LGs Co RFS ooo 829 Do cil Hye jJ ERIT ac 1 005 127 14 n j2 m5 100 100 44 lad o 100 80 0 lal os nes ha P ps 093 e jd 5 j089 ls lai 025 155 13 30 p 15 3100 4 100 100 8 al ji 4 Doc 7430 0108 01 Rev D Figure 11 5 XSniffer Neighbor Screen Display 11 2 7 TimeSync This tab displays time synchronization messages Table 11 6 XSniffer TimeSync Tab Parameters w HeWesedngm OOOO Elapsed Time Global time as referred to the base station see Options Tab Skew msec The time difference between the time message and the base station time This computation is based on when the PC time stamps the incoming message Due to variable time delays in the sniffer and serial port communication this computation is only roughly accurate 100 msec Number of time sync messages detected How long ago in second the last message was received Page 107 XMesh User s Manual Crossb w Q XSniffer id Phase Cor Authority 40 4 4 Figure 11 6 XSniffer TimeSync Screen Display Page 108 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 12 MoteConfig MoteConfig 1s a GUI utility for programming Motes It provides an interface for downloading pre compiled TinyOS software applications A major benefit of MoteConfig is that Mote platforms can be programmed without having to install the TinyOS programming
56. 5 msec Page 1 mote 1 6 fragments throttle 40 mec Page 1 mote 1 0 fragments throttle 40 mec Page 1 mote 2 0 fragments throttle 40 msec Page 1 finished Page 2 mate 1 128 fragments throttle 40 msec Page 2 mote 1 29 fragments throttle 45 msec Page 2 mote 1 4 fragments throttle 50 mec Page 2 mote 1 1 fragments throttle 50 msec Page 2 mote 1 fragments throttle 50 msec Page 2 mote 2 0 fragments throttle 50 msec Page 2 finished Page 3 mote 1 128 fragments throttle 50 msec Page 3 mote 1 2 fragments throttle 50 mec Page 3 mote 1 fragments throttle 50 msec Page 3 mote 2 0 fragments throttle 50 msec Page 3 finished Figure 10 11 Trace all downloading steps 7 Reboot The last step is to reboot into the newly loaded image for the selected nodes To do this check the nodes you want to reboot specify the Slot and click on Reboot Alternatively you can type the node IDs in Select Nodes box When all the selected nodes are successfully rebooted you will see the output shown in Figure 10 12 and the color of the selected nodes turns back to Green Doc 7430 0108 01 Rev D Page 93 XMesh User s Manual Crossb w f MoteConfig ER E c xl File Settings Help Local Program Remote Program Operation Option Select File to be Programmed v Check Base Heartbeat C Program Files Crossbow MoteView 4 20 xmesh mica2 XMD
57. 7 O0 9 OC3C INT5 PES U 7 ATmega128 L 42 1 PC7 A15 PC6 A14 SS PBO C SCK PB1 O 11 38 O PC3 A11 MOSI PB2 O 12 37 O PC2 A10 MISO PB3 OCO PB4 O 14 35 0 PCO A8 OC1A PB5 O 15 34 1 PG1 RD OC1B PB6 g 40 O PC5 A13 RESET L 20 XTAL2 XTAL1 PDOL 25 PD2 PD3 PD4 PD5 m Qm QE m Qm Qm 0 GR Qm TOSC1 PG4 19 NT1 NT2 NT3 CP1 CK1 T1 T2 TOSC2 PG3 C OC2 OC1C PB7 SCL INTO All X SD RXD1 TXD1 Figure 3 2 ATmega128L Microprocessor Pinout Page 24 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual The ATmegal28L can operate up to 6 volts maximum power input and down to 2 4V Typical operation is from 3 6V to 2 4V The ATmegal281 V can operate up to 6 volts maximum voltage input and down to 1 8V The output voltage of the GPIO and other pins on the processor will track the operating voltage 1 e when turned on they will be at the operating voltage OCOB PG5 RXDO PCINT8 PDI PEO TXDO PDO PE1 XCKO AINO PE2 OC3A AIN1 PE3 OC3B INT4 PE4 OC3C INT5 PES T3 INT6 PE6 ICP3 CLKO INT7 PE7 SS PCINTO PBO SCK PCINT1 PB1 MOSI PCINT2 PB2 MISO PCINT3 PB3 OC2A PCINT4 PB4 OC1A PCINTS PBS OC1B PCINT6 PB6 YO OC ce d ME DEN us NE a C T A 0 FF WH ue wN CO CIE ee seco T TET wl C IM 3 3 Ei Ae al FEAT ET et CY 0O O TENTE 2 0 9 0 0 2 0 E ee 3 O 4 AJ e xp Ly tO oa rr e Se ckei
58. A very small form factor for the network modules is needed so that endpoints can fit inside or attach easily to an existing device A robust networking protocol is needed to meet the above requirements as well as those of a particular mesh networking design The networking protocol provides support for the network s topology and manages the routing of data through the network In order for the application to benefit from the promises of wireless sensor networking the underlying protocol must support all of these basic requirements 1 2 Topologies There are several architectures that can be used to implement wireless sensor network applications including star mesh and star mesh hybrid Each topology presents its own set of challenges advantages and disadvantages In order to understand the topologies you need to be familiar with the components of a wireless sensor network These components include e Endpoints Integrate with sensors and actuators to capture the sensor data For ZigBee networks these are commonly referred to RFDs Reduced Functional Devices RFDs cannot forward network messages upstream or downstream XMesh ELP Motes behave as RFD devices e Routers Extend network area coverage route around obstacles and provide backup routes in case of network congestion or device failure In some cases routers can also act as endpoints Routers are also referred to as full function devices FFD in a ZigBee network All versions
59. Average Current The average current can be estimated if the following is known e Current of each operational state e Duty cycle of each operational state For this application the operational states are Page 36 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 1 Sleep The system is in this state approximately 95 of the time 2 Timer0 This timer service 1s always running as it supplies timer services for all the TinyOS components For the MICAz this timer wakes every 230 msec for 400 usec increments a counter and goes back to sleep During this time the processor 1s using 8 mA of current 3 Measure Sensor For this application the sensor 1s on for 50 msec The ATmegal28 1s used to measure the sensor output timer counter so the lowest power state for the processor is the idle state 4 mA Also the sensor itself consumes 400 uA The measurements are done every second so the duty cycle is 50 msec 1000 msec 4 Transmit Data This occurs every twenty seconds for the application The data packet 1s transmitted in about 4 msec but the MAC layer adds a random back off of about 4 msec Also the link level acknowledgement adds about 2 msec for a total of about 10 msec that both the radio and processor are awake 5 Health Data Health packets are sent only every several minutes Sending a health packet 1s similar to the data packet except that 1t uses end to end acknowledgement The time to receive the acknowledgement depends
60. EEN UNE TE pojo Mote TX switch SW2 Te m Connector This should normally be a in the OFF position RS 232 Serial Port DBS female ISP LED red Power OK LED green MICAx series connector MICA2DOT connector on bottom side Lan 4 Mote JT AG connector Figure 3 7 MIB510 Serial Programming Board 3 Mount a MICA2 or MICAz for debugging on the MIB programming board Doc 7430 0108 01 Rev D Page 39 XMesh User s Manual Crossb w Figure 3 8 MIB510 Attached to Atmel JTAG for Debugging N WARNING Do not attach a sensorboard that uses the analog to digital ADC4 ADC7 pins as these pins are used for JTAG Normally power is supplied to the JTAG via the MIB board s external power supply If the pod is configured to supply power to the mote then do not power the MIB board from the external power supply 4 Setup the environment variables for avarice This can be done in the PC s environmental variables system variables Environment Variables User variables for abroad Value C Program Files Microsoft Visual Studi C Program Files Microsoft Visual Studi C Documents and Settings abroad Loc C Documents and Settings abroad Loc System variables j dev ttySO ComSpec C WINDOWS system32 cmd exe Edit System Varia ble FP_NO_HOST_C NO FRAMEWORKPATH C VXIpnp WinNT INCLUDE C Program Files Microsoft Visual Studi Variable name AVARICE ARGS Variable value j de
61. K Radio Clock 4 THERM PWR GPIO 48t RSTN Micro Processor Reset m mw feo s wc Votage baton 4 Es e eo s ono sew ie tShared use ttDO NOT use For in system programming ISP 3 2 ATmega128 Resources The ATmegal28L and ATmegal281 microprocessors run both the user s application and the XMesh protocol stack The table below summarizes the internal and external resources of the ATmegal28 family of microprocessors Page 22 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Table 3 4 Resources of the ATmega128 family Microprocessors Program b bas E the application ecd is ene Memory 128K Bytes 128K Bytes through an ase station or using When reprogrammed the entire memory is erased except for the Flash Memory bootloader section This memory section is used to store user application 4K Bytes 8K Bytes parameters XMesh variables and TinyOS variables It also contains the stack This memory is used to store persistent values such as mote_id group_id radio channel etc TIMERO In ATmega128L 8 bit is used by TinyOS and is available to the user via the standard TinyOS clock services EEPROM 4K Bytes 4K Bytes In ATmega1281 8 bit is not available to the user on the IRIS it is used by the TinyOS radio stack and cannot be used otherwise TIMER1 16 bit is available to the user TIMER2 In ATmega128L 8 bit is only available to the user on the MICA2 For MICAz it is u
62. Manual 7 1 1 Low Power Strategies Since the OS already takes care of the power management of the processor the focus then shifts toward making communication less power intensive It should be noted that most sensor network applications have very low data rates that do not require continuous processor or network activity Any strategy that tries to reduce energy used by the radio should take advantage of the low duty cycle requirements of typical sensor network applications However it is not enough just to power down the radio when it s not sending a message A radio must also be able to receive messages from its peers and know when to power on the radio for reception Power Cycling Some nodes in a network are known ahead of time to be edge devices that do not need to participate in routing These devices can adopt the power strategy of powering on the radio when they need to communicate and then powering off when the transmission 1s completed XMesh ELP This assumes that these edge devices will be able to make contact with a node that 1s capable of routing the message from the edge device through the network Power Cycling on a Known Schedule This strategy involves power cycling the radio on a fixed interval by all nodes in a network Every node using this strategy will periodically power on their radio to listen for activity The listening time of a node 1s fixed and the interval between each channel monitoring 1s also fixed The period b
63. N dann soe Figure 2 1 Screenshot displaying XSniffer Output 2 4 Using Binaries i 145 1 oO m ah ot _ EE a ed d nnn o a 1 mo no 0 mo ww WO Oo Oo MMM Nh Crossb w Crossbow provides XMesh in the form of binary components which allow users to link to XMesh object files and use services provided therein The default make commands will use these binaries For example builds the MICAz high power mesh using the binaries files The XMesh binaries are located Moteworks tos lib X MeshBin make micaz route hp Doc 7430 0108 01 Rev D Page 18 Crossb w XMesh User s Manual 3 Hardware Overview This section gives a general overview of e MICAz and MICA2 hardware platforms e ATmegal28 resources e Using ATmegal28 resources e Low power operation e Optimizing for battery operation e Hardware debugging techniques 3 1 Hardware Platforms The table below summarizes the core elements of the MICAz MICA2 and IRIS hardware platforms Table 3 1 Hardware Platform Summary ud j v LEN ATmega128L ATmega128L ATmega1281 CC2420 2 4GHz CC1000 433MHz 916MHz RF230 2 4GHz External Serial AT45DB041 Flash 512 Kbytes The serial flash can be used for over the air programming OTAP and or data logging Unique ID DS2401P regs ea This chip contains a unique 64 bit identifier 51 Pin Yes except for OEM modules Connector This connector brings o
64. OMsd voldi payload link tbe Tgog emn here users can Set the Stare CO Stare Sending Mex Packer A common model is to start a one shot timer after a message 1s sent out If the end end acknowledgement is not received before the timer expires then the application makes a decision as to whether to resend the packet The recommended timer interval 1s 10 seconds for XMesh LP and 20ms for XMesh HP A typical example is the following In a task sendTask send out the packet and start the timer xe Meo cS ces P EDS Ee UST DS DORE SUNT ESSE SEM AN NGI E CUM SI uec suot co US be coe nce SI ES MIETEN AOR o Ear EA L EMERE OD NP oO ROT OD er E toro CURES One Ta des bAckWait TRUE When the timer fired event occurs decide whether to resend the packet based on a retry number event result_t TimerAck fired LE at NUM RE Re NUN eE iat post sendTask else reach retry limit num retry 0 bACkWwWaic FALSE EE recur SUCCESS If the end to end acknowledgement is received before the timer expired cancel the timer event FOS MsgPrr RevAck recerive TOs MsgPEr pMsg vold payload unnt lo t payloadien if bAckWait Gas messe VS Opn je num_retry 0 bAckWait FALSE return pMsg 4 NOTE There is no global sequence number in XMesh the sequence number in the XMesh multihop header is on a per hop basis which is used for link quality computation so the end end acknowledgement does NOT carry a sequence number
65. Radio Band 2420 MHz Type XMESH2 HP Addresses MOTE ID h Hex f Auto Inc Route Update 36 Sec GROUP ID f 25 c Hex Packet Size 36 Bytes Radio RFP 3 v D dB MS j Payload Size 29 Bytes RF Channel CHANNEL_26 v 2480 MHz Select Program OTAP Enable Stop Figure 12 3 Screenshot of MoteConfig which scanned the main exe executable file The MoteConfig displays the following information that was compiled into the application Display Platform XMesh Type Packet Size Payload Size App Sensor RF Power Radio Band Channel No UARTO baud Mote Id Group Id Health Update Route Update Table 12 7 MoteConfig Parameters The power output of the radio Displayed a register value and dBm The radio frequency band The radio channel within the radio band The baud rate for UARTO on the mote The mote address to program into the unit This address can be auto incremented after each unit is programmed The group id of the network The update rate sec of health packets The route update rate note all motes must have the same route update rate S S S S S No No No No No Ye No Ye Ye Ye Ye Y e Programmable Yes MoteConfig also allows users to load an OTAP image into the serial flash memory see Section 10 2 The Enable Watch Dog checkbox will enable a watchdog timer see Appendix A Doc 7430 0108 01 Rev D Page 111 XMesh User s Manual Crossb w 13 Appendix
66. Select Check Operation Timeout Select Nodes e g 1 4 7 11 12 17 Select Slot O Ready O Preparing 2 j C Programming O Rebsating Prepare aE Query NIE Program L Reboot Stop Node 1 is s ready to Query Program or Reboot Hode 2 is ready to Query Program or Reboot Node 1 ts ready to Query Program or Reboot Node 2 is ready to Query Program or Reboot Node 1 is ready to Query Program or Reboot Node 2 is ready to Query Program or Reboot Hode 1 is ready to Query Program or Reboot xolap exe sf localhost S001 42 p 12 II pbionis cmd boot sf localhost S001 group id 123 debug 1 hitml report file otap him image id motes 212 iRebooting mate 1 from slot Please wait for the mote to turn green Rebooting mote 2 from slot 2 Please wart for the mote to turn green Crossbow Inc 2006 Device mib510 Port comi Figure 10 12 Rebooting the Nodes in the Network The specified nodes should now start running the new application 10 3 1 OTAP Using Cygwin Interface For the users who prefer to Cygwin command line interface the following section describes step by step procedure for the OTAP The Users can also implement these command line arguments while developing their own client GUI l Page 94 Connect the base station to the PC interface board and turn on the remote nodes that were prepared as per Section 10 2 8 Start XServe on the PC connected to the ba
67. Size see Table 112 for 0 programmed details Select Reset Vector 1 unprogrammed m s s Doc 7430 0108 01 Rev D Page 115 XMesh User s Manual Crossb w The following table corresponds to bit settings 1n the uisp wr fuse setting for ATmegal28L Fuse Low Byte mT Default Value BODLEVEL 7 Brown out detector tigger level Brown out detector enable 1 unprogrammed BOD disabled SUTI i Select start up time 1 unprogrammed exse T saacana serene CRKSE WO Select Clock source 1 unprogrammed The following table corresponds to bit settings in the uisp wr fuse 1 setting for ATmegal 281 Fuse Low Byte Bit No Description Default Value fexour e Tooo rurea soni 2 eee e O GKSEL3S Select Clock source 0 programmed cria 2 SdectCrcksouce O ogtenmes Fem 1 SelstOiocsouce Tumewomm rexsei0 0 Selector souce o programmed The following table corresponds to bit settings in the uisp wr fuse e setting for ATmegal 28L Extended BitNo D ipti Default Val Fuse Byte it No escription efault Value M103C 1 ATmega103 compatibility mode 0 programmed Page 116 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual The following table corresponds to bit settings in the uisp wr fuse e setting for ATmegal 281 Extended Fuse Byte Description Default Value 1 BODLEVWL2 1 Brown out Detector trigger level 1 unprogrammed BODLEVWL1 1 Brown out Detector trigger level 1 u
68. Text labels in GUIs Doc 7430 0108 01 Rev D Page iii Crossb w XMesh User s Manual 1 Introduction This manual is intended for developers using Crossbow s MoteWorks software platform User s should have read or be familiar with the following e MoteWorks Getting Started Guide e TinyOS and nesC fundamentals This chapter gives a general overview of the XMesh landscape and features It includes e Mesh Networking Fundamentals e XMesh Overview e What is a Multi hop Network e XMesh Network Landscape e XMesh Features and Benefits 1 1 Mesh Networking Fundamentals Short range networks based on wireless mesh networking architectures have evolved to enable power efficient means for managing non computer devices Self organizing mesh network architectures have enabled new wireless machine to machine applications including motion detection sensors used on the battlefield thermometers gauging the temperature of food products and pharmaceuticals in transit and medical devices monitoring patient vital signs Wireless sensor networks can be designed in a variety of ways to address different priorities and make the appropriate technology trade offs based on the requirements of the application AII wireless mesh networking systems share a set of common requirements These include e Low power consumption To support long term operation the power consumption of the radio link must be minimized so that devices can be powered by compact
69. XMesh User s Manual Revision D April 2007 PN 7430 0108 01 WWwWw xbow com 2005 2007 Crossbow Technology Inc All rights reserved Information in this document is subject to change without notice Crossbow MoteWorks MICA TrueMesh and XMesh are registered trademarks of Crossbow Technology Inc Other product and trade names are trademarks or registered trademarks of their respective holders Crossb w XMesh User s Manual Table of Contents I Introductions sii ep ERE FIERE SER RINT ERES a a CINE UeS NEUE Ll Mesh Networking Fundamentals oet te ree to e ees l 1 2 80 01 0 221 lt p ere et ee et PE NA NNN 2 LS XII S TI Oy Civ PT UT H E 4 L4 XMesh Network Landscape geisha he ccs isteach ea foi Ma d did ea odisea 7 LS AXMesbecatutesaud Bencs 2 Heo NIE UMEN E E EE 8 Ze HD GX NCSI m DA Mesh DB uiidsE iyo nine Hb sooo ou rae Ed E NANI BM D UMEN EE 10 2 2 Building an XMesh Application cccccccccccccccccccccccccccccccecceeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeees 12 2 9 Deployme tle NetWork oce eM ON DM MN EE MM UL 17 24 Dsme BIBJEIeS sedent emot tendere ten Iu ettet EEN e ten ite e told tu tent ab itus 18 3 Hardware Overview sien ES Sub Hardware Plator S enia inet Sareshoadnnatadsinealecsddukaudhtet Sarsheadnneneesiestecsadelauasoetiste 19 2 2 wNATImebal28 ROUE ascia boost A tasUA MUR E US D COENA TUA CocDA UP dEUE
70. ach other to communicate A message can be delivered to one or more nodes in between which will route the data Likewise if there 1s a bad radio link between two nodes that obstacle can be overcome by rerouting around the area of bad Page 4 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual service Typically the nodes run in a low power mode spending most of their time in a sleep state in order to achieve multi year battery life XMesh 1s a software library using the TinyOS operating system that runs on embedded devices called Motes Motes consist of a 1 Microprocessor Atmel ATmegal28 for MICA2 MICA2DOT and MICAz ATmegal28 has 128K of flash memory 4K of RAM and 4K of EEPROM or Atmel ATmegal281 for IRIS ATmegal281 has 128K of flash memory 8K of RAM and 4K of EEPROM 2 Radio a MICA2 radio at 916 433 MHz or MICAz IRIS radio at 2 4 GHz 3 Serial Flash External flash storage memory to support OTAP over the air programming and data logging 4 UID An integrated circuit that is programmed with a unique 64 bit identifier for MICA2 and MICA2DOT The entire XMesh network consists of see Figure 1 4 1 One or more Motes which participate in the network 2 A base station node This is another MICA2 or MICAz mounted on a Crossbow MIB510 520 600 interface board and programmed with XMeshBase application It manages the network and forwards data messages into and out of the mesh 3 A PC Stargate or other
71. age and the current parent s RSSI is also included 10 1 1 Enabling Health Packets XMesh exports a command called health_packet that enables health packet reporting during run time command void health_packet bool enable uintl6_t interval if enable is TRUE the health packet will be sent out periodically every interval seconds Interval is usually set to several minutes in order not to impact the overall mesh message rate Typical values for interval are e XMesh HP 1 minute or more e XMesh LP 10 minutes or more M EXAMPLE also refer to MoteWorks apps examples XMesh Counts To Leds ess AT IC wari st qc add ADM Nealth packet gt SMCSRNEOUEE T Ara Ap M ne eho Usor caon enable tho hoadlth packet epos ehen ApoMane uses secibn ON add command void health packet bool enable uintl60 t intv NETTES NIS eCommerce doce onere Call health packet TRUE 600 10 minute interval TTo wi dTa leche heal eh packer epo tci Call health packet FALSE 0 Doc 7430 0108 01 Rev D Page 79 XMesh User s Manual Crossb w The base station will forward these packets along with other data packets to XServe for data conversion and then they can be relayed to MoteView for monitoring They can also be viewed with XSniffer see Chapter 11 10 1 2 Data Packet Health Header There are two types of health packets in XMesh e Statistics Health Packets e Neighbor Health Packets The two health packets are transmitted sequenti
72. al28 processor offers in circuit debugging through its JTAG interface This tool allows users to e Perform real time in circuit debug e Trace program execution directly e Access CPU registers RAM ATmegal28 peripherals e Set breakpoints e Change variables and jump over code In order to use JTAG the following are required e AJTAG pod such as the ones available from Olimex This device is available with both a serial port or USB connection http www olimex com dev avr jtag html Page 38 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 2 at Figure 3 6 Olimex JTAG pod e A MIB510 or MIB520 programming board These units contain a JTAG connector which connects to the JTAG pod The JTAG connector is labeled as J3 MOTE JTAG on the MIBS510 MIB520 To setup the JTAG environment 1 Connect the JTAG pod to a PC serial port or USB port 2 Connect the JTAG pod s 10 pin header to the MIB510 MIB520 Be careful of the orientation There is a silkscreen designator o by pin 1 of the MIB510 connector Also there is a square pad versus the other 9 round pads on the bottom side of the MIB510 MIB520 for pin 1 Usually the red wire of the flex cable connecting the JTAG header to the JTAG pod 1s pin 1 Make sure the polarity is correct N WARNING On the MIB510 DO NOT connect the JTAG pod to the ISP J8 connector This could erase the code in the ISP processor of the MIB510 4 NOTE Enable Disable NESECOW
73. all MhopSend send dest mode amp gMsgBuffer length Base sd Remote mote ID Remote mote ID o UPSTREAM A MODE UPSTREAM Hopes DOWNSTREAM A MODE DOWNSTREM Base BASE STATI ON ADDRESS 4 NOTE When calling the Mhopsend interface to send packets XMesh will decide the AM type for the message based on the mode parameter specified in the function call The appropriate AM type will go into the type field of TOS header and appID will go into the socket field of the TOSMHop Msg header The base station will respond with an acknowledgement when it receives an upstream message that requires end end acknowledgement It is up to the application to determine whether to retransmit the message if no acknowledgement has been received 5 3 2 Sending Upstream Messages Applications simply call the send command call Mnhoosencd send BASE STATITON ADDRESS MODESUP STREAM coMS GBut CHE pm Oki e and implement the sendDone event event result_t Send sendDome TOS_MsgPtr pMsg results success return SUCCESS 5 3 3 Sending Upstream Messages with End End Acknowledgements In order to receive the acknowledgement packet the application needs to wire in AppM RcvAck gt XMeshRouter ReceiveAck appID The appID should be the same as in the MhopSend send wiring Then the application implements the ReceiveAck event Page 56 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual even MOS IMsgGP Es RevAck receive TOSsMSsgPer
74. ally in an alternative fashion one every health update interval and use the same packet format All health packets use AM type 3 see Appendix A All Health packets have a similar header component which describes the information contained within the health packet Table 10 1 Statistics Health Packet Structure uint8_t type_node This is for backward compatibility The value of the first 4 bits for XMesh2 will always be OxF Any other value means this is an XMesh1 health packet rte version Most significant bit O high power mesh 1 low power mesh Least 3 significant bits 0 XMesh 1 version of health packet 1 XMesh 2 version of health packet uintl6 t type The value of this field indicates if the packet is a statistics packet or a neighbor packet Statistic packets have a type of 0x01 and neighbor packets have a type of 0x02 10 1 3 Data Packet Statistics Health Packet statistical health packets contain statistical information about the packets being sent through the particular node The following types of data are sent in this type of packet e Accumulating packet counter num node packets num fwd pkts num drop pkts num rexmits represent statistical information on packet transmissions from the node gathered since boot time e Instantaneous power information such current voltage readings and accumulated power usage in low power e Current parent id and information such as link quality and rssi value The s
75. am Optiorr v Check Base Heartbeat Operation Select File ta be Frogrammed Select Select Nodes amp g 1 3 7 11 12 17 Select Slot O Ready Preparing fe a LD Programming LJ Rebooting Search Prepare Query Program Reboot Stop cmd query Check Operation Timeout sf localhost 9001 group id 129 debug 1 html repart file xotap html mates 2 Mote 1 micaz time since reboot 1 1 min voltage 3 0 boot image 0 Image Hash start stop size checksum Type T 0 2973 ceg bootable 1 64 80 31103 faf2 bootable 2 empty empty Mote 2 micaz time since reboot 1 1 min voltage 3 1 boot image 0 Image Hash start stop size checksum Type 0 015 29773 49bb bootable b4 8D 31103 atal bootable 2 ex rptu 5 ae gt Crossbow Ine 2006 Device mb5l Potcom g Figure 10 8 Querying the Nodes in the Network for OTAP Image Doc 7430 0108 01 Rev D Page 91 XMesh User s Manual Crossb w 6 Program Click on Select and browse to the binary image of the XMesh application main exe that you want to program with Check the nodes you want to program and specify the slot where you want to store the application Alternatively you can type the node IDs in Select Nodes box Click on Program as shown in Figure 10 9 As the OTAP progresses you will see the report in terms of number of pages downloaded into the flash During the OTAP process
76. and 1 that defines weight of the new estimated value SE Send Estimate the radio transmit quality of the link to a specific neighbor it 1s obtained from the route update messages of the neighbor When a node broadcasts a route update message it also puts its neighbors RE in the packet so neighbors know what the SE is to this node 4 NOTE SE and RE are normalized to be a value in 0 255 with 255 being the perfect quality LC Link Cost to a specific neighbor Once SE and RE to a specific node are known the LC is computed as LC 1 lt lt 18 SE RE 4 NOTE If the link quality is perfect which means SE and RE are all 255 the LC is then 4 This translates to a cost of 4 per hop provided that the link quality 1s perfect Doc 7430 0108 01 Rev D Page 49 XMesh User s Manual Crossb w NC Neighbor s cost a value that is obtained from the Route Update Message from a specified neighbor OC The Cost value of sending message to the base It 1s calculated as OC LC NC The mote will pick the neighbor with the lowest OC as its parent 4 NOTE The higher the cost value the more energy is required to make a transmission to the base XMesh then uses the Minimum Transmission MT cost metric The purpose of the cost metric is to minimize the total cost it takes to transmit to the base station Mote Each node in the mesh network will broadcast its cost value The base station Mote broadcasts a zero cost
77. are allowed The XMesh network has been extensively tested both at indoor and outdoor locations In a typical indoor test nodes are placed at every 300 sq ft to cover a 10 000 sq ft facility To simulate larger distance between nodes the radio transmit power was turned down to 6dBm In outdoor tests nodes are spread across several acres of rugged terrain with an average density of one Mote per 10 000 sq ft and at full radio power Statistical analysis across many deployments shows on average greater than 90 of all traffic generated at any node will be collected at the base station without the use of end to end acknowledgements guaranteed delivery XMesh2 micaz upstream with end2end ack 120 0096 100 00 94999 999099 6 99e 99599494490090 9900049 80 00 o O 8 E 60 00 E a 40 00 20 00 0 00 0 10 20 30 40 50 60 Node ID Figure 1 5 Percent Packet Delivery for 48 Mote 72 Hour Test Page 6 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 1 4 XMesh Network Landscape A wireless network deployment is composed of the three distinct software tiers 1 The Mote Tier where XMesh resides is the software that runs on the cloud of sensor nodes forming a mesh network The XMesh software provides the networking algorithms required to form a reliable communication backbone that connects all the nodes within the mesh cloud to the server 2 The Server Tier is an always on facility
78. at communicate with parent nodes running XMesh HP A leaf node is defined as a node that does not participate in the mesh it never routes messages from child motes to parent motes The ELP version results 1s very low power because the mote does not need to use the time synchronized wake up mode to check for radio messages The mote can sleep for very long times In this mode the mote maintains its neighborhood list to remember which parents it can select If it does not get a link level acknowledgement when it transmits to a parent it will find another parent This can happen very quickly or may take some time if the RF environment or mesh configuration has changed considerably Doc 7430 0108 01 Rev D Page 47 XMesh User s Manual Crossb w The Table 4 1 shows the types of power modes supported by Crossbow Motes Table 4 1 XMesh Power Configuration Matrix Power Mode MICA2 MICA2DOT MICAz XMesh HP Y XMesh LP asynchronous and time synchronized LEN Asynchronous only Table 4 2 XMesh Performance Summary Table Parameter XMesh HP XMesh LP XMesh ELP Route Update Interval 36 sec 360 sec 36 sec if built using HP 360 sec if built using LP Data Message Rate 10 sec typ 180 sec typ Mesh formation time 2 3 times Route Update Interval for mesh with average of 2 5 hops Average current usage 20 30 mA 250 pA M 50 pA lt 400 pA f HI MICA2 LP using time synchronized mesh MICAz LP using asynchronous mesh 4 2 F
79. ate XMesh ELP only works for nodes which are located at the edge of the network These nodes do not forward radio messages upstream or downstream for other motes 1 e they can only be the children of other motes and never the parents The Figure 8 1 shows a graphical representation of the network topology The XMesh network using High ea E ad Power mode for nodes that make ZN oM i up the backbone and Extended Eu a FC Low Power mode for nodes k 1 along the edge iW i 1 Base Station Mote Figure 8 1 XMesh ELP Network Topology The ELP strategy is intended for applications were data is send very intermittently These types of devices normally sleep for minutes to hours or perhaps days Some examples of devices that could use ELP are e Light switches which only send messages several times per day For this application the device must quickly wake up and send the message Doc 7430 0108 01 Rev D Page 67 XMesh User s Manual Crossb w e Battery operated machines that are only used several times a day This type of application could require the machine to power up and start a communication session for a period of time then go back to sleep ELP Motes join the mesh through the following e On power up they will stay awake until they join the mesh This means that they have located their parents e They can then go into the sleep state The ELP node retains it s neighborhood table during sleep The next time it wakes up
80. beperrperszc z ze aN PEE a 8 8 8 5 8 8 8 2 Sd 8 8 INDEX CORNER ATmega1281 2561 iellsrziialimsi iesle eli ieleisreivli 3 e 81 8 LS lel L8 18 E Ls ll LS la lal SI LS Co L l LAJ LO LN LO Lej Loj LJ Lh Ley LE LAJ 5 Loy LO Re om Soe cC oW x Se NM CS XE T es ee Pi Sze ec ttreoerkeaae s ug 3 a a aa E O o e e e e e x rhe E Z tQ Q Z Z Z Z 0 D 7 Oo ae ME C Se B E ccm Mm eng d e Q o Figure 3 3 ATmega1281 Microprocessor Pinout PA3 AD3 PA4 AD4 PAS ADS PA6 AD6 PA7 AD7 PG ALE PC7 A15 PC6 A14 PCS A13 PC4 A12 PC3 A11 PC2 A10 PC1 A9 PCO A8 WARNING The MICA2 and MPR600 radio is rated to 5V The MICAz IRIS and M2110 radio is rated only to 3 6V The maximum output current per I O pin is 40 mA and the maximum current for the processor 1s 200 mA Doc 7430 0108 01 Rev D Page 25 XMesh User s Manual Crossb w 3 3 2 UARTs The ATmegal28 has two UART ports UARTO and UARTI They can operate in both an asynchronous and synchronous using a clock mode The external clock for the MICA2 and MICAz use a 7 3228 MHz oscillator which generates precise timing for these UARTS to support high baud rates N WARNING The internal RC oscillator does not support high baud rates Check the ATmegal28 manual UARTO is used by the base station mote for communication to a client device and configured as the default I O serial comm
81. conn SIG INTERRUPTO External Interrupt6 Named INT2 on expansion conn STONPU CENE OwpaCompemimemp swommrom Owdwiwampg Sre mnou eneren muCwue ampi 516 o0reor coneansia ouput Comare 516 outeur comas ouput Compareren sre overo foe 516 ouzeur coneanso ouput Comperomert sree oeo Page 28 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Uemwme Un Wee es femme NN RN NCmRDTEN VART O ReseCowemwng mense sw mesmtmwaeiems SIG UART DATA UART Data Register Empty Interrupt SIG UART1 TRANS UART 1 Transmit Complete Interrupt SIG ADC ADC Conversion complete MEER SIG EEPROM Eeprom ready SIG COMPARATOR Analog Comparator Interrupt NENNEN Table 3 8 ATmega1281 Interrupt Routines meme owen NOR uemmmemm C0 Bwmameng semen Emwma uemmmwrn 7 Eemmewd uemmmewn 0 Beemewd 0 scm HANE Pin Cane mema 0 0000 scm CHANGE PeCemee nee 0 SIG PIN CHANGE2 Pin Change Interrupt Request2 SG WATOHDOG TINEOUT Waren SGOUTT COMPARA Oupa Con een SG OUTPUT COMPARES Oupa Comro em sov Oeecmemg o SG NRUCAHURE wes Omesieag 0 SI OUTRIT COMPARER Oupa Cone en SGOUUFCOWPARER Oui ome emm SIG OUTPUT COMPAREIC Output Comparel C Interrupt aovo foem Doc 7430 0108 01 Rev D Page 29 XMesh User s Manual Crossb w SIG OUTPUT COMPAREOB Output CompareO B Interrupt SIG OVERFLOW 0 Ov
82. d below Interface command result t disable Description Disables the ELP mode Interface command bool isActive Description Query if the node is in ELP mode 8 3 2 Elpl Interface Example Wiring MyappM Elpl gt XMeshRouter Elpl Example Usage Call Elpl wake Interface Command xxesulrt tr route drscover urmnto9o run Description Attempts to join the mesh When called it Turns the radio on for up to rui ROUTE UPDATE INTERVAL s attempting to find a parent If a parent 1s found sends a health message retries up to x times requiring an end end acknowledge from the base station 3 rui The number of ROUTE UPDATE INTERVALS to wait for joining the mesh i e within this time the mote should have heard 2 route updates from neighbors and selected a parent Page 70 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual event Lesult t route discover lt done urnte t sSuccess urintlo t Interface parent Description Event returns after route_discover has either found a parent or timed out after the rui period If route_discover fails it s up to the application to decide when to try route_discover again Parameter Description SUCCESS SUCCESS A parent has been found FAIL No parent was found The address of the parent command result t sleep uintl6_t duration uintl6_t Interface health interval uint8 t iRetries uint8 t force sleep Description Puts an XMesh ELP capable mote to sleep
83. d in the user application as the parameter of MhopSend interface while AM type is used inside XMesh radio layer routing layer and transport layer Application ID allows applications to multiplex to different user services with the same AM type User applications only deal with Application IDs through the MhopSend receive interface to send and receive message XMesh decides which AM type is appropriate for the message AM type is internal to XMesh currently there are 16 predefined AM types in XMesh that users should never use for other purposes The most current defined types can be found in Appendix A Doc 7430 0108 01 Rev D Page 55 XMesh User s Manual Crossb w N WARNING Do not use the AM parameter in multihop messages this parameter is reserved by XMesh gt IMPORTANT Application IDs from 128 to 255 are reserved by Crossbow for future use The user s Application IDs should always be from 1 to 127 When sending a message the application should implement the following code 1 Geta pointer to a data buffer and typecast it to an application data structure for example pData Ping t call MhopSend getBuffer amp gMsgBuffer amp Len pData now points to the application payload portion of the TOS message and Len has the length of the available payload buffer The maximum data length 1s determined by the TOSH_DATA_LENGTH define 2 Send the message The value of dest and mode depends on the transportation mode C
84. e lt mote platform gt 2 3 Deploying the Network Once the motes are deployed and powered use XSniffer to monitor the network activity refer to Section 11 2 This allows users to monitor the mesh formation route update packets and all upstream and downstream traffic After you have seen the routing packets being exchanged using XSniffer you are able to view the individual packets arriving through the base station Using XServe or a standard terminal program e g HyperTerminal you can view the raw data packets coming from the base station Refer to Chapter 9 for more information on the serial data packets The screen shot in Figure 2 1 shows the mesh formation of a single Mote 1 The initial transmissions from the mote are all broadcast bcast transmissions since the mote has not yet joined the mesh This occurs until the 1 11 24 190 time 2 At 1 11 19 904 the base station transmits a route update message The message tells the mote that the base station can hear it 3 At 1 11 24 060 the mote transmits a route update message telling the base that the mote can hear it 4 At 1 11 24 190 the mote has joined the mesh and now directs its messages directly to the base Doc 7430 0108 01 Rev D Page 17 XMesh User s Manual i Log de XSniffer 1 0 2111 23276 L Dbug ies Neighbor oe 71109839 Beast af n ee Beast Qg 11 ee er eje a ee u ee ee re R TAA AANA N NN
85. e platform reinstall O mib510 mib510 mib600 device location gt IMPORTANT The base station is always programmed with node ID equal to zero Doc 7430 0108 01 Rev D Page 77 XMesh User s Manual Crossb w 9 4 Using the Heartbeat XMeshBase provides the link from the mesh network to the outside world It is important that this link does not fail To monitor the health of XMeshBase a heartbeat mechanism 1s incorporated to validate that the link between the base and the PC 1s operating correctly The heartbeat mechanism sends a heartbeat packet from the base station over the serial port every 5 seconds Applications running on the PC can monitor the packets to verify that they arrive If XMeshBase fails to send a heartbeat the monitoring application can alert users that a problem has occurred with XMeshBase connection For users using XServe with XMeshBase a complete monitoring solution has already been incorporated XServe monitors heartbeats from XMeshBase If three heartbeats are missed XServe alerts users of the failure For applications using the MIB510 or MIB520 programming board for their base station XServe will also attempt to restart the XMeshBase application by power cycling the Mote The heartbeat messages sent by the XMeshBase application have the structure described in Table 9 2 Table 9 2 Packet Structure of XMeshBase Heartbeat Messages uintl6 t addr uint8 t am type uint8 t group IQ 5 Leng en This is the Tos Msg le
86. e server Doc 7430 0108 01 Rev D Page 83 XMesh User s Manual Crossb w 10 2 2 XOTAPLiteM The XOtapLoader programmed can be wired into the user s application as follows In the Application component file add the following wiring implementation MyAppM XOtapLoader MULTIHOPROUTER In the Application module file add the following component interface and the command module MyAppM provides uses interface XOtapLoader Also add the command response command to check with the application if it can be interrupted before rebooting to another image If the application is in the middle of a state it can properly complete its actions and leave the mote in a known state before resetting event result t XOtapLoader boot request uint8 t imgId call XOtapLoader boot imgId pedem iU CN Once the mote receives the boot command and the application gives a go ahead on the reboot it will schedule the reboot time based on how far away it 1s from the base in other words the closer it is to the base the longer it should delay for the reboot so that children won t lose pending downstream messages due to the reboot of their parents The Table 10 2 shows the delay time for the reboot Table 10 2 Delay times for reboot Hop count Deisy ee o3 6 8 Page 84 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 10 2 3 Bootloader The Bootloader is an independent piece of code that is
87. ent These are still alternated with the statistics packets The diagram below shows the sequence of health packets for a mesh with 10 neighbors in the neighborhood list otatistics Pkt Neigh 1 5 Neigh 6 10 otatistics Pkt eem n Heat m Hat 2 The format for the neighborhood health packets is provided in Table 10 3 Table 10 3 Neighbor Health Packet Structure Data Fields Description This field is in the Health header The bottom 4 bits will contain the dane ENDS Mode number of neighbors sent in the packet hn quality Records containing information about the link quality of the neighbor Each nodeinfo record consist of the following elements Neighbor s ID Doc 7430 0108 01 Rev D Page 81 XMesh User s Manual Crossb w Data Fields Description Link quality normalized to 255 10096 10096 indicates that into t both the neighbor and mote hear 100 of each other s messages Hop count Hop count of the neighbor 0 the Hop count of the neighbor 0 The The RSSI or LQI value of the neighbor or LQI value of the The RSSI or LQI value of the neighbor 10 2 Over the Air Programming OTAP The Over the Air Programming OTAP feature allows users to reprogram any Mote within the XMesh network OTAP allows one or more Motes to receive new programming images from XServe via XOtap a server side application via wireless communication REMOTE OR LOCAL GATEWAY XMESH NETWORK SERVER Send Request MIBS10
88. erflow0 Interrupt SIG_SPI SPI Interrupt SG SAU ARV UTORE eee um SIG USARTI RECV UART 1 Receive Complete Interrupt Sa usak pata URTO Daa Reer enoo mer SG ISART IDEA VARTO Dana Reeser Enorme Sauso mRANS VARTO amit Conie me SIG USARTI TRANS UART 1 Transmit Complete Interrupt rrr ODT SIG_ADC ADC Conversion complete BEEN SIG EEPROM READY Eeprom ready SIG COMPARATOR Analog Comparator Interrupt TinyOS supplies two macros to use for interrupt handlers e TOSH INTERRUPT signame executes with interrupts enabled 1 e another interrupt can be serviced while this routine 1s executing e TOSH SIGNAL signame executes with interrupts disabled 1 e another interrupt will not be serviced while this routine 1s executing M EXAMPLE An example of these handlers are TOSH SIGNAL SIG UARTO RECV aie allay UCS ROA a dp IEDC signal VART oci imp UDRO TOSH INTERRUPT SIG OUTPUT COMPARE1A susogmeiL Pago anaes 3 4 Low Power Operation Achieving low power operation requires attention to both the electrical interface and software sensor code The ATmegal28 processor is very good at low power operation but if the I O pins are not programmed correctly the supply current can increase by hundreds of As Page 30 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 3 4 1 HPLPowerManagement TinyOS supplies a power management component HPLPowerManagementM which will monitor the interrupt sta
89. esented by the tos_time_t structure The tos_time_t 1s a 64 bit integer which represents the current time as a number of milliseconds The 64 bit integer 1s represented as two 32 bit integers for easier access on platforms which do not recognize 64 bit numbers The high 32 bits are the most significant bits in the 64 bit time and the low32 bits are the least significant 32 bits in the 64 bit time The structure of the time packet is provided in Table 10 5 Time Synchronization Packets use AM type 239 and do not use a mutihop header Table 10 5 Time Packet Structure Parameter Format Description o source_addr uint16_t Source address of time message phase Unco t The difference between the mote s local time and the time update from the last timesync message Corr Smoothed out skew correction value authority ullto ct Authority is the mechanism to form a timesync hierarchy Each node s initial authority is its local address with base station being 0 After that each node only accepts timesync packets from nodes with a lower authority Once a time sync packet is accepted the nodes local authority becomes the authority of its timesync parent 2 Every timesync period the nodes authority increments by one This is so nodes that lose their timesync parent will eventually be able to attach to another node since it will be increasing authority every period timeL uint32 t Leastsignificant 32 bits Isb 1000 1024 sec
90. etween channel monitoring 1s known through out the network Thus if any node wishes to communicate with its neighbors it will transmit a wake up sequence for the duration of the wakeup period before transmitting the actual message In this fashion if any neighboring nodes detect any radio activity during its channel monitoring it will remain on until the message is completely received This strategy allows nodes to power down a majority of the time and only power on during channel monitoring and message transaction Power Cycling on a Synchronized Schedule In the previous strategy every node in the network powers on their radio at a fixed periodic interval If a node monitors the channel 8 times per second then the period is 125 ms between each channel monitoring When a node wishes to send the node must first send a wakeup sequence of 125 ms or however long this period 1s This consumes a lot of energy for simply notifying its neighboring nodes The reason the wakeup sequence must span the entire period 1s because nodes are not synchronized Without synchronization nodes do no know the exact moment in the periodic interval when its neighbors will monitor the channel With a synchronized schedule where every node periodically monitors the channel during the same time window then the wakeup sequence can be dramatically reduced This time window if in the neighborhood of Ims can guarantee that every node will monitor the channel for activity within
91. even if the fragment is addressed to another Mote When it 1s their turn to download fragments the OTAP Page 86 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual algorithm will determine what fragments in the current page have been received and will only send missing fragments Whenever any OTAP download starts XOtap first informs all the nodes in the list to be programmed to be ready to receive an image in the specified slot Then it informs all the nodes in the list that it is going to send a specified page After that starting from the first node in the list it sends downstream packets of data All nodes which can hear this packet will promiscuously listen to this packet and update their slot 10 2 7 XOtap Application The XOtap application 1s a server side tool that works either with XServe or directly connected to the serial port of the XMesh Gateway to communicate with the XMesh network It resides in the XServe Layer in a remote or local server or Stargate of the XMesh Network landscape You use XOtap to download program images to the Motes by having the application first read an HEX image file name and a list of Motes to download Then the image is downloaded to each Mote The application then writes a report and exits There are 3 basic types of OTAP commands 1 Query Gets status loaded and boot images information 2 Load Load program image or data 3 Boot Boots into the specified image XOta
92. g energy Period Length vs Transmission and Reception Energy The period length will only have an effect on transmission and reception energy when the listening periods are unsynchronized or if a packet need to be send sent out with a wakeup sequence that must span the entire period length The longer the period length is the greater the wake up sequence must be to span the entire period length If the receiver is assumed to be unsynchronized then on average the receiver will power on during the middle of the period length Thus the reception energy will all increase by only by half as much as the transmission energy on average 7 1 4 Time Synchronized Radio Stack and the Periodic Wake up Checks The radio stack uses the synchronized time clock which 1s provided by the Time Synchronization service see Section 7 1 4 to schedule periodic wake up checks for sensing RSSI This 1s achieved by e A periodic wake up check is initiated when the clock s lowest 7 bits all reads zeroed 0 or 128 ms A timer event for each wake up check must be scheduled as well e When a wake up check needs to be scheduled the radio stack requests the current time value The number of clock ticks are counted until the lower bits read zero 0 and then a Page 64 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual calculation 1s made for future scheduled wake up checks This method allows the clock value to be moved forward and backward in time withou
93. guaranteed to execute after each reset of the Mote independent of the TinyOS Application It 1s responsible for loading the program image into the Processor program flash memory if commanded prior to the reset by the XOtap tool s message The bootloader binaries for MICAz MICA2 MICA2DOT and IRIS are maintained in the following directory MoteConfig TOS BootLoader bl_micaz sec bl mica2 srec bl mica2dot srec bl m2110 srec bl The command to program the bootloader is the following all as one line uisp dprog mib510 dserial dev ttyS0O wr fuse h 0xd8 dpart ATmegal28 wr fuse e ff upload if bl micaz srec You may need to choose appropriately the parameters for serial port mote programmer and the pathname to bootloader binary N WARNING The UISP will erase the bootloader every time the Mote is programmed so it must always be reloaded every programming cycle Also make sure that the correct fuse settings are used wr fuse h 0xd8 wr fuse e ff 10 2 4 OTAP Protocol The OTAP protocol reformats a large code image into pages and fragments in order to reduce the traffic required for the download process The downloaded image is broken into pages and fragments that fit in a TinyOS packet A fragment 1s the amount of the image that can be transmitted in a single TOS packet 1 e 19 bytes 29 byte TOS message with 7 byte XMesh header and 3 bytes OTAP header A page is a sequential set of fragments that are managed as an entit
94. he top right which will open up a directory window see Figure 12 2 or navigate to another directory which has the pre compiled Mote application you wish to install Select the specific exe file of the application you want to download into the Mote Open The binary scan feature built into MoteConfig will display the default parameters programmed into this application 4 Specify desired MOTE ID Group ID RF Power and RF Channel from the drop down menus 5 Right click on the Program button and you will see the resulting output at the bottom of the screen see Figure 12 3 Page 110 Doc 7430 0108 01 Rev D Crossb w f MoteConfig XMesh User s Manual x File Settings Help select File to be Uploade Setting fuse using mib520 uisp dprog mib510 dserial dev tyS5 dpart ATmegal 26 wr_fuse_h 0xd9 wr fuse I xff wr fuse e xff Erasing binary using mib52 Uploading SUCCESSFUL Crossbow Inc 2006 C Program Files Crossbow MoteView xmesh micaz MTS310 XMTS310CA_2420_hp exe Read Fuses Clear Text View Details Platform MicaZ Local Program Remote Program d 0 uisp dprog mib510 dserial dev tyS5 dparn AT meqal 26 erase installing binary using mib520 uisp dprog mib510 dserialz dev ttyS5 dpart AT megal 26 upload if C Program Files Crossbow MoteView xmesh micaz MT S310 WMTS310CA 2420 hp exe out srec Device mib520 Port comb Platform XMesh Type Micaz
95. health information to the base station The health information includes data on how well the node is performing in the network with regards to radio traffic battery voltage and parent s node Radio Signal Strength Indicator RSSI The base station Mote will forward the health information data to MoteView Refer to MoteView User s manual and XSniffer to monitor and diagnose the health of XMesh 15 6 Time Synchronization XMesh LP support a network global time synchronization to 1 msec The time stamping is used to synchronize radio messages but is also available to users to synchronize sensor measurements 15 7 OTAP XMesh supports Over the Air Programming which allows users to reprogram all nodes in the mesh with new code OTAP uses a directed downstream strategy that allows different code images to be sent to different Motes This allows users to deploy networks of multiple sensor boards and only reprogram the units of interest OTAP also uses a promiscuous listening mode motes that can overhear the new code download and know that they also need the same image will store the code transmissions Doc 7430 0108 01 Rev D Page 9 XMesh User s Manual Crossb w 2 Building XMesh This chapter guides the user through building XMesh and deploying a small network It includes e The XMesh build environment e Building an XMesh application e Deploying and testing a small network e Using binaries to build an application e Accessing the Cro
96. his time Interface command result t wake Description Wakes a node from sleep into a full power state and turns the radio and UARTO on When this completes a wake done will be signaled Interface event result t wake done result t success Description Signaled after node leaves ELP mode Always returns SUCCESS 8 4 Building XMesh ELP The application needs to follow the ELP coding requirements for the mote to work properly in ELP mode Typical usage of ELP by the user would be An external interrupt wakes up the user s application The application calls 1pI wake which turns the radio on and rejoins the mesh async event result t FireDetect alert eru Ro waken esteem OM whe stad occ te qouba Mesh The application waits until 1pI wakedone and then sends radio messages event result t ElpI wake done result t ss call MhopSend send After the radio message has been sent the application calls ElpI sleep to return to sleep mode 4 NOTE ElpI sleep returns SUCCESS if the mote has returned to ELP sleep mode event result t Send sendDone TOS MsgPtr pMsg result t success call ElplI sleep elp sleep sec elp health sec elp retry monitor flag Peele ih SUCCESS Page 72 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 8 5 Testing XMesh ELP A test application for ELP mode is supplied in Mote Works apps examples TestElp2 This application will Start up in full power Send route
97. hod returns a pointer to the location in the buffer where the application can insert its information Once the packet 1s filled out the application must hand the message to XMesh to send The MhopSend send method provides the sending interface The application provides the address of the receiver in this case the BASE STATION ADDRESS Italso provides the send mode In this application we are using the UPSTREAM mode with no reliability guarantees as shown by the parameter MODE UPSTREAM After XMesh has attempted send the message it informs the application of the result through the MhopSend sendDone event An example of the MakeXbowlocal file for this application could have parameters shown in Table 2 5 Table 2 5 MakeXbowlocal Parameters Parameters MICA2 MPR600 MICAz MPR2600 IRIS M2110 RADIO CLASS 916 RADIO CHANNEI RADIO POWER TXPOWER ODBM TXPOWER 3 2DBM DEFAULT LOCAL GROUP 0x3 0x3 0x3 An example of the Makefile for this application could be o OR Mae e E IE QS IUIS a 0 Sia a ER include Makefile component EO Cuder Malexbowtboecad Automakica Iy add eertain Command lane goals GOALS t basic freq route hp TOSMAKE_PATH TOSROOT contrib xbow tools make include TOSROOT tools make Makerules The Makefile component for this application 1s Doc 7430 0108 01 Rev D Page 15 XMesh User s Manual Crossb w COMPONENT XMeshCountToLeds MSG SIZE 49 Once all the correct parameters are set for an a
98. ill be described later Each application which links into the XMesh send interface attaches with its own application id XMesh uses this application id to multiplex packets from different applications 1n the network In this example we chose application id 10 to interface with XMesh The id value is important in that each application on XMesh should have a unique id and both the send and receive interface for an application should use the same 1d Below are code excerpts from the XMeshCountToLeds application for sending multihop messages TOSMsg ons oy task void sendMsg Dunne SE ODE eI S nee era Ue CounEMscees COUNEMSO e OUS Ce Page 14 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual MhopSend getBuffer amp g_msg amp bufferLength countMsg nodeId TOS LOCAL ADDRESS GOoUuUDnEMSq omodeeounte 0 Count call MhopSend send BASE co PAT TONLADDRE SS M DESUE Ss EREAMAGC GMs Oy S c Oi C Ount Mis CIS TS The basic messaging structure in TinyOS is the TOSMsg object The application declares a TOSMsg which it will fill with application specific messaging information In this case the information 1s the local node id and the current count value Though the message object 1s owned by the application XMesh will fill out the initial portion of the message with its own mesh information To retrieve the area of message buffer that 1s for use by the application the code uses the MhopSend getBuffer method The met
99. ing pressureDataPtr gt Board_id BOARD_ID pressureDataPtr gt Pkt_id PKT_ID pressureDataPtr gt Parent_id call RouteCor pressureDataPtr gt Sample_period DEFAULT_SAMF pressureDataPtr gt NmbSamples gSampleCount call RadioControl start call COMM send BASE STATION ADDRESS F call Leds greenOn call COMM send BAOSE STATION ADDRESS F bSending TRUE XMesh User s Manual After the CPU 1s halted usually through a breakpoint the CPU registers can be viewed by selecting View gt Registers Users can e View all CPU registers including the PC counter PC stack pointer SP and status register SREG e Change the value in any register by entering a new value and hitting return e Restart the program by setting the PC counter to 0x0000 hitting return and selecting the run icon see Figure 3 Registers Figure 3 12 Viewing the CPU Registers 3 8 5 Viewing SRAM SRAM can be viewed by selecting View gt Memory Users can e View and change any section of SRAM e View and change any of the CPU I O registers see Figure 3 12 Doc 7430 0108 01 Rev D Page 43 XMesh User s Manual Crossb w oOx Addresses Address pan z bod is LITTLE endian MEME oo exeo exo exec lexrt exor lexes oxen cos exon exer axes eoe exes exra exes 0x00800110 0x01 0x00 0x00 0x00 Oxbc 0x08 0x00 0x00 OxOF 0x00 0x00 OxOO OxOO OxOO 0x00 0x0
100. ing Hardware Version Software Version Reported JIAG device ID Ox 782 Gonfigured for device ID Hx77B2 atmegali28 LockBits gt Hxff Reading Fuse Bytes Extended Fuse byte gt Axff High Fuse byte gt Axi Low Fuse byte gt Hxff JTAG config complete Downloading FLASH image to target Download complete Waiting for connection on port 6423 Connection opened by host 127 0 0 1 port 4633 Doc 7430 0108 01 Rev D Page 41 XMesh User s Manual Crossb w The main screen of the GUI should appear as below Sometimes this screen 1s sized incorrectly This can be overcome by resizing the window step c run step assembly Source Window File Run Yew Control references Melp ASAM in vectors vj JjaDCControl nc JRDCREFH nc jaMStandard nc code modules for the application BareSendisg nc 16 gt jmp 6x3a4 3ByteComm nc 28 jnp 8x3ah 3CC1888Control nc 2h jnp 8x3ah 1888ControlH nc 285 jnp x3ah CC1888RadioIntH nc 325 jnp x3ah Clock nc 36 gt jmp 8x3a 4O gt jmp Ox3a4 Counter nc i Framer amp ckH nc bouis Jnp vtae EPiaePH ne 48 gt jmp 6x3a4 T 52 jnp 8x3a JHPLRDC nc 56 gt jmp 6x3a4 _HPLADCH nc 68 gt jmp 0x1a22 s 6x46 lt __vectors 64 gt jmp 6x3a4 Figure 3 10 The Main Screen of the ice insight GUI The icons shown will allow e View all source code modules linked into the application e Execute run the application or run to a
101. int Figure 1 1 as Li JU th F di a i am w i u iP a a e P iP umm NN a T P k c Gateway End paint Figure 1 1 Diagram showing a Star Topology The star topology delivers the lowest overall power consumptions but is limited by the transmission distance of the radio in each endpoint back to the gateway There are also no alternate communication paths to the endpoints If path becomes obstructed communication with the associated endpoint will be lost 12 2 Mesh Topology Mesh topologies are multi hopping systems in which all wireless sensor nodes are identical they are all routers and communicate with each other to hop data to and from the sensor nodes and the gateway This 1s the standard XMesh configuration Unlike the star architecture where the nodes can only talk to the gateway the nodes in a mesh topology can also hop messages among other router nodes Figure 1 2 d Gateway pt Router Figure 1 2 Diagram showing a Mesh Topology Doc 7430 0108 01 Rev D Page 3 XMesh User s Manual Crossb w The propagation of sensor data through the mesh allows a sensor network to be extended in theory to an unlimited range A mesh network is also highly fault tolerant since each sensor node has multiple paths back to the gateway and to other nodes If a sensor node fails the network will reconfigure itself around the failed node automatically Depending on the number of nodes and
102. l C on o DCN SS cie Memcpy amp tos msg data amp app data len copy data into data section Ho SIDSON cree S TC 7 Comoured Ge Appemdess E Seod to se mila INSP OSamISC i ccm s Me Mes Sage tO Choseri all PORE A SECOS cms mites Message ome co swe URI tom bom Nc NER Td ce ds 5 3 5 Sending Downstream Messages with End End Acknowledgements If sending from the base station mote call the following send command call MhopSend send downstream node id MODE DOWNSTREAM ACK amp gMsgBuffer length and amplement the sendbonevewventt event result t Send sendDone TOS MsgPtr pMsg result t success return SUCCESS If downstream packets are sent from a PC or other host via a base station MIB5xx plus MICA2 or MICAz running XMeshBase the PC is the same as the previous example except for the type field TOSS Gyo Ole Ecco OX S essc CH MVSbte De elis Page 58 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual The PC code should also implement a callback for AM type 247 which 1s the end to end acknowledgement from the node to base station N WARNING Messages to and from XMeshBase require PPP HDLX framing Refer to Chapter 9 for details Doc 7430 0108 01 Rev D Page 59 XMesh User s Manual Crossb w 6 XMesh Route Controls Sometimes users need to make application level decisions based on network conditions To accommodate this need XMesh provides a RouteCont rol interface Mote Works interfaces for the user
103. lication ID that they are wired to The complete buffer received payload The payload portion of the packet for this protocol layer If this layer has layers above it it should signal receive with payload incremented by the size of its header Payload is a pointer into the msg structure payloadLen The length of the payload buffer If this layer has layers above it it should signal receive with payloadLen decreased by the size of its headers and footers Indicates the packet should be forwarded FAIL indicates that it should not be forwarded 5 2 3 Promiscuous Listening This interface allows the application to snoop all radio messages including broadcast messages regardless of the application id and address Example Wiring XMeshRouter vPromi scucusSnatr gt MyappM PromiscuousSniff Example Usage event void PromiscuousSniff TOS MsgPtr pMsg To use PromiscuousSniff include the following declaration in the provides section of the application module module XsSniM 4 provides event void PromiscuousSniff TOS_MsgPtr pMsg 5 3 Using the Messaging API 5 3 1 Active Messaging and Application ID TinyOS has historically used an AM parameter in TOS messages as a service application identifier This allowed users to route messages to different services in their application XMesh now reserves this parameter and it 1s not available to the user XMesh supplies the same service through an Application ID Application ID is use
104. lled by avr functions see below directly within the user s code Processor pins can also be remapped using an alias statement TOSH ALIAS PIN name other name TinyOS provides several macros to set these pins as described in Table 3 6 Table 3 6 TinyOS Macro for I O Pins TOSH SET name PIN Set the named output pin to high TOSH CLR_ name _PIN Set the named output pin to low TOSH READ name _PIN Read the named input pin Doc 7430 0108 01 Rev D Page 27 XMesh User s Manual Crossb w TOSH MAKE name OUTPUT Define the pin as an output TOSH MAKE name INPUT Define the pin as an input M EXAMPLE An example of using these macros is ROSE EANSs IE ONE ES EDD e E TOSH_MAKE_RED_LED_OUTPUT MOSHE EDE DENO N WARNING The SET command sets the ATmega128 pin high This turns off the LED The CLR macro turns on the LED Consult the schematics that explain how to turn on off the peripherals 3 3 7 Interrupts In the AVR LIBC environment convenient macros are predefined to point to interrupt routines with predetermined names By using the appropriate name routines will be called when the corresponding interrupt occurs The ATmega128 library provides a set of default interrupt routines as shown in Table 3 7 and Table 3 8 for ATmega128L and ATmega1281 respectively Table 3 7 ATmega128L Interrupt Routines C Ws E 0 C 0 C 0 C 0 SIG_INTERRUPT4 External Interrupt4 Named INTO on expansion
105. n Users can do the following e Send upstream and downstream messages from the end point with or without requiring end to end acknowledgement e Intercept traffic for in network processing such as data aggregation and distributed compression e Snoop traffic for various promiscuous listening purposes 5 2 1 The MhopSend Interface MoteWorks interfaces The MHopSend interface uses the application id to parameterize the commands Users are highly encouraged to use this interface as opposed to Send interface which is described below to transmit packets This interface includes the following 3 commands events Example Wiring MyappM MhopSend gt XMeshRouter MhopsSend AP_ID Example Usage call COMM send BASE STATION ADDRESS MODE UPSTREAM dataMsgPtr sizeof dataMsg Interface command void getBuffer TOS MsgPtr msg uintl6 t length Description Given a TinyOS message buffer provide a pointer to the data payload section that an application can use as well as its length If a protocol unaware application 1s Page 52 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual sending a packet with this interface 1t must first call get Buffer to geta pointer to the valid data region This allows the application to send a specific buffer while not requiring knowledge of the packet structure The message to get the data region of Length Pointer to a field to store the length of the data region A pointer to the data region
106. nd control strategy is a key to maintaining battery life TinyOS is highly optimized for low power sensor operation but users must be careful both at a hardware and software level to maintain low power operation Some of the critical components are 3 5 1 The state of all Mote s CPU GPIO and other control lines must be kept in the correct state during sleep Setting a single GPIO into the wrong state can add an additional 100 uA of current consumption Refer to the ATmegal28 manual for more specific information Many sensors are very low power and require only a few milliamps of power Consider powering them directly from a GPIO line of the processor This allows the processor to easily shut down the power during sleep Be careful of all leakage paths between the battery voltage and ground A 100K resistor from the battery to ground will introduce 30 uA or so Battery Selection Alkaline Batteries These are the most common batteries and perhaps the best for sensors that can operate over the Alkaline s voltage range Two AA alkaline batteries will typically start out at 3 2V but quickly come down to 2 7V Then the voltage will slowly degrade over time to around 2 3V before the batteries are depleted MICA2 and MICAz units will operate down to this voltage range Lithium Batteries These batteries will maintain a voltage at 3 2V or greater and are best for sensors that require this minimum level of operating voltage Lithium Thionyl These
107. ngth field The length of the heartbeat message is 2 bytes uintl16 t seq no This is the heartbeat sequence number It s a 16 bit number which wraps around after overflow The sequence number is useful for applications which want track the packets though the most important aspect of the heartbeat is its absence The heartbeat application is turned on by default in XMeshBase To remove the heartbeat functionality from XMeshBase comment out the following line in the Makefile CFLAGS DFEATURE HEARTBEAT To monitor heartbeats start XServe with the following flag heartbeat lt num missed The num missed gt variable is the minimum number of heartbeats missed before XServe will attempt to restart XMeshBase Each heartbeat period 1s 5 seconds so in the case of a serial connection problem the base station will be down for num missed 5 seconds Page 78 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 10 XMesh Services The XMesh services include the following features e Health Statistics e Time Synchronization for Low Power e OTAP e WatchDog 10 1 Health Statistics Health statistic packets allow the user to monitor the health of the XMesh network They are enabled or disabled from the user s application If enabled they are transmitted upstream to the base station These packets contain useful information about how well the Mote is performing in the mesh regarding radio traffic Information such as battery volt
108. nprogrammed BODLEVWLO 1 ma Brown out Detector trigger level 1 unprogrammed N WARNING The base station mote mote id 0 must run with the external clock enabled otherwise the UART baud rates will not be correct Do not run a MICA2DOT as a base station mote It uses a 4MHz resonator crystal which is not accurate enough for high speed uart baud rates Always program a MICA2DOT using the internal 8MHz oscillator The fuse settings can be set via a uisp command such as uisp dprog mib510 dserial dev ttyS0O wr fuse h 0xd8 dpart ATmegal28 wr fuse e ff There are several fuses that must be set for correct XMesh operation The following table shows fuse setting for ATmegal28L XMesh Description configuration XMesh LP and Oxd9 Oxc4 Oxff Clock Source Internal Oscillator XMesh ELP Brown out detect disabled no OTAP JTAG disabled BootLoader disabled XMesh LP and Oxd8 Oxc4 Oxff e Clock Source Internal Oscillator XMesh ELP e Brown out detect disabled OTAP e JTAG disabled e BootLoader enabled XMesh HP Oxd8 Oxff Oxff Clock Source Internal oscillator OTAP Brown out detect disabled JTAG disabled BootLoader enabled Base Station Oxd9 Oxbf Oxff e Clock Source External oscillator XMeshBase e Brown out detect enabled e JTAG disabled e BootLoader disabled The following table shows fuse setting for ATmegal28l Doc 7430 0108 01 Rev D Page 117 XMesh User s Manual Crossb w XMesh Descri
109. o build install and analyze Mote networks Before building and installing the example application we will give a brief overview of the application itself gt IMPORTANT The following assumes knowledge of TinyOS nesC programming Please refer to MoteWorks Getting Started Guide for more information on TinyOS and nesC programming Refer to Appendix C to check that the correct TinyOS environment variables are set The XMeshCountToLeds application is located in MoteWorks apps examples X Mesh CountTo Leds The application is composed of two main files e XMeshCountToLeds nc Contains component wiring information and shows how the application connects to the XMesh multihop networking service e XMeshCountToLedsM nc Contains the application The XMeshCountToLedsM nc file increments a count variable every second and displays the count value in binary on the LEDs The application then sends the count variable along with the node id to the base station for viewing XMesh provides a rich set of services to send and receive application messages see Chapter 5 In this example we will display the basic UPSTREAM send service The service implemented in this application will have no reliability guarantees and runs at full power Below are code excerpts from XMeshCountToLedsM nc void displayCount uintl6 t value Me Teeubure amp d eel mecls cack Ur elise ce seeder IOmn D ie subse c 2 call tec see oU a if value amp 4 call Led
110. oaded Platform Mesh Type Mica2 Radio Band 916 MHz Type xMESH2 HP Addresses MOTE ID if Hex T Auto Ine Route Update 5 Sec Radio Packet Size 55 Butes GROUP ID 100 Hex 255 5 RF Power 205 decr Payload Size E Bytes RF Channel cHaNMEL 00 303 018 MHz Read Fuses Clear Text View Details Program OTAP Enable Stop 4mesh micaz x MeshBase S3 hp exe aut srec Setting fuse using mibh1 U wisp dprag mibb1lU dserialz dev ttyS dpart2A T megal 28 wr fuse h ld3 wr Fuse I UxsEE wr fuse e stf Erasing binary using mibS 0 wisp dprog nmibS1 0 dserialz dev ttyS dpart2A T megal 28 erase Installing binary using mib510 wisp dprag2mibh1LU deenal dey thyS0 dpartzA T megal 28 upload f Program Files Crossbow MoteView smesh micas VM eshB unc erp Crossbow Inc 2006 Platform Micaz Device mib510 Port com E Figure 10 5 Programming XMeshBase application into base station using MoteConfig 10 3 OTAP using MoteConfig Utility Once all the Motes are prepared for OTAP you can then program them over the air The following steps explain how to use MoteConfig to program the nodes in the network 1 Connect the base node to the PC interface board and turn on the remote nodes that were prepared as shown in section 10 2 8 2 Switch to the Remote Program tab 3 Click on the Search button to start up XServe and listen for remote nodes The Motes found within the network will be
111. oc 7430 0108 01 Rev D Crossb w XMesh User s Manual ix File Settings Help Local Program Remote Program Option v Check Base Heartbeat Operation Select File ta be Programmed C Program FilesCrassbow M oteView 1 4 20 mesh micaz MD Select Select Nodes e g 1 4 7 11 12 17 Select Slot C Ready Preparing Check Operation Timeout O Programming Rebooting Finished 2 motes successful 0 mates failed Node 2 is ready ta Quer Program or Reboot Made 1 is ready to Quern Pragram or Reboot Node 2 is ready to Quern Program or Reboot Node 1 is ready to Ouen Program or Reboot Node 2 is ready to Uuem Program or Reboot Node 1 is ready to Guern Program or Reboot Node 2 is ready to Ouen Program or Reboot Node 1 is ready to Ouen Program or Reboot Begin scan C Program Files Crossbow Moteview 1 4 20 mesh micaz MDAT40O0CB S03_hp exe Mesh protocol four Converting C Program Files Crossbow SM ote ew 4 20 emeshi micas MDA 1 00CB_ 303 hp exe ta C Program FilessCragsbow M oteyiew 1 4 2D mesh micaz M041 0006903 hp exe ihes Process completed Crossbow Inc 2006 Device mib510 Port con a Figure 10 7 Nodes are running the OTAP image 5 Query Users can optionally query a node when it is running the OTAP Image to get information about different slots as shown in Figure 10 8 oix File Settings Help Local Program Remote Progr
112. of the acknowledged packet User applications should not send a new upstream acknowledgement packet if the ack for the previous packet 1s not received 5 3 4 Sending Downstream Messages There are two scenarios for sending downstream messages Doc 7430 0108 01 Rev D Page 57 XMesh User s Manual Crossb w 1 Sending directly from the base station mote 2 Sending from a PC or other host that 1s connected to a base station Mote If sending from the base station mote call the following send command call MhopSend send downstream node id MODE DOWNSTREAM amp gMsgBuffer length and implement the sendDone event event result_t Send sendDone TOS_MsgPtr pMsg result_t success return SUCCESS If downstream packets are sent from a PC or other host via a base station MIB5xx plus MICA2 or MICAz running XMeshBase the PC code needs to e Put the downstream node id to the address field of the TOSMsg header e Put 0OxOC downstream no ack or OxOE downstream with ack into the type field of the TOSMsg header e Put the socket id into the socket field e Compute the crc appendix E e NEVER modify the multihop header which is internal to XMesh XMesh in the base station will complete the remaining fields in the message before sending it downstream An example code is like this Tos msg addr downstream ig Tos msq cyoe 20x00 77 sending downstream no ack Tos msg Wengen len data Vengun Too mog cic aple aton IND Apo
113. ogresses you will see the report in terms of number of pages downloaded into the flash A WARNING You should never write over the Slot 0 because it is reserved for the OTAP Image Doc 7430 0108 01 Rev D Page 95 XMesh User s Manual Crossb w copo cod cmo aT i 2 a tees y eol Sy dnte cob SUNS SILO ional do p inti S2 Hrs dolre qe db ZZ Opens cmd download Sif loe eulliosis ello GsOup ra Ra eT debug 1 hemi report Erle xotap him image id 2 ie we CH Um eet AMIS sO oma Am ccr ze em ceisneedetde d Flash OFESeE 273 bootable 1 Mine Vv odi deca e e cthroctle 15 motes 1 2 Mote 1 micaz time Sance reboor 4 2 man woltadges 2 94 book Image none More 2 mca ime since Teboory 4 2 mun vVolwage 210 Door image none Binary conversion complete size 28843 12 pages 1519 fragments icis sieve CIO Wem se el Downloading Page kor T Page 11 mote 2 O fragments throttle 15 msec Page 11 finished Donn loading Page 2 sor 12 Page L2 mote 75 lll fragments Ehrotele 15 msec Page 12 mote 1 O fragments throttle 15 msec Page 12 mote 2 O fragments throttle 15 msec Page 12 finished All pages downloaded Registering image 2 on mote 1 Registering image 2 on mote 2 Download finished 2 O 2 mores done Lm eo amoto Suee scu nei cc mses kee Page 96 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 6 Reboot The last step 1s to reboot into the ne
114. on the message latency up and down the mesh Typically for several hops this can be 100 msec to 200 msec During this time the processor and radio will be on If a health packet is sent every 3 minutes and the mote 1s on for 300 msec the duty cycle 1s 0 017 Table 3 13 Calculation of Average Current We wm E m h o kp C 0 E E Transmit Data Transmit Health Total Average Current The screenshot in Figure 3 5 shows the current consumption vertical axis of the Mote as a function of time horizontal axis Periodically every 230 msec Timer fires to service all timers Once every second the mote wakes up and takes sensor data Once every 20 seconds the mote also transmits a data packet after taking sensor data Doc 7430 0108 01 Rev D Page 37 XMesh User s Manual Crossb w Measured averaged current 50 msec idle to acquire sensor data including health packets 309 uA Sensor power on Sensor Measure Interval Timer Service Figure 3 5 Current Consumption of a Mote 3 8 Hardware Debugging Techniques 3 8 1 LEDS The MICA platforms MICA2 MICAz have three LEDs red yellow and green that can be easily used to debug code TinyOS supplies a component Ledsc which enables turning any led off or on also toggling the led Inserting calls to the LEDs in the code supplies a visual indicator TinyOS also supplies a component NoLeds which if wired to disables the LEDs refer to Appendix D 3 8 2 JTAG The ATmeg
115. orming a Multi hop Mesh Network To form and maintain a Mesh network the following 2 parallel processes are involved 1 Link Estimation A node promiscuously listens to radio traffic in its neighborhood and uses that information to populate a neighbor table It estimates how good it can hear a neighbor by monitoring the sequence numbers in the Multihop header and runs an EWMA algorithm to smooth out that estimate The neighbor table size is preset by a define usually 16 see Appendix A If a mote can hear more than 16 neighbors it will evict the lowest quality ones from the table The base station mote s neighbor table size 1s set to a larger value of 40 to handle more neighbors since the base station does not usually run an application it is not as memory constrained as the children motes Parent Selection The node searches its neighbors in the neighbor table and selects the one that will incur the lowest energy cost to be its parent A neighbor is considered a parent candidate if it e has already joined XMesh e is nota descendant node for the last 3 RUIs Route Update Intervals this is intended to avoid cycles Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual e isnot an ELP node An XMesh multihop network 1s formed by having all motes in the network periodically broadcast Route Update Messages which contains the following information 1 Parent ID If the node has not yet joined the mesh this field is OXFFFF
116. ossb w zero energy cost The base station Mote is always identified as node 0 in a single base station system In addition to the base station the mesh network consists of some number 1 100s of other Motes each with a unique node identification number This system of Motes running XMesh will self configure itself into a network and route radio messages upstream from Motes to the base station and downstream base to Motes 1 5 XMesh Features and Benefits XMesh has many features and benefits They include e TrueMesh e Mutliple Transport Services e Multiple Quality of Service QoS Modes e Multiple Power Modes e Health Diagnostics e Time Synchronization e Over the Air Programming OTAP 15 1 TrueMesh TrueMesh technology refers to the ability of the nodes to dynamically seek new routes for delivering packets when parts of the network go offline due to radio interference or power duty cycling A network may be formed ad hoc by simply scattering a collection of nodes next to each other The nodes will discover each other and build a routing tree based on the link estimates of the particular radio environment that they belong to Therefore nodes within an XMesh network are truly self organizing and self healing 15 2 Multiple Transport Services XMesh provides multiple transport services for communication between nodes They are e Upstream Delivers packets from a node to the base station Mote e Downstream Delivers
117. overheard by XSniffer since the start of the test Time Time since last message was heard seconds Q xsniffer eX Log All Route Health Neighbor Time Sync Options Rsvd Parent Lam p CostEst Msg Time all o 115 100 100 0 4 13 i290 ja o 0 100 100 Jo j2 109 12 90 idi o IO 100 100 0 i2 f2 Figure 11 4 XSniffer Health Screen Display Page 106 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 11 2 6 Neighbor The neighborhood display is based on information derived from health packets and gives information as to the quality of the radio links to nearby neighbors Table 11 5 XSniffer Neighborhood Tab Parameters Column Description Address of mote originating the health packet MSeq Sequence number of the health packet This is not the multihop header sequence number Each health packet from a mote has its own incrementing sequence number i Link quality of neighbor send estimate and receive estimate A value of 100 means 100 of messages have been heard received Hops Hop count of neighbor to base station The radio strength of the parent as heard by the mote originating the health packet r O p O A m XSniffer Log All Route Health Neighbor Time Sync Options Id MSe Msg Time Cnt Nbrid La1 m n Costi RF1 Nbrid2 La2 m Cos RF2 Nbrid3 L3tm Cost3 3F Nor La4 Co
118. p supports the following arguments described in Table 10 4 Table 10 4 XOtap Command Arguments f image file Download the file v threshold Download if the voltage is above the threshold default 2 7v SST pSports XServe host port default to localhost 9001 o x COM DOBt Serial port if connected directly eg c COM1 moteID motelID List the Motes to download or check status M EXAMPLE 10 2 8 OTAP Preparation using MoteC onfig Utility Before you can program the Motes in the network over the air you need to prepare them with bootloader and OTAP image You can use MoteConfig GUI utility to accomplish this Follow these steps to prepare the Motes for over the air programming 1 Start the MoteConfig from Start gt Programs gt Crossbow gt MoteConfig Doc 7430 0108 01 Rev D Page 87 XMesh User s Manual Crossb w 2 From Settings gt Interface Board Settings select appropriate programming interface board and port i i interface Board Settings E DIE A S ie coM 4 57600 t MIB52U s First Serial Port Prog Comm MIB6OO Host localhost 10001 10002 Apply Close Figure 10 3 Programming Interface Board Settings in MoteConfig 3 OTAP enabled programming using UISP Click on the Local Program tab and click on Select Browse to an XMesh application file main exe Choose appropriate Mote ID Group ID RF Power RF Channel and make sure that OTAP Enable box 1s checked Click on Program
119. packets from base station Mote to node s e Single Hop Delivers packets to neighboring nodes only 15 3 Multiple Quality of Service QoS Modes XMesh provides multiple qualities of service modes They are e Best Effort Link level acknowledgement where motes will try multiple times to transmit a message to its immediate neighbor e Guaranteed Delivery Provides end to end acknowledgement where a message is transmitted through the mesh to the base station or downstream and an acknowledge message 1s then sent back to the originator Page 8 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 15 4 Multiple Power Modes XMesh can be configured to run in one of the several power modes The modes are 1 High Power HP The HP mode provides e TrueMesh capability e Every node in the network can route data e High bandwidth low latency full channel utilization e Mote radios are always powered 2 Low Power LP The LP mode provides e TrueMesh capability e Every node in the network can route data e Low bandwidth high latency ideal for low data rate applications e Mote radios are normally in a low power sleep state and wake periodically to check for radio traffic 3 Extended Low Power ELP The ELP mode provides e Used only for end nodes of the network e Nodes cannot route data e Uses hybrid star mesh configuration 15 5 Health Diagnostics Within the XMesh network nodes can automatically transmit
120. payload uintl6 t payloadLen event TOS MsgPtr receiveAck TOS MsgPtr msg void payload uintl6 t payloadLen Description These two interfaces share the same signature of command event The content of the payload is different A pointer to the buffer received payload The payload portion of the packet for this protocol layer If this layer has layers above it it should signal receive with payload incremented by the size of its header Payload is a pointer into the msg structure payloadLen The length of the payload buffer If this layer has layers above it it should signal receive with payloadLen decreased by the size of its headers and footers The buffer to use for the next receive event Interface event result t intercept TOS MsgPtr msg void payload uintl16 t payloadLen event result t snoop TOS MsgPtr msg void payload uintl16 t payloadLen Description intercept Signals that a message has been received for the mote and the wired application ID AP ID snoop Signals any message overheard for the wired application ID AP ID These two interfaces share the same signature of command event the only difference between the two is that intercept handles the packet that is meant for the current mote while snoop handles the packet that is NOT meant for the Page 54 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual current mote Note that these routines will only intercept snoop messages for the app
121. ples TestElp2 refer Section 8 5 The application requires following Page 34 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 1 XMesh ELP refer to Chapter 8 on a MICAz The device will act as a leaf node 1 e it will communicate directly with a powered back bone mesh running XMesh HP 2 Sample every second storing the data in SRAM 3 After twenty samples transmit the last 20 samples Normally XMesh ELP 1s used for devices that send data at very low data rates Periodically between data packet transmits XMesh ELP would send a health packet and wait for an acknowledgement If the acknowledge is not received it will stay awake trying to make contact with the base station Transmitting the health packet and waiting for the acknowledgement consumes more battery current because of the latency time up and down the mesh If no acknowledge is received after the time out it will try again Health packets typically would be sent only every several minutes For this type of application sending a health packet for every data packet consumes too much energy and does not improve the connectivity to the mesh XMesh ELP allows users to decide when to send data packets and health packets With this flexibility a power efficient application can be designed by allowing the application to control transmission of either packet type Different Timers used in the application are outlined in Table 3 12 Table 3 12 Different Timers used in
122. plication M EXAMPLE COMPONENT ELPTest SENSORBOARD micasb ENCE UDE St D ADOS Mia recom Sc DEFINES DROUTE UPDATE INTERVAL 15000 DEFINES DTOSH DATA LENGTH 50 DEFINES DDATA REPORT RATE 10 2 2 Building an XMesh Application In this section we will build a simple XMesh HP application to demonstrate building a multihop network The application we will develop is the xMeshCountToLeds application In this application each node in the network will increment its individual count every one second and Page 12 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual send the value back the base station for viewing To verify that the count application is working the LEDs will display the count value To build this application we will need the following equipment e Motes At least 3 motes running under similar radio platforms for example the MICA2 and MICA2DOT or the MICAz platform e Mote Programming Board You will need a programming board to program the motes and to act as an interface between your PC and the mote network Potential programming boards are the MIB510 MIB520 or MIB600 You will also need the accompanying cabling to connect the board to your computer serial for MIB510 USB for MIB520 and Ethernet for MIB600 e Personal Computer You will need a PC running Linux or Windows installed with Cygwin e Crossbow MoteWorks Installation CD The MoteWorks installation CD comes with necessary PC side software t
123. pplication the build process can be started by executing the make command from the application directory The make command has the following parameters make mote platform binlink none build from source code make mote platform hp build from XMesh Radio binaries The mote platform corresponds to the hardware platform mica2 mica2dot micaz iris gt IMPORTANT If the default ROUTE UPDATE INTERVAL has been changed make sure the Makefile Component for both the application and XMeshBase are the same for this parameter At the end of the build the code space ROM and variable storage memory RAM allocation of the application will be displayed see below It is important to make sure that the application does not consume too much RAM otherwise there may not be enough space for the stack and the code can crash When using the ATmegal28 there are 4096 bytes of RAM The maximum RAM usage should not exceed 3750 bytes 19052 bytes in ROM 1883 bytes in RAM B avr objcopy output target srec build micaz main exe build micaz main srec avr objcopy output target 1hex build micaz main exe build micaz main ihex writing TOS image Once the application has been built the motes can be programmed To install an application to the mote users need a programming board connected to their computer Available programming boards and their connections are e MIB51O with serial connection e MIB520 with USB connection e MIB600 with E
124. ption configuration XMesh LP and Oxd9 Oxc2 Oxff Clock Source Internal Oscillator XMesh ELP Brown out detect disabled no OTAP JTAG disabled BootLoader disabled XMesh LP and Clock Source Internal Oscillator XMesh ELP Brown out detect disabled OTAP JTAG disabled BootLoader enabled XMesh HP Clock Source Internal oscillator OTAP Brown out detect disabled JTAG disabled BootLoader enabled Base Station Clock Source External oscillator XMeshBase Brown out detect enabled JTAG disabled BootLoader disabled 4 NOTE Enabling the JTAG fuse allows users to debug code on the ATmegal28 using a JTAG pod If this fuse 1s enabled on motes running XMesh LP ELP then the power consumption will increase Using the internal 8MHz oscillator reduces power consumption The only time the external oscillator is needed is for the base station Mote Setting fuses with the fuses script The Mote Works tools bin has a script which allows the fuses to be read and written easily The screen shot below shows the options The fuses script can be invoked from any application directory by setting an alias in the profile file see Appendix C fuses fuses Ver Id fuses v 1 1 2005 03 01 17 24 19 jprabhu Exp Usage fuses command port args read read fuses clkint set to internal oscillator clkext set to external oscillator jtagen enable JTAG jtagdis disable JTAG Command wr_fuse_1 OxfFf clkint wr fuse l OxcH jtagdis
125. r RC CRC check Refer to Appendix E Table 5 2 XMesh Packet Structure Type Name Description Component uint16 t Destination address next hop AM type defines type of message TinyOS Header MICA2 uice Secr Sn additional bytes length Remaining bytes in message N I CRC uint16 t Address of mote that sent the message uint16 t originaddr Address of mote that originated the message XMesh multihop header uint 6 t Message sequence number uint8 t data Payload Payload size is set with the TOSH DATA LENGTH define Default size is 29 bytes uint16 t CRC check Refer to Appendix E gt IMPORTANT The maximum data size is typically limited to 55 bytes Extending the data size increases SRAM usage due to creation of multiple TOS buffers Shorter data length messages can be sent at any time TOSH DATA LENGTH only determines the maximum message size see section 5 2 1 5 2 XMesh Messaging API XMesh can transfer messages upstream from nodes to a base station and downstream from a base station to a node Downstream communication enables efficient transmission of data from Doc 7430 0108 01 Rev D Page 51 XMesh User s Manual Crossb w the base station Mote to a node in the XMesh network The downstream path is the same as the upstream path as determined by the upstream route taken by the packets from a node A downstream message can only be sent if the base station Mote has previously received an
126. r to estimate the crystal skew The estimated crystal skew value 1s used to automatically update the clock in between receiving synchronization messages The synchronization update messages are simply used to confirm that the current clock correction parameters are accurate The XMesh Time Synchronization service is available for XMesh networks using the Low Power LP mode The purpose of the Time Synchronization is to synchronize all the nodes in the network to the same time This 1s accomplished by declaring the time on the base station Mote as the global time then synchronizing all the nodes within the XMesh network to the global time This time stamp technique achieves a time synchronization of all the nodes in the XMesh network with 1 msec error 10 5 1 Calculating Offset and Skew It is often not sufficient to just periodically update the time of all nodes in a network Crystals used to keep track of time at different nodes are slightly different Typical accuracy of a mote clock crystal is around 20 to 30 ppm That means that for a 32 kHz clock crystal the time will drift more that 1 msec apart from the global time in only 30 second after an update Thus it 1s important to also track the rate of the local crystal to the rate of the global time scale The ratio of the rate of the global time over the rate of the local time is called the Skew and the difference between the global time and the local time 1s called the offset One common equa
127. rM WaitTimer fired 28 gt mouw r30 r24 Ox442e lt PressureSensorM WaitTimer firedt t30 gt add r30 r18 0x4430 lt PressureSensorM WaitTimer firedt 32 gt adc r31 r19 0x4432 lt PressureSensorM WaitTimer fired 34 gt std Z 6 r28 0x06 0x4434 lt PressureSensorM WaitTimer fired 36 gt std Z 7 r29 0x07 0x443a lt PressureSensorM WaitTimer fired 42 gt subi r24 OxFF 255 Ox443c lt PressureSensorM WaitTimer fired 44 gt sts 0x0110 r24 fennna zneas uA Cama Meas Ta marie eadh ahs Avi n 1 Figure 3 15 Viewing Assembly Code 3 8 8 SODBUG SODbug allows users to send sprintf type messages directly from the application code to the UART serial port If the Mote is running on a MIB510 MIB520 MIB600 users can send serial messages directly to any terminal program such as HyperTerminal by configuring 57600 baud 8 bits No Parity and 1 Stop Bit SODbug code is located in the SODbg h file in MoteWorks tos interface Doc 7430 0108 01 Rev D Page 45 XMesh User s Manual Crossb w To use SODbug e Inthe application code insert sprint f type like SODbg DBG_PKT MYAPPSMsgRcvd i n data e Include SODbug h and its defines in all code modules that need serial output immediately after the start of the implementation section implementation Foe time DBG PFI 1 define SO DERUG ll finclude SOdebug h An example of SODbug is in Mote Works apps examples SODbug Terminal v1 9b 12087007 by Bray Baud
128. s 1lib CC2420Radi oAck RadioCRCPacket nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Rad1 oAck TimerJiffyAsyne ne preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Radi oAck byteorder h preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib Queue Queu eControl nc preprocessing C XtinyosXcugwinxXoptXtinuos 1 xdeuxXcontribXxbowuxtosXlibXQueue Queu edSend ne preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib Queue Queu Page 120 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 16 Appendix D TinyOS Components Some commonly used TinyOS components are provided below Wiring Example MyappM Leds LedsC Leds Usage call Leds redOn call Leds readaToggle call Leds yellowOn call Leds yellowToggle n call Leds greenOn call Leds greenToggle Usage Example call Leds redOn call Leds redToggle Wiring Example MyappM Timer TimerC Timer unique Timer Usage Example call Timer start TIMER REPEAT 1000 call Tamer start LlIMER ONE SHOT 50 00 Description Fire a repetitive or one shot timer Time is set in milliseconds uint 32 Minimum time is 3 msec Wiring Example MyappM CommControl Comm MyappM SendMsg gt Comm SendMsg AM TYPE J Usage Example Call SendMsg send TOS UART ADDR MSG LEN msg ptr Description Send a message over the uart or radio do not use this for sending radio messages with
129. s and 1s schedule to transmit between the periodic wake up checks It can be transmitted without causing surrounding nodes to wake up The Table 7 1 describes the packet transmission type Table 7 1 Packet Transmission Types Packet Type Usage Preamble Duration Start Time Strength Parameter Full Extended Preamble Neighborhood 140 ms T 15 communication Short Extended Preamble Time sync 40 ms T 114 Oxffff communication Standard Preamble Base station 0 ms 2ms OxTfff communication 4 NOTE The network stack uses the different packet transmission types depending on the value of their strength field 1n the outgoing packet The node s average power consumption can be calculated by determining the packet transmission type and the number of packets that were transmitted and received The expected Doc 7430 0108 01 Rev D Page 65 XMesh User s Manual Crossb w lifetime of a node can be calculated by using the parameters for the RX cost TX cost and RF Wake up check cost as well as the number of each type of packet that was sent and received Page 66 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual 8 XMesh ELP Extended Low Power This chapter discusses XMesh in the Extended Low Power mode It will also discuss e What is ELP e XMesh ELP interface e Building XMesh ELP e Testing XMesh ELP 8 1 What is ELP XMesh ELP achieves the minimum operating power because motes spend almost all of their time in a sleep st
130. s application to extract information from the routing component Example Wiring MyAppM RouteControl gt XMeshRouter Example Usage parente call outecohtroLogetbarembo Interface command uintl6_t getParent Description Returns the address of the present present Oxffff for broadcast 1 e no parent Interface command uintl6_t getDepth Description Returns the node s depth Depth is defined as how many hops away the mote is from the base station Interface command uintl6_t getSender TOS MsgPtr msg Description Gets the address of the mote that sent the message A pointer to the TOS Msg of interest The address of the sender Interface command uint8 t getOccupancy Description XMesh queues up forwarding message Returns the length of the routing forwarding queue an indicator of how busy the current node is Interface command uint8 t getQuality uint8 t type Description Gets a measure of goodness for the current parent Returns value between 0 255 where 255 represents that 100 of messages has been heard type l1 sendEst type 2 receiveEst Page 60 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Interface command result t setUpdateInterval uintl16 t Interval Description Sets the routing components internal route update interval Interval The duration in seconds of successive routing updates EOUHEB SUCCESS if the operation succeeded Doc 7430 0108 01 Rev D Page 61 XMesh User s
131. s nodes to efficiently communicate before the synchronization process 1s complete However once synchronized all transmissions are based on the globally time synchronous framework which provides Doc 7430 0108 01 Rev D Page 97 XMesh User s Manual Crossb w e An implemented time synchronization protocol that is based on the system clock signal from the base station Mote and distributed to each node in the network e Periodically each node will broadcast its version of the current time along with its Authority Rating The Authority Rating 1s represented as an 8 bit unsigned integer When a time sync message 1s received a node will do the following 1 Set its time clock to the value contained in the packet if the authority value is lower than its current value 2 Set its authority value to two greater than the authority value of the packet Every time a node transmits a packet the node will increment its authority value by one 4 Ifthe authority value of an incoming packet s authority value is equal to the node s existing value then the time value 1s adopted only if the source s sequence number is less than the receiving node s ID 4 NOTE The zero 0 is the highest possible authority value and is assigned to the base station When a node transmits a time synchronization packet it first initiates the transmission The radio communication stack fires a timing event to the Time Synchronization Layer when the start
132. s yellowOn Doc 7430 0108 01 Rev D Page 13 XMesh User s Manual Crossb w else call Leds yellowOff event result_t Timer fired G COUME DT da play ount Cope Count Lost SendM ome recura SUCCESSO The application runs a one second timer which increments a count variable on every fire The count variable is then displayed using the LEDs The number is displayed as a 3 bit binary number with the yellow led being most significant bit and the red led being the least significant bit Once we have displayed the count value to the LEDs the application attempts to send the count value and node id to the base station PC using the XMesh multihop network As described above this application will only send UPSTREAM messages with no reliability guarantees Below is a code excerpt from the XMeshCountToLeds nc implementation components Main XMeshCount ToLedsM LedsC TimerC XMeshRouter StdControl XMeshCountToLedsM StdControl Main StdControl TimerC StdControl Main StdControl XMeshRouter StdControl Main StdControl XMeshCountToLedsM StdControl XMeshCountToLedsM Leds LedsC Leds XMeshCountToLedsM Timer TimerC Timer unique Timer XMeshCountToLedsM MhopSend XMeshRouter MhopSend 10 The XMesh service 1s implemented by the XMeshRouter component The routing component provides a sending interface in MhopSend which sends packets into the network A receiving interface 1s also implemented but w
133. se station assuming the base station 1s connected to COM3 xserve s dev ttyS3 Initialize The next step in the OTAP process is to reboot all chosen nodes to OTAP Image for preparation of OTAP ing a new image LJ OLS CS Set Mocelinost cu se 1 2 OPE TONG cmd boot sug eedktexersulblevoxss 001 Group ides MEAS debug 1 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual html report file xotap html image id OQ motes 12 Rebooting mote 1 with image 0 Rebooting mote 2 with image 0 2 of 2 motes done Dims hed 2 NES Seo ss DELIS s OL agone tailed 4 Query Users can optionally query a node when it 1s running the OTAP Image to get information about different slots Me ee e e cu eco CE Opt Tons cmd query si llocedliaosic s 001 enogno aol 1029 debug 1 html report file xotap html motes 12 More 5 mileaz rime Since reboot 2 6 min voltage 2 0 boot image O Image flash start stop size checksum Type 0 O 14 2817 5 teo bootable 1 64 79 Zoe ds JUS bootable 5 Kempt y 3 Kempt y Morelo nimica t me e neces T boor min oom image 0 Image flash start stop size checksum Type O 0 14 Zoe MEDIO bootable il 64 79 28843 b2la bootable 3 Kempt y 3 x xxxempty 2 of 2 motes done Ernrsho L 2 moteo Successirul Omo S ick de 5 Program Specify the nodes you want to program and specify the slot Select the binary image of the app main ihex As the OTAP pr
134. sed by the TinyOS radio stack and cannot by used otherwise In ATmega1281 8 bit is used by TinyOS and is available to the user via the standard TinyOS clock services TIMER3 16bit is available to the user The SPI bus is reserved exclusively for the radio interface SPI Bus n a n a and is not available for user applications The SPI bus is also used during reprogramming by the MIB units I2C Bus This is a standard serial interface to many sensors The processor has two UARTs that can be run in either an asynchronous or synchronous mode UARTO is used for UART 2 2 base station communication UART1 is available to users The control pins for this uart are shared with the serial flash There is a 10 bit ADC available for users On MICA2 one channel is allocated for the radio s RSSI The ADC inputs ADC 8 channels 8 channels are also used for JTAG so users should try to use other ADC inputs if possible if they wish to use the JTAG capability There are many general purpose l O lines available Some GPIO of these support additional functionality see ATmega128L or ATmega1281 manual as appropriate This crystal speed is chosen to generate correct UART baud rates 57 6K baud It is only needed for base station Motes that communicate over the UART or other user applications that communicate to external serial devices 7 3728 MHz 7 3728 MHz Normally a non base station mote is fuse programmed to use an internal 8 MHz clock as this clock has
135. sh fuses gettos settos located in Mote Works tools bin can be copied to the usr bin file TinyOS scripts location sh This script will list all the files compiled into the application Run this script only after successfully building an application For example Doc 7430 0108 01 Rev D Page 119 XMesh User s Manual Crossb w location sh make micaz route hp will show an output similar to c BEE location sh make micaz route hp2 preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Radi oAck CO2420Control ne preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos lib CC2420Rad1i oRck CC2420ControlM nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Radi oAck CC2420RadioC nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos lib CC2420Rad1i oAck CC2420Radi0M nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Rad1i oAck HPLCC2420 nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Rad1i oAck HPLCC2420FIFO nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Radi oAck HPLCC2420RAM nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Radi oAck MacBackoff nc preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Rad1 oAck MacControl ne preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow to
136. ssbow CVS code repository 2 1 XMesh Build Environment XMesh is compiled and built using MoteWorks refer to MoteWorks Getting Started Guide For building XMesh applications the important parameters are located in 3 files e MakeXbowlocal e Makefile e Makefile component When building any application it 15 necessary to set the correct parameters in each of these files 2 1 1 MakeXbowlocal The MakeXbowlocal file contains global parameters which are applicable across all applications built for a particular installation The file is located in MoteWorks apps Table 2 1 MakeXbowlocal Parameters This parameter defines the radio band in which the network communicates for RADIO CLASS MICA2 MICA2DOT radios The operating band is defined by the mote s radio hardware This should correspond to the label on the board The available classes for Mica2 and Mica2Dot are 916 MHz 433 MHz and 315 MHz This parameter defines the radio channel the network is operating on Each band has multiple channels upon which it can operate The user should RADIO CHANNEL choose a channel which is not being used by other wireless devices in the network including other sensor networks See table below for MICAz settings RADIO POWER This parameter defines the power level for the radio The local group is the group id upon which each node in your network will DEFAULT LOCAL GROUP communicate on The group id is a way for multiple networks to operate on the
137. t causing the undue interruptions to the timer events e Prior to proper time synchronization the node relies on the initial un synchronized value of the timer which results in periodic sampling at 128 ms intervals 7 15 Radio Stack and Packet Transmissions In addition to scheduling the wake up check the radio stack also schedules packet transmissions base on the synchronized clock There are three types of packet transmissions e Full Extended Preamble e Short Extended Preamble e Standard Preamble These various types of packet transmissions are used by the routing and time synchronization layer based on the recipient list The Full Extended Preamble is used to communicate with all neighboring nodes regardless of the presence of time synchronization This packet transmission is scheduled to start transmitting 15 ms after the wake up check so that the nodes that are properly synchronized with the transmission node incur minimal reception costs The Short Extended Preamble is used to communicate with time synchronized nodes This packet transmission 1s scheduled to be transmitted precisely when the other nodes will perform their channel sampling Nodes will detect the incoming transmission and have time to turn on their radios before the actual data packet begins to arrive The Standard Preamble is used to communicate with high power nodes that leave their receivers on continuously This packet transmission contains no extra preamble byte
138. tatistics health packet fields are provided 1n Table 10 2 Table 10 2 Statistics Health Packet Structure Data Fields Description This is the sequence number of the health packet Page 80 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual uintl6 t num node pkts Number of application packets that have been generated locally uintl6 t num fwd pkts Number of radio packets that the mote has forwarded in the mesh uintl6 t num drop pkts Number of radio packets that the mote has dropped due to failed link level retransmissions uintl6 t num rexmits This is the number of times that the message was re transmitted Battery reading uintl6_t power sum Power statistics in low power radio stack not used n quality nedeinfo A record containing information about the ink to the present parent uint8 t link quality Link quality to parent uint8 t path cost The routing path cost to the base station uint8 t radio link indicator rssior lqi value of the parent 10 1 4 Data Packet Neighbor Health Packet The Neighbor health packet contains information about the Mote s neighborhood and radio link quality to these motes Motes track up to sixteen neighbors Health packets can only send back information on five neighbors at any one time If the table contains more than five neighbors the information is contained in sequential neighbor packets If there is only a parent and no other neighbors the Neighbor health packet 1s not s
139. te of the processors peripherals The HP LPowerManagement adjustPower routine checks several registers to see if peripherals are active Based on these registers it will set the SM2 SM1 and SMO bits in the MCUCR CPU register to enable one of the following power down modes e Idle This runs at about 50 of the full current or about 4 mA for the ATmegal 28 In this mode any interrupt will wake up the processor e Power Save This runs at about 15uA In this mode only Timer0 interrupt wakes the processor also external interrupts HP LPowerManagement adjustPower is only executed if the HP LPowerManagement enable command has been executed The following registers are presently checked by HPLPowerManagement to determine which sleep modes to enable e TIMSK timer interrupt mask register Checks if any timer except TimerO is enabled for interrupts e UCSROB and UCSRIB Checks if UARTO or UART is enabled for a receive or a transmit interrupt e ADCSR to see if the ADC is enabled The power state of the processor is not set by HPLPowerManagement It only sets the SM2 SMO bits The processor will not change power states until the SE Sleep Enable bit of the MCUCR register is set to one This is done by the TinyOS scheduler When there are no additional tasks on the queue it will enable SE setting power state idle power save as determined by HPLPowerManagement Several components such as the radio stack and Timer0 automaticall
140. that handles translation and buffering of data coming from the wireless network and provides the bridge between the wireless Motes and the internet clients XServe and XOtap are server tier applications that can run on a PC or Stargate Refer to XServe User s manual 3 The Client Tier provides the user visualization software and graphical interface for managing the network Crossbow provides free client software called MoteView but XMesh can be interfaced to custom client software as well MOTE TIER SERVER TIER CLIENT TIER XMesh XSensor Apps Database Logger Visualization Analysis Tools Sensor Mesh Network m N Figure 1 6 Software Framework for a Wireless Sensor Network An XMesh sensor network system consists of multiple motes MICA2 MICAz and a base station unit MICA2 MICAz installed on an interface board eg MIB520 This base station Mote serves two purposes 1 It acts as the Gateway between the Mote Tier and Server Tier The base station communicates with other motes over the radio and with the server using serial communication In this way the base station forms a bridge to send and receive messages between a host system PC and or Stargate and the rest of the mesh network 2 It forms the network and directs all data messages from the Motes to itself To other Motes in the network this base station Mote can forward messages to the PC host with Doc 7430 0108 01 Rev D Page 7 XMesh User s Manual Cr
141. the distances between them the network may also experience increased latency as sensor data is hopped from node to node on its way to the gateway 12 3 Star Mesh Hybrid A star mesh hybrid seeks to take advantage of the low power and simplicity of the star topology as well as the extended range and self healing nature of a mesh topology A star mesh hybrid organizes sensor nodes in a star topology around routers which in turn organize themselves in a mesh network The routers serve both to extend the range of the network and to provide fault tolerance Since wireless sensor nodes can communicate with multiple routers the network reconfigures itself around the remaining routers if one fails or if a radio link experiences interference Figure 1 3 d Gateway o Rauter End point Figure 1 3 Diagram showing a Hybrid Star Mesh Topology 1 3 XMesh Overview XMesh is a full featured multi hop ad hoc mesh networking protocol developed by Crossbow for wireless networks An XMesh network consists of nodes Motes that wirelessly communicate to each other and are capable of hopping radio messages to a base station where they are passed to a PC or other client The hopping effectively extends radio communication range and reduces the power required to transmit messages By hopping data in this way XMesh can provide two critical benefits improved radio coverage and improved reliability Two nodes do not need to be within direct radio range of e
142. thernet connection To install an application onto the mote attach it to the programming board and connect the programming board to the PC Once connected program the mote using the GNU make system Page 16 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual make mote platform install lt node_id gt mib510 mib510 mib600 device location The mote platform is defined above The node id parameter is the node id you wish to assign The value zero is reserved for the base station Finally you specify the type of programming board connected to the mote and the location of the device The device location is determined by your operating system and whether you have a USB or serial connection The ATmegal28 s internal fuses must also be correctly set This can be done using the uisp exe in the application directory or the fuses script Refer to Appendix B for the correct fuse settings For XMesh HP the default fuse setting are used For XMesh LP the JTAG fuse must be disabled and the internal oscillator enabled N WARNING The correct ATmegal28 fuses must be set Refer to Appendix B Programming the base station Refer to Chapter 9 Compile and program a Mote as Mote address 0 with the application in Mote Works apps XMesh XMeshBase as make mote platform base route hp Programming a Sniffer Mote Refer to Chapter 11 Compile and program a sniffer Mote with the application in Mote Works apps general X Sniffer mak
143. tion that expresses the local time in terms of the global time is C t ait b where t is the global time a is the skew and b is the offset By keeping track of the skew it is possible to keep desired synchronization with fewer time updates Doc 7430 0108 01 Rev D Page 99 XMesh User s Manual Crossb w To obtain the current global time from the XMesh Time Synchronization service your applications must be wired to the TimeSyncService module using the Time interface The Time interface provides the following commands interface Time req c Eo C Test RING 7 Ie Bae pe b Sh a o SIG IMs P SUCI Wise reine e E woe Eee Ore Lr Pee Cee eiae dcin SA Tode cU Cur ETDLISTE EN OBS 4 Susan e ee dSUOIO E Wale S2 me rene de DEOS LE jx es ae db ONIS So OIG NOUEN CUMS eames Aes cusa Wroumiien ool MUU Me 62 ee res Ions OAL 8 Oa Ge Clock phase or rset so neo mikes ceci esit Ce x in unit of micro seconds as vine cornmeuric spe Teo serere EDISON Here is the tos_time_t structure typedef struct VISIONS ee EIE OTIO urnto2 homo lc 5 dm cime t M EXAMPLE Below is a wiring example to the TimeSyncService uses incertace bdo oi bol as TP TIBeSt Sd interface Time implementation components YourAppM TimeSyncService YourApp TimeStart TimeSyncService MOS Owl limes MISIT COO UT eC Page 100 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Time is repr
144. tions Sets the radio channel for the application This feature acts as an application specific override of the RADIO CHANNEL parameter set in the MakeXbowlocal file Usage is freq lt freq gt or freq lt channel gt Sets the group id for the application and acts as an override of the DEFAULT_LOCAL_GROUP parameter set in the MakeXbowlocal file Usage is group lt group gt power Sets the radio power and acts as an override of the RADIO POWER parameter set in the MakeXbowlocal file Usage is power lt power gt route Sets the XMesh power operating mode Usage is route lt operating mode gt The available operating modes are e hp to build XMesh high power e p to build XMesh low power This will build the time synchronized MICA2 mesh or asynchronous MICAZ mesh e elp to build XMesh extended low power base The base goal sets the application image as the base station node in XMesh This should only be used for building XMeshBase 2 1 3 Makefile component The Makefile component contains application specific parameters The parameters defined in the component file are applicable to the particular application and are provided by the application itself Table 2 4 Makefile component parameters COMPONENT The component parameter tells the build system which application is being made and also can include Zdefines to configure XMesh The component listed here should be the top level application component in the ap
145. unication port by TinyOS see XMeshBase chapter UARTI is available to users The UART transmit and receive pins are shared with the serial flash which is also used by OTAP see XMesh Services If the mote is communicating with another serial device through UARTI users must design the interface so that the external device s transmit pin which would be connected to UART1 s receive pin defaults to a high impedance state on reset Otherwise OTAP will not be able to access the serial flash USART1 TXD USART1 CLK USART1 RXD A WARNING UARTI s transmit and receive pins are shared with the external serial flash chip which is used for OTAP 3 3 5 ADC The ATmegal28 has an internal 10 bit ADC which gives a resolution of 1 part in 1024 0 1 The diagram below shows the connection to the ATmegal28 pins ADC channels 4 7 share the JTAG TCK TMS TDO and TDI pins If users want to interface analog sensors to these channels and use JTAG use a 1K 10K resistor between the output of the sensor and input to the ADC channel so that the sensor output will not interfere with JTAG When JT AG is operational these channels cannot measure sensor signals Some of the ADC channels are dedicated to on board peripherals for the MICA2 ADCO is used to measure the RSSI RF signal strength from the Chipcon1000 radio and is not available Also ADC is wired to a thermistor for temperature measurements but this channel can be shared with another analog
146. updates and monitor route updates until it joins the mesh Send a health packet to the base station requesting a downstream acknowledge Go to sleep for 20 seconds Repeat the previous two steps continually Building the Application l 5 6 To build the application for a MICAz type make micaz route elp Program this into a mote Build the XMeshBase Chapter 9 application route hp base and program into the base station mote Build and load XSniffer with the same radio frequency Run the base station on batteries or a MIB programming board Run XSniffer refer to Chapter 11 gt IMPORTANT The ROUTE UPDATE INTERVAL in the Makefile Component for both the ELP application and XMeshBase must be the same 8 6 Monitoring the Network with XSniffer The following screen shot shows the XSniffer Log page during the startup of the network l During the initial phase the ELP Mote has not joined the network At this time it does not have a parent as seen by its route update message at 0 07 19 The mote current during this time 1s around 26 mA At 0 07 21 seconds the base station broadcasts a route update Rte notifying the ELP mote that it 1s seen At 0 7 52 seconds the ELP mote broadcasts its route update Rte and has joined the network selecting the base station as a parent and it sends health packets Health packets are sent every 20 seconds Doc 7430 0108 01 Rev D Page 73 XMesh User s Manual Crossb w
147. ut most of the ATmega128L signal Doc 7430 0108 01 Rev D Page 19 XMesh User s Manual Crossb w Antenna Nv Logger Flash c oO o Q x LLI E D L b ln Figure 3 1 The MICAz Hardware Architecture The Table 3 2 shows the 51 pin expansion connector for the MICAz IRIS and the pins that are available for user application Page 20 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual Table 3 2 MICAz IRIS Tes Connector Interface ES UART RXDO UART OReceve 0 Receive Lu UAI 1x00 UARTS Tamen mmo eomm GPIO PWM 10 LED1 Red LED 36 ADC7 ADC CH7 JTAG TDI EN W 16 PROG MOS Serial Program MOSI 17 PROG MISO Serial Program MISO b istt SPI_CLK SPI Serial Clock ae CO Sow eo lemna cmommms mom s veo Dita Say Shared use ttDO NOT use For in system programming ISP The Table 3 3 shows the 51 pin expansion connector for the MICA2 and the pins that are available for user application Doc 7430 0108 01 Rev D Page 21 XMesh User s Manual Crossb w zm 44 106 PROG MOSI Programmer Pin zm PROG MISO Programmer Pin gt Table 3 3 MICA2 51 pin Connector Interface Pim Name Description Pin Name Description UART Transmit 5 INT1 GPIO 31 PW2 GPIO PWM s ws oro s pws leom Ry RR Qo N 11 RD GPIO 37 ADC6 GPIO ADC CH6 JTAG GPIO ADC CH1 GPIO ADC CHO 18 SPI CL
148. v ttySO Figure 3 9 Setting Environmental and System Variables of the PC Page 40 Doc 7430 0108 01 Rev D Crossb w XMesh User s Manual The example shown above sets the JTAG pod for serial port COMI SO This also can be done from the Cygwin command line export AVARICE ARGSz j COMI To build a debug version of an application do make micaz debug OT make mica2 debug OF make iris debug N WARNING The mote i d address will be 1 and cannot be changed by the normal install process since this is not used when loading code via JTAG A different id can be set in the StdControl start routine of the application by coding TOS LOCAL ADDRESS xx where xx is the desired 1d Make sure the JTAG fuse 1s enabled on the mica platform This can be done using the fuses script see Appendix B fuses jtagen N WARNING The default fuse setting is JTAG disabled Each time the mote is programmed with make install platform the JTAG fuse will be disabled Start avr ice by typing ice insight build mica2 main exe ice insight build micaz main exe ice insight build iris main exe or ice gdb if it doesn t work This should download the code image into the Mote via JTAG ltinyos cvs tinyos 1 x apps cnttoledsandrf m 13266 bytes in ROM 444 bytes in RAM avr ohjcopy output target srec build micaZ main exe build micaZ main srec 4 jtagmica AUAaRICE version 2 80 20636825cus Aug 25 2683 20 53 25 JTAG config start
149. wly loaded image for the selected nodes When all the selected nodes are successfully rebooted you will see the output shown below S Uxor Ib e eot 2 Opr rors cmd boot sum dior culb etesste e JOC owe wee zc ak debug 1 html report file xotap html image id 2 motes 12 Rebooting mote 1 with image 2 Rebooting mote 2 with image 2 2 of 2 motes done faa Sinecl 2 mieices Suecessitll goes aaa d eol The specified nodes should now start running the new application 10 4 Watch Dog XMesh uses a watchdog component WDTM nc to perform a watchdog reset after it has missed 5 route update messages in a row To enable this functionality add the following line in the Makefile DEFINES DUSE WATCHDOG Once the watchdog functionality is enabled the mote will reboot itself if it does not hear any route update message in a period of 5 RUI Route Update Interval N WARNING Enabling the watchdog timer will increase the sleep current by an additional 15uA for the ATmegal28 gt IMPORTANT Never enable watchdog on an ELP node otherwise the ELP node will keep rebooting itself since it will miss most of the Route Update Message from its neighbors 10 5 Time Synchronization for Low Power The Time Synchronization service is used to establish a global network time stamp and to schedule network communication Time synchronization 1s implemented on top of the long preamble Full Extended Preamble communication mechanism that allow
150. y Hops This field contains hop count for route update message Rte it contains application p id for any other message Appld Application ID Remaining columns Data content of message Log Bos esamais ae m wx osi s oy amr ue E a ea P Es m Po Bo di SEEE EM DY eC ERI E ae F aon TS e o S WO NS P ee o a D D a zu 44 LE 2 n p un a A i RN NOR RN BR EU RU UN RR ER RR rac 9 02 011 Beast r Rte Status r 115200 baud Flapsed Time 00 29 02 Pon Fikar None Figure 11 2 XSniffer Log Screen Display Page 104 Doc 7430 0108 01 Rev D Crossb w 11 2 3 All Display a summary of all received messages Table 11 7 XSniffer All Tab Parameters XMesh User s Manual w Mefesmingmie OOOO OO Data Msg Number of data messages detected Time since last message heard sec TimeSync Mst Number of time sync messages detected Time since last message heard sec Q XSniffer JOE RF 594 100 o2 322 100 0 02 Qj 9 JO 1041 100 0 0 2 lal jot joo fo Figure 11 7 XSniffer All Screen Display 11 2 4 Route This tab displays the route messages Since this is only a local broadcast message not forwarded to the base not all messages will be detected by XSniffer The tab displays the normal multihop information Table 11 3 XSniffer Route Parameters Column Description Id of the reporting node Seq Hops Sequence number of the message
151. y There can be a maximum of 128 fragments per page A program image of 31 568 byes for example would be fragmented as 1 31568 19 1662 fragments with round off 2 1662 fragments 128 12 pages of 128 fragments and 13 page with 126 fragments Doc 7430 0108 01 Rev D Page 85 XMesh User s Manual 10 2 5 OTAP Download Packet Format Send LOAD IMAGE to all motes All pages Yes downloaded No Get next page Remove mote from download list Send LOAD PAGE to all motes Crossb w Clean up generate report exit All motes downloaded Throttle Control Send all outstanding fragments in page Error No The OTAP download packet contains the fields described in Table 10 3 Fed Table 10 3 OTAP Packet Fields Length Number of Bytes Description 1 2 19 This is the slot in the serial flash between O 3 This is the fragment id of the fragment being transmitted This is the binary data for the fragment 4 NOTE The OTAP packet does not contain any page information The page containing a fragment is determined by dividing the fragment offset by 128 offset gt gt 7 10 2 6 Promiscuous Listening During an image download the Motes in the download list will listen promiscuously for download packets and read fragments to update the image in the designated slot
152. y enable HPLPowerManagment 3 42 Testing for low power operation 1 Run the TestSleep application Mote Works apps examples TestSleep on the MICA2 or MICAz without a sensor attached This application does not use the radio it only toggles a led every 5 seconds or so while keeping the processor in a sleep state The battery current will alternate from about 3 mA with the led on to approximately15 uA with the led off 2 Attach the sensor Modify TestSleep to keep the sensor in an off state Measure the increased battery current when the led 1s off This is the lowest current state the unit can achieve attached to the sensor 3 Modify TestSleep to turn on the sensor when the led is on Measure the current Subtract this from the led current 3mA This is the lowest current state the unit can achieve when the sensor is on N WARNING The JTAG fuse for the ATmegal28 must be disabled to achieve low power operation If this fuse is on the minimum current is around 3mA The JT AG fuse is normally programmed to be disabled Refer to Appendix B Doc 7430 0108 01 Rev D Page 31 XMesh User s Manual Crossb w Do not measure the current with the Mote on the MIB programming board as this will increase the current Typically the current is measured between the positive battery terminal and the input connector on the Mote 3 5 Optimizing for Battery Operation The Table 3 9 shows some standard battery configurations and operational voltages

XMesh User's Manual

Contents

Download Pdf Manuals

Related Search

Related Contents