Noty Frequently Linear Technology
Frequently Asked Questions
Frequently Asked Questions Page of 1 26
1 Revision History
Revision Date Description
1 03/18/2013 Initial Release
2 10/21/2013 Additional questions added
Frequently Asked Questions Page of 2 26
2 General SmartMesh FAQs
2.1 Basics
Q: How often can my sensors send data?
A: When the mote joins, it will be given enough network resources to stay connected to the network. The sensor can request
extra network resources in the form of a service request. That tells the network how much traffic this sensor is expected to
offer to the network. If the sensor is configured to report a measurement every 60s, then the sensor should submit a 60s
service request. The network will inform the sensor whether the service has been granted. If EVERY sensor in the network is
configured to send data at the same rate, it may be more convenient to set the network-wide base bandwidth at the manager
and not do any service requests at the edge.
Since all traffic flows through the AP, the maximum theoretical capacity of the network is 1 packet/slot, with ~90 bytes of
payload space per packet. In practice, several factors serve to derate this value:
Slot size differs between SmartMesh IP (7.25 ms) and SmartMesh WirelessHART (10 ms), so the total packets/s
available differs.
The manager sets aside ~15% of the total bandwidth for downstream communications, advertising, and neighbor
discovery
We choose a default provisioning factor of 3x (3 links assigned for every one used) to allow for the large expected
variation of path stability
Consult the table below for the total system egress bandwidth. This total bandwidth needs to be shared across all the motes in
the network. So if there are 24 motes in an LTP5901 network, then you can send 1 packet/s, 2 packets/s for 12 motes, etc.
Manager #AP RX
Links
#AP RX per
sec
Pkt/s @ 3x
prov
Pkt/s @ 2x
prov
LTC5800/LTP5901/LTP5902-IPRA
150 72.9 24.3 36.4
LTC5800/LTP5901/LTP5902-IPRB or IPRC + External
RAM
223 108.3 36.1 54.2
LTP5903-WHR
737 72.0 24.0 36.0
Frequently Asked Questions Page of 3 26
Q: Is it better to send small payloads or big payloads?
A: It is always better to send only the data that is needed. Transmitting one small payload consumes less power than
transmitting one large payload. But sending 10 small payloads is more costly than sending one large payload. Concatenating
measurements and sending them less frequently is more efficient. The cost is that the older measurements are more 'stale'.
For trending data, this might be useful. For real-time monitoring, the most valuable data is typically the freshest data. If you
have an event that requires you to send 8000 bytes of data, it is far better to send 100 80-byte payloads than it is to send 1000
8-byte payloads.
Q: My data messages are larger than a single payload. Does the network automatically fragment and defragment my
payloads?
A: No. Fragmentation and reassembly is the responsibility of the application on each end.
Q: Mote firmware and sensor firmware?Can a mote's firmware be updated wirelessly?
A: The mote firmware can be programmed over the air (OTAP). There is built in manager support for this in SmartMesh
WirelessHART. In SmartMesh IP, an external application is needed to control OTAP - we provide a reference implementation
called OTAPCommunicator. There is no native OTAP support for sensor firmware, but many customers have implemented
sensor OTAP simply using the network to transport those payloads.
Q: My sensor requested a 30s service, and it was granted. Will something bad happen if I send data once every 60s
instead? What if I send data once every 10s instead?
A: There is no validation at the mote holding you to your service request. Nothing bad will happen if you send less often than
the service level you requested. In fact, some sensor applications will ask for extra service deliberately in order to achieve
lower latency. If a sensor asks for a 10s service and sends data once every 60s, that data will be delivered more quickly than if
the sensor had only asked for a 60s service. Sending more data than your service allows may cause congestion in the
network. That congestion may happen locally at the mote, or it may happen upstream at a router that is routing more traffic
than the services indicate should be expected. In general it is not a good practice to send more data than you have been
granted.
Q: Do all my sensors have to publish data at the same rate (i.e. get the same services)?
A: No. Each sensor can send unique service requests. One sensor may ask for a 60 s service, and another may ask for a 10s
service and another can ask for a 1 s service. The network manager will lay in links to accommodate all granted services.
Heterogeneous services are totally supported.
Frequently Asked Questions Page of 4 26
Q: Is there a limit to the services my sensors can ask for?
A: Yes. Services are not an infinite resource. With default manager settings, sensors will start getting denied services when
the total of all services exceeds the maximum throughput of the manager (refer to individual product documentation). For
example, for the manager that supports 25 packets/s, you should not exceed more than 25 motes publishing at 1 second
each. So, if sensors send data once per second, you should not plan on using more than 25 motes per manager. Similarly, if
you want to build a 250 mote network, then 10 s is the fastest service you could expect to get for all motes.
There is also a limit on the fastest service an individual mote can expect to receive. With default settings this is ~100 ms. A
shared bandwidth backbone feature allows packet to fall well below this number for shallow networks, but it islatency
designed for infrequent data, not routine publishing.
Q: Can I guarantee my power consumption by setting my data reporting rate?
A: No. A sensor that sends data less often will consume less power, but the amount of data forwarded from children in the
mesh also has a large impact on total power consumption. If you have a power supply that has a hard limit (like a scavenger
circuit), you can use the mote API to set power source information of the device, but that will limit the manager's ability to
build the best possible mesh, and those limits should be used with care.
Q: My sensors send data once an hour. Can I turn off the network and turn it back on when my sensors want to send data
and save power?
A: This is generally not recommended. The motes often consume less power in the network than they do when searching for
the network. Furthermore, the motes being on and maintaining connection to the network means that you can easily
implement alarm type reporting over and above your very infrequent regular updates. Also you have the ability to send
downstream commands for actuation, configuration, etc., at minimal extra power. An IP mote can live in a network AND
report every 30 seconds for an average current under 10 μA.
On the other hand, if you have an application such as container tracking where the whole network (on a shipping container)
may not need to be monitored for days at a time, there may be other overriding considerations.
Q. Why does my network have a single parent mote?
A: All networks will have one mote with the AP as its only parent. This is required to prevent timing and data loops in the
network. A network with more than one single parent mote indicates that you need to either add a mote or move a mote to
improve the connectivity.
Q: Are out of order packets received in a wireless mesh network?
A: Yes, a packet flowing upstream in a mesh network can follow any one of many sets of redundant paths to the manager. The
application layer is responsible for reordering received packets if necessary, which can be done using the accurate timestamps
in each packet.
Frequently Asked Questions Page of 5 26
1.
2.
3.
4.
Q: How can I verify the integrity of a wireless mesh network?
A: In order to ensure the integrity of a wireless mesh network, every mote must have at least 3 neighbors with path
good
stability of 50% or better. Path stability data is only available on paths with active upstream links. If there aren't 3 paths being
actively used by the mote and shown with a path stability in the path statistics for that mote, then the measured RSSI on that
path can be used as an approximation. In that case, an RSSI higher than -75 dBm is considered a good neighbor path.
Path statistics can be returned through the API of the Manager for every mote. This allows the client to write software to verify
network integrity. It's also a good idea to give the network at least an hour to discover all the usable paths before making a
decision to add repeaters.
Q: Why are the motes slow to join the manager? Why does my network take so long to form?
A: The most common reasons for slow join time are:
Motes that have joined the manager are suddenly moved to a new location. When this happens, the mote must detect
that all its paths have failed, which can take several minutes. The mote will then reset itself and then attempt to join the
network again at its new location. This join time takes more time. To fix this problem, simply reset the mote any time it
is moved to a new location. The mote will immediately try and rejoin the manager.
Poor path stability - the presence of interference, or motes that are too far apart can result in the message sequence to
join the mote timing out, and the mote will need to reset and attempt to synchronize and join again.
Mote search duty cycle is low - See “How can I make my motes join faster?” below.
The size of the network is large (more than 100 motes) and is deep (covers a large area). Typical join rate for larger
networks is 1 min/mote.
Q: How can I make my motes join faster?
A: Increase the mote's join duty cycle using the mote’s API command <joinDutyCycle> to be up to 255 (100%).
setParameter
The default setting is 5% for WirelessHART motes, and 25% for IP motes, which conserves power when trying to join. High
duty cycle search will consume mA of current, which may be undesirable, particularly if motes are deployed in advance of a
manager to join. A developer working at their desk may have to watch the mote on their desk join 20 times in a work day. That
person needs the mote to join fast. A salesperson doing a demonstration in front of a board room of people probably also
wants joining to be as fast as possible. For most real deployments, though, it may be wise to save a lot of power in search and
accept that joining might not be instant.
Q: Why would a mote suddenly reset?
A: A mote will reset if its /RST hardware pin is asserted or it receives a reset command from the sensor processor. A mote will
also reset in the rare event that it loses communication with both its parents. If you are seeing a mote reset many times, pay
close attention to how many neighbors have RSSI > -75 dBm and could potentially become good parents.
If you are seeing that a mote appears to have good neighbors and parents but still resets, you may have an RF interference
problem. This can be verified by calculating a path stability vs. RSSI curve for any troubled motes. The ratio should be
relatively consistent for many deployments. If you see a sudden drop in path stability relative to RSSI, you should suspect RF
interference is causing the problem. Wireless sniffers can be used to measure in-band interference.
Frequently Asked Questions Page of 6 26
Q: What happens when a mote has the wrong credentials to join a network?
A: In the case of a wrong Network ID, the mote will continue in the “search” state forever. It is looking for an advertising
packet with a Network ID matching its configuration, which may never come. After a period of time, the microprocessor may
want to reduce the join duty cycle time to conserve power consumption. This can be done by using the mote API command
<joinDutyCycle>.
setParameter
If the mote has the correct Network ID but the wrong join key or is not on the ACL, it will attempt to join but the manager will
not respond. The mote will reset itself after several minutes and the microprocessor will get a boot-event.
If the mote's flash has been erased, its join counter will be reset to 1. Since the manager keeps a history of each mote's
joining, it will interpret the new joins as a replay attack and not accept the mote. To fix this problem, you should delete the
mote from manager's ACL and re-add it.
The mote serial API command <moteStatus> can be used to verify the state of a mote. A mote with the wrong
getParameter
Network ID will always be in the state. A mote with the wrong join key or join counter will continue past theSearching
searching state but will never reach the state.Operational
Q: Why does a mote have two parents that are far away, when there are other motes that are closer?
A: The network manager's algorithms are designed to build the best network it can, using paths that are 'good enough'. It
does not make decisions that are locally greedy. It is far better to send data two hops (even if the packet success rate is only
80% at each hop) than it is to send data 5 hops (even if every hop is 100% packet success rate). The manager will tend to
make the 'flattest' network possible (fewest average hops).
Q: Can a SmartMesh manager be accessed via an IP address?
A: SmartMesh WirelessHART managers support connection by Ethernet, allowing access to the manager API via the
manager's IP address (IPv4), but only the packaged managers have an RJ45 Ethernet jack. It is up to the system integrator to
provide network access on an embedded WirelessHART manager. SmartMesh IP managers are serial devices - they get
internet connectivity (IPv6) through a border router - Dust has provided a reference implementation of a border router to
demonstrate this capability.
Q: Can a mote be accessed via its IP address ?
A: When a low power border router is present, SmartMesh IP motes can be directly addressed by their IP address.
SmartMesh WirelessHART motes do not have an IP address, so while they can be addressed through manager APIs, they
cannot be addresses directly via an IP address.
Frequently Asked Questions Page of 7 26
2.2 Advanced Topics
Q: What resources are used to maintain the network, collect info on link health, assign and re-assign links to motes, etc?
A: Each mote generates three health report packets every 15 minutes. These packets summarize the information the manager
uses to maintain and optimize the network. Downstream, we typically only see a few packets per hour required to repair and
optimize the network.
Q: Is a single superframe/slotframe configuration used across an entire network?
A: In general use, all motes are assigned all superframes/slotframes. For SmartMesh WirelessHART pipes, the endpoint is
specified by the user, and the manager handles setup/teardown of the superframes and links. In SmartMesh IP, the manager
does not give low-power motes (info given by the mote at join) the advertisement slotframe, but it is identical for all other
motes.
Q: If there are multiple networks with the same networkID in the same radio space, which network will a mote join and
how can this be managed?
A: A mote will synchronize to the first advertisement it hears, and it will attempt to join the network that sent this
advertisement. Mote allocation can be controlled by using ACLs on each manager, however, motes will still try to join
whichever network they hear first. If a mote is not on that network's ACL, it will reset and start listening again.
Q: If line power is available, how does this affect the opportunity to create low-latency communications?
A: The low-latency backbone can be activated to reduce the latency throughout the network without increasing the energy
draw at battery-powered devices. The more line-powered devices are available, the better the performance of the backbone.
However, the backbone is not appropriate for every use case, see "Application Note: Using the Powered Backbone to Improve
Latency" for more details.
Q: If a customer has physically lost a mote, can our system help find it?
A: While we do not provide a mechanism for querying the location of a mote, triangulation based on the strength of used
paths (available through mote statistics) may help locate a device.
Frequently Asked Questions Page of 8 26
Loading...