Wirepas firmware v.3. User Guide

Wirepas Mesh 2.4GHz

Wirepas Mesh 2.4GHz is a wireless connectivity technology for massive IoT. Wirepas Mesh 2.4GHz running in the devices enables a scalable, reliable, and cost-efficient IoT solution.

The network provides one horizontal connectivity layer for all IoT use cases: collect data from your sensors to an IoT application in the cloud, control remotely located devices, communicate device-to-device in the network with or without cloud and track the location of moving assets.

All the networking intelligence is included in the Wirepas Mesh 2.4GHz software to form a resilient large-scale wireless network.

Wirepas Positioning Engine (WPE)

Wirepas Positioning Engine (WPE) is an RTLS solver which computes the position of mobile devices based on the position of Fixed Anchors.

Thanks to Wirepas Mesh 2.4GHz it allows to deploy fully battery-operated infrastructure of Anchors used both as locators and routers.

WPE is a stream-based processing engine which provides a position (WGS84 / GPS) for every measurement taken by the asset.

WPE uses RSSI based trilateration and supports services to:

• Declare Anchors
• Declare Buildings, Areas, Floors, Zones
• Provide Tag position with matching of Building, Floor, Zone

WPE offers an open API based on MQTT or GRPC. WPE can be run on any cloud.

BlueUp Positioning Engine (BPE)

BlueUp Positioning Engine (BPE) is a IPS software based on RSSI and trilateration. It supports several technologies, including Wirepas Mesh 2.4GHz tags. MeshIPS is based on mesh infrastructure, where Wirepas anchors are used for positioning reference and Wirepas tags are used for tracking and locating people, assets, vehicles, …

BPE can be installed on a local server. Communication between BPE and host application is implemented using standard HTTP JSON REST APIs. MQTT server support is also available.

Wirepas-enabled positioning application

BlueUp positioning application for Wirepas-enabled devices runs on both moving tags and anchors. BlueUp positioning application introduces a series of advanced functionalities and allows to manage the positioning interval of moving tags on the basis of motion status (detected by the accelerometer), in order to get an optimal compromise between energy consumption (i.e. battery life) and refresh rate. Positioning app also allows to configure optional BLE beaconing functionality.

Positioning application Finite-State Machine for moving tags

BlueUp positioning application implements a Finite-State Machine (FSM) for moving tags, based on 4 different states:

DEFAULT: startup and default operating state of the tag, with a configurable positioning interval P1. If the accelerometer is not enabled and alarms are not triggered (e.g. button not mounted) tag remains in DEFAULT state permanently. Tag exits from DEFAULT state when motion is detected (entering MOTION state) or when an alarm is detected (entering ALARM state) or when no motion is detected for T1 interval (tag enters SLEEP state).

MOTION: state triggered by motion detection from the accelerometer. When motion is detected (3-axis acceleration over a configurable threshold THR), tag enters MOTION state, with a positioning interval P2, and remains there until the timeout T2 expires (with T2 configurable). After T2, if no motion is detected, tag returns in DEFAULT state. When accelerometer is not enabled, tag never enters MOTION state.

ALARM: state triggered by detection of an alarm condition (i.e. button pressed, man-down, shock detected). When an alarm is detected tag enters ALARM state, with a positioning interval P3, and remains there until the timeout T3 expires (with T3 configurable). After T3, if no motion is detected, tag returns in DEFAULT state, otherwise it returns in MOTION state. When alarm cannot be triggered, tag never enters ALARM state.

SLEEP: state mainly used for tag storage or for tracking tags with extremely long periods of absence of motion. When tag is in DEFAULT state, it enters SLEEP state when no motion is detected for at least T1 period (with T1 configurable). In SLEEP state tag has a configurable positioning interval (suggested value equal or higher than 24 hours). Tag exits from SLEEP state when motion is detected (entering MOTION state) or when an alarm is detected (entering ALARM state). If the timeout from DEFAULT state is set to 0 or if accelerometer is not enabled, tag never enters SLEEP state.

ALARM state has the highest priority. Possible ALARM events are:

• Button pressed (single short press, single long press, double press)
• Horizontal position detection
• Free-fall detection
• Shock detection
• Man-Down detection

The following scheme highlights individual states and state transitions. The FSM parameters are configurable (either in production or using Application Data Configuration).

The parameters of the finite state machine are:

State Packet

Each time a state-transition is triggered a network scan is performed and a dedicated custom data message is sent to the MQTT broker over the mesh network.

Data message is sent on source/destination endpoint 73/73.

Tag State Packet format

Anchor Tag Configuration Packet format

Quuppa emulation - if enabled

