BlueUp Wirepas Firmware
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:
| Parameter | Definition |
|---|---|
| P1 | Positioning interval in DEFAULT state |
| P2 | Positioning interval in MOTION state |
| P3 | Positioning interval in ALARM state |
| P4 | Positioning interval in SLEEP state |
| T1 | Timeout in DEFAULT state (to enter SLEEP state) |
| T2 | Timeout in MOTION state (to return in DEFAULT state) |
| T3 | Timeout in ALARM state (to return in DEFAULT or MOTION state) |
| THR | Accelerometer threshold (to detect movement) |
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.
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.
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.
