Home

XMesh USER MANUAL

Contents

1. E 1 4 Le eee eee eee Figure 2 1 Screenshot displaying XSniffer Output 2 4 Using Binaries MEMSIC 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 make micaz route hp builds the MICAz high power mesh using the binaries files The XMesh binaries are located Moteworks tos lib XMeshBin Doc 7430 0108 02 Rev A Page 19 XMesh User s Manual MEMSIC 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 T 1 o a ATmega128L ATmega128L ATmega1281 CC2420 2 4GHz CC1000 433MHz 916MHz RF230 2 4GHz External Serial AT45DB041 dena 512 Kbytes The serial flash can be used for over the air programming OTAP and or data logging Unique ID DS2401P integrated 64 bit circuit This chip contains a unique 64 bit identifier 51 Pin Yes except for OEM modules Connector This connector brings out most of the ATmega128L signal Page 20 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual Antenna Nv Logger
2. 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 even if the fragment is addressed to another Mote When it is their turn to download fragments Page 88 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual the OTAP 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 is 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 IHEX image file name and a list of Motes to download Then the image is downloaded to each Mote The application then writes a r
3. 2 niria N PYA Pae 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 is 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 3 4 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 3 5 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 MEMSIC sensor boards 3 3 6 The hardware 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 called 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 describ
4. 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 health_interval uint8_t iRetries uint8_t force_sleep Interface Description Puts an XMesh ELP capable mote to sleep 9 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 5 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 1Retries 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 Doc 7430 0108 02 Rev A Page 73 XMesh User s Manual MEMSIC Force_sle IP 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
5. 9 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 92 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual Z MoteContig IG x File Settings Help Local Program Remote Program Option l Check Base Heartbeat Operations Select File to be Programmed C Program Files Crossbow MoteView 4 20 emesh mica2 MD Select Select Nodes e g 1 4 7 11 12 17 Select Slot CL Ready O Preparing C Programming O Rebooting Check Operation Timeout Finished 2 motes successful 0 motes failed Node 2 is ready to Quern Program or Reboot Node 1 ts ready to Quer Program or Reboot Node 2 is ready to Quer Program or Reboot Node 1 ts ready to Quer Program or Reboot Node 2 is ready to Quern Program or Reboot Node 1 ts ready to Quer Program or Reboot Node 2 is ready to Quern Program or Reboot Node 1 ts ready to Quer Program or Reboot Begin scan C Program Files Crossbow Moteview 4 20 emeshh micas M DA 1 DCB 903_hp exe Mesh protocol found Converting C Program Files Crossbow MoteView 4 20 gres h rmie azo MDS 1 O0CB_ 903 _hp exe to C Program Files Crossbows M otev ew 4 20 emeshh micas sM DA 1 00CB_903 _hp ese ihe Process completed Crossbow Inc 2006 Device mibS10 Port con a Fig
6. Doc 7430 0108 02 Rev A Page 97 XMesh User s Manual MEMSIC A WARNING You should never write over the Slot 0 because it is reserved for the OTAP Image S 4 SOtEO eke sit localhost 1 2 i Sf 66 Ge AOS See Slay AUS IO T ERE EE a EE avec I 2 Opt One cmd gf group id debug 1 html report file image id download kares Unos e 7001 129 OES ee ZZ INE a T E ne Slo MISS NG Tomita eel E 7 lel bial 5 Le flash offset 128 bootable 1 min voltage 2 7 throttle 15 motes 1 2 Mote I miGaz time Samce reboots 4 2 min voltage 2 8 boot image none Mote 2 micaz time since reboot 4 2 min voltage 2 9 boot image none Binary conversion complete size 28843 12 pages 1519 fragments Starting dovnload Downloading Page 1 of 12 Page 11 mote 2 0 fragments throttle 15 msec Page 11 finished Downloading Page 12 of 12 Page 12 mote 2 111 fragments throttle 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 Registering image Download finished 2 Or 2 motes done Page 98 2 on mote 1 2 on mote 2 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual SE BE G 2 meces Suecessitll nieces sac Lec 6 Reboot The last step is to reboot into the newly loaded image for the selected nodes When all the selected nodes are successfully rebooted
7. Receive operations consumes power in the range of 10 to 20 mA In addition to TX and Page 64 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual RX the radio transceiver also has a series of low power states When the transceiver is fully powered down it consumes around 3 uW 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 19 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 is capable of routing the message from the edge device through the network Power Cycling on a Known Schedule This strategy
8. 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 Doc 7430 0108 02 Rev A Page 65 XMesh User s Manual MEMSIC gt the channel for activity within Ims 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 Ifa node is setup to monitor the channel 8 times per second then this length is 125ms 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 is 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 is directly proportional to the Latency and inv
9. Doc 7430 0108 02 Rev A Page 61 XMesh User s Manual MEMSIC 6 XMesh Route Controls Sometimes users need to make application level decisions based on network conditions To accommodate this need XMesh provides a RouteControl interface Mote Works interfaces for the user s application to extract information from the routing component Example Wiring MyAppM RouteControl gt XMeshRouter Example Usage Parent call Routeconcrol getParent 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 get Sender TOS_MsgPtr msg Description Gets the address of the mote that sent the message msg 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 1s 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 l sendEst Page 62 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual type 2 receiveEst Interfa
10. Flash c Ke m G x lt UU S D k md w Figure 3 1 The NIC AZ 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 Doc 7430 0108 02 Rev A Page 21 XMesh User s Manual MEMSIC Table 3 2 MICAz IRIS 51 pin Connector Interface Res os GND Ground 2 UART_RXDO UART_OReceive z ven Sensor Scr fs ms feo 29 wo GPIOPWM 6e in emo 32 PWR epomwm LED GreenteD 34 PWS GPIOPWM ee ee o mfo ono er anos abe one srac TOO 16tt PROG MOSI Serial Program MOSI gt 47t PROG MISO Serial Program MISO 18tt SPI CLK SPI Serial Clock a facek aceon TT Epe femme fs frmo Fromme tShared use ttDO NOT use For in system programming ISP gt lt The Table 3 3 shows the 51 pin expansion connector for the MICA2 and the pins that are available for user application Page 22 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual Table 3 3 MICA2 51 pin Connector Interface Pin Name Deseripon Pin Name Deserpion eimo eno pws eoe mw n0 ar anes eroan ov TAS 16 PROG MOSI programmer Pin GPIO ADC CH1 eal 17t PROG MISO Programmer Pin 18tt Spl CLK Radio Clock 48tt RSTN Micro Processor Reset 4 P tShared use DO NOT use For in system programming ISP 3 2 ATmega128 Resources The ATm
11. 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 is sent or by issuing a wake command see below 9 NOTE the radio is not on at this 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 ElpI wake which turns the radio on and rejoins the mesh async event result_t FireDetect alert call ElpI wake ER on the radio and reolin time Mech The application waits until ElpI 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 Page 74 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual 9 NOTE 1p1 sleep returns SUCCESS if the mote has returned to ELP sleep mode event result_t Send sendDone TOS_M
12. 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 bytes and is 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 Doc 7430 0108 02 Rev A Page 67 XMesh User s Manual MEMSIC 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 T 15 Ox7fff communication 9 NOTE The network stack uses the different packet transmission types depending on the value of their strength field in 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 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 68 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 8 XMesh ELP Extended Low
13. PC STARGATE GATEWAY XMESH NETWORK E E MIB510 Mesh Netw ork P MICA2 MICAz Figure 9 1 Mesh Networking Architecture Usually the client runs XServe MEMSIC s server interface to the base station but users can directly 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 02 Rev A Page 77 XMesh User s Manual MEMSIC 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
14. 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 Interface command result_t send uint1l6_t dest uint8_t mode TOs Msg Ftr pMsG Want lo vt length Description Sends a message buffer with a data payload of a specified length dest Destination Mote_ld 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 uintlo6_t length Description This Send interface uses the AM type to parameterize the command It is provided to maintain backward comparability with previous XMesh applications that use AM type to distinguish differ
15. 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 Page 4 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual E Gateway d Router d Endpoint Figure 1 3 Diagram showing a Hybrid Star Mesh Topology 1 3 XKMesh Overview XMesh is a full featured multi hop ad hoc mesh networking protocol developed by MEMSIC 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 each other to communicate A message can be delivered to one or more nodes in between which will route the data Likewise if there is a bad radio link between two nodes that obstacle can be overcome by rerouting around the area of bad 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 is a software library using the TinyOS operating system that runs
16. 0108 02 Rev A MEMSIC gt XMesh User s Manual Table 10 2 Delay times for reboot Rop count Deisy ee o pa 10 2 3 Bootloader The Bootloader is an independent piece of code that is guaranteed to execute after each reset of the Mote independent of the TinyOS Application It is 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 ttyS0 wr_fuse_h 0xd8 dpart ATmega128 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 A 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 is the amount of the image tha
17. 02 Rev A Page 81 XMesh User s Manual MEMSIC The base station will forward these packets along with other data packets to XServe for data conversion and then they can be relayed to Mote View 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 sequentially 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 int t version Most significant bit 0 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 uinti 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
18. PBS PG1 RD OCT B PCINT6 PB6 PGO WR ZI IZ IST Ia LQ Ley Ley a Lal ST Lea IZ IS Lea IS 12 gt a ST pe OF OF Na N 02 Yb Bo fk 69 9Ik 2 Z 2949 9 K 9 R eos S g gt W K R eZ eZ Z Z Z Hj I e e E E X E E Z D Q 0 0 I 9 A ailn U Q O 3 Z Z Z amp t E O 4 s S Pe z r C E amp Q S Figure 3 3 ATmega1281 Microprocessor Pinout A WARNING The MICA2 and MPR600 radio is rated to 5V The MICAz IRIS and M2110 radio is rated only to 3 6V Page 26 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual The maximum output current per I O pin is 40 mA and the maximum current for the processor 1s 200 mA 3 3 2 UARTs The ATmegal28 has two UART ports UARTO and UART1 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 A 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 communication 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 UART1 users must design the interface so
19. Program and Data N Downloading 0 programmed SPI prog enabled WDTON Watchdog Timer always on 1 unprogrammed 3 BESAVE EEPROM memory 1S preserved trough 1 unprogrammed EEPROM not preserved the Chip Erase 2 0 programmed BODA N Select Boot Size prog BOOTSZO Select Boot Size see Table 112 for 0 programmed details BOOTRST oo Select Reset Vector 1 unprogrammed Doc 7430 0108 02 Rev A Page 117 XMesh User s Manual MEMSIC The following table corresponds to bit settings in the uisp wr_fuse setting for ATmegal28L Fuse Low renr Yaa Default Value BODLEVEL LEVEL aa Brown out detector Brown out detector trigger level level 1 unprogrammed BODEN 6 Brown out detector enable 1 unprogrammed BOD disabled SUT1 Select start up time 1 unprogrammed exse 1 samce ogame The following table corresponds to bit settings in the uisp wr _ fuse setting for ATmegal 281 Fuse Low Byte 7 eee a Value CKDIV8 CKDIV8 7 Dude clock Divide clockby8 8 O programmed Son fe feronn steer xsex o _ SeecCossoues T The following table corresponds to bit settings in the uisp wr _ fuse c setting for ATmegal28L Extended Description Default Value Fuse Byte ae ae ee Page 118 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual WDTON 2 o Watchdog Timer always on 1 unprogrammed The following table corresponds to bit settings in the uisp wr _ fuse c setting for ATmegal 281 Exte
20. T 74 o CS 51 1 L A M ECP ncetatoetencssin E E cinco dasneiendcan A E ER AR 75 8 6 Monitoring the Network with XSniffer esse 75 v E Ei L E N O S O E A 77 E AE A M 12T S ar E A T EE EE E AE EET E PE 09 LT TE T eae CS aca secs vrata laters E e bese tae diame EEE 78 93 Building IS S TT 79 a Unom ex Kora 0 or ae eee en ng ro ee EAEE 80 I0 A MOS SOP VICES nE EE E 81 10 1 PVE gS VAIS TTT 8 1 10 2 Over the Air Programming O TAD 84 10 3 OTAP using MoteConfig Utility azg asantan aaa inanan 9 oA Ye 8 E 7 a sazeese ssa sere ania ze vane seteaaseseneasocseseaesaseneauneseteesiesencaseaseneceresenesuresetecasesenesieas 99 10 5 Time Synchronization for LOW Power cccccccsccsceeeeeeeeeeeceeeeceeecceceeeeeeeeeeeeeeeeeeees 99 U HE 0 T 2 E EE 104 11 1 Building and Starting XSniffer sss esec e senenn ennenen 104 Wee E 2 T 104 12 Moe ONE cov asics E E EEE 111 13 Appendix A XMesh Constants eeeececcccscscsssssssssececececcocsooosssssssssesececcesssssssssssssssssseeeee 114 14 Appendix B MICA FUSE SETTINGS sssssisssasieisssasresonsssnossscosasis csvsnsdssssasdssossssidasesisi so 117 15 Appendix C TinyOS Settings and Scripts sssssssssceceocccssssccecoccsssssscecocosssssscecocsossssseee 122 16 Appendix D TinyOS RT rS T E 124 17 Appendix E Computing TOS Packet CRC ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss 126 Doc 7430 0108 02 Rev A Page ii MEMSIC gt XMesh User s Manual About Th
21. TimerJiffyAsyne ne preprocessing C tinyos cygwin opt tinyos 1 oAck byteorder h preprocessing C tinyos cygwin opt tinyos 1 eControl ne preprocessing C tinyos cygwin opt tinyos 1 edSend ne preprocessing C tinyos cygwin opt tinyos 1 xdev contrib xbow tos 1lib CC2420Rad1 xdev contrib xbow tos lib CC2420Rad1 xdev contrib xbow tos lib CC2420Rad1 xdev contrib xbow tos 1lib CC2420Rad1 xdev contrib xbow tos 1lib CC2420Rad1 xdev contrib xbow tos 1lib CC2420Rad1 xdev contrib xbow tos 1lib CC2420Rad1 xdev contrib xbow tos lib CC2420Rad1 xdev contrib xbow tos 1lib CC2420Rad1 xdev contrib xbow tos lib CC2420Rad1 xdev contrib xbow tos lib CC2420Rad1 xdev contrib xbow tos lib CC2420Rad1 xdev contrib xbow tos 1lib Queue Queu xdev contrib xbow tos lib Queue Queu xdeyv contrib xbows tos lib Queue Queu Doc 7430 0108 02 Rev A Page 123 XMesh User s Manual MEMSIC 16 Appendix D TinyOS Components Some commonly used TinyOS components are provided below Component Wiring Example Usage Description Component Wiring Example Usage Example Description Component Wiring Example Usage Example Description Component Wiring Example Usage Example Description Wiring Example Component Usage Example Description Page 124 LedsC MyappM Leds gt LedsC Leds call Leds redOn call Leds redToggle j call Leds yellowOn call Leds yellowToggle call Leds greenOn call Leds
22. 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 application 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 Mnopsend AP_ID Example Usage call COMM send BASE STATION ADDRESS MODE UPSTREAM dataMsgPtr sizeof dataMsg Page 54 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 is sending a packet with this interface it must first call getBuf fer to geta pointer to the valid data region
23. XMesh User s Manual 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 1 5 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 1 5 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 packets from base station Mote to node s e Single Hop Delivers packets to neighboring nodes only 1 5 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 a
24. and writes it into the packet as it is 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 is to ensure that data is 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 is 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 100 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual Beacon broadcast to form an ad hoc time authority hierarchy Base Station Mote lt 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 order to estimate the crystal skew The estimated crystal skew
25. 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 Page 36 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual Table 3 12 Different Timers used in the Application Timer Period Type Description sec UpdateTimer Sets sampling interval fires WaitTimer 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 Elol route_discover Command result er SraContr rol start 7 call UpdateTimer start TIMER_REPEAT gSampleInterval j cally Healehiimerssstece TIMER REP EA ELP Sit RH MiSs jr Cale Mest omn cols iecie mn Gall EloControll enable Cally R sourenorscover NUMEROUIEED PS COVER MINTS i pressureDataPtr pressureMsg call COMM getBuffer dataMsgPtr skem crecurcn SUR S S 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 ElpIT 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 A WARNING When joining the mesh the ELP Mote needs to stay awake for several route updat
26. in Table 3 11 below 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 and 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 e 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 e 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 e Becareful of all leakage paths between the battery voltage and ground A 100K resistor from the battery to ground will introduce 30 uA or so 3 5 1 Battery Selection e 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
27. 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 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 is 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 Doc 7430 0108 02 Rev A Page 35 XMesh User s Manual MEMSIC gt Sensor uP radio on to sniff Radio xmit uP sleep measure RF evefy 125 msec Sensor Sensor lt pwer on A
28. msec The time stamping is used to synchronize radio messages but is also available to users to synchronize sensor measurements 1 5 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 Page 10 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 MEMSIC CVS code repository 2 1 XMesh Build Environment XMesh is compiled and built using Mote Works 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 is necessary to set the correct parameters in each of these files 2 1 1 MakeXbowlocal The MakeXbowlocal file contains global parameters which are applicable acro
29. 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 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 MEMSIC XMesh networks make no distinction between RFDs and FFDs except for XMesh ELP All Motes can have int
30. 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 statistics health packet fields are provided in Table 10 2 Table 10 2 Statistics Health Packet Structure uintle_t seq num This is the sequence number of the health packet Page 82 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual uint1l6_t num node_pkts Number of application packets that have been generated locally uintl 6 _t num_fwd_pkts Number of radio packets that the mote has forwarded in the mesh uint16_t num drop_pkts Number of radio packets that the mote has dropped due to failed link level retransmissions uintlo_t num_rexmits This is the number of times that the message was re transmitted uint8_t battery voltage Battery reading 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 Hea
31. power off Figure 3 4 Behavior of Lithium Thionyl battery under XMesh ip 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 Mote Works apps examples TestElp The TestElp application is based on the default XMesh ELP application Mote Works apps examples TestElp2 refer Section 8 5 The application requires following 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 is 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
32. provided by either a 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 MEMSIC 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 Page 6 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 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 analys
33. that the external device s transmit pin which would be connected to UARTI s receive pin defaults to a high impedance state on reset Otherwise OTAP will not be able to access the serial flash USART1 TXD g RAD USART CLK a A WARNING UART1 s transmit and receive pins are shared with the external serial flash chip which is used for OTAP 3 3 3 ADC The ATmegal128 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 ATmegal128 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 JTAG 1s operational these channels cannot measure sensor signals PFSTMS PF amp TDO PFTITDI 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 Doc 7430 0108 02 Rev A Page 27 XMesh User s Manual MEMSIC gt available Also ADC1 is wired to a thermistor for temperature measurements but this channel can be shared with another analog input eh ie Le l S T Ls oppg H RIN L c4 VENSR aza 7 ar our E L NOLOAL A R ADC C ADGI0 71 CHF_OUT jg X OHF OUT RESI xosu H E SOS 0 PAOD LO THERM_PWR gt Cie R13 D0 tuF TAR E
34. the PressureSensorM module enter PressureSensorMSgSampleCount in the watch window and Add entry PressureSensorM gSampleCount uint8_t 0 Q msg TOS_MsgPtr Ox8008ab 2 Local parameters These are local to the procedure and they are entered directly without the name of the module A 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 Page 46 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual PressureSensorM nc Source Window COX Fie Run View Control Preferences Help IPPO PP S amp S A E Fina ada PressureSensorM nc PressureSensorM WaitTimer fired SRC ASM 183 TODO Make sure cpu doesn t sleep in a state which disables counter 184 185 event 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 a return SUCCESS event result t WaitTimer fired uint16_t currentCount currentCount call readCounter ressureDataPtr gt SensorCount gSampleCount c
35. 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 event 109 MsgPrr RevAck receive TOS MsqrPer pMso vold pay load R G E payloadLen here users can set the state to start sending next packet 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 is 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 ip eau oend send BASERET STATION ADDRESS MODE SUP STEP AMSACK GoMisgBuc ken Saco Upc ream EI R GC hoo any Ca IT imMmer Ack otari TIMER ONE E O 7 tom miogh power seack bAckWait TRUE When the timer fired event occurs decide whether to resend the packet based on a retry number event result c TimerAck fired ite NUMER Diy Enmen ry post sendTask else reach retry limit num_retry 0 bAckWait FALSE iee E K SUC SS If the end to end acknowledgement is received before the timer expired cancel the timer event HE Msgr G REVA lt 5 Sieve EH pMa a Wwealcla ETI U EEE 6 sic payloadLen if bAckWait call TimerAck stop num_retry 0 Doc 7430 0108
36. value is 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 is 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 is 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 is called the offset One common equation that expresses the local time in terms of the globa
37. you will see the output shown below S 5 SOLES e Locelinost 1 2 o 12 OPE TON cmd boot sar lh eWinosic s UG Group id 129 debug 1 html report file xotap html image id 2 motes 1 2 Rebooting mote 1 with image 2 Rebooting mote 2 with image 2 2 of 2 motes done E R E G 2 mores Suecessitll CO neces sac Lec 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 A WARNING Enabling the watchdog timer will increase the sleep current by an additional 15uA for the ATmegal 28 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 1s used to establish a global network time stamp and to schedule network communication Time synchronization is implemented on top of the long preamble Full Extended Preamble communication mechanism that allows nodes to Doc 7430 0108 02 Rev A XMesh User s Manual MEMSIC efficiently c
38. 02 Rev A Page 59 XMesh User s Manual MEMSIC bAckWait FALSE cecurn PMSG 9 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 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 1 Sending directly from the base station mote 2 Sending from a PC or other host that is 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 0x0C 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 cre appendix E e NEVER modify the multihop header which is internal to XMesh XMesh in the base station wil
39. 39 Usm A Ke eT 25 34 Low Power Operaio eee cn AERE ey 32 3 5 Optimizing tor Battery Operati Oli ssssssi resen A EE E E 33 3 6 A Low Power Design EXampl s sss 36 3 7 Estimating th Average Current sireeni a ENNAN 38 3 8 Hardware Debugging Techniques sss 39 T AM TT OVNI W E E 4t XMesh Power Configurations cccccccccccccccccceceeceaeeeeessseeseeeeecceeeeeeeeeeeeeaaaeeeseseeees 49 4 2 Forming a Multi hop Mesh NeworkK sss sese 50 5 Sending and Receiving XMesh Messages ssscccsccccssssssssssssscccccccsssssssssccccssssesees SL TinyOS M lhihop NSS SA 8 CS osmine reatar Era e EA AEE AENEA 53 DZ AMesh Messanin t AP D rsrirenaeinien ira RE EE Er EEEN 54 53 Using tbe Messaging U H 57 A Mesh Ront Controls wisisiccescenccencstescaasececesaccasessavesacsbauctacvassssuectseswesvesetassaasesudesusesceeceaes X Mesh LP Low Power saunei eie anen e a iasi a a TA Low Power OPC ION pacsrasscvasservercebesevnaavenanrctynsineasbersonsd vesedasevansionatvasendadbsanenatbesadenetseses 64 8 XMesh ELP Extended Low Powe r ccccccccsssccssccssccscsccssccsccccscccscccccsccsccccccccecces i Ware re ascescserancaseuncs nna E R 69 62 erat Theory Of aces c aseneepeavestone nasa caren eea ATE EE EEEE EERE a 70 Doc 7430 0108 02 Rev A Page i XMesh User s Manual MEMSIC gt 8 3 Whe X Mesh ELP Iter aCe ansccsssssaveiesaccatsesoseanaperaavassaceousnsataceinsestananvanaguaasossousanezeneansadss qe Bet Bodine DIVE MELP
40. 3a4 Clock nc poms jmp h Counter nc peer Imp Xaa Framer ckh nce ri la Ban Framerh ne K Jmp aS ay 52 gt jmp Hx 23 lL S L 56 gt jmp 0x3a4 S Aea vlo jmp 0x1a22 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 breakpoint Doc 7430 0108 02 Rev A Page 43 XMesh User s Manual MEMSIC e Step through C code or assembly code 9 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 atthe 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 A 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 breakpoint
41. D PG1 RD PGO WR OC1A PB5 O 15 OC1B PB6 C Go Go PD1 L 26 RESET L 20 VCC L GND 1 22 XTAL2 XTAL1 LL 24 PDO Lj 25 PD2 LJ PD3 U 28 PD6 LU 31 PD7 Lj 32 gian Ra R p i sS p TOSC1 PG4 19 NT1 NT2 NT3 CP CK1 T1 T2 TOSC2 PG3 L OC2 OC1C PB7 C SCL INTO A I X SD RXD1 TXD1 Figure 3 2 ATmega128L Microprocessor Pinout Doc 7430 0108 02 Rev A Page 25 XMesh User s Manual MEMSIC 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 ATmegal281V 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 T WOO s Oo 2 gt fF KA rr AN Q FTF WO DO N 2 0 O O U U G H Oo N OY 0 6 OG ob O O oO on en ee ee a L DOD r A SF WW BD 5 ri wa Z Z Z TTL K LK LL Z 2 Z Z Z ZI SISI SISISI S RI REE RAGES OCOB PG5 1 PA3 AD3 AXDO PCINT8 PDI PEO PA4 AD4 TXDO PDO PEt es PAS ADS XCKO AINO PE2 PA6 ADB OC3A AIN1 PEB PA7 AD7 OC3B INT4 PE4 6 PG2 ALE OC3C INT5 PES PG7 A15 T3 INT6 PEG 41 PC6 A14 ki ATmega1281 2561 E ICP3 CLKO INT7 PE7 9 PCR A13 SS PCINTO PBO PC4 A12 SCK PCINT1 PB1 PC3 A11 MOSI PCINT2 PB2 PC2 A10 MISO PCINT3 PB3 PC1 A9 OG2A PCINT4 PB4 PCO A8 OCG1A PCINTS5
42. ERRUPT5 External Interrupt5 Named INT1 on expansion conn SIG_INTERRUPT6 External Interrupt6 Named INT2 on expansion conn SIG _INTERRUPT 7 External Interrupt7 Named INT3 on expansion conn Page 30 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual SIG_OVERFLOW ab mae aa OOO man apa SIG USARTO DATA UART 0 Data Register Empty Interrupt SIG USART1 DATA UART 1 Data Register Empty Interrupt SIG_USARTO TRANS UART 0 Transmit Complete Interrupt SIG_USART1 TRANS UART 1 Transmit Complete Interrupt SIG_ADC ADC Conversion complete OO SIG EEPROM READY Eeprom ready l SIG COMPARATOR Analog Comparator Interrupt D 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 is executing e TOSH_SIGNAL signame executes with interrupts disabled i e another interrupt will not be serviced while this routine is executing M EXAMPLE An example of these handlers are TOSH_SIGNAL SIG_UARTO_RECV ENP UIC ROAS IL IC Signal UART Cree alia UDI 2 Doc 7430 0108 02 Rev A Page 31 XMesh User s Manual MEMSIC gt TOSHA TNTERRUP IS IG LEER Ul COMME TAI TANT STON Cagney E G E 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
43. EUE_ SIZE Mote Addresses BASE_STATION_ADDRESS STATION ADDRESS 00 Base station address TOS LOCAL ADDRESS _ address usually assigned when loading code via install x or reinstall x or MoteConfig TOS BCAST ADDR Oxffff Broadcast address radio messages addressed to this address can be received by all motes Page 114 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual TOS UART ADDR 0x007e oe with this address are sent to the Platform Defines set when building for a specific platform TOSH HARDWARE MICAZ Code is built for MICAz TOSH_HARDWARE_MTCA2 Code is built for MICA2 TOSH_HARDWARE MICAZC Code is built for IRIS Application IDs Application ID 1 127 User available Application ID 128 255 MEMSIC reserved AM Messages Types User applications only deal with Application ID through using the MnopSend receive interface to send receive message and XMesh decides which AM type is 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 oo data msg from node to base no end end AM DATA2NODE Downstream data to node AM DATAACK2BASE Upstream guaranteed delivery to base Doc 7430 0108 02 Rev A Page 115 XMesh User s Manua
44. MEMSIC Powerful Sensing Solutions for a Better Life XMesh USER MANUAL Document Part Number 7430 0108 02 Rev A MEMSIC Inc 1759 McCarthy Blvd Milpitas CA 95035 Tel 408 964 9700 Fax 408 854 7702 email infoca memsic com website www memsic com 2010 MEMSIC Inc All rights reserved Information in this document is subject to change without notice MEMSIC MoteWorks MICA TrueMesh and XMesh are registered trademarks of MEMSIC Inc Other product and trade names are trademarks or registered trademarks of their respective holders MEMSIC gt XMesh User s Manual Table of Contents E BREE OCU einai cacenseccecexauvcccescecccveissvcucenceccecevanwsucenscccecetsstecucencescecevanscuceseessensiusecescaceccevercs 1 1 Mesh Networking Fundamentals sss sese l Rp K lt 0 6 re ea 2 I AN SROV IEN TT 5 A XMesh Network Landscape ssssessisssesroiesasesaisoseitoiesnseoididesroissair iieo ioiei iiianoe iaia E 15 Mesh Features and ST ts xasascvsssaasuuevsacwnntandsvassszaansvesidasouevuacwesinad diassneuancvesaaaseeenieats 8 2 MPU XVI CGI oaxczccececccocescecssascasevevevssetanscevecevececusssesstassvevssevanccesesetescecsonssatcsevevecevauacesers ZA AAMk el Wy OIC OC TTT 11 2 2 Building an XMesh AppIIcanon sss 14 23 Deploying he NetWork TTT 18 S UEB A See ected A E E EA E ea EEA EE 19 SD Prina 8 L 2 T erae EN E EE SEEEN EREE EERE ET sk Hardware PI ON eenia EE NEEE E 20 E AT E OO EE E E EEEIEE EA EAE EEE IE 23
45. Measure Sensor oS 7p gt Have Yes l parent _ Call Elpl wake p Elpl wake_done b Xmit Data Z O Yes sleep force_sleep 0 No R sleep force_sleep 1 3 7 Estimating the Average Current The average current can be estimated 1f the following is known e Current of each operational state e Duty cycle of each operational state For this application the operational states are 1 Sleep The system is in this state approximately 95 of the time 2 TimerO This timer service is 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 is using 8 mA of current 3 Measure Sensor For this application the sensor is on for 50 msec The ATmegal128 is 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 pro
46. MeshBase application have the structure described in Table 9 2 Table 9 2 Packet Structure of XMeshBase Heartbeat Messages uintl16_t addr This the Tos_Msg address field which is always set to 0 uint8_t am_type This is the Tos Meg am_type field The am_type for heartbeat messages are OxFD inco group This is the Tos_Msg group field set to the built group id for XMeshBase uint t Length This is the Tos_Msg length field The length of the heartbeat message is 2 bytes uintl6_t seq_no This isthe 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 gt The lt num missed gt variable is the minimum number of heartbeats missed before XServe will attempt to restart XMeshBase Each heartbeat period is 5 seconds so in the case of a serial connection problem the base station will be down for lt num missed gt 5 seconds Page 80 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 10 XMesh Services The XMesh services include the following features e Health Statistics e Ti
47. N OxEF An unknown packet type 2 n 1 Payload Data In most cases will be a TinyOS Message of varying length which is described below n n SYNC_BYTE Always 0x7E 9 3 Building XMeshBase XMeshBase 1s 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 lt hardware platform gt base route lp for XMesh LP 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 is 55 see Makefile component If the application data packets are larger than 55 data bytes then build XMeshBase with TOSH_DATA_LENGTH gt 55 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 bu1ild micaz main exe 25746 bytes in ROM i 3642 bytes in RAM avr objcopy output target srec bulld micaz main exe b
48. Pork com 5 Figure 10 9 Select an Application for Programming the Nodes Page 94 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 2 MoteConfig 5 E x File Settings Help Local Program Remote Program Operation Option W Check Base Heartbeat Select File to be Frogrammed C Program Files Crossbow Moteview 4 20 emesh micas MD Select Select Nodes e g 1 4 7 11 12 1 71 Select Slot O Ready O Preparing T Check Operation Timeout O Programming O Rebooting Begin scan C Program Files Crossbow Moteview 1 4 20 emesh rica sM DAT UUCB A 903_hp ene Mesh protocol found Converting C Program Files Crossbows oteView 1 4 20 smesh mica2MDA100CB_ S03 _hp exe to C Program Files Crossbow Moteview 4 20hemesh mic az sha Da 00CE_903 _hp eee thes Process completed Node 2 iz ready to Quern Frogram or Reboot Node 1 ts ready to Quern Program or Reboot Downloading Page 6 of 13 Crossbow Inc 2006 Device mibS10 Por com Programe 00 00 45 a Figure 10 10 Programming the nodes in the network via XOTAP Open the Process Messages window by clicking on File gt 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 L E Starting download Page 1 mote 1 128 fragments throttle 30 mec Page 1 mote 1 29 fragme
49. 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 state 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 pi 0 d Power mode for nodes that make AR up the backbone and Extended we NS HP Y S U Low Power mode for nodes along the edge 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 02 Rev A Page 69 XMesh User s Manual MEMSIC gt 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
50. RF The radio strength of the parent as heard by the mote originating the health packet G xSniffer mm X Log All Route Health Neighbor Time Sync Options Id MSe Msg Time Cnt Nbrid1 LA1 m n Costi RFI Nbrid2 LQ2 m n Cost2 RF2 Norid3 LQ3 m Cost3 RF Nbr La Co RF_ Nbr Last Co RFS gos 127 14 jm 2 2500 00 4 fai jo 100 80 fd il id i i os he3 h3 m l l5 hoogs ie Sts je a S i O O ail 025 hss h3 fo R fhs 3100 4 al 5 ft00 700 sat fa 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 ofthe sendingmote OOOO 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 Doc 7430 0108 02 Rev A Page 109 XMesh User s Manual MEMSI C Log All Route Health Neighbor Options Id_ Phase Corr Authority RawTime Elapsed Time Skew ms Msg Time 003 4 40 4 2919965 0d00 49 55 406 3435 IR 144 ooo jo o 2 1342746 0d0049 51971 jo 2 221 Figure 11 6 XS
51. Source External XMeshBase oscillator Brown out detect enabled JTAG disabled BootLoader disabled The following table shows fuse setting for ATmegal 281 XMesh Description configuration XMesh LP and Oxd9 Oxc2 Oxff Clock Source Internal XMesh ELP Oscillator no OTAP Brown out detect disabled JTAG disabled BootLoader disabled XMesh LP and Oxd8 Oxc2 Oxff Clock Source Internal XMesh ELP Oscillator OTAP Brown out detect disabled JTAG disabled BootLoader enabled XMesh HP Oxd8 Oxff Oxff Clock Source Internal OTAP oscillator Brown out detect disabled JTAG disabled BootLoader enabled Base Station Oxd9 Oxff Oxfd Clock Source External XMeshBase oscillator Brown out detect enabled JTAG disabled BootLoader disabled 9 NOTE Enabling the JTAG fuse allows users to debug code on the ATmegal28 using a JTAG pod If this fuse is 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 Page 120 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual fuse
52. acket if it is set to 0 the ELP node first sends a health packet to the base and 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 A 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 ree ster Force_sleep 1 No Xmit Health Pkt lt q T Max Fire Health Int Timer Retries NO AER as E Timer amp Sleep T da Stop Timer e Fire Duration Timer Done gt y 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 Q Sleep SleepDone User App lt Duration gt First Health Packet Sent Immediately Health Messages lt Health Int Figure 8 3 Sequence of Events during ELP Doc 7430 0108 02 Rev A Page 71 XMesh User s Manual MEMSIC gt 8 3 The XMesh ELP Interface There are two interfaces Mote Works tos interfaces to control XMesh ELP enabled Motes e ElpControll e Elpl 8 3 1 ElpControll Interfac
53. ange any section of SRAM e View and change any of the CPU I O registers see Figure 3 12 OX Address 0x800100 o Target is LITTLE endian B G T 8 9 A B C E x f w D O O x 134 D Oj o o D o G o x X o o D oj G x M M D D T D o G 0x00800130 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0 0x00800140 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0 xO 0x00800150 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0 0x00800160 0x00 0x00 0x00 0x00 0x00 oxo9 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0 0x00800170 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0 4 CG3 CG3 o amp Mm x o G amp H X o amp Gl amp M o amp G Figure 3 13 Viewing CPU s I O Registers The ATmegal128 I O registers are mapped into a high portion of memory starting at 0x800020 The Register Summary at the back of the ATmegal128 manual shows all registers and their offset from 0x800020 and 0x800000 Offset from 0x800020 so Offset from 0x800000 33 53 TCCRO FOCO WGMOO COMO1 COMOO WGMO01 32 52 TCNTO Timer Counter0 8 Bit 31 51 OCRO Timer CounterO Output Compare Re Doc 7430 0108 02 Rev A Page 45 XMesh User s Manual MEMSIC 30 50 ASSR ASO Addresses Address lo
54. are not programmed correctly the supply current can increase by hundreds of LAs 3 4 1 HPLPowerlManagement TinyOS supplies a power management component HPLPowerManagementM which will monitor the interrupt state 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 ATmega128 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 Timer0 is enabled for interrupts e UCSROB and UCSRIB Checks if UARTO or UART1 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 schedu
55. ariable 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 Variable Value 4 E ComSpec C WINDOWS system32 cmd exe Edit Syst em Variable FP_NO_HOST_C NO FRAMEWORKPATH C VXIpnp WinNT INCLUDE C Program Files Microsoft Visual Studi v Variable name AVARICE_ARGS Variable value Figure 3 9 Setting Environmental and System Variables of the PC j dev ttySO The example shown above sets the JTAG pod for serial port COM1 SO This also can be done from the Cygwin command line export AVARICE_ARGS j COM1 To build a debug version of an application do make micaz debug OT make mica2 debug Or make iris debug A WARNING The mot e_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 T0S_LOCAL_ ADDRESS xx where xx is the desired id Make sure the JTAG fuse 1s enabled on the mica platform This can be done using the fuses script see Appendix B fuses jtagen A WARNING The default fuse setting is JTAG disabled Each time the mote is programmed with make install lt platform gt the JTAG fuse will be disabled Start avr ice by typing ice insight build mica2 main exe ice insight build micaz
56. as COM1 export AVRICE_ARGS j dev ttyS0O e To invoke the avr ice jtag program for a MICAz alias jtagmicaz ice insight build micaz main exe usr ocal bin File Scripts can be executed directly if they re located in Mote Works Suite cygwin usr local bin Several scripts such as location sh fuses gettos settos located in Mote Works tools bin can be copied to the usr bin file TinyOS scripts Page 122 Doc 7430 0108 02 Rev A XMesh User s Manual location sh This script will list all the files compiled into the application Run this script only after successfully building an application For example location sh make micaz route hp will show an output similar to C location sh make micaz route hp2 preprocessing C tinyos cygwin opt tinyos 1 oAck CC2420Control ne preprocessing C tinyos cygwin opt tinyos 1 oAck CC2420ControlM ne preprocessing C tinyos cygwin opt tinyos 1 oAck CC2420Radio0C nc preprocessing C tinyos cygwin opt tinyos 1 oAck CC2420Radi10M nc preprocessing C tinyos cygwin opt tinyos 1 oAck HPLCC2420 nc preprocessing C tinyos cygwin opt tinyos 1 oAck HPLCC2420F IFO nc preprocessing C tinyos cygwin opt tinyos 1 oAck HPLCC2420RAM nc preprocessing C tinyos cygwin opt tinyos 1 oAck MacBackoff nc preprocessing C tinyos cygwin opt tinyos 1 oAck MacControl ne preprocessing C tinyos cygwin opt tinyos 1 oAck RadioCRCPacket nc preprocessing C tinyos cygwin opt tinyos 1 oAck
57. ber of milliseconds The 64 bit integer is 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 1s 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 source_addr uint16_t Source address of time message phase G E E rt The difference between the mote s local time and the time update from the last timesync message Corr Smoothed out skew correction value authority uinte t 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 Most significant 32 bits uint32_t Least significant 32 bits Isb 1000 1024 sec Doc 7430 0108 02 Rev A Page 103 XMesh User s Manual MEMSIC gt 11 XSniffer MEMSIC has dev
58. ble unchecked Page 90 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual MoteConfig ioj x Fie Settings Help Local Program Remote Program Select File to be Uploaded C Program Files Crossbowk lev 1Iew Nrmnez mG aZ M eshb ase 202 hp ere Plathorm Type Micae Rado Band 916 MHz Addresses Mesh Type XMESH2 HF MOTE ID if Hex T Auto Irie Route Update aE Sec GROUP ID 100 T Hex Saas Packet Size 55 Bytes 9 5 poe ag Pi Payload Size jas Duez RF Channel CHANNEL_00 9 903 018 KH Read Fuses Clear Text View Details Program a TAP Enable Stop Vemeshmicae Meshb ase 202 hp exe out srec Setting fuse using mib510 wisp dproag mibS1 0 dsenal devthyS0 dparts47 megal 29 wr_fuse_h Oed9 wr_fuse_l Qsff wr use e lt 0gTT Erasing binary using mb U wisp dprog nmibS10 dsenal dey thyS0 doarts47 megal 26 erase Installing binary using mib510 wisp dprogemib5 deenal dev thyS0 doars47 megal 29 upload i C Program Files Crossbow MoteView smesh micas M ezh ROTTE Crossbow Ine 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 inte
59. c which enables turning any led off or on also toggling the led Inserting calls to the LEDs in the code Doc 7430 0108 02 Rev A Page 39 XMesh User s Manual MEMSIC gt 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 ATmegal 28 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 Set breakpoints e Change variables and jump over code In order to use JTAG the following are required e A JTAG 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 SS SS a A l t l W U l Ree EERE gt f 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 MIB510 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 U
60. ce command result L setUpdateInterval uint1l6_t Interval Description Sets the routing components internal route update interval The duration in seconds of successive routing updates SUCCESS if the operation succeeded Doc 7430 0108 02 Rev A Page 63 XMesh User s Manual MEMSIC gt 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 7 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 uAmps The differences between the power modes are processor specific Users should consult Atmel s ATmegal28 manual for the MICA2 MICAz Motes and ATmegal281 manual for the IRIS Mote
61. cessor are awake Page 38 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual 5 Health Data Health packets are sent only every several minutes Sending a health packet is similar to the data packet except that it uses end to end acknowledgement The time to receive the acknowledgement depends 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 is on for 300 msec the duty cycle is 0 017 Table 3 13 Calculation of Average Current Operational State Current mA Duty Cycle Avg Current pA a IT 5 14 13 Total Average Current 31200 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 Timer0 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 Measured averaged current 50 msec idle to acquire sensor data including health packets 309 pA Sensor power on Ts 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 Leds
62. ck Operation Timeout Select Nodes e g 1 4 7 11 12 17 Select Slot O Ready DU Preparing BE DG reen TTT m EEE EE Program m sea L So INode 1 is ai to Query Program or Reboot Node 2 is ready to Quern Pro an or Reboot Node 1 ts ready to Quam Frogiam or Reboot Node 2 is ready to Duer Program or Reboot Node 1 is ready to Query Program or Reboot Node 2 ts ready to Query Program or Reboot Node 17 ts ready to Query Program or Reboot yotap ere sf localhost S001 i2 p 12 U pions cmd boot S localhost S001 group id 129 lri report fle sotap him image moles 1 2 Rebooting mote 1 from slot 2 Please wait for the mote to turn green Rebootng mote 2 from slot 2 Please wart for the mote to turm green Crossbow Ine 2006 Device mib510 Port comi E F 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 1 Connect the base station to the PC interface board and turn on the remote nodes that were prepared as per Section 10 2 8 2 Start XServe on the PC connected to the base station assuming the base station is connected to COM3 xserve s dev ttySs3 3 Initialize T
63. cknowledge message is then sent back to the originator 1 5 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 Doc 7430 0108 02 Rev A Page 9 XMesh User s Manual MEMSIC gt 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 1 5 5 Health Diagnostics Within the XMesh network nodes can automatically transmit 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 1 5 6 Time Synchronization XMesh LP support a network global time synchronization to 1
64. date Intervals this is intended to avoid cycles e is not an ELP node An XMesh multihop network is 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 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 is 16 for the remote mote 40 for the base station if 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 it is 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 qualit
65. difference between the two 1s that intercept handles the packet that 19 meant for the current mote while snoop handles the packet that is NOT meant for the current mote Note that these routines will only intercept snoop messages for the application ID that they are wired to Parameter Description 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 1d and address Example Wiring XMeshRouter PromiscuousSniff 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 XSnfM provides event vorid Er omiscuous oniri TOS MJP joMise 5 3 Using the Messaging API 5 3 1 Active Messaging and Application ID TinyOS has historically used an AM parameter in TOS message
66. e Example Wiring MyeppM ElpControll gt xXMeshRouter BlpControll Example Usage call ElpControll enable Interface command result L 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 sleep command 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 Bipl gt xAMeshRouter blpl Example Usage Call Elpl wake Interface command result t route discover uints t ruil Description Attempts to join the mesh When called it Turns the radio on for up to rui ROUTE UPDATE INTERVALs attempting Page 72 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual to find a parent If a parent is found sends a health message retries up to x times requiring an end end acknowledge from the base station cel The number of ROUTE_UPDATE_INTERVALS to wait for joining the 3 mesh i e within this time the mote should have heard 2 route updates from neighbors and selected a parent event result ct route discover done uints_t success uintlo c parent Interface 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
67. e box 1s checked Click on Program Z MoteConfig k E loj x File Settings Help Local Program Remote Program Select File to be Uploaded C Program Files Crossbow Moteview emesh mG az MTS 37004 202 Ap ese Select Platforn Mesh Type Mica Radio Band 1916 MHz O Tee NE ata IE Me Type MESH2 HP Addresses MOTE ID 3 V Hex Auto Ine Route Update 36 Sec F adia Packet Size E Bytes GROUPO noo V Hex 25 5 RF Power 205 YA Payload Size 23 Bytes RF Channel CHANNEL_00 9 903 01 B MHz Read Fuses Clear T ext View Details Program I OTAP Enable Stop Begin scan F CrossBow wireless apo4MoteConfigsbinD ebugGolden magesOtapGold_micaz_916 exe Mode ID set as 3 Group ID set as 100 WAAR TO Baud set as 57600 Mesh Health Update set as 60 me CC1000 Channel set as 916MHz band CHANNEL DU channel CC1000 T Power set as 255 Converting F CrossB ow wireless app4M oteContighbinD ebug G oldenimages0 tapG old_micae_916 exe out to F Crossbow wuireless Lapp oteConfigsbinD ebug Golden mageOtapGold_ mica 91 E sve sred Crossbow Inc 2006 Platform Mica 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 Ena
68. e 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 ame YEG XMesh Network Base Station Mote Figure 10 1 XOtap Architecture 10 2 1 How does OTAP Work Every MEMSIC 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 i 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 MEMSIC advises users to use small component XOTAPLiteM This component uses just 30 extra bytes If an Application wires in XMesh component the XOTAPLiteM 1s 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 Page 84 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual down
69. e 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 ATmega128 there are 4096 bytes of RAM The maximum RAM usage should not exceed 3750 bytes 19052 bytes in ROH 1883 bytes in RAM B avr objcopy output target srec build micaz main exe build micaz main srec avr objcopy output target ihex build micaz main exe build micaz main ihex writing TOS image Doc 7430 0108 02 Rev A Page 17 XMesh User s Manual MEMSIC gt 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 MIBS510 with serial connection e MIB520 with USB connection e MIB600 with Ethernet 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 make lt mote platform gt install lt node_id gt mib510 mib510 mib600 lt device location gt The lt mote platform gt is defined above The lt node id gt paramete
70. ecific 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 lt specific app name gt An example Makefile is 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 fora MICAz and XMesh HP make micaz base route hp An example of a Makefile 1s include Makefile component include MakeXbowlocal Page 12 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual r Automatically add certain command line goals GOALS basic freq route hp Table 2 3 Makefile Services pasic Responsible for including the standard MEMSIC services This service should be included in all XMesh applications os power route Sets the radio channel for the application This feature acts as an application specific override of the RADITO_CHANNE L parameter set in the MakeXbowlocal file Usage S 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 Sets the radio power and acts as an override of the RADIO_POWER parameter set in the MakeXbowlocal file U
71. ed in Table 3 6 Page 28 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 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 1s POSH ASS lGNS PIN REDT LED A 2 TOSHEAMAKEMREDEAFEDEOUNEUVM OF TOSE _SET_RED L D_ PIN A 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 ATmegal281 respectively Table 3 7 ATmega128L Interrupt Routines Doc 7430 0108 02 Rev A Page 29 XMesh User s Manual MEMSIC SIG_OUTPUT_COMPARE1A Output Compare LA Interrupt re SIG_OUTPUT_COMPARE1B Output Compare1 B Interrupt re Table 3 8 ATmega1281 Interrupt Routines SIG _INTERRUPT4 External Interrupt4 Named INTO on expansion conn SIG _INT
72. ed 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 in its route update messages XMesh executes a parent selection task every 8 RUIs it is 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 1t 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 1s 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 RUJ nodes two hops away will join the Mesh in 2 RUI2 so on and so forth and it will take 8 RUIs for the Mesh to get stable Page 52 Doc 7430 0108 02 Rev A MEMSIC 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 incl
73. eds application In this application each node in the network will increment its individual count every one second and 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 MEMSIC MoteWorks Installation CD The MoteWorks installation CD comes with necessary PC side software to 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 1s located in Mote Wor
74. egal28L and ATmega1281 microprocessors run both the user s application and the XMesh protocol stack The table below summarizes the internal and external resources of the ATmega128 family of microprocessors Doc 7430 0108 02 Rev A Page 23 XMesh User s Manual MEMSIC Table 3 4 Resources of the ATmega128 family Microprocessors ATmega128L_ ATmega1281 Program This memory stores the application S ico Memory 128K Bytes 128K Bytes through an MIB base 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 SRAM 4K Bytes 8K Bytes parameters XMesh variables and TinyOS variables It also contains the stack EEPROM 4K Bytes 4K Bytes 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 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 used 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 T
75. egrated 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 Page 2 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual disadvantages and each topology is appropriate under some circumstances but may be unsuitable in others 1 2 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 commands to the sensor endpoints The gateway 1s 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 point Figure 1 1 g Gateway d Endpoint 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 1 2 2 Mesh Topology Mesh topologies are multi h
76. eloped 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 MEMSIC MIBS510 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 MEMSIC Sniffer 9 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 Mote Works 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 ttyS0 A WARNING XSniffer does not run XMesh do not use route hp or route p 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 overhead within its radio range Users can use XSniffer to e Check to see if a mote has joined the mes
77. ent 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 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 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 Doc 7430 0108 02 Rev A Page 55 XMesh User s Manual MEMSIC Interface event result_t sendDone TOS_MsgPtr msg result_t success Description Signals when a packet sent with send completes 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 fa attempt a new parent was selected but no acknowledge was received The g attempt was a broadcast message Should always return SUCCESS 5 2 2 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
78. eport 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 XOtap supports the following arguments described in Table 10 4 Table 10 4 XOtap Command Arguments aeieea O Download if the voltage is above the threshold default 2 7v XServe host port default to localhost 9001 Serial port if connected directly eg c COM1 M EXAMPLE 10 2 8 OTAP Preparation using MoteConfig 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 Doc 7430 0108 02 Rev A Page 89 XMesh User s Manual MEMSIC 1 Start the MoteConfig from Start gt Programs gt MEMSIC gt MoteConfig 2 From Settings gt Interface Board Settings select appropriate programming interface board and port Interface Board Settings COM i 57600 L MIB520 s First Serial Port L MIB 00 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 Enabl
79. erface Board Settings COM 57600 T MIB520s First Serial Port Prog Comm C MIBGOO Host localhost mmm Une Interface Board Settings MIB510 Serial Port come 57600 T MIB520 s First Serial Port Prog Comm MIBG00 Host 10 1 1 99 10001 10002 3 Right click on the Select button on the 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 7 x Page 112 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 E MoteConfig iil X File Settings Help Local Program Remote Program Select File to be Uploaded C Program Files Crossbow MoteView xmesh micaz MTS310 XMTS310CA_2420_hp exe Select Platform Mesh Type Micaz Radio Band 12420 MHZ Type XMESH2 HP Addresses MOTE ID i M Hex M Auto Inc Route Update Be Sec GROUP ID h 25 H l Hex S Packet Size 36 Bytes Radio RF Power 31 v 0 dBm Payload Size 29 Bytes RF Channel CHANNEL_26 v 2480 MH
80. ersely 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 monitoring 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 Page 66 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual 7 1 4 Time Synchronized Radio Stack and the Periodic Wake up Checks The radio stack uses the synchronized time clock which is provided by the Time Synchronization service see Section 7 1 4 to schedule periodic wake up checks for sensing RSSI This is 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
81. es 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 is forced out of the sleep mode Once XMesh signals that the radio 1s on data can be transmitted After the message 1s 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 1s 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 Doc 7430 0108 02 Rev A Page 37 XMesh User s Manual MEMSIC Fire Update Timer Repetitive Fire Update Timer one shot
82. et CRC The following code is used to compute the CRC of a data packet ile lakes E E E R e a E Tishe ice yn ioe D ere ere Virne b lt 25 s tor int i 0 i lt TE TT if crce amp 0x8000 0x8000 ere Cre lt a7 OOZ alles cre ere n i return Cre amp Us E E EE TE etare a T D e le Ode kera Ine Inde E Mie COUNT ine ere 0 ine Lp while count gt 0 Cre CalcByte cre packer index Count ED G CeCe Page 126 Doc 7430 0108 02 Rev A MEMSIC gt 1759 McCarthy Blvd Milpitas CA 95035 Phone 408 964 9700 Fax 408 854 7702 Website www memsic com
83. ets Accept AND OR Value Ranges TH G e eT RT E RSSI Display Option H Er Y Display as Icon Hi E S t Display as dBm lS G e g 1 3 5 17 210 254 Log Numeric Format Option Y All Decimal Log F Headers Decimal other Hex AckDwn PaleTurg XMesh p a All Hex m l l Ack p PaleViole r Any2Any LightSteel XMesh Filename Measure Over Most Recent 7 secs T aeae pe Skew Reference Mote ID 7 Control G PAUSE E 115200 baud Elapsed Time 00 41 28 C Host localhost Logging No 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 02 Rev A Page 105 XMesh User s Manual MEMSI C Table 11 2 XSniffer Log Screen Parameters Timestamp of the message guata wine stamped by the PC Bcast The destination address of the Addr Base message Others Id of the receiving mote RF Either numerical or icon display of the radio receive strength RSSI as measured by the XSniffer mote radio te Route Update HI Type AM message type Sync E2EAck Local broadcast message Upstream message to base R Health Message Global Time Sync End to End Ack Group ID Address of mote that sent the message Address of mote the originated the message Sequence number of the message This number is incremented by the Src mote each time it transmits a new message for multiho
84. ffer Route Parameters Doc 7430 0108 02 Rev A ia Wotthereporingnode SSS How long ago in second the last message was received Page 107 XMesh User s Manual MEMSIC G xsniffer Mm X Log All Route Health Neighbor Time Sync Options td Seg Hops Parent Cost Enties Idi Esti 1d2 Est2 id3 Es id4 Est tos Es5 Msg Time o 000 30 l0 126 0 2 j5 255 25 255 7 11 5 005 71 2 Ji5 S 3s S 9 H HS C 91T 19 23 015 98 li lo l4 3 ls as5 lo ago asia 29 les 02 Mmo h b l4 3 5 255 0 255 hs i255 29 2 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 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 XMesh power state LP or HP Vers Version of XMesh application HSeq App Fwd Drop ReXmit Volts Sequence number of the health packet Number of packets generated by the Mote Number of packets forwarded by the Mote Number of packets dropped by the Mote Number of packets re transmitted by the Mote Battery voltage reported by the Mote vy T The radio strength of the parent as heard by the mote originating the health packet Reserved for internal u
85. greenToggle Turn on off toggle red yellow green leds NoLeds MyappM Leds gt NolLeds call Leds redOn call Leds redToggle 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 TimerC MyappM Timer gt TimerC Timer unique Timer call Timer start TIMER_REPEAT 1000 Gell Timer starc TIMER ONE SHOT 5000 Fire a repetitive or one shot timer Time is set in milliseconds uint_32 Minimum time is 3 msec COMM MyappM CommControl gt Comm MyappM SendMsg gt Comm SendMsg AM_TYPE Call SendMsg send TOS_UART_ADDR MSG_LEN msg_ptr Send a message over the uart or radio do not use this for sending radio messages with XMesh HPLPowerManagementM not a component MyAppM PowerManagement gt HPLPowerManageM MyAppM Enable gt HPLPOowerManageM Enable MyAppM Disable gt HPLPowerManageM Disable call Enable call PowerManagement adjustPower 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 02 Rev A MEMSIC XMesh User s Manual L This is a parameterized interface TinyOS automatically assigns a value to the unique Timer value Doc 7430 0108 02 Rev A Page 125 XMesh User s Manual MEMSIC 17 Appendix E Computing TOS Pack
86. h 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 A WARNING XSniffer can only hear radio messages within its radio range Normally the XSniffer Mote is 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 104 Doc 7430 0108 02 Rev A MEMSIC 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 Allows users to set filters on incoming messages based on the message parameters and using AND OR logic nn en 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 G XSniffer Log All Route Health Neighbor Time Sync Options Juanscesscnnsearevasseaseeed Filter Options Packet Attributes E G Standard Pack
87. he 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 radios 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 I 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 4 Timers 4 Timers Timers two 8 bit two 8 bit two 16 bit two 16 bit External Clock High Speed use an internal 8 MHz clock as this clock has a faster start up time and reduces the overall power consumption for a low power mesh The high speed c
88. he next step in the OTAP process is to reboot all chosen nodes to OTAP Image for preparation of OTAP ing a new image S 5 SOLGIOc aks Sei lecelnose i 1 se i 2 R LONG cmd Door Sie Poal 00n grou paa E 129 debug 1 Page 96 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual html report file xotap html image id U motes 1 2 Rebooting mote 1 with image 0 Rebooting mote 2 with image 0 2 of 2 motes done Ritts ied emotes sueeeoosnily Om mM Oucs feild Query Users can optionally query a node when it is running the OTAP Image to get information about different slots Sg SOEG So eke Sit Jecelinose O 2 Opt Tons cmd query saz loca linosic es UCI group id 9 debug 1 html report file xotap html motes l1 2 Mote 5 micaz time Since reboot 2 6 min voltage 2 8 boot image U Image flash start stop size checksum ype U O 14 IRS IS Eada bootable il 64 79 28843 1350 bootable 2 XXX emp Y T 2 Kempt y Mote 15 micaz time since reboot 2 min voltage 2 2 Door image U Image flash start stop size checksum Type U 0 14 eis SHE bootable 1 64 79 28843 b2la bootable 2 Kempt Y T 3 xx x xempty 2 of 2 motes done Ernrshe d 2 mOces suecessiul O moces farled Program Specify the nodes you want to program and specify the slot Select the binary image of the app main ihex As the OTAP progresses you will see the report in terms of number of pages downloaded into the flash
89. ient 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 Doc 7430 0108 02 Rev A Page 1 XMesh User s Manual MEMSIC multi hop routing so that data packets can be relayed from one repeater to another when the mobile RF terminal is far away from the base station e Bi directional communication Communication between the gateway and sensor 1s 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 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
90. ility 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 MICA2 MPR600 MICAz MPR2600 IRIS M2110 RADIO CLASS 916 RADIO POWER TXPOWER_ODBM_ TXPOWER 3 2DBM DEFAULT LOCAL GROUP 0x3 0x3 0x3 An example of the Makefile for this application could be a OCS Makori lea B LRE BH rk pa ogo include Makefile component Page 16 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual include 4 Makexbow local Automatically add certain command line goals GOALS basic freq route hp TOSMAKE_PATH TOSROOT contrib xbow tools make include TOSROOT tools make Makerules The Makefile component for this application 1s COMPONENT xMeshCount Toleds MSG_SIZE 49 Once all the correct parameters are set for an application the build process can be started by executing the make command from the application directory The make command has the following parameters make lt mote platform gt binlink none build from source code make lt mote platform gt hp build from XMesh Radio binaries The lt mote platform gt corresponds to the hardware platform mica2 mica2dot micaz iris gt IMPORTANT Ifthe default ROUTE UPDATE INTERVAL has been changed mak
91. incoming and outgoing packets are framed using a PPP HDLX protocol http www fags org rfcs rfc1662 html In XMeshBase this is handled by the FramerM TinyOS component The format of the packet is e The raw data packet is wrapped on both ends by a frame synchronization byte of 0x7E This is 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 Ox7E 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 0x7E 0x42 TOS_Msg Header Payload OxAFE2 0x7E reye Feld SSCs crip o Seynenbye SSCs OE User packet ACK required Includes a P PACKET ACK 0x41 prefix byte Receiver must send a P_ACK Page 78 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual a response with prefix byte as contents P_ACK 0x40 The ACK response to a 7 P_PACKET_ACK packet Includes the prefix byte as its contents p UNKNOW
92. 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 is fixed and the interval between each channel monitoring is also fixed The period between channel monitoring is 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 anode 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 is This consumes a lot of energy for simply notifying its neighboring nodes The reason the wakeup sequence must span the entire period is 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
93. is 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 00 100 00 rere ri iiiaio 0000000 80 00 GL se E 60 00 O i S L 40 00 20 00 0 00 0 10 2 430 40 50 a Node ID Figure 1 5 Percent Packet Delivery for 48 Mote 72 Hour Test 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 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 Doc 7430 0108 02 Rev A Page 7 XMesh User s Manual MEMSIC gt 3 The Client Tier provides the user visualization software and graphical interface for managing the network MEMSIC provides free client software called MoteView but XMesh can be interfaced to custom c
94. is Document The following annotations have been used to provide additional information 9 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 is 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 Sample code and screen output Commands to be typed by the user Times New Roman Italic TinyOS files names directory names Franklin Medium Condensed Text labels in GUIs Doc 7430 0108 02 Rev A Page iii MEMSIC XMesh User s Manual 1 Introduction This manual is intended for developers using MEMSIC s Mote Works 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 Ove
95. it is seen Doc 7430 0108 02 Rev A Page 75 XMesh User s Manual MEMSIC 3 At0 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 4 Health packets are sent every 20 seconds E XSniffer 1 0 2174 25968 Log Neighbor Health Route All Time Sync Options F TEMOR POA 8 a 9 H O T OOO TR T BU a 5 9 59 O OO R P AR ee ee eee eee Figure 8 4 Screenshot displaying XSniffer Output gt IMPORTANT If the JTAG fuse Appendix B is not disabled the sleep current will be less than 3 mA Page 76 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual 9 XMeshBase This chapter discusses XMeshBase which is the standard base station application XMesh The topics reviewed are e What is XMeshBase e XMeshBase services e How to build XMeshBase 9 1 What is 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 MEMSIC interface boards 1 MIB510 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
96. 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 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 is 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 Elpl route_discover rui The service will wait up to rui ROUTE UPDATE INTERVALS to join the mesh The event Elpl route_discover_done success parent signals the result if success is TRUE then the ELP node has successfully joi
97. ks apps examples XMeshCountToLeds 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 di play Count RE L mre vailue Page 14 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual if value amp 1 call Leds redon elee Call RE E e E 5 it T EL 2 cali Meds qreenOn else call Leds greenOff if value amp 4 call Leds yellowOn else call Leds yellowOff eayeme icestllic ic Taner a G COUNT daspo ountc eoun PoS nea recura SUCCESS 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
98. l MEMSIC MODE _ONE HOP_BROADCAST 251 A WARNING Do not use the AM parameter in multihop message when sending messages this parameter is reserved by XMesh Page 116 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 14 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 ATmegal1281 manuals show these fuse settings The following table corresponds to bit settings in the uisp wr_fuse_h setting for ATmegal28L Fuse High Byte Description Default Value 7 Enable OCD JTAGEN 6 Enable JTAG 0 programmed JTAG enabled SP LEN 9 Enable Serial Program and Data a Downloading U programmed SPI prog enabled CKOPT Oscillator options 1 unprogrammed 3 l BR GAV L oo Memon ls preServeg Mrougn 1 unprogrammed EEPROM not preserved the Chip Erase 2 0 programmed pote as a Select Boot Size Prog BOOTSZ0 Select Boot Size see Table 112 for 0 programmed details BOOTRST o Select Reset Vector 1 unprogrammed The following table corresponds to bit settings in the uisp wr_fuse_h setting for ATmegal281 Fuse High Byte Description Default Value 7 Enable OCD JTAGEN 6 Enable JTAG 0 programmed JTAG enabled SPIEN 9 Enable Serial
99. l complete the remaining fields in the message before sending it downstream An example code 1s like this Tos_msg addr downstream_id Tos mog type OX0C sending downstream mo ack Tos_msg length len data length Tos mog 20Ckot application ID application id to send message ro Memcpy amp tos_msg data app data len copy data into data section Tos mS ene some econ uted ere ADO nd xcs E Send_to_serial amp tos_msg send the message to the serial port chis could send tche message directly to UART or to a serial forwarder Page 60 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 implement the sendDone event event result_t Send sendDone TOS_MsgPtr pMsg result_t success return SUCCE Sor met 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 Tos_msg type Ox0E sending downstream with ack 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 A WARNING Messages to and from XMeshBase require PPP HDLX framing Refer to Chapter 9 for details
100. l time is C t at b Doc 7430 0108 02 Rev A Page 101 XMesh User s Manual MEMSIC where t is the global time a is the skew and bj is the offset By keeping track of the skew it is possible to keep desired synchronization with fewer time updates 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 jee CUrrenit neice ROCO LE oo eme Ee ERE mice XX asyie Commerc COS caine Ic eeic jos E a Isaela 32 lsitS Gi Cuicieeinc came Beye Commeiaicl O e S42 T T Pees Cec lie lower S2 ts oF Cuicieeinc time A E DT HT ET e 2c e a 2 F ors get clock phase tone T since last clock cick x in unit of micro seconds xx agyi command WlaLigue IG E gorus Here is the tos_time_t structure typedef struct uint o 2 chg igus c low32 COS Cime t M EXAMPLE Below is a wiring example to the TimeSyncService uses interface ScoaControl as TPS SITE intcertace Times implementation components YourAppM TimeSyncService YourApp TimeStart gt TimeSyncService TOU Appr I e laine ovil a cia E Page 102 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual Time is represented by the tos_time_t structure The tos_time_t 1s a 64 bit integer which represents the current time as a num
101. ld use the same id Doc 7430 0108 02 Rev A Page 15 XMesh User s Manual MEMSIC Below are code excerpts from the XMeshCountToLeds application for sending multihop Messages TOSMsg g_ msg task void sendMsg Unit o ee lteter hengen 0 CountMsg_t countMsg CountMsg_t MhopSend getBuffer amp g_msg amp bufferLength countMsg gt nodelId TOS LOCAL ADDRESS countMsg gt nodeCount g_count call MhopSend send BASE So TATIONVADDERE Ss MODE SUES WE AMeSomnse ars 4c One CO mmmMis g ENI 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 is the local node id and the current count value Though the message object is 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 is for use by the application the code uses the MnopSend getBuffer method The method 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 It also provides the send mode In this application we are using the UPSTREAM mode with no reliab
102. 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 XMeshCountToLedsM LedsC TimerC XMeshRouter SE IDE broly Mesh Coume lomedsM StTOControl Main SE OIC RUE TEL gt Timer StadControls Main SE IC nE Ie JL gt XMesnRouter SE Cdeommno le Main SE HE IEL gt XMesnCountToLecdseM SE I IHE EG JL gt XMeshCountTohLedsM Leds gt LedsC Leds XMeshCountToLedsM Timer gt TimerC Timer unique Timer XMeshCountToLedsM MhopSend gt XMeshRouter MhopSend 10 The XMesh service is implemented by the XMeshRouter component The routing component provides a sending interface in MhopSend which sends packets into the network A receiving interface is also implemented but will 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 in 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 shou
103. ler 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 automatically enable HPLPowerManagment 3 4 2 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 Page 32 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 is 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 A WARNING The JTAG fuse for the ATmegal 28 must be disabled to achieve low power operation If this fuse is on the minimum current is around 3mA The JTAG fuse is normally programmed to be disabled Refer to Appendix B Do not measure the current with the Mote on the MIB programming board as this will increase the current Typically the cu
104. lient software as well MOTE TIER SERVER TIER CLIENT TIER XMesh XSensor Apps Database Logger Visualization Analysis Tools 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 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 Page 8 Doc 7430 0108 02 Rev A MEMSIC gt
105. load The other slots in the memory are allocated for user code or data Before reprogramming users must ensure that the OTAP image resides in slot zero of the serial flash memory 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 LJ TAH image Slot U 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 Doc 7430 0108 02 Rev A Page 85 XMesh User s Manual MEMSIC The OTAP f
106. lock is off when the MICA is sleeping Page 24 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual In ATmega128L this clock is used for TinyOS timing External Clock TIMERO in ATmega128L and TIMER2 in ATmega12871 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 Output Mode Clear a pin to low Input Mode Read a pin s state high or low The ATmega has ports named A G each with pins named 0 7 ZnO Oz 0 O emt E E L or P wm wo be nt E SIRE oOo O O C O o C or W GO D O D D OO D G Q O w SS CE OR U ae wad 06 w r MU Qc gt 2 C C W WC WC C WC WC LO e e t U G G G BA DG G G G G G DL H T T T V Pel T T n Tn T T f T a1 C C5 Pa LO ST C3 EO O LO LO LO LO LO LO OU uw lt T 48 O PA3 AD3 47 D PA4 AD4 TXDO PDO PE1 46 O PAS ADS XCKO AINO PE2 O 4 45 O PAG AD6 OC3A AIN1 PES 44 O PAT AD7 OC3B INT4 PE4 OC3C INT5 PES O 7 43 O PG2 ALE 42 D PC7 A15 T3 INT6 PE6 O 8 i T PC6 A14 ICP3 INT7 PE7 O0 9 ATmega1 28 L 40 D PCR A13 SS PBO C PC4 A12 SCK PB1 17 MOSI PB2 O 12 MISO PB3 C OCO PB4 O 14 38 D PC3 A11 37 D PC2 A10 PC1 A9 35 D PCO A8 34
107. lth 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 sent 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 Statistics Pkt Neigh 1 5 Neigh 6 10 Statistics Pkt lt Health Int lt 4 Health Int Health Int gt The format for the neighborhood health packets is provided in Table 10 3 Table 10 3 Neighbor Health Packet Structure uint8_t type node This field is in the Health header The bottom 4 bits will contain the 9 number of neighbors sent in the packet hn_quality Records containing information about the link quality of the neighbor nodeinfo Each record consist of the following elements uint16_t Neighbor s ID Doc 7430 0108 02 Rev A Page 83 XMesh User s Manual MEMSIC gt Data Fields Description Link quality normalized to 255 100 100 indicates uint t that both the neighbor and mote hear 100 of each other s messages Hop count of the neighbor 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 on
108. main exe Page 42 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 tinyos cvs tinyos 1 x apps cnttoledsandrfm 13266 bytes in ROM 444 bytes in RAN avr ohbjcopy output target srec build mica2 main exe build micaZ2 main srec 4 jtagmica AUARICE version 2 8 20838825cus Aug 25 2083 20 53 25 JTAG config starting Hardware Version xc Software Version amp x 78 Reported JIAG device ID x9 782 Configured for device ID Ox9782 atmegal28 LockBits gt Bxff Reading Fuse Bytes Extended Fuse byte gt Axff High Fuse byte gt Axi Low Fuse byte gt Axff JTAG config complete Downloading FLASH image to target Connection opened by host 127 6 8 1 port 4633 The main screen of the GUI should appear as below Sometimes this screen is sized incorrectly This can be overcome by resizing the window step c run step assembly Source Window File Run Wew Control Preferences Melp SMO FC DS RASS MYO Fin l v E vectors x Janc ne p HR ADCControl nc 4 jmp Ox3a4 ADCREFHM nc 8 gt jmp 0x3a4 l ftans ane 12 gt in Oxday code modules for the application BareSendMsg nc 16 gt jmp Ox3a4 ByteComm nc 28 gt jmp 0x3a4 C1666Control nc 24 gt jmp Ox3a4 gt C1666ControllH nc 28 gt jmp 6x3a4 C01 666RadioIntH nc 32 gt jmp 0x
109. me 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 voltage and the current parent s RSSI 1s 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 Mote Works apps examples X MeshCountsToLeds Ais Aligh eave 4 VN eyo stare wrn Ie add ADM ues JE DL packet gt XMesSnRoOuTer in AppeM nc che User can enable the health packot ropor ting in the AppM nc uses section add command void health packet bool enable uintel6 t ancy a T a a T e mcdd Call health packe TRUE COU 7 10 minute interval This will disable the health packet reporting Call health_packet FALSE 0 Doc 7430 0108
110. n 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 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 1s 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 if the message should be resent This QOS consumes more power than just link level acknowledges and also consumes more of the RF bandwidth
111. nded Description Default Value Fuse Byte rs BODLEVWL2 1 2 Brown out Detector trigger level BODLEVWLI I 1 Brown out Detector trigger levei BODLEVWLO 1 0 o Brown out Detector trigger level 1 unprogrammed 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 XMesh ELP no OTAP XMesh LP and Oxd8 Oxc4 Oxff XMesh ELP OTAP XMesh HP Oxd8 Oxff Oxff OTAP Doc 7430 0108 02 Rev A Clock Source Internal Oscillator Brown out detect disabled JTAG disabled BootLoader disabled Clock Source Internal Oscillator Brown out detect disabled JTAG disabled BootLoader enabled Clock Source Internal oscillator Brown out detect disabled JTAG disabled BootLoader enabled Page 119 XMesh User s Manual MEMSIC XMesh Description configuration Base Station Oxd9 Oxbf Oxff Clock
112. ned the mesh and parent parameter contains the ID of the parent If success is 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 ElpI sleep can be invoked While the node is in ELP sleep mode health packets are periodically interval 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 iRet ries it will return a sleepdone with failed and not try again until ElplI sleep is 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 Page 70 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 p
113. 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 calculation is made for future scheduled wake up checks This method allows the clock value to be moved forward and backward in time without 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 1 5 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 is scheduled to be transmitted precisely when the other nodes will perform their channel sampling
114. niffer TimeSync Screen Display Page 110 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual 12 MoteConfig MoteConfig is 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 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 iolxi File Settings Help Platform Type Radio Band MH 2 Addresses MOTE ID if T Hex T Auto Ine Route Update Sec GROUP ID 100 Hex P adic Packet Size Bytes gAs 7 dem Payload Size RF Channel 9 MH2 Read Fuses Clear T ext View Details Program T OTAP Enable Shop m ao Bytes Crossbow Inc 2006 Device mib510 Port com 2 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 02 Rev A Page 111 XMesh User s Manual MEMSIC Int
115. ntation define DBG_PKT 1 define SO_DEBUG 1 include SOdebug h An example of SODbug is in Mote Works apps examples SODbug Doc 7430 0108 02 Rev A Page 47 XMesh User s Manual lt Terminal v1 9b 120870072 by Bray COM Port _ fonnect f COM C COM2 Disconnect E About C COM4 f COMS Quit COME Settings Baud rate C EUU t S600 t 1200 14400 C 2400 19200 t 4800 CO 38400 Data bits f 56000 57600 t 115200 t 256000 Auto Dis Connect Set font Time CHe LF Receive Reset Counter 13 G OSCOPERF Debug Groupi 103 Node 4 0 OS COPERF Debug Groupe 103 Mode 4 dataTask readingMumber 10 dataTask readingMumber 20 dataTask readingMumber 30 dataTask readingMumber 40 dataTask readingNumber 50 dataTask readingNumber 60 Counter 27 Stop Bits fe L 15 L f HEK Sting StartLog MEMSIC Handshaking f none L TSW f ON OFF C ATSZCTS DN DEE C ATS on Ta Dec Hex Bin 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 48 Doc 7430 0108 02 Rev A MEMSIC 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 MEMSIC sens
116. nts throttle 35 msec Page 1 mote 1 6 fragments throttle 40 msec Page 1 mote 1 D fragments throttle 40 msec Page 1 mote 2 0 fragments throttle 40 mec Page 1 finished Fage 2 mote 1 128 fragments throttle 40 msec Page 2 mote 1 29 fragments throttle 45 msec Fage 2 mote 1 4 fragments throttle 50 mec Page 2 mote 1 1 fragments throttle 50 msec Page 2 mote 1 0 fragments throttle 50 msec Fage 2 mote 2 0 fragments throttle 50 mec Page 2 finished Page 3 mote 1 128 fragments throttle 50 msec Page 3 mote 1 2 fragments throttle 50 msec Page 3 mote 1 0 fragments throttle 50 mec Page 3 mote 2 D 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 02 Rev A Page 95 XMesh User s Manual MEMSIC MoteConfig 7 ioj x File Settings Help Local Program Remote Program Operations Option Select File to be Programmed Ie Check Base HeartBeat C Program Files Crossbow Mote view 4 20 xmesh micazsXMD Select T Che
117. o 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 13 Appendix 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 TOSH DATA LENGTH changed make sure that XMeshBase uses equal or greater value BASE STATION ADDRESS fo goe of base station Should never be Time between route update intervals These 60 sec for HP values should not be changed If changed 600 sec for LP make sure that XMeshBase and the application use the same values HEALTH UPDATE INTERVAL 80 Time between health messages seconds Base 30 Defines maximum number of neighbors that ROUTE TABLE SIZE Oth T 15 mote can track If a mote is not in this table it a will not be selected as a parent DESCENDANT TABLE SIZE Base 100 Defines the maximum number of children for the Others 50 mote Used for downstream communication Define the maximum number of multihop Base 16 Others 8 messages the mote can queue up Once a exceeded messages will be dropped USE WATCHDOG Enables reboot if no route update messages are heard within a defined interval FEATURE_HEARTBEAT HEARTBEAT 0 Enable disable base station heartbeat Enable disable base station heartbeat station heartbeat ROUTE_UPDATE_INTERVAL MHOP_QU
118. ommunicate before the synchronization process is complete However once synchronized all transmissions are based on the globally time synchronous framework which provides 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 19 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 Setits 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 is adopted only if the source s sequence number is less than the receiving node s ID 9 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 symbol transmission begins The Time Synchronization Layer reads the current clock value
119. on embedded devices called Motes Motes consist of a 1 Microprocessor Atmel ATmegal28 for MICA2 MICA2DOT and MICAz ATmegal128 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 VIC AZ IRIS radio at 2 4 GHz 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 Doc 7430 0108 02 Rev A Page 5 XMesh User s Manual MEMSIC gt 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 MEMSIC 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 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
120. opping 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 is 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 Doc 7430 0108 02 Rev A Page 3 XMesh User s Manual MEMSIC R i a s k ra 1 ta 6 9 Gateway d Router Figure 1 2 Diagram showing a Mesh Topology The propagation of sensor data through the mesh allows a sensor network to be extended in theory to an unlimited range A mesh network 1s 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 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 1 2 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
121. or networks can run several power strategies Each strategy is a trade off between power and data rates For systems that have continuous power XMesh HP is 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 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 is 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 avery short interval to see if the radio is detecting any signal over the noise background If so the radio is 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 ac
122. p messages only Bane This field contains hop_count for route update message Rte it contains p application id for any other message Appld Application ID Data content of message XSniffer i SeqNo Log AN neuie l Health Neighbor Time Syne Options oraza is lal naomha ho o s i eb beeb tT TT 5O5 D Je 1 6 Base wil DatUp Ne ED LISD OF Vid E H lt S i eS LER ERE EE EE K bese OoN F L Beast F Fte fo Z Elapsed Time 00 29 02 Legging Ma Fiter None Figure 11 2 XSniffer Log Screen Display Page 106 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 11 2 3 All Display a summary of all received messages Table 11 7 XSniffer All Tab Parameters w ofthe sendingmote OOOO O O e moen O Time since last message heard sec XSniffer JOE peeeceoyencenssensonns Log Route Health Time Sync UT Se ee eT oS Tens PktR RF 000 125 322 nooo jo2 a 005 T25 z l R E 4 E TS a s94 hooo o2 14 015 125 E 40 19 40 46 19 lo 1041 100 0 o2 lal 025 125 f2 50 Mz 3 62 3 lo fos 500 o2 al E 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 XSni
123. quire 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 that 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 is 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 1t does not get a link level acknowledgement when it transmits to a parent it will find another Doc 7430 0108 02 Rev A Page 49 XMesh User s Manual MEMSIC parent This can happen very quickly or may take some time if the RF environment or mesh configuration has changed considerably The Table 4 1 shows the types of power modes supported by MEMSIC Motes Table 4 1 XMesh Power Configuration Matrix mien Eager WIG XMesh LP asynchronous and time synchronized TT E only Table 4 2 XMesh Performance Summary Table 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 Ra
124. r 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 lt device location gt is determined by your operating system and whether you have a USB or serial connection The ATmega128 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 A WARNING The correct ATmega128 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 X MeshBase as make lt mote platform gt 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 XSniffer make 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 ba
125. rface 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 displayed in the tree view control as shown in Figure 10 6 Doc 7430 0108 02 Rev A Page 91 MEMSIC XMesh User s Manual ix File Settings Help Local Progam Remote Program Operation Option I Check Base Heartbeat Select File to be Progranimed Select T Check Operation Timeout Select Slot LI Ready LJ Preparing Programming L Rebooting Search Prepare Query Program Reboot Stop Searching network Select Nodes e g 1 4 7 11 12 1 7 serve Connected to Serve Crossbow Inc 2006 Device mib510 Pork com Search 00 00 12 E Figure 10 6 Searching for nodes within the mesh network 9 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 Nodes textbox During this process the Prepare button will be disabled and the selected node will turn blue
126. rrent 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 Table 3 9 Standard Battery Configurations and Operating voltages Mote Hardware Standard Battery Typical Battery Practical Operating Voltage Platform required Capacity mA hr Range V MICAz AA 2 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 Goon MICAz MICA2 IRIS p mA mA mA Microprocessor full operation e E po Microprocessor sleep 0 020 0 020 0 010 Radio receive Radio sleep 0 001 0 001 0 001 Serial flash memory write Serial flash memory read Serial flash memory sleep Doc 7430 0108 02 Rev A Page 33 XMesh User s Manual MEMSIC gt 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
127. rview 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 All 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 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 effic
128. s 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 set to external oscillator enable JTAG disable JTAG clkext jtagen jtagdis Command wr_fuse_1 OxfFf elkint wr_fuse_1 Oxc4 jtagdis wr_fuse_h Oxd9 jtagen wr_fuse_h 0x13 read rd_fuses Doc 7430 0108 02 Rev A Page 121 XMesh User s Manual MEMSIC 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 SMAKERULES 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 1s executed when Cygwin starts up and is useful for executing scripts that set paths and other variables This file is usually contained in Mote Works Suite cygwin etc e To seta 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
129. s 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 In TinyOS the application user 19 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 is 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
130. s as a service application identifier This allowed users to route messages to different services in their application XMesh now reserves this parameter and it is not available to the user XMesh supplies the same service through an Application ID Application ID is used in the user application as the parameter of MnopSend 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 Doc 7430 0108 02 Rev A Page 57 XMesh User s Manual MEMSIC gt User applications only deal with Application IDs through the MhopSend receive interface to send and receive message XMesh decides which AM type 1s appropriate for the message AM type 1s 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 A 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 MEMSIC for future use The user s Application IDs should always be from 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 L call MhopSend getBuffer amp gMsgBuffer amp Len pData now poin
131. s since it does not reset them on power up PressureSensorM nc Source Window File Run View Control Preferences Help M 70 456308 Fina PressureSensorM nc lt PressureSensorM SendSamples break gt 126 if bSending 127 pressureDataPtr gt Board_id BOARD_ID 128 pressureDataPtr gt Pkt_id PKT_ID 129 pressureDataPtr gt Parent_id call RouteCor 130 pressureDataPtr gt Sample_period DEFAULT_SAMF 131 pressureDataPtr gt NmbSamples gSampleCount 132 call RadioControl start 133 134 call COMM send BASE_STATION_ADDRESS F 135 call Leds greenOn 136 call COMM send BASE_STATION_ADDRESS F 137 bSending TRUE Figure 3 11 Debugging using ce insight GUI 3 8 4 Examining the CPU registers After the CPU is halted usually through a breakpoint the CPU registers can be viewed by selecting View gt Reegisters 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 Page 44 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual 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 ch
132. sage is power lt power gt 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 lp 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 defines to configure XMesh The component listed here should be the top level application component in the application M EXAMPLE COMPONENT ELPTest SENSORBOARD micasb JIC ALMOND eh Sis 1 ofoofo of os TOS Lib XMesh2 TestSuite DEPTE se E PrO OUTES UP DAI INDUS AE 1 SiO 7 DRE NES EO AEDA AENEA sO DEFINES DDATA_REPORT_RATE 10 Doc 7430 0108 02 Rev A Page 13 XMesh User s Manual MEMSIC gt 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 XMeshCountToL
133. se Parent of the node O 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 overheard by XSniffer since the start of the test Time since last message was heard seconds Pwr XSniffer JOEY Log All Route Health Neighbor Time Sync Options ld MSeq Pwr Vers HSeq App Fwd Drop Rexmit Volts RF Revd Parent La m p CostEst Msg Time F w ioo pe 751 Lo f 9 B op o m 270 al 0 15 100 100 0 p4 m3 lo fy m o 7 o h 290 jail 0 0 100 100 0 j2 jos La 1 13 107 10 0 0 2 90 all o 0 100 100 0 112 J12 7 Ic 99 g j C Figure 11 4 XSniffer Health Screen Display Page 108 Doc 7430 0108 02 Rev A MEMSIC 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 ld Address of mote originating the health packet 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 Link quality of neighbor send estimate and receive estimate A value of 100 means 100 of messages have been heard received
134. se 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 Page 18 Doc 7430 0108 02 Rev A MEMSI C XMesh User s Manual 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 E xSniffer 1 0 2111 23276 Log ee Route Doug Health mates re ao oe fas i 1100500 cas 145 1 HRS Beast Pal e M 2 ati bee ain 145 11 h h e ho h fo 09 mo hs H a a ae 145 111 RH S 397 Bcast 145 ah 1 11 16 369 369 acas 145 pen Beast at r fes i e 31 1118351 lal m psm h h Bs ho fj o Beo T T a SS Beast ag las Inr lr be ho d o s o EA p as HR zH a r H RR an ann 1 11 21 256 Beast_ al 11 145 17 h n fe ho f o Bso TJ TIJ b w z LH E T l al ee W HO I 9 9 0 E 1129209 Beast 41 145 0 H aa 00 fo Cd S S
135. sgPtr pMsg result_t success call ElpI sleep elp_sleep_sec elp_health_sec elp_retry monitor_flag Hael E K SUCCESS 8 5 Testing XMesh ELP A test application for ELP mode is supplied in Mote Works apps examples TestElp2 This application will e Start up in full power e Send route updates and monitor route updates until it joins the mesh e Send a health packet to the base station requesting a downstream acknowledge e Goto sleep for 20 seconds e Repeat the previous two steps continually Building the Application 1 To build the application for a MICAz type make micaz route elp 2 Program this into a mote 3 Build the XMeshBase Chapter 9 application route hp base and program into the base station mote 4 Build and load XSniffer with the same radio frequency 5 Run the base station on batteries or a MIB programming board 6 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 1 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 is around 26 mA 2 At 0 07 21 seconds the base station broadcasts a route update Rte notifying the ELP mote that
136. ss all applications built for a particular installation The file is located in Mote Works 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 same radio band and channel yet filter communication by group id Doc 7430 0108 02 Rev A Page 11 XMesh User s Manual MEMSIC 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 Table 2 2 IEEE 802 15 4 Channels All frequencies are in GHz Channel Upper Frequency 2 406 2 1 2 Makefile The Makefile contains build sp
137. 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 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 uintl6_t payloadLen event result_t snoop TOS_MsgPtr msg void payload uintl6_t payloadLen Description intercept Signals that a message has been received for the mote and the wired application ID ADP ID snoop Signals any message overheard for the wired application ID AP_ID Page 56 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual These two interfaces share the same signature of command event the only
138. sually the red wire of the flex cable connecting the JTAG header to the JTAG pod is pin 1 Make sure the polarity is correct Page 40 Doc 7430 0108 02 Rev A MEMSI C XMesh User s Manual A 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 pale Sika Er gee Mote TX switch SW2 Te q Uonnert r This should normally be sa in the OFF position A ei i Sn ice ISP LED red Power OK LED green MICAx seres connector MICA2DOT connector on bottom side Mote JTAG connector Figure 3 7 MIB510 Serial Programming Board 3 Mount a MICA2 or MICAz for debugging on the MIB programming board V H ra l L GY eee TTT TTL erent sqsiepers7yiiiiiti E Pi Figure 3 8 MIB510 Attached to Atmel JTAG for Debugging A 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 Doc 7430 0108 02 Rev A Page 41 MEMSIC XMesh User s Manual 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 V
139. t 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 entity 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 02 Rev A Page 87 MEMSIC XMesh User s Manual Send LOAD_IMAGE to all motes p gt All pages Yes downloaded No Get next page Send LOAD_PAGE to all motes Clean up generate report exit All motes downloaded Throttle Control Remove mote from download list Send all outstanding fragments in page Error No 10 2 5 OTAP Download Packet Format The OTAP download packet contains the fields described in Table 10 3 Table 10 3 OTAP Packet Fields Field Length Number of Bytes Description Image Id This is the slot in the serial flash between 0 3 This is the fragment id of the fragment being transmitted This is the binary data for the fragment 9 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
140. te 10 sec typ 180 sec typ NA Mesh Mesh formation time time 2 3 times Route Update Interval for mesh with average of 2 5 hops current usage 20 30 mA lt 250 pA M 50 pA lt 400 pA 4 HI MICA2 LP using time synchronized mesh 2 MICAz LP using asynchronous mesh 4 2 Forming 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 1ts 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 Ifa 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 is 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 2 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 Page 50 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual e has already joined XMesh e is not a descendant node for the last 3 RUIs Route Up
141. the batteries are depleted MICA2 and MICAz units will operate down to this voltage range e 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 e Lithium Thionyl These batteries are good for applications that require wide temperature operations 40 to 80 C and have large capacities but are expensive Page 34 Doc 7430 0108 02 Rev A MEMSIC gt XMesh User s Manual e NiCad These are rechargeable however have a lower cell voltage 1 2V typically so stacking 2 batteries 1s about 2 4V When stacking 3 cells the initial voltage can be 4 2V which 1s 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 e 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 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
142. ts to the application payload portion of the TOS message and Len has the length of the available payload buffer The maximum data length is determined by the TOSH_DATA_LENGTH define 2 Send the message The value of dest and mode depends on the transportation mode Call MhopSend send dest mode amp gMsgBuffer length MODE UPSTREAM A MODE UPSTREAM MODE DOWNSTREAM A MODE _DOWNSTREM CK CK Base BASE STATION ADDRESS 9 NOTE When calling the MnopSend 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 MhopSend send BASE STATION_ADDRESS MODE_UPSTREAM amp gMsgBuffer SERAS Or Om ie jc Page 58 Doc 7430 0108 02 Rev A MEMSIC XMesh User s Manual and implement the sendDone event event result_t Send sendDone TOS_MsgPtr pMsg result_t success return SUCCE Soy 5 3 3 Sending Upstream Messages with End End Acknowledgements In order to receive the acknowledgement packet
143. 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 the color of the selected nodes turns to Orange as shown in Figure 10 10 A WARNING You cannot write over the Slot 0 because it is reserved for the OTAP Image ioj File Settings Help Local Program Remote Program Option Ie Check Base HeartBeat Operation Select File to be Frogrammed C Program Files Crosebows Moteview 4 20 emesh micae MD select Select Nodes fe g 1 4 7 11 12 1 71 Select Slot O Ready O Preparing L Programming O Rebooting Check Operation Timeout Finished 2 motes Successful U motes failed Node 2 is ready to Quern Program or Reboot Node 1 is 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 Quern Program or Reboot Node 1 is ready to Quer Program or Reboot Node 2 is ready to Quer Program or Reboot Node 1 is ready to Quern Program or Reboot Begin scan C Program Files CrossbowsMoteView 4 20 smesh micae M041 0006 202 Ap exe Mesh protocol found Converting C Program Files Crossbow MoteView 4 20 emnesh micas MDATOOUCB S03 _hp ese to C Program Files Crossbow Moteview 4 20 smesh micae hMDA1O0CB_ 903 _hpexe hex Process completed Crossbow Ine 2006 Device mib510
144. udes 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 Composed of standard TOS header and XMesh multihop header CRC check Refer to Appendix E Table 5 2 XMesh Packet Structure Type Name Description compone uint16 L Destination address next hop AM type defines type of message TinyOS Header MICA2 ici group group additional bytes length Remaining bytes in message N I CRC uint16 L Address of mote that sent the message uint16 L originaddr Address of mote that originated the message XMesh multihop header uint16 T Message sequence number uint8_t data Payload Payload size is set with the TOSH_DATA LENGTH define Default size is 29 bytes 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 Doc 7430 0108 02 Rev A Page 53 XMesh User s Manual MEMSIC 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 the base statio
145. uild micaz main srec avr objcopy output target i1hex build micaz main exe build micaz main i1hex writing TOS image To program the compiled code into the mote MICA2 or MICAz make lt mote platform gt reinstall O mib510 mib510 mib600 lt device location gt Doc 7430 0108 02 Rev A Page 79 XMesh User s Manual MEMSIC gt IMPORTANT The base station is always programmed with node ID equal to zero 9 4 Using the Heartbeat XMeshBase provides the link from the mesh network to the outside world It 1s important that this link does not fail To monitor the health of XMeshBase a heartbeat mechanism is incorporated to validate that the link between the base and the PC is 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 X
146. unctionality is implemented within TinyOS by a component known as XxMgmt 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 the server 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 gt 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 1f 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 resultlt XOuaploader boot request Uinti t imgld Cally xXOoOtap loader booi imgld Ie SNe E K SUC Classe 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 is 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 Page 86 Doc 7430
147. ure 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 LI cx File Settings Help Local Program Remote Program Option IY Check Base Heartbeat Operatiors Select File to be Frogrammed Select Select Nodes e 9 1 47 11 12 1 71 Select Slot C Ready Cl Preparing haoo 9 C programming L Rebooting Search Prepare Query Program Reboot Stop cmd query Check Operation Timeout sf localhost 9001 group id 129 debug 1 html report file otap html motes 1 2 Mote 1 micaz time since reboot 1 1 min voltage 3 0 boot image 0 Image flash start stap size checksum Type U O15 29773 ced bootable 1 64r 80 31109 Tarz bootable 4 erat 2 erty Mote 2 mcaz time since reboot 1 7 min voltage 3 1 boot image 0 Image flash start stop SIZ checksum Type U O15 29773 45bb bootable 1 64r 80 31109 afal bootable J St appky S S Crossbow Ine 2006 ff eie mib Port Garm fg Figure 10 8 Querying the Nodes in the Network for OTAP Image Doc 7430 0108 02 Rev A Page 93 XMesh User s Manual MEMSIC 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
148. urrentCount TOSH_CLR_SENSOR_ON_PIN sensor off call CounterControl stop call Leds redOff call Enable count done enable sleep Ox442a lt PressureSensorM WaitTimer fired 26 gt ade r25 r25 Ox442c lt PressureSensorM WaitTimer fired 28 gt mouw r30 r24 0x442e lt PressureSensorM WaitTimer fired 30 gt add r30 r18 0x4430 lt PressureSensorM WaitTimer fired 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 Ox07 0x443a lt PressureSensorM WaitTimer fired 42 gt subi r24 OxFF 255 Ox443c lt PressureSensorM WaitTimer fired 44 gt sts 0x0110 r24 M 31 Dli Pw a R M Canaaw L KT 2 nae Ole w ddl x aki AWIE ua 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 Mote Works tos interface 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 impleme
149. x800000 4 Target is LITTLE endiar 0 1 2 3 4 gt 6 T G G H B C D E E 0x00800000 OxfF 0x00 0x08 0x00 0x05 0x20 8x00 Ox3a 0x02 0x01 0x02 0x00 0x00 Ox3a 0x49 OxOc 9x00800010 0x00 0x09 0x00 0x00 0x00 0x00 OxOb Oxes 0x00 0x00 0x0 0x00 xdd Ox1b 0xb1 0x01 0x00800020 0x00 0x43 0x00 0x00 0x00 0x00 OxOe 0x00 0x10 OxOF Oxd8 0x22 0x00 0x50 0x00 0x00 9x00800030 0x44 0x28 0x00 0x00 OxFF 0x00 OxOd 0x07 0x01 Ox6F Ox6F Ox6F 0x00 0x00 0x00 Oxad 0x00800040 0x00 0x00 0x00 0x00 0x00 0x00 x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00800050 0x08 0xe6 0x00 OxOb 0x13 0x20 0x00 0x02 0x00 0x40 0x00 0x00 oxoe OxF3 0x10 0x82 AY AAR AAA D Avi E AAA AAN Aye Pie Fie Pie AN Pie Ar Ay Ae Awd Awd AAN Ayan Ae Pie Aw AN Pie Air Awa 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 example to watch gSampleCount in
150. y 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 19 a value between 0 and that defines weight of the new estimated value SE Send Estimate the radio transmit quality of the link to a specific neighbor it is 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 9 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 Doc 7430 0108 02 Rev A Page 51 XMesh User s Manual MEMSIC gt 9 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 is perfect 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 is calculated as OC LC NC The mote will pick the neighbor with the lowest OC as its parent 9 NOTE The higher the cost value the more energy is requir
151. z Read Fuses Clear Text View Details Program OTAP Enable Stop Setting fuse using mib520 uisp dprog mib510 dserial dev ttyS5 dpar ATmegal 26 wr_fuse_h 0xd5 wr_fuse_l 0xtf wr_fuse_e Oxf Erasing binary using mib520 uisp dprog mib510 dserial dev ttyS5 dpar ATmegal 26 erase installing binary using mib520 uisp dprog mib510 dserial dev ttyS5 dpar ATmegal 26 upload if C Program Files Crossbow MoteView xmesh micaz MT 3310 VAMTS310CA_2420_hp exe outsrec Uploading SUCCESSFUL Crossbow Inc 2006 Platform Micaz Device mib520 Port com lt lt 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 Table 12 7 MoteConfig Parameters No No RF Power The power output of the radio Displayed a register value Yes and dBm Radio Band The radio frequency band No Channel No The radio channel within the radio band Yes UARTO baud The baud rate for UARTO on the mote Yes Doc 7430 0108 02 Rev A Page 113 XMesh User s Manual MEMSIC The mote address to program into the unit This address Mote Id a Yes can be auto incremented after each unit is programmed Group Id The group id of the network Health Update The update rate sec of health packets Route Update The route update rate note all motes must have the same Yes route update rate MoteConfig als

Download Pdf Manuals

Related Search

Related Contents

SD800 - Extech Instruments  Notice d`utilisatioN - Lidl Service Website  Dynamic Analysis and Profiling of Multi  温室効果ガス排出削減ー吸収量認証依頼書  Unilift CC 5, CC 7, CC 9    FICHE PRODUIT  SFP Transceivers User Manual  Panasonic NN-SE782S microwave  Breville BEC300 - Direct Coffee Supplies  

Copyright © All rights reserved. Failed to retrieve file