iBeacon - if enabled

Safety - if enabled

Eddystone UID - if enabled

Mobile Tag Configuration Packet format

Beaconing - Quuppa Emulation mode

Beaconing - iBeacon

Beaconing - Safety

Beaconing - Eddystone-UID

Accelerometer - Motion Detection

In this mode the accelerometer will recognize whether the tag is still or moving.

The configuration parameters are:

• Movement detection threshold (units of 16mg) - Range [1, 127] - Defines the intensity of movement. Acceleration needs to be greater than the threshold to detect movement. In real world physics, this value can be expressed in mg units, knowing that 1 LSb = 16 mg (1 mg = g / 1000, g is the gravitational acceleration).
• Movement detection duration (seconds) - Range [0, 255] - Defines the minimum time period for which the acceleration must be greater than the threshold.

Accelerometer - Position Detection

In this mode the accelerometer will recognize tag position changes: vertical position or horizontal position of the tag. The horizontal / vertical position is detected against the accelerometer Z axis, that is the axis orthogonal to the device board.

The configuration parameters are:

• Angle (degrees) - Range [1, 90] - Defines the angle that the board uses to detect the horizontal / vertical position.
• Position detection duration (seconds) - Range [1, 255] - Defines the minimum time period that the device should be stable in the position.

Accelerometer - Position + Motion Detection

Accelerometer - Freefall Detection

In this mode the accelerometer will recognize tag freefall events.

The configuration parameters are:

• Minimum fall height (centimeters)
  • Range [50, 255]
  • Defines the minimum fall height for which the freefall will be recognized at the lowest sensitivity. Any fall below this height won’t be detected.
• Sensitivity (units of 50mG)
  • Range [1, 10]
  • Defines the sensitivity to use for freefall detection.
    A low sensitivity will recognize only freefall events very close to the 0g acceleration – lowering the probability of false positives, but increasing the probability of missing detection.
    A high sensitivity will be more permissive with freefall detection – this will increase the probability of false positives but decrease the missing falls detection.

Accelerometer - Freefall + Motion Detection

Accelerometer - Shock Detection

In this mode the accelerometer will recognize an unexpected strong acceleration of the tag.

The configuration parameters are:

• Shock intensity (units of 50mg)
  • Range [1, 10]
  • Defines the intensity to be recognized as a shock. Min = 1: small shock detected; Max = 10: only big shocks are detected
  • The shock intensity starts from 1500 mg, following the equation

Accelerometer - Shock + Motion Detection

Important notes

• Positioning rate P4 in SLEEP state is strongly suggested to be set to a relatively high value, such as 1 per day or less frequently

• When positioning rate is set less then 60 seconds the tag automatically enters Autoscan mode. Please be aware of energy consumption since in Autoscan mode the tag maintains the connectivity to the network (see below for details on various tag/anchor modes).

• Carefully take into consideration your use-case to program the parameters positioning interval (P1, P2, P3, P4), timeout (T1, T2, T3) and accelerometer threshold THR, in order to avoid excessive energy consumption (due, for instance, to too-short positioning interval or too-long timeout values or extremely-low accelerometer threshold that triggers unwanted movement detection). Not properly designed values could impact on battery operating life.

• Consider that each time a state transition occurs, a network scan is performed: avoid configurations that could lead to excessive state transitions.

BLE Beaconing

BLE beaconing can be enabled on both moving tags and anchors. Enabling BLE beaconing allows to manage advanced functionalities such as:

• hybrid RTLS system with sub-areas covered with specific antenna systems such as Quuppa RTLS platform or BlueUp ZoneRTLS platform (beaconing enabled in moving tag);
• enabling proximity detection systems for smartphone-based applications (beaconing enabled in anchors).

Beaconing functionality is disabled by default (unless requested in production), and can be enabled and configured with Application Data Configuration.

Mobile Tag Beaconing

BlueUp firmware introduced specific support for different BLE packet types:

• Quuppa Emulation Mode: packet format compatible with Quuppa localization platform, allows a sub-meter accuracy;
• iBeacon: standard BLE advertising format specified by Apple for proximity applications;
• Safety: BlueUp proprietary format, using iBeacon format with minor number used for broadcasting tag internal information like battery voltage, motion status, button pressure, …

In case of moving tags, beaconing follows the same FSM behavior of the figure above: advertising interval ADVn (n=1,2,3,4) and transmission power TXn (n=1,2,3,4) vary depending on tag state (DEFAULT, MOTION, ALARM, SLEEP) and are configurable.

Anchor Tag Beaconing

BlueUp firmware introduced specific support for different BLE packet types:

• iBeacon: standard BLE advertising format specified by Apple for proximity applications;
• Eddystone-UID: BLE packet format specified by Google.

In case of anchor tags, DEFAULT-state beaconing settings are used.

Sensors Packet Structure

BlueBeacon Wirepas FW v.3 supports Sensors packet frame type. The BlueBeacon Wirepas Ultra Deluxe is the most suitable device for Sensing purpose and, at the moment, is equipped with temperature, humidity, pressure and CO2 sensors.

Data message is sent on source/destination endpoint 238/238.

The following table contains the Sensor Packet format.

Data is an array of array of Sensor Data Structures.

Each Sensor Data Structure has the following format:

Since the hardware board can have multiple sensors that are measured simultaneously, Sensor Packet Data can be interpreted as an array of Sensor Data Structures, one for each measured sensor, i.e.:

SENSOR_TYPE_1, SENSOR_ID_1, SENSOR_DATA_1, SENSOR_TYPE_2, SENSOR_ID_2, SENSOR_DATA_2, SENSOR_TYPE_3, SENSOR_ID_3, SENSOR_DATA_3, ...

Sensor Types Table

Sensor IDs Table

Sensor Types / Data Table

Operation Modes

Two operating modes are dedicated to tag (Autoscan and NRLS) and two operating modes are dedicated to anchors (Opportunistic and Autoscan).

Tag: NRLS mode

In the non-router long sleep mode (NRLS) the tag is in sleep mode between two measurement updates. The tag will wake-up at periodic configurable intervals and: perform a network scan, connect to WM, send the collected measurements, receive application configuration, disconnect from WM and finally change to sleep mode.

In this mode the positioning app does not trigger a network scan and the scan performed by the WM stack (required for establishing the connectivity) is used for collecting the RSSI measurements.

Even if in NRLS mode the tag maintains connectivity only as long as is required to deliver the measurements there are two advantages: power consumption is reduced given that the tag is in sleep mode most of the time and the connection slot to the WM is freed allowing more tags to be served by the same anchors.

The disadvantage is that the tag cannot receive data while in sleep. The application configuration is used to provide configuration updates to the tag at wake-up.

NRLS mode is the recommended mode for a standard asset tracking tag.

Tag: Autoscan mode

In the autoscan mode the tag is a standard low-energy subnode. The tag will detect the WM and connect to the best available router in the vicinity. Connectivity to the WM is maintained as long as possible throughout the lifetime of the tag. As the tag is continuously connected, it is possible to send and receive data messages at any moment.

At periodic configurable intervals the positioning app running on the tag will trigger a network scan to detect and collect RSSI measurements. Once the measurements are collected the tag will send them though a data packed towards the sink / gateway / backend.

Autoscan mode is recommended in use cases where the tag has to be connected all the time to the WM i.e. there is the requirement to send and receive data packets at random times. This is not the typical use case for a standard asset tracking tag and is usually used only when the positioning app is expanded with additional functionality.

Since the tag in Autoscan mode maintains the connectivity, the power consumption is higher than in NRLS mode especially when the tag is moving around.

For this reason its use is recommended only in special use cases.

Anchor: Opportunistic mode

An anchor (router) is connected at all times to the WM network. For the purpose of maintaining the connectivity the WM stack will perform network scans in order to detect headnodes/sinks in the vicinity. The positioning app will collect and send the measurements generated by these scans, thus the opportunistic mode. Given that the positioning app does not trigger additional scans, the power impact on the anchor is minimal (only the cost of sending a data packet).

The opportunistic mode is the recommended mode to be used for an anchor.

Anchor: Autoscan mode

The behavior of the anchor Autoscan mode is identical to tag autoscan mode. It was added for research and development and is not recommended to be used in a production system.

Configuration over Wirepas network

It is possible to modify configuration parameters of the tags and trigger specific actions (like switching ON and OFF of LED, vibration, buzzer, …) by using the “Application Data Configuration” for the Wirepas network.

Commands have the following syntax: [Class] [Type] [Length] [Value] where each field is described in the following.

[Class] enables to differentiate among tag groups, if necessary.

By default, the “Class” is assigned to BlueUp tags and anchors according to the following table:

Sent commands are addressed to one or more Class(es). It is required to know the tag Class for sending commands.

Custom Class can be applied to tags/anchors in production, based on customer specifications. Custom Class must be specified when ordering.

[Type] identifies the chosen functionality or parameter to modify. [Length] defines data size (in bytes). [Value] to be updated or activation/deactivation data.

Anchor Tag Configuration command

Max TxPower

Beaconing - if enabled

iBeacon - if enabled

Eddystone-UID - if enabled

