How it Works
Noty
Loading...
SmartMesh IP Application Notes
Start Guide
159 pgs6.5 Mb0
Start Guide
21 pgs1.05 Mb0
Table of contents
Loading...

Noty SmartMesh IP Application Notes Start Guide

SmartMesh IP Application Notes
SmartMesh IP Application Notes Page of 1 159
Table of Contents
1 Revision History _________________________________________________________________________________ 8 2 Application Note Summary _________________________________________________________________________ 9 3 Application Note: How to Evaluate Network and Device Performance ________________________________________ 11
3.1 Introduction _______________________________________________________________________________ 11
3.2 Join Behavior ______________________________________________________________________________ 11
3.2.1 Tradeoff Between Search Time and Average Current __________________________________________ 12
3.2.2 Measuring Join Time __________________________________________________________________ 14
3.2.3 Effect of Downstream Bandwidth on Join __________________________________________________ 14
3.2.4 Network Formation vs Single Mote Join ___________________________________________________ 17
3.2.5 Measuring Time to Recover from a Lost Mote _______________________________________________ 17
3.3 Latency ___________________________________________________________________________________ 19
3.3.1 Measuring Latency ____________________________________________________________________ 19
3.3.2 Comparison with a Star Topology ________________________________________________________ 20
3.3.3 Tradeoff Between Power and Latency _____________________________________________________ 22
3.3.4 Roundtrip Latency ____________________________________________________________________ 22
3.4 Channel Hopping and Range __________________________________________________________________ 24
3.4.1 Using radiotest for Single Channel Measurements ___________________________________________ 24
3.4.2 Range Testing _______________________________________________________________________ 25
3.4.3 Blacklisting __________________________________________________________________________ 26
3.5 Power ____________________________________________________________________________________ 29
3.6 Mesh Behavior _____________________________________________________________________________ 30
3.6.1 Testing the Mesh _____________________________________________________________________ 30
3.6.2 Changing Mesh Policies ________________________________________________________________ 30
3.7 Data Rates ________________________________________________________________________________ 31
4 Application Note: How to use Filters in the Subscribe API _________________________________________________ 32
4.1 The Subscribe Filter _________________________________________________________________________ 32
4.2 Acknowledged or Unacknowledged? ____________________________________________________________ 32
5 Application Note: Monitoring SmartMesh IP Network Health ______________________________________________ 33
5.1 Health Reports _____________________________________________________________________________ 33
5.1.1 Neighbors HR _______________________________________________________________________ 33
5.1.2 Device HR __________________________________________________________________________ 34
5.2 Periodic API Calls ___________________________________________________________________________ 34
5.2.1 getMoteConfig _______________________________________________________________________ 34
5.2.2 getMoteInfo _________________________________________________________________________ 34
5.2.3 getNextPathInfo ______________________________________________________________________ 35
5.3 Tests _____________________________________________________________________________________ 35
5.3.1 For the AP Only ______________________________________________________________________ 35
5.3.2 Iterate Over All Motes _________________________________________________________________ 36
5.3.3 Iterate Over All Paths __________________________________________________________________ 37
SmartMesh IP Application Notes Page of 2 159
5.3.4 Network Checks ______________________________________________________________________ 37
5.4 Graphing __________________________________________________________________________________ 37
6 Application Note: Data Publishing for SmartMesh IP ____________________________________________________ 38
6.1 Request and Response Packet Formatting ________________________________________________________ 38
6.1.1 Header _____________________________________________________________________________ 38
6.1.2 Flag Byte ___________________________________________________________________________ 39
6.2 Basic Steps ________________________________________________________________________________ 39
6.3 Next Steps ________________________________________________________________________________ 44
7 Application Note: Managing Advertising in an LTC5800-IPR Based Network __________________________________ 45
7.1 Advertising State Machine ____________________________________________________________________ 45
8 Application Note: Configuring Networks for Short-term Data Bursts _________________________________________ 46
8.1 Introduction _______________________________________________________________________________ 46
8.1.1 Network Requirements and Service Requests _______________________________________________ 46
8.2 Network 1: Base Configuration _________________________________________________________________ 46
8.3 Network 2: Longer Downstream Slotframe _______________________________________________________ 49
8.4 Network 3: Higher Power, Low Latency __________________________________________________________ 50
8.5 Network 4: Backbone Example _________________________________________________________________ 51
8.6 Network 5: Star Network _____________________________________________________________________ 52
8.7 Advertising Management _____________________________________________________________________ 53 9 Application Note: How to Get Redundancy in an IP Network _______________________________________________ 54 10 Application Note: Using the Powered Backbone to Improve Latency _________________________________________ 55
10.1 Introduction _______________________________________________________________________________ 55
10.1.1 General Motivation ____________________________________________________________________ 55
10.1.2 Settings to Enable RX in the Upstream Backbone ____________________________________________ 56
10.2 Application 1: Low-latency Alarms ______________________________________________________________ 56
10.3 Application 2: Call and Response _______________________________________________________________ 57
10.4 Application 3: Lower Latency in All Low-Traffic Networks ____________________________________________ 58
10.5 Unsuitable Use of Backbone 1: Replacing Dedicated Links ___________________________________________ 59
10.6 Unsuitable Use of Backbone 2: High-Traffic Networks _______________________________________________ 59 11 Application Note: Building a Mesh-of-Meshes __________________________________________________________ 61
11.1 Introduction _______________________________________________________________________________ 61
11.1.1 Tunneling ___________________________________________________________________________ 63
11.1.2 Backhaul Bridge ______________________________________________________________________ 63
11.1.3 Backhaul and Host Applications __________________________________________________________ 64
11.2 Tunneling Protocol __________________________________________________________________________ 65
11.2.1 Downstream Data ____________________________________________________________________ 66
11.2.2 Upstream Data _______________________________________________________________________ 67
11.2.3 Request ____________________________________________________________________________ 68
11.2.4 Reply ______________________________________________________________________________ 69
11.3 Remote Procedure Interface ___________________________________________________________________ 70
11.3.1 getOperationalMotes Procedure __________________________________________________________ 71
11.4 Bandwidth Considerations ____________________________________________________________________ 72
11.5 Miscellaneous ______________________________________________________________________________ 72
SmartMesh IP Application Notes Page of 3 159
12 Application Note: Building Deep IP Networks __________________________________________________________ 73
12.1 Introduction _______________________________________________________________________________ 73
12.2 Deployment Guidelines _______________________________________________________________________ 73
12.3 Determining Range __________________________________________________________________________ 74
12.4 Mote and Manager Versions and Settings ________________________________________________________ 74
12.5 Calculating Links ___________________________________________________________________________ 75
12.6 Estimating Latency __________________________________________________________________________ 75
12.7 Over-the-Air Programming ____________________________________________________________________ 77 13 Application Note: Overlapping Networks ______________________________________________________________ 78
13.1 Introduction _______________________________________________________________________________ 78
13.2 Method ___________________________________________________________________________________ 78
13.3 Results ___________________________________________________________________________________ 80
13.4 Conclusions _______________________________________________________________________________ 84 14 Application Note: Planning A Deployment _____________________________________________________________ 85
14.1 Estimating Range ___________________________________________________________________________ 85
14.2 Mapping out a Deployment ___________________________________________________________________ 85
14.3 Estimating Power and Latency _________________________________________________________________ 86 15 Application Note: Predicting Network Health ___________________________________________________________ 87
15.1 Motivation ________________________________________________________________________________ 87
15.2 Overview __________________________________________________________________________________ 87
15.3 Does the Network LOOK GOOD? _______________________________________________________________ 88
15.4 Does the Network Have the Building Blocks to BE GOOD? ____________________________________________ 88 16 Application Note: Common Problems and Solutions _____________________________________________________ 89
16.1 Introduction _______________________________________________________________________________ 89
16.2 No Motes Join _____________________________________________________________________________ 90
16.3 A Collection of Motes Doesn't Join _____________________________________________________________ 90
16.4 One Mote Doesn't Join _______________________________________________________________________ 90
16.5 One Mote Gets Lost and Rejoins Over and Over ____________________________________________________ 91
16.6 Devices Within Operating Range Have Bad Path Stability _____________________________________________ 91
16.7 I Need to Install a Repeater but I'm Already at Max Motes ____________________________________________ 91
16.8 Data Latency is Higher than I Expect ____________________________________________________________ 91
16.9 The Network is Using Paths that Don't Look Optimal ________________________________________________ 91 17 Application Note: Changing Provisioning Factor to Increase Manager Throughput ______________________________ 92
17.1 Introduction _______________________________________________________________________________ 92
17.2 Changing Provisioning: IP ____________________________________________________________________ 92
17.3 Changing Provisioning: WirelessHART ___________________________________________________________ 93 18 Application Note: Debugging Congested Networks ______________________________________________________ 94
18.1 Introduction _______________________________________________________________________________ 94
18.2 Respecting Services _________________________________________________________________________ 94
18.3 Estimating Availability _______________________________________________________________________ 94
18.4 Identifying Congestion _______________________________________________________________________ 96
18.5 Bandwidth Model ___________________________________________________________________________ 96
18.6 Mitigating Congestion _______________________________________________________________________ 97
SmartMesh IP Application Notes Page of 4 159
19 Application Note: Identifying and Mitigating the Effects of Interference ______________________________________ 98
19.1 Introduction _______________________________________________________________________________ 98
19.2 Checking RSSI and Path Stability _______________________________________________________________ 99
SmartMesh IP Application Notes Page of 5 159
25 Application Note: Configuring a Network for Bounded Data Latency ________________________________________ 127
26.3.1 SmartMesh WirelessHART _____________________________________________________________ 130
26.3.2 SmartMesh IP ______________________________________________________________________ 131
26.3.3 Mixed IP - WirelessHART Environments __________________________________________________ 131
28.4.1 Keying Model _______________________________________________________________________ 137
28.4.2 Manager Security Policies for Joining ____________________________________________________ 138
28.4.3 Key Management ____________________________________________________________________ 138
28.4.4 A Note on CCM* ____________________________________________________________________ 139
29 Application Note: Using the TestRadio Commands _____________________________________________________ 140
SmartMesh IP Application Notes Page of 6 159
31.8.1 Wireless Hart Snapshot Log ___________________________________________________________ 151
31.8.2 Log File Interpretation and Analysis ______________________________________________________ 153
31.8.3 Neighbor Stability Analysis ____________________________________________________________ 154
32 Application Note: What is Packet ID and why do I Need it? _______________________________________________ 155
SmartMesh IP Application Notes Page of 7 159
1 Revision History
Revision Date Description
1 03/18/2013 Initial Release
2 07/18/2013 Added "What is Packet ID and why do I Need it?" Application Note
3 10/22/2013 Minor corrections
4 01/30/2014 Added "Overlapping Networks" Application Note
Modified "Building a Mesh-of-Meshes" Application Note to reflect sample implementation
5 04/04/2014 Clarified how Q is calculated
SmartMesh IP Application Notes Page of 8 159
2 Application Note Summary
This document contains a collection of Application Notes about the SmartMesh IP product family:
- Methods for measuring a host of performance metrics.How to Evaluate Network and Device Performance
- Strategies for monitoring manager notifications.How to use the Subscribe API Filter
- Automated checks to ensure that your network is performing well.Monitoring SmartMesh IP Network Health
- Low-level descriptions of how to use the mote's API for sending data.Data Publishing for SmartMesh IP
- A state machine to save power by turning advertising off.Managing Advertising in an LTC5800-IPR Based Network
- Strategies for low-power solutions when motes may suddenlyConfiguring Networks for Short-term Data Bursts
queue up several packets.
- Using more devices to get different levels of redundancy.How to Get Redundancy in an IP Network
- Description of several backbone use cases.Using the Powered Backbone to Improve Latency
Building a Mesh of Meshes - Very large networks constructed with a hierarchical model.
- Settings to use for networks up to 32 hops deep.Building Deep IP Networks
- Calculations of how many motes can safely coexist in the same radio space.Overlapping Networks
The following Application Notes apply to both SmartMesh IP and WirelessHART families. Differences between the products, if any, are highlighted:
- High-level considerations prior to deploying a network.Planning A Deployment
- Initial post-deployment assessment tips.Predicting Network Health
- General troubleshooting advice.Common Problems and Solutions
- Decreasing per-mote bandwidth to support moreChanging Provisioning Factor to Increase Manager Throughput
total traffic in high-stability conditions.
- Understanding impact on network operation when mote queues are full and tips onDebugging Congested Networks
remedying such situations.
- Graphically representing network statistics to noticeIdentifying and Mitigating the Effects of Interference
interference-related problems.
- How to use the network time synchronization properly for timestamping packets.Obtaining Accurate Timestamps
- Considerations for deployments exceeding the mote limits of aUsing Multiple Managers to Build Large Networks
single manager.
- Examples on using the spreadsheet for predicting powerUsing the SmartMesh Power and Performance Estimator
and latency in a variety of networks.
- Details on the behavior of a mote moving to a different location in the sameWhat to Expect with Motes That Move
network.
- Details on how to migrate motes between different networks.Moving Motes Between Networks
- Adding bandwidth to a network to decrease the packet latency.Configuring a Network for Bounded Data Latency
- Features that allow multiple networks to operate in the same radio space.Network Coexistence
- Considerations for trading off power and join speed.How to Choose a Join Duty Cycle
- A description of the security used in all SmartMesh networks.SmartMesh Security
SmartMesh IP Application Notes Page of 9 159
- A description of how to use APIs for testing radio performance or certification.Using the TestRadio Commands
- Guidelines to follow in order to keep average currentBest Practices to Limit Average Current During Peak Periods
down when booting or writing flash.
- Overview of deployment and statistics collection for network pilots.Methodology For Pilot Network Evaluation
- Details on the single bit used to provide reliable call and response with theWhat is Packet ID and why do I Need it?
Sensor Processor.
SmartMesh IP Application Notes Page of 10 159
3 Application Note: How to Evaluate Network and Device Performance
3.1 Introduction
OK, you just got a - now what? This app note describes a number of tests you can run to evaluateSmartMesh IP starter kit specific performance characteristics of a SmartMesh network. It assumes that you have installed the SmartMesh IP SDK python tools, and the necessary FTDI drivers to communicate with manager and motes. It also presumes you have access to the Manager and Mote CLI and API documentation.
First thing is to connect to the manager ( ) and log into the manager's CLI as described in the Introduction in the DC9001
SmartMesh IP Manager CLI Guide
> login user
You will also need to connect a Eterna Interface Card to one or more A-B motes in order to access the mote'sDC9006 DC9003 CLI to configure it.
3.2 Join Behavior
How fast does a mote join? Mote join speed is a function of 6 things:
Advertising rate - the rate at which motes in-network advertise. The user has little control of this other than mote density, or turning it off explicitly at the manager Join duty cycle - how much time a searching mote spends listening for a network versus sleeping Mote join state machine timeouts - there is no user control over these timeouts in SmartMesh IP Downstream bandwidth - affects how quickly motes can move from being synchronized to the network to ,Operational i.e. able to send data Number of motes - contention among many motes simultaneously trying to join for limited resources slows down joining with collisions Path stability - over which the user has little or no control; path stability is the ratio of successful (acknowledged) packets to sent packets between a pair of motes
The join process is broken up into three phases: search, synchronization, and message exchange.
Search time is determined by advertising rate, path stability, and mote join duty cycle - this can be 10's of seconds to 10's of minutes, largely depending upon join duty cycle Synchronization is determined by mote state machine timeouts - this period is only a few seconds in SmartMesh IP.
SmartMesh IP Application Notes Page of 11 159
Message exchange is determined by downstream bandwidth and number of motes (which compete for downstream bandwidth). This is a minimum of ~10 s per mote, and can be much slower.
So, for example, it may seem that to join a network quickly, you would set the join duty cycle to maximum. However, this may result in a lot of motes competing for downstream bandwidth, and a network may form more quickly with a lower setting. In the experiments below, you will examine the "knobs" you have to control search and message exchange phases.
3.2.1 Tradeoff Between Search Time and Average Current
An unsynchronized mote listens for manager and other mote advertisements to synchronize to the network. The fraction of time spent listening versus sleeping is called the . The join duty cycle is one-byte field that can be set from 0
join duty cycle
(0.2%) to 255 (almost 100%) - the default for Starter Kits is 100% or a setting of 255. Lower settings result in longer search times at lower average current, while higher settings shorten search but increase average current. Provided that at least one mote is advertising in the mote's vicinity, the dedicated to joining remains the same - join duty cycle only affectsenergy average . If a mote is isolated, or if the manager is not on, or if advertising has been turned off, a mote couldcurrent potentially exhaust its battery looking for a network. Join duty cycle gives the user control over the tradeoff between speed when a network is present and how much energy is used when it isn't.
The time for a mote to synchronize and send in its join request is the first visible sign of a mote joining a network. You can activate the manager's mote state trace using the CLI command:trace
> trace motest on
When the manager sees the mote's join request, it will mark the mote as being in the (Negot1) state.Negotiation1
To see the effect of join duty cycle:
Connect to the manager CLI and turn on the mote state trace as described above. Connect to the mote CLI by using an Eterna Interface Card ( )DC9006 Reset the mote - it will print out a reset message
> reset SmartMesh IP mote, ver 1.1.0.32 (0x0)
this will cause the mote to begin searching for the network with it's default duty cycle. You should see a series of notifications as it changes state, with a timestamp in ms followed by the state:
52727 : Joining 56227 : Connected 60121 : Active
SmartMesh IP Application Notes Page of 12 159
It should take <10 seconds on average for a mote to synchronize and sent its join request. You may want to repeat several times (resetting each time) to see the distribution of synchronization times.
Reset the mote and use the mote CLI to set the join duty cycle to 5% (0.05 * 255 = 13) - this is controlled through the mote CLI command Join duty cycle is non-volatile in a SmartMesh IP mote - it persists through resetmset joindc
or power cycle, so you only need to do this step once for each join duty cycle change. Measure how long it takes the mote to transition to the state, repeating the measurement as described above. It should be ~3 min onNegotiating1 average.
> mset joindc 13
Reset the mote and use the mote CLI to set the join duty cycle to 25% (64). Measure how long it takes the mote to transition to the state. It should be ~30 s on average.Negotiating1
> mset joindc 64
Note: When the manager sees a join request from a mote that was previously operational, it will mark it firstLost before promoting it to connected. It will appear as:
264504 : Mote #2 State: Lost -> Negot1 266178 : Mote #2 State: Negot1 -> Negot2
SmartMesh IP Application Notes Page of 13 159
3.2.2 Measuring Join Time
It takes a number of packets sent by the manager and acknowledged by the mote to transition a mote to the Operational (Oper) state where it can begin sending data. We can use the manager mote state trace CLI command (this trace should still be on from the test above) to see these state transitions and measure how long they take. The timestamps are in ms. Reset the mote and watch it transition to . Each line in the following trace represents one handshake between the moteOperational and the manager:
117757 : Created mote 2 117765 : Mote #2 State: Idle -> Negot1
119853 : Mote #2 State: Negot1 -> Negot2
122366 : Mote #2 State: Negot2 -> Conn1
125222 : Mote #2 State: Conn1 -> Conn2
127127 : Mote #2 State: Conn2 -> Conn3
129185 : Mote #2 State: Conn3 -> Oper
Here it took ~11.5 s to transition.
3.2.3 Effect of Downstream Bandwidth on Join
The rate at which the manager can send packets is a function of the downstream slotframe size - the manager assigns the same number of dowstream links, regardless of slotframe size, so a 4x longer slotframe has 1/4 the bandwidth. This is shown in Figure 1 - Slot 1 in a 100-slot slotframe repeats twice as often as the same slot in a 200-slot slotframe. By default, the manager builds the network on a "fast" 256-slot slotframe, and then transitions to a "slow" slotframe after one hour. The slow slotframe can be 256 (default), 512, or 1024 slots - this is set via the (downstream slotframe multiplier) parameter.
dnfr_mult
A longer frame means fewer downstream listens per unit time, so it will lower the average current for all motes, but also slow down the join process (and any other downstream data) for motes added later. While this has no effect on the time it takes to synchronize to the network (time to the state), it spaces out the other state transitions.Negotiating1
SmartMesh IP Application Notes Page of 14 159
Figure 1 - Slot 1 repeats more often on a 100-slot frame than in a 200-slot frame
Note these are the nominal sizes - the actual slotframe sizes are randomized a bit to improve coexistence when multiple networks are overlapping. We will refer to their nominal sizes throughout.
To see the effect of longer downstream slotframe:
Via manager CLI, confirm that the normal "fast" slotframes are being used. Look for the line that shows the downstream slotframe multiplier ( ):
dnfr_mult
> show config netid = 1229 txpower = 8 frprofile = 1 maxmotes = 17 basebw = 9000 dnfr_mult = 1 numparents = 2 cca = 0 channellist = 00:00:7f:ff autostart = 1 locmode = 0 bbmode = 0 bbsize = 1 license = 00:00:00:00:00:00:00:00:00:00:00:00:00 ip6prefix = fe:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00 ip6mask = ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00 radiotest = 0 bwmult = 300
Now you will adjust the downstream slotframe multiplier to give a 1024 slot slotframe - by setting the multiplier to 4, you get a 4*256 slot slotframe. Config parameters are non-volatile:
> set config dnfr_mult 4
SmartMesh IP Application Notes Page of 15 159
Force the longer slotframe use:
> exec setDnframe normal Start Global Unicast Command setDnFrame
This may take a couple minutes to take effect.
Confirm that the manager is using the longer downstream slotframe:
> show status
S/N: 00-17-0D-00-00-38-0C-8C MAC: 00-17-0D-00-00-38-0C-8C IP6: FE:80:00:00:00:00:00:00:00:17:0D:00:00:38:0C:8C HW ver: 1.2 NetworkID: 293 Base bandwidth (min links): 9000 (1) Frame size Up/Down 277/1052. Number of working timeslots 256. Available channels 15. Base timeslot(TS0) 20 Network mode is Steady State Downstream frame 1052 timeslots Optimization is On Advertisement is On AP output CTS is Ready Backbone is off Location is off API is Not Connected License 00:00:00:00:00:00:00:00:00:00:00:00:00 Network Regular Mode Total saved links 3
Manager CLI commands often use the term "frame" instead of the more formal "slotframe." "Frame" is never used to indicate an 802.15.4 packet.
Now power cycle the single mote again and note the time it takes for the mote to transition from to Negotiating1
. This should be ~4x the "fast" join time you saw above.Operational
Path stability also affects join time, as worse path stability means more retries. Having a mesh architecture means that the effect of any individual path is minimized.
SmartMesh IP Application Notes Page of 16 159
1.
2.
3.
3.2.4 Network Formation vs Single Mote Join
The number of motes joining simultaneously also affects network formation time, as these motes must compete for limited join links and downstream bandwidth. To see this effect (this assumes you are using the longer downstream frame from above):
Configure all of your motes for 100% join duty cycle (as described above) - we aren't concerned with average current here Reset a single mote, and let it join. Repeat this 10 times to get an average join time. Reset all motes and note the time it takes for the network to form completely, i.e. all motes transition to Operational when the join trace is on. You may want to repeat this experiment a few times to get a feel for the variability.
Having 5 motes means, on average, that someone will hear the advertisement faster than one mote would in a single mote network so you may see the first mote join quicker in the 5-mote case. However, if too many motes synch up at once they will contend for the same shared Access Point (AP) links which can slow down the overall network join time.
Return the manager to the "fast" downstream frame before proceeding:
> set config dnfr_mult 1
Reset the manager and log back in.
3.2.5 Measuring Time to Recover from a Lost Mote
One of the reasons a mesh is important is the robustness to path failures. In star and tree structures, a single RF path can represent a single point of failure for one or many devices data. In evaluating the mesh, many observers will want to see the mesh recover from a path failure. The most reliable way to make a path fail is to power off a device. Many observers also care a great deal about recovery time after the loss of a device, so this test can address both.
First we must decide what we mean by 'recovery'. If a user walks up to a 10-device mesh, and powers down one device, we consider the network recovered if the only change in data delivery is that the one node powered down stops sending data. If all other nodes continue to send data at their configured rates without interruption, then we consider the recovery time to be zero. The network survived the loss of a node with no disturbance to the remainder of the network. Another way to look at it is to establish some metric for quality of service, like data latency, that is being met prior to powering down a node, and then looking for the loss of the node to cause that QoS metric to degrade, and look for that QoS metric to get back to where it was before. This involves more of a judgement call from the observer and depending on the reporting rates might not be easy to assign a hard time value. The third way to identify recovery is to power down a node that is a parent of one or more nodes, and measure the time it takes for the network to detect that a parent has been lost and establish a new parent.
To summarize the three different "time to recover" test motivations are:
SmartMesh IP Application Notes Page of 17 159
1.
2.
3.
1.
2.
3.
Uninterrupted data delivery. If powering down a mote causes no interruption to data delivery from any other motes, then time to recover = 0. If data delivery is interrupted, then time to recover is the time until data delivery from all nodes its restored QoS data delivery. Baseline the QoS of a network through data analysis. Power down a node, and note degradation in the QoS metric for some or all nodes. Time to recover is the time until that previous QoS metric is met again Time to repair the mesh. Look at the mesh. Power down a node that will cause other nodes to have only a single parent. Time to recover is the time it takes for the network to detect the loss and re-establish a full mesh
Test 1 and 2 are essentially the same. We recommend you deploy a network (see Tip below) and connect to CLI and turn
. Each packet received by the manager will then print the Mote ID and the latency of that packet. Capturetrace stat on
this text for some time, and then power down a mote. The mote you power down could be chosen randomly or you could specifically identify a mote with many children in the mesh. Note an approximate timestamp in your text capture when you powered down a node. Let the network continue to run for several minutes. Then you should be able to plot the data from this text capture to identify the moment when the last packet was received from the powered down mote, and after that time you should be able to identify if there are any gaps or delays in data delivery from any other nodes. You will need to provide your own parsing an data analysis tools - MATLAB, Excel, and Python are all suitable.
Wait for the first few motes to join before powering up the remaining motes to form a mesh more quickly than if you power up all motes simultaneously. Motes report who they heard advertising when they join - when you power up all motes at the same time, only the AP is advertising, so likely motes will only report the AP as a possible neighbor. Motes discover and report other neighbors slowly to minimize energy, it takes up to 5 minutes after joining for the manager to begin "meshing" the network. In real deployments the delay to discover neighbors is unimportant, but in demo or evaluation scenarios, waiting for a few motes to join allows immediate meshing.
Test 3 involves a different trace function on the manager. Deploy your initial network, and observe that a mesh has been established (i.e. if numparents=2, then all motes will have two parents except one mote will have exactly one parent). Start a text capture of the manager . Select and power down a mote. Note the approximate timestamp for thetrace link on
moment you powered the mote down and watch the events associated with detecting paths that have failed and the activity associated with establishing new paths. After a few minutes stop the trace, and convince yourself that a full mesh has been restored. The 'time to recover' is the time from when you powered down the mote to the timestamp of the final link add event in your capture. Expected results
If the network was a good mesh to start with, we expect no data loss and no additional mote loss due to the removal of a single device. At moderate report rates (one packet per 5s or slower), we expect no disturbance in QoS. At faster report rates, you may see latency delays associated with a single device loss. Motes that had ~200ms latency might have ~500ms latency for a short time. Recovery time should be between one and two minutes. Powering down a mote should be detected and repaired between one and two minutes
The Stargazer GUI tool, which is typically installed with an evaluation kit, allows you to see the mesh forming
SmartMesh IP Application Notes Page of 18 159
3.3 Latency
3.3.1 Measuring Latency
Activating the manager CLI statistics trace provides a latency measure for every upstream packet received at the manager:
> trace stats on
281098 : STAT: #2: ASN Rx/Tx = 38694/38570, latency = 899, hops = 1 281100 : STAT: new average hops10=10 latency/10=56
This trace has two lines of report for each upstream packet. The first line shows when, in Absolute Slot Number (ASN) the packet was received (Rx) at the manager and when the packet was generated (Tx) at the mote. ASN is the number of timeslots that have elapsed since the network was started, or The difference20:00:00 UTC July 2,2002 if manager UTC time is set. between these two counts, multiplied by 7.25 ms per slot, gives the value reported here as 899 ms. The time between the sensor generating the data, and the notification at the manager will be slightly longer, as there may be some queueing delay. The first line also shows how many hops upstream the packet took.
The second line shows the manager averaging the statistics after receiving this packet. It shows the average hops for this mote (in units of 0.1 hops) and the average latency (in 10 ms units). So here the average latency is 56*10 ms = 560 ms.
You can collect a large number of latency trace prints and plot a distribution. It should look something like this:
SmartMesh IP Application Notes Page of 19 159
On average, unless path stability is very low, we expect a per-hop upstream latency of < 1/2 the upstream slotframe length.
3.3.2 Comparison with a Star Topology
In ZigBee networks, sensor nodes typically report to powered, always-on routers. As a result, data latency can be very low ­until the link fails.
Dust's networks offer a number of means to achieve low data latency - through a powered backbone (see note below) which affects the entire network, through network-wide base bandwidth settings, or through per-mote services.
Try the following experiment:
Place the motes within a few meters of each other and form a mesh network (default).
Measure average latency as described in the previous section. By default each mote will send temperature data once every 30 s, so you should take > 10 minutes of data.
Form a star network, by forcing the motes to be non-routing. This is done via the mote CLI
:
> mset rtmode 1 > mset maxStCur 20
and are non-volatile - it persists through reset/power cycle, but it must be changed before the mote
rtmode maxStCur
joins the network or the mote must rejoin the network if the setting is changed after joining. You will need to connect the board, use CLI to change the routing mode, then disconnect the and repeat with another mote.DC9006 DC9006
SmartMesh IP Application Notes Page of 20 159
We use the setting here to ensure that the mote is in the absolutely lowest power mode possible.
maxStCur
Measure average latency - you should see it has decreased slightly, as now motes will only have the AP as a parent. This star configuration makes motes vulnerable to link failures, and didn't really improve latency much, and isn't really the right solution to improve latency.
Set the motes back to routing-capable, and turn the upstream backbone on - this is done by the set config
manager CLI command. The backbone is a short slotframe with contention-access slots (as opposed to the normal dedicated slots used in other frames) that can be used to provide low-latency shared bandwidth across many motes. To get the lowest possible power mote configuration, we'll also eliminate the manager downstream multicast links by setting to zero. Note that you need to input the superuser password prior to making this change.
nummlinks
> set config bbsize 1 > set config bbmode 1 > su becareful > seti ini nummlinks 0
After this, a manager reset is required for the backbone to come on. Backbone mode is non-volatile and persists through reset. After reconnecting to the manager and joining all motes, turn manager CLI latency trace back on:
> trace stats on
Measure the average latency - it should be dramatically lower, despite motes occasionally routing through peers.
Turn off the backbone:
> set config bbmode 0
Reset the manager and turn the stats trace back on.
Increase the base bandwidth in the network. The default is 9000 ms (i.e. 1 packet per 9000 ms, or .11 packets/s). You will set it to 1000 ms. This is also done with the command:set config
> set config basebw 1000
After this, a manager reset is required. After reconnecting to the manager and joining all motes, turn CLI latency trace back on Measure average latency - it should have dropped. Even though motes are not publishing any faster, they have received more links, so latency decreases.
Set the base bandwidth back to 9000 ms.
SmartMesh IP Application Notes Page of 21 159
> set config basebw 9000
Request a service on one mote. Measure average latency - you should see that it dropped for the mote with a service, and may have dropped a little on other motes that have that mote as a parent.
By default, motes only have a transmit link in the upstream powered backbone - this only has a miniscule effect on mote power. In order to receive (and thus forward packets for other motes on the backbone) the
API must be invoked on the mote. This is discussed in the app note "
setParameter<pwrSource>
Application Note:
." This can improve latency network wide - either upstream, orUsing the Powered Backbone to Improve Latency bi-directionally, but it increases mote current considerably. However, even with a bidirectional backbone on, a Dust mote will still be 10x lower current than a typical ZigBee router.
3.3.3 Tradeoff Between Power and Latency
In general there is a tradeoff between power and latency. The more links a mote has, the lower the latency will be on any given packet, since we tend to space links relatively evenly throughout the slotframe. This means that motes that forward traffic have lower latencies than motes that don't, even if they generate packets at the same rate. It also means that a mote can improve latency by asking for services at a mean latency target even if the data generation rate is lower.
Some of the power measurement experiments in the Power section show the correlation between power and latency.
3.3.4 Roundtrip Latency
Dust's networks are designed to primarily act as data collection networks, so most bandwidth is spent on upstream traffic. While the use of services can improve the upstream contribution, if fast (< 2 s per message) call-response is needed, the bidirectional backbone can be used. Try the following experiment:
Turn the and traces on via the manager CLIio iodata
Use APIExplorer in manager mode to send acknowledged application packet to a mote. This is done using the
API - set the source/destination ports= (0xF0B9), and the payload = .
sendData
61625 050002FF020302000100
This turns the indicator LED on on the mote, and causes the mote to acknowledge that the LED has been set. You should see a print similar to the following on the manager CLI:
SmartMesh IP Application Notes Page of 22 159
442887 : TX ie=32:2c mesh=1222 ttl=127 asn=59614 gr=2 dst=2 rt=r4 r=1:2 tr=u:req:8; sec=s nc=0 ie=fe:00 IP=7d77 UDP=f7 sP=f0b9 dP=f0b9;
443503 : TxDone
444269 : RX ie=32:1c mesh=4002 ttl=127 asn=59699 gr=1 src=2 rt=g tr=u:req:0; sec=s nc=11 ie=fe:00 IP=7d77 UDP=f7 sP=f0b9 dP=f0b9;
Repeat this several times and measure the roundtrip latency (delta between TX time and RX time, here 1382 ms)
Turn on bidirectional backbone:
> set config bbsize 2
> set config bbmode 2
After this, a manager reset is required for the backbone to come on.
After reconnecting to the manager and joining all motes, turn CLI latency trace back on:
> trace stats on
Repeat the test of step one - you should see a dramatic improvement in roundtrip latency.
sendData
The powered backbone persists through reset/power cycle until deactivated and the network is reset again. It results in the motes consuming 1-2 mA average current.
SmartMesh IP Application Notes Page of 23 159
3.4 Channel Hopping and Range
Unlike most other 15.4 based systems, Dust's products employ a Time Slotted Channel Hopping MAC - this means that transmissions are spread out over all (or some - see Blacklisting below) channels in the 2.4 GHz band. This has the advantage that the system's performance depends on the average channel stability, rather than a single channel's stability. The following test will show you the how to measure single channel stability and see the effect of channel hopping. This test requires that you have access to a 802.11g Wi-Fi router and can set it on a particular channel - set the router to 802.11 channel 6 - this should cover mote channels 4–7. You will also need to configure your manager and a mote for radio test.
Note that in the various APIs below, channels are numbered 0-15. These correspond to channels 11-26 in the IEEE channel numbering scheme.
3.4.1 Using radiotest for Single Channel Measurements
This description places the manager in the role of transmitter, and the mote in the role of receiver, but the test can be run easily with roles swapped.
On the manager CLI, log in and place the manager into radio test mode
> login user > radiotest on > reset system System reset by CLI SmartMesh IP Manager ver 1.1.0.30. 658 : **** AP connected. Network started
After the manager resets, configure it to be the transmitter, setting it for a packet test, on channel 0, at +8 dBm power, 1000 packets, 80 byte payload - wait to hit return until you've configured the mote as receiver. Login is optional in radiotest mode.
> radiotest tx reg 0 8 1000 80
On the mote CLI, place into radio test mode and reset. Then configure it to receive on channel 0 for two minutes
SmartMesh IP Application Notes Page of 24 159
> radiotest on > reset SmartMesh IP mote, version 1.1.0.41 (0x0)
> radiotest rx 0 120
At this point hit return on the manager to start the test. After the manager is done sending, record the number of packets received on the mote CLI:
> radiotest stat Radio Test Statistics OkCnt : 998 FailCnt : 2
The ratio of received to sent is the path stability (or packet success ratio) for this channel. Note that 1000 - may not
OkCnt
equal , since the manager only counts packet that it can lock onto.
FailCnt
Repeat for all channels. You should see a dip in path stability around the channels being used by the Wi-Fi router - note how the dip isn't as big as you might expect. This is in part due to the fact that the router is also duty cycling, and is only on a small fraction of the time.
3.4.2 Range Testing
The radioTest commands can also be used to do range testing. Range is the distance at which two devices can reliably exchange packets, but it is also a grey area, since the following all affect the ability of two devices to communicate at a distance:
Reflectors - things the radio signal bounces off of, including the ground. Obstacles - things the radio signal must go through Presence of interferers Antenna design Radio power settings
The simplest test is to repeat the single channel measurement described above, and repeat for all channels, since a real network will use all channels. You will find that the packet error rate is strongly influenced by the height of the radio off the ground, due to self-interference between the line-of-sight path and the bounce path. With motes at 1 m elevation, you may see a drop off in packet success ratio near 50 m spacing, only to have it improve farther out. Motes placed several meters above an open field should be able to communicate at hundreds of meters.
After this test, return the manager and mote to normal operation:
SmartMesh IP Application Notes Page of 25 159
> radiotest off OK > reset
The boards come with an integrated chip antenna that has significantly less gain (-2.3 dBi average vs +2DC9003 dBi) than a dipole antenna. Range measurements should take this difference into account.
3.4.3 Blacklisting
The manager provides an API to blacklist certain channels in the case of a known interferer. In general, unless you know that there is a strong interferer (such as a very busy wifi router) you should not blacklist
Form a 5 mote network - after all motes have joined, clear statistics:
> exec clearstat
Run for an hour. Use the manager CLI to look at the path stability for the network as a whole. At no time should you see packets lost due to the interferer.
SmartMesh IP Application Notes Page of 26 159
> show stat
Manager Statistics --------------------------------
established connections: 1
dropped connections : 0
transmit OK : 1907
transmit error : 0
transmit repeat : 0
receive OK : 35
receive error : 0
acknowledge delay avrg : 15 msec
acknowledge delay max : 35 msec
Network Statistics --------------------------------
reliability: 100% (Arrived/Lost: 1931/0)
stability: 98% (Transmit/Fails: 983/25)
latency: 200 msec
Motes Statistics -----------------------------------
Mote Received Lost Reliability Latency Hops
#2 1019 0 100% 120 1.0
#3 19 0 100% 1050 1.0
SmartMesh IP Application Notes Page of 27 159
Reset the manager, blacklist channels 4-7, and reset the manager. The blacklist persists through reset/power cycle.
> login user > set config channellist 00007f0f > reset system System reset by CLI SmartMesh IP Manager ver 1.1.0.30. 658 : **** AP connected. Network started
After the network has formed, clear stats, run for another hour, and observe the path stability - it should have improved.
Return the manager to 15 channels before proceeding:
> login user > set config channellist 00007fff > reset system System reset by CLI SmartMesh IP Manager ver 1.1.0.30. 658 : **** AP connected. Network started
SmartMesh IP Application Notes Page of 28 159
3.5 Power
This section details how to measure power on an Eval/Dev board. In order to measure mote current, you should use a DC9003 A-B/ combination. You can either connect a scope across the jumper marked VSENSE on the - this measuresDC9006 DC9006 the voltage drop across a 10 Ω series resistor, or you can remove both the CURRENT jumper (black) and the red jumper behind it, and connect an averaging current meter across the CURRENT jumper pins.
The LED_EN jumper on the A-B board must be disabled or the current measurement will be incorrect.DC9003
Suggested Measurements:
Idle current - when a mote has been reset, but no join API command has been issued. The mote must be configured in
mode to prevent automatic joining. After measuring idle current, return the mote to mode.slave master
Searching - Measure at 5% duty cycle, and 100% duty cycle. You should see the current change from ~250 µA average to 5 mA average. Mote joined - Set to 4, and to fast and reset the manager before joining the mote. After an hour,
dnfr_mult setDnframe
the manager will transition to the longer downstream frame, allowing you to compare the average current. It should be about 29 µA before the transition, and 24 µA after. Turn off advertising with a 'exec setAdv off' command in the CLI and see that the average current falls to 10 µA. Backbone - Set the bbmode to 2 and bbsize to 2 and reset the manager. Measure the average current - it should be about 500 µA.
Dust provides a to help estimate mote average current under various useSmartMesh Power and Performance Estimator cases. Compare your test results to the spreadsheet results.
SmartMesh IP Application Notes Page of 29 159
3.6 Mesh Behavior
Dust's networks automatically form meshes - each mote has multiple neighbors through which it can send or forward data. This setting is a manager policy that is visible with the manager CLI command >show config (see above). The config element that sets this policy is numparents, and as you can see above the default value is 2. The manager will make sure every mote has at least the number of parents indicated by numparents, provided there are no loops in the mesh. Try to sketch this on your white board and you'll find that in a one mote network, that one mote will have only the AP mote as a parent. Add a second mote, and one mote will get two parents, but the other will be left with only one parent, to avoid making a loop. Regardless how many motes you add, there will always be one 'single parent mote'.
3.6.1 Testing the Mesh
The Stargazer GUI application will allow you to see the mesh as it forms - if you haven't already installed it, do so now. It also requires that you install the Serial Mux.
A mote having two parents is the best balance between robustness and power consumption under most operating conditions. Robustness is achieved by having multiple parents. To confirm that we recommend you find a mote in your network that is a parent to one or many motes. Power that mote off. Data delivery from that mote will stop, but the children will continue to send data. Use 'trace stats on' as above to show a live stream of data from all the children motes, which are sending data through their other parents. You may see a temporary increase in latency for a few minutes, and if you capture that trace to a file you can show this graphically. The manager will take a few minutes to reassign parents and links in the system to account for the loss of the mote you powered down.
3.6.2 Changing Mesh Policies
The parameter 'numparents' can be given any of 4 values: 1, 2, 3 or 4. If you set numparents to 1, your network will be a tree, not a mesh. Each mote will have one parent, and that one parent may not be the AP. This is better than a star in that a tree supports multi-hopping. But like a star, a tree network has numerous 'single points of failure'. If you power down the parent of a mote in a tree, the child mote will drop off the network because it has no connections to any other devices. It will reset and will have to join again, most likely resulting in data loss. A tree structure can be slightly lower power, because each device only has to listen to one parent for downstream messages and only has to maintain synchronization with one parent. Furthermore it is assumed that data latency will be more bounded in a tree, because individual packets can't 'wander' around the mesh. We believe that the likelihood of network collapse and data loss far outweigh the potential benefit in power and latency.
Two is the default and has a nice balance of robustness vs power. Setting numparents to 3 or even 4 increases the 'meshiness' of the system and gives the network additional robustness at the cost of somewhat higher power. We recommend increasing the number of parents in networks where you know that paths will be breaking frequently. See the Application note . Moderate mobility of some nodes may be betterIdentifying and Mitigating the Effects of Interference supported with numparents = 4.
SmartMesh IP Application Notes Page of 30 159
Loading...
+ 129 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use