Testing fast mass inventory on low-power mesh networks

My name is Hannu Hirvi and I’m a core stack developer at Wirepas. This is the first blog post in a series of Wirepas Developer Blogs, The idea is to giving you a sneak peek into development of the Wirepas Massive as well as support tools and testing. Let’s get started.

One rule of thumb in software development is that ‘even the least probable occurrence is guaranteed to occur in large scale’. For example, if code contains a glitch that happens once every million seconds in one device, then in a device network of a million it occurs, on average, every second. Avoiding and mitigating this is one of the challenging aspects of software development.

Working with Wirepas Massive

Development of the Wirepas Massive usually starts with small scale, i.e. several devices. When that is done and we are happy with the results, the device amount is increased rapidly to spot the difficult-to-catch problems. The mechanism itself works fine but understandably contains the inherient problem of analyzing what is going on. It does not really help to check issues in larger setups if there are no ways to analyze what is going on in the network.

Example case – fast mass inventory on low power mesh networks

An example of such is the use case of mass inventory. The use case is a pallet containing hundreds, even thousands of individual packages each of which is tracked. Now, when a pallet is entering a dedicated area, such as a warehouse or truck loading area, there is a need to get the inventory of each package on the pallet. Each device is equipped with a Wirepas Massive enabled tag. The inventory is then performed by ensuring that tags find the Wirepas Massive network routing devices as fast as possible. The routing devices transfer the tracking information to backend via normal operation of Wirepas Massive.

What makes this use case challenging is the fact that tags are battery-operated. This makes power saving one of the key requirements, as well as the ability to create full inventory as fast as possible. And these are basically conflicting requirements for a wireless battery-operated network.

Traditionally, to understand what happens in this kind of set up, a trace harness is injected into devices in the setup. This trace harness would need to be injected into both tags and Mesh routing devices to see ‘both sides of the coin’. However, the sheer amount of these tags makes it impossible to create a practical way of extracting debug harness from each of them.

How to ensure that the needs of the use case are met?

One major design feature of the Wirepas Massive is that devices are intelligent on their operation and can gracefully operate together in mass volumes. To verify this operation, we needed one additional testing aspect, which requires tracking all activity in the radio interface. In addition to this it is mandatory that a device is totally non-intrusive and does not affect the existing network, i.e. the tool is listening only. This tool, denoted here as the network scanner, listens to all packets in the radio interface, for example data transmissions, acknowledgements, control plane signals, network discovery signals, basically everything.

Besides that, metadata such as exact transmission time of the data packet, signal strength etc. are tracked. Also, failures such as packet collisions are tracked. The same radio devices as other devices can be used for implementing the network scanner.

A definite pro of the network scanner is that it shows how the devices are working collaboratively in the radio interface. It has been proven many times that to optimize operation in dense scale requires a totally different approach than, for example, optimizing traditional point-to-point operation. Optimizing performance by using just two devices would be a total disaster in large scale. By using the network scanner, the difficult-to-spot occurrences are also found. For example:

• Starvation of single device (one device cannot get transmission through).

• Ensure that tags do not use excess transmission power.

• Reveal tendency for ‘mass hysteria’ occurring when a large number of devices decide to perform radio operations synchronously.

Another design feature of Wirepas Massive network is the ability to use multiple radio channels. However, the network scanner can only track one radio channel at a time. So, multiple scanners are needed to get a holistic view of the system. And to make that feasible, we needed a cost-effective solution. This is achieved by a setup which contains very cost-effective components:

• First, we chose Raspberry Pi mainly because it is very commonly used and already familiar. The Second reason is that it contains easy built-in SPI (Serial Peripheral Interface) support. This interface is used between Raspberry Pi and the radio device and is fast enough to log all incoming data without becoming a bottleneck.

• For the radio device, the Promistel Raspberry Pi HAT device was optimal and an affordable choice. And because it resides in the Raspberry Pi casing it is a sustainable choice.

Another requirement for testing is, of course, power consumption measurement. Since tracked items are battery-operated, power consumption measurement ensures that battery usage is sustainable. But while the network scanner ensures that devices do not waste power on the radio interface, devices may waste energy on other aspects. However, this can be done on only a very small subset of the tracked items.

To summarize, the testing setup is the following

Wirepas Massive network sends data to Wirepas Massive gateway. This data contains actual use case of the setup, for example, detection of the tracked item in the setup.

Some devices are injected with the debug trace harness. In practice, there can be only a few such devices.

• Network scanners track the communication between devices in the radio interface.

• Power consumption measurement is done for tags. Again, in practice, this can be only performed for very few of them.

It is important to be able to combine information from multiple sources. This helps you ensure operation from different points of view and get the ‘big picture’ of how the system is operating.

Note that there are additional use cases that the network scanner enables, since it tracks all the packets heard in the radio channel. An example is tracking devices in the radio range. By tracking device RSSI and device address, it is possible to find lost devices. When searching for the lost device, all that is necessary is to walk towards the direction where RSSI is stronger. To make the use case feasible, you need a portable device with user interface capability. We have been using Raspberry Pi with built-in display and USB battery pack.

Conclusion

As a developer of Wirepas Massive the most rewarding aspect is to make a large number of devices act collaboratively. Ensuring the system works requires collecting data from various angles. Only when all the collected data is combined into information and analysis is it possible to truly understand how such a setup works. To develop and test a collaborative element in a dense and large-scale network also requires development of new testing techniques, which may even solve some totally unrelated use cases.