Wirepas Stack Transition (Stack Version 5.X)

Purpose

Organic Response system relies on Wirepas as its RF communication protocol. Similar to firmware versions in OR, Wirepas releases upgrade in terms of stack. A similar stack upgrade is released by Wirepas recently which has offered us opportunites to develop new features and make significant improvements to existing features. An example of this is new method of wireless linking which will be introduced in 2022.1 release. The purpose of this document is to provide guidance towards what to expect with a change of stack and to understand how it effects both communication within OR and your existing or upcoming projects.

Stack Versions

All our sensor node SN3.X come with their own dedicated nordic versions which utilise a specific version of stack. All RF communication in Organic Response are dependant upon which stack version is running on the nordic of each sensor node. Here is the list of stack version that we have utilised so far

1. Stack 3.2.0 - Only released in SN2 and very early version of backpacks

2. Stack 3.4.46

3. Stack 4.0.5

4. Stack 4.0.64

5. Stack 4.0.68

6. Stack 5.1.0.97 - Upcoming release 2023.1 (Feb 2023)

Stack Intercompatibility

Different stack version may or may not be able to communicate with one another, in order to clarify kindly see the information in form of a compatibility matrix below,

An easier way to remember would be by checking the major in each revision. As an example “3“ is major in 3.4.46 while “4“ is major in 4.0.5 revision number. Whenever a major changes the wirepas communication will not be able to operate across any other stack major. In other words any versions from the stack of “4” will be unable to communicate with 3.x.x or 5.x.x.

While a stack 4 sensor node is compatible to work over IR with a stack 5 node, the few features which are dependant upon RF communication will not be intercompatible. These features are outlined in the OR feature release matrix (for comprehensive view click here) which outlines a particular nordic or PIC version requirement for each feature. We will update the information to include new firmware versions once we are closer to the release dates.

Stock Management

Since the release 2022.1 will have a major stack change we recommend all partners to establish a way to distinguish newer version of sensor nodes from older version.

1. Avoid mixing these nodes with older version of stack 3.x.x or 4.x.x sensor nodes as they cannot be used interchangeably.

2. It is recommended to maintain some stock at hand for older version to account for replacement needs on existing installations with old stack version of 4.x.x or lower.

3. In certain circumstances where it is not possible to deliver older version for existing project please ensure to maintain the installation such that the different stack version of sensor nodes are not dispersed in the installation randomly. Instead ensure that all stack 4.x.x or lower version nodes are installed together while all stack 5.x.x nodes are installed separately.

In case where a mix of nodes has to be deployed please engage OR Technologies through service desk early on to prepare a plan for carrying out any upgrades. Please note that you may require to install more or additional gateways in some cases to provide enough network coverage.

Firmware Upgrade / OTAP

In addition to general upgrade requirements laid out in this article to carry out or prepare for over the air upgrade it is important to note that with a stack (major) change the upgrade process can have additional requirements or considerations laid out below,

1. A sensor node can only become part of a network if it has the same stack version as the rest of the network. With a major stack change from (current) 4.x to (upcoming in 2022.1) 5.x there is a break in communication between 2 stacks. It means on Wirepas network/RF the 2 different stack sensor nodes can't communicate with one another.

2. Although a stack of 4 nodes can be upgraded/OTAP to stack 5 but a stack of 5 sensor node can't be downgraded remotely to stack of 4. This is the same pattern as observed between stack of 3.x and 4.x sensor nodes.

3. When there are mix of nodes introduced on site randomly the network can become very distributed thus resulting in the upgrade to become unsuccessful or tedeous to manage. A gateway can only belong to a stack at a time and can only reach nodes in its own network that are physically close to it.

4. Where a mix of installation is expected every effort must be made to ensure that the all nodes from a stack are all installed in the same area or on the same floor such that they can form their own network. This is to avoid moving of gateways physically closer to different stack sensor nodes to reach them and carry out an upgrade.

5. Each area of network will require access to the gateway to upgrade them all to become part of the same network. This could mean that the gateways will need to be physically moved around until all the nodes become part of the same network.

As you can see that introducing multiple stack network can cause quite a few challenges. Therefore it recommended to maintain a clear distinction between sensor nodes from different stack versions.