Mobile Tag Configuration command

Accelerometer Modes Parameters

The default values of the parameters are listed below. In case of MANDOWN Detection Mode, the additional parameters are:

• Debounce Duration [0, 255] sec = defines the maximum time interval in which the body of the fallen person or of the object bounces when hit on the ground.
• Stationary Duration [0, 255] sec = defines the minimum time interval in which the body or the object should remain stationary on the ground to detect the ManDown event.
• Alert Duration [0, 255] sec = defines the Alarm duration time interval, after the ManDown event has been detected, during which the tag emits an alarm sound and after which the tag starts sending data about the ManDown event detection. If the Alert Duration is equal to 0 the tag starts sending ManDown detection data immediately. If the Alert Duration is set to a non-zero value, the tag will wait for Alert Duration time to send data and at the same time will emit an alarm sound. If the alarm is disabled by button during this time, it means that it was a false detection and the tag will not send ManDown detection data.

Motion Detection

Position Detection

Position + ManDown Detection

Freefall Detection

Freefall + ManDown Detection

Shock Detection

Shock + ManDown Detection

Accelerometer Modes default parameters values

Motion Threshold equal to 10 is a sufficient value for both asset and people tracking to not to have false movement detection even if the tag is worn pendent around the neck and there are small oscillations of the tag.

Beaconing - if enabled

Common parametres in case beaconing is enabled

Quuppa - if enabled

iBeacon - if enabled

Safety - if enabled

IMPORTANT NOTES

• A sent command is persistent in the network. Each tag in the network receives this command (if the tag Class coincides with the Class in the command), and each new tag entering the network (with Class coinciding with that of the command) also receives the command.

• Each configuration command SHOULD include command for Mobile Tags (Type = 0xB2; default Class = 0xFA) and command for Anchor Tags (Type = 0xA2; default Class = 0xF9). Since the command is persistent on the network, any new tag (either Mobile or Anchor Tag) entering the network, will receive the configuration command. If only one type of tags (Mobile or Anchor Tags) needs to be updated, the configuration command SHOULD be sent also for the other type of tags (Anchor or Mobile Tags), by simply using the previous command settings.

• A tag operating or configured for NRLS mode will receive the command and apply it only upon wake-up (during connection to the mesh network after scan for nearby anchors). Consequently, maximum time delay to receive command is equal to the configured positioning period.

Commands over Wirepas Network

The following paragraphs describe the BlueUp packet specifications for sending commands over Wirepas Network to a Wirepas Node.

Data message is sent on source/destination endpoint 73/73.

Reboot (0xB0)

This command is used to Reboot a Node.

API example to Gateway/api/sink/data1/sendMessage:

{
 “dst_addr” : 4000000,
 “src_ep” : 73,
 “dst_ep” : 73,
 “buffering_delay” : 1,
 “qos” : false,
 “is_unlock_csma_ca” : false,
 “hop_limit” : 15,
 “data” : [176, 0]
 }

Factory Reset (0xB1)

Button Configuration (0xB2)

This command is used to enable or disable the button on a device.

API example to Gateway/api/sink/data1/sendMessage:

Type: 178 Length: 1 Value: 1 (Button enable)

{
 “dst_addr” : 4000000,
 “src_ep” : 73,
 “dst_ep” : 73,
 “buffering_delay” : 1,
 “qos” : false,
 “is_unlock_csma_ca” : false,
 “hop_limit” : 15,
 “data” : [178, 1, 1]
 }

Alert Configuration (0xB3)

Node Alarm configuration (led / buzzer / vibration).

Leds Color / Enable Mask

API example to Gateway/api/sink/data1/sendMessage:

Type: 179

Length: 10

Value: 0, 0, 0, 0, 0, 0, 10, 5, 50, 66

• Leds Period: 10 (100ms)
• Leds Repeats: 5
• Leds DutyCycle: 50 (%)
• Leds Color/Enable Mask: 66 = 0x42 =0b 0100 0010
  • Color: RED
  • Enable/Mask: LED1

{
 “dst_addr” : 4000000,
 “src_ep” : 73,
 “dst_ep” : 73,
 “buffering_delay” : 1,
 “qos” : false,
 “is_unlock_csma_ca” : false,
 “hop_limit” : 15,
 “data” : [179, 10, 0, 0, 0, 0, 0, 0, 10, 5, 50, 66]
 }

Accelerometer Configuration (0xB4)

To the underlined Accelerometer Modes (Position + Motion_Detection, Freefall + MotionDetection, Shock + Motion_Detection) it is possible to optionally add the MANDOWN Detection Mode. The additional parameters are:

