TABLE OF CONTENTS
- Introduction
- Getting started
- Checklist Summary
- References
- Revision History
- Legal Notice
Status | Date | Doc Version | Applicable | Confidentiality |
RELEASED | v1.0 | Wirepas Massive 5.1 and 5.2 | PUBLIC |
Introduction
This document provides a minimal checklist to verify the stability of a network in order to ensure a proper installation and avoid stability problems. It is recommended to check those in a test network before a large deployment.
The tests provided in this document shall be applied to a network with more than 20 nodes to be pertinent. It is also recommended to make those checks on networks that reproduces as much as possible the final deployment condition to get relevant data (Environment, sensors density…).
Those tests can also be performed on a final installation to validate it.
What you’ll learn
- The different points to check to know if your network behaves well or not.
What you’ll need
- A Wirepas Massive test Network similar to the one you plan to deploy.
- A Wirepas Network Tool (WNT) backend
- A Gateway configured to send Wirepas network data to the WNT backend
- WNT Client running on a computer in order to have access the relevant metrics used in this document
Getting started
To perform reliable checks, it is recommended to wait 1 or 2 days after the installation to let time for the network to stabilize.
If you perform those checks on a test network, it is pertinent to compare all the nodes to have an overview.
If they are made on a big network (more than 60 nodes) take care to the number of nodes selected and the data history duration as it might take a while to retrieve all data from the backend and displayed graph can be hard to read.
The list below summarize the points to check, detailed in the following parts. The last step is specific, not always needed depending on your Network.
Checklist Summary
Link to Step | Check | Result | |
Diagnostics activated and correct Nodes configuration. | True | False | |
Gateway Clock are synchronized | True | False | |
Nodes boots are as expected (v5.1 and above) | True | False | |
Link quality>90%, Installation quality>50% | True | False | |
Node’s traffic is within Wirepas Massive KPIs | True | False | |
Routers are not doing too many BLE scanning (Low Latency network only) | True | False | |
Step 0 : Activate diagnostics and check nodes configuration
This first step will help you to check the Node’s configuration diagnostics frequency set and if the connection of the nodes is stable over time.
How to check this ?
1. Set Diagnostics : The diagnostics can be set in the Settings → Networks menu. Select your network and set “Diagnostic Interval” to 300s (5 min), and apply to the network. This delay is enough to have pertinent diagnostics, and not too frequent, which otherwise could saturate the network with diagnostics making results not reliable in addition to introducing an overconsumption on battery operated nodes.
2. Check Nodes’ configuration : The node’s configuration can be seen in WNT client under the “Node” menu. Each node should be configured as desired; the following points needs attention:
- Node’s mode of operation: Low Latency or Low Energy
- Node’s role: router or non-router
- Node’s Autorole parameter: on (recommended mode) or off (in some specific case)
3. Approve Nodes : Some diagnostics can’t be seen if the node is not approved. This can be done from the Settings menu, by drag and drop your nodes on the floorplan [2], or with a right click on a list of nodes.
Note : It is preferable to place nodes on the floorplan where they are physically located as it can give additional insight/help to interpret diagnostics data.
4. Check Nodes are Online : The “Online Status” shows if the node is well connected to the Network :
Interpret the results :
The following table summarize the results you may obtain and eventual actions you may take depending on the online status of your nodes :
Online Status | Diagnostic | Action |
All nodes Online, sometime Uncertain | No issue here. Nodes can be reported as uncertain if:
| Pass to next step |
All nodes Offline | Most probably a problem with Gateway(s) | You can check the following points:
If none of this solve your issue, contact Wirepas Support at support@wirepas.com |
Some nodes Online, other Offline | The nodes might not have enough neighbors. | Check the node placement :
|
Step 1 : Check that Gateway clocks are synchronized
How to check this ?
This second step checks if the gateway and the WNT client and backend clocks matches. A desynchronization make all other checks invalid.
This can be done from WNT client → Settings → System Clocks tab, as follow :
Interpret the results
If all the gateways show the same clock as WNT client and backend, then the diagnostics will be relevant of the current status of the network.
If not, your gateways should be set back to the correct time.
Note : Not all gateways from our providers implement the query clock. Gateway “query clock” feature is only available with API version 2 onward. Please see “API version” column in the above screenshot.
Step 2 : Check the Nodes boot (v5.1 and above)
Nodes may reboot for several reasons; issue in the application, malfunctioning hardware such as bad battery connection or simply because of a remote API request. It is useful to check if those boots are justified or not. A new feature has been added since v5.1, in the Event tabs a list of the boots reasons for each nodes can be displayed.
How to check this ?
Navigate to the “Event” tab, and select “Boots” and a timeline to see the boots of your nodes.
Interpret the results
The boot reasons can be interpreted differently depending on their frequency. If a node reboot several times without any known action made on it, it can be due to an issue in the application. In reverse, a single boot when the node is powered ON or a reboot due to an OTAP operation are expected behaviors.
The following list gives the boot reasons that can be encountered :
Wirepas Massive v5.1
Bootline_hash | Bootline_nbr | Reason |
0 | 0 | Power ON Boot |
0xdcae | 110 | Boot by call to |
0x8f3a | 1303 | Boot requested by remote api |
0x3bfc | 74 | Boot requested by otap operation |
0xa170 | 400 | Watchdog handler |
0xa170 | Any number | Other handlers |
Wirepas Massive v5.2
Bootline_hash | Bootline_nbr | Reason |
0 | 0 | Power ON Boot |
0xdcae | 118 | Boot by call to |
0x8f3a | 1294 | Boot requested by remote api |
0x3bfc | 68 | Boot requested by OTAP operation |
0xa170 | 400 | Watchdog Handler |
0xa170 | Any number | Other handlers |
In any case, if something seems abnormal or if you have trouble to interpret the booting reasons do not hesitate to contact Wirepas support at support@wirepas.com.
Step 3 : Check Radio Quality
1 - Installation quality
How to check this ?
The “Installation quality” information is available since Wirepas Massive version 5.1. More details about this diagnostic can be found in the Radio Installation quality API application Note [1].
The Installation quality diagnostic gives an indication on whether the node has a correct route to sink, with reliable links to its neighbors and a reasonable number of hops to the sink. It can be checked for all nodes individually in the “Comparison” tab, or for the whole installation in the “Overview” tab. If the whole installation quality is bad it is pertinent to check this for each nodes separately.
The “Installation quality errors” gives more information on why the installation quality is bad.
Interpret the results
Installation quality | Diagnostics | Action |
Installation Quality >=50% | The node is well positioned. | Pass to next step |
50% > Installation Quality > 25% | The node is not very well positioned and the connectivity will work most of the time, but is vulnerable to changes in the surrounding environment or in the network itself. | It is recommended to modify your nodes' placement and/or to add some router node to increase the number of neighbors of the nodes (and by then the possibilities to get a better route to sink) |
25% > Installation Quality | Installation quality is bad. The Node might be able to connect to the Network but is likely to experience connectivity breaks. | Same as above. |
In the installation overview, ideally all the nodes should be in the “green” part. However, this front page only tells situation at the moment and does not give information whether problem has been occurring earlier.
In the screenshot below, the Blue Node is good, the Green is more or less good too, but the Yellow one has a bad installation quality.
Looking together the installation quality and the Installation quality errors, it appears that the yellow node has not enough neighbors and a bad RSSI, instead of the two others have very few errors.
2 - Link Quality
How to check this ?
In the “Comparison” menu , the “Link quality” indicates the amount of successful transmission/reception. It gives an indication on whether the node is well placed in the network, i.e if data is lost it means that the connection isn’t reliable.
Interpret the results :
Link quality | Diagnostic | Action |
100%>LinkQuality>90% | Links are reliable. | Pass to next step |
90%>LinkQuality>75%, punctual drops below 90% | Links are not completely reliable, it may be related to the node’s amount of neighbors. | Check the node location and change it (maybe add other router node) to increase the link quality. You can also have a look to the “Next hop RSSI” [1]. |
75%>LinkQuality | Links are not reliable | Same as above. You may also consider to increase the number of router node/ gateway if needed. |
Step 4 : Check the traffic
How to check this ?
To see the global traffic impact on all nodes, it is pertinent to first look at the “Memory allocation failures”. If no failures are detected, it means that the buffer capacity was not exceeded, and the traffic is supported by the installation. Directly, looking at the “Max Buffer usage” and “Average Buffer usage” gives the information of the percentage of Node’s packet buffer that is used. It can be found in the “Comparison” tab.
Interpret the results
The below table summarize the validity ranges of the Average Buffer usage. The lowest the better. The same deductions can be done with the Max buffer usage.
Average Buffer Usage | Diagnostic | Action |
Avg Buffer Usage > 50% | The traffic is too high. There is not enough routes to absorb the traffic. | Buffer usage depends on the node distance from the gateway, first hops being normally more constrained. Adding routers and eventually some gateways may solve this issue. |
50% > Avg Buffer Usage > 10% | The traffic is a bit high. | The traffic should be monitored. Adding router node or a gateway may reduce the traffic on this node. |
10% > Avg buffer Usage > 0% | The traffic is adapted to the network capabilities | None. |
Step 5 : Check if routers are doing BLE scanning (Optional)
How to check this ?
This step checks the channels used by your installation. In Low latency Network, nodes with role fixed to router can do BLE scanning, and in that case they are forced to operate on BLE advertiser channels only, which can be overloaded if the traffic on those channels is very high. This can be checked in the “Comparison” tab, with the “Cluster Channel in use” parameter.
Interpret the results
Some network channels should be avoided, especially the one reserved for BLE advertising, which are usually very crowded. Be careful not to use them, except if you are doing BLE advertising.
They can either be set in autorole (or Low Latency subnode), or converted to Low Energy devices. However this may create other issues, then visible through the installation quality.
Conclusion
If all the checks has been passed successfully, the network can be considered reliable. It is recommended to perform those checks for each new installation, even when adding some nodes to an existing network.
If any doubt subsist after this on your installation, or on the pertinence of the analysis, the Wirepas support team is available to analyze the checks and give some advice on how to improve the Network quality.
References
[1] Radio Installation quality API application Note
[2] How to place Anchors and Tags on a building floorplan in WNT client
[4] Wirepas Massive BLE advertising and scanning application Note
Revision History
Date | Version | Notes |
v1.0 | The first version. |
Legal Notice
Use of this document is strictly subject to Wirepas’ Terms of Use and Legal Notice.
Copyright © 2021 Wirepas Oy