• Debounce Duration [0, 255] sec = defines the maximum time interval in which the body of the fallen person or of the object bounces when hit on the ground.
• Stationary Duration [0, 255] sec = defines the minimum time interval in which the body or the object should remain stationary on the ground to detect the ManDown event.
• Alert Duration [0, 255] sec = defines the Alarm duration time interval, after the ManDown event has been detected, during which the tag emits an alarm sound and after which the tag starts sending data about the ManDown event detection. If the Alert Duration is equal to 0 the tag starts sending ManDown detection data immediately. If thw Alert Duration is set to a non-zero value, the tag will fait for Alert Duration time to send data and at the same time will emit an alarm sound. If the alarm is disabled by button during this time, it means that it was a false detection and the tag will not send ManDown detection data.

Power Down

Motion Detection

Postion Detection

Position + Motion Detection

Freefall Detection

Freefall + Motion Detection

Shock Detection

Shock + Motion Detection

GPIO Pin Configuration

GPIO Mode

API example to Gateway/api/sink/data1/sendMessage:

Type: 181

Length: 2

Value: 0, 17

• GPIO ID: 0
• GPIO Mode: 17 = 0x11 = 0b 0001 0001
  • Output: 1
  • Value: 1 (High)

    {
     “dst_addr” : 4000000,
     “src_ep” : 73,
     “dst_ep” : 73,
     “buffering_delay” : 1,
     “qos” : false,
     “is_unlock_csma_ca” : false,
     “hop_limit” : 15,
     “data” : [181, 2, 0, 17]
     }
    

Other API example to Gateway/api/sink/data1/sendMessage:

Type: 181

Length: 2

Value: 0, 128

• GPIO ID: 0
• GPIO Mode: 128 = 0x80 = 0b 1000 0000
  • Reset: 1

    {
     “dst_addr” : 4000000,
     “src_ep” : 73,
     “dst_ep” : 73,
     “buffering_delay” : 1,
     “qos” : false,
     “is_unlock_csma_ca” : false,
     “hop_limit” : 15,
     “data” : [181, 2, 0, 128]
     }
    

Other API example to Gateway/api/sink/data1/sendMessage:

Type: 181

Length: 2

Value: 0, 12, 5

• GPIO ID: 0
• GPIO Mode: 12 = 0x0C = 0b 0000 1100
  • Output: 0
  • PullCFG: 3 (PullUp)
• GPIO Send Interval: 5 min

The H/L Logic Level is sent every time a logic level transition HL/LH occurs and also every 5 minutes.

{
 “dst_addr” : 4000000,
 “src_ep” : 73,
 “dst_ep” : 73,
 “buffering_delay” : 1,
 “qos” : false,
 “is_unlock_csma_ca” : false,
 “hop_limit” : 15,
 “data” : [181, 3, 0, 12, 5]
 }

Sensors Configuration (0xB6)

Sensors Measure Interval configuration.

Sensors Calibrate (0xB7)

If available, performs a CO2 sensor calibration.

If Length is set to 0 or Target CO2 is set to a value below the minimum (400 ppm), the calibration is performed with a Target CO2 value = 400 ppm.

The CO2 will be calibrated by a pre-calibrated CO2 measurement instrument, which will measure a variable CO2 within the ranges [400, 1600, .. max 2000] ppm.

Send Configuration (0xB8)

This command is used to request the current Node Configuration.

5.10. Send Positioning (0xB9)

This command is used to request the current Node Positioning Data.

Firmware update using Wirepas Network Tool (WNT)

The Firmware update can be performed using WNT v4 in Settings → Node Update. The Firmware Update operation can take some time to complete.

In the Scratchpad File field upload the otap file provided by BlueUp.

In this tab it is also possible to require the information about the nodes. By pressing the Run once button in Query Information.

After performing this operation, the WNT controls all the nodes and updates the information fields, as shown in the screenshots below.

If there is “No otap” in Scratchpad Action field, this means that there is no otap pending in the network and the Firmware Update can be performed.

After pressing Continue, figure below will appear.

In the Scratchpad File Information, the Version refers to the FW version to be uploaded.

To start the otap procedure, press Start scratchpad status query.

After the first step is completed (Responses: 1 / 2) the client has to choose the update method. The method to use is OTAP v2, for which the firmware was designed, that performs the update of the firmware automatically.

After the Propagation Step is completed, looking at the information of the Sink and the Nodes, the Scratchpad Action on the Sink is “Propagate and Process”, while on the Nodes is “No otap”. This means that the otap file has reached the Sink and it has to be propagated to the Nodes.

After all the operations are completed, the Sink and Nodes tab contains updated information.