Status | Date | Doc Version | Applicable | Confidentiality |
RELEASE | 17 Feb 2025 | v1.8 | WPE 1.3.x, 1.4.x, 1.5.x, PosApp, PosLib | PUBLIC |
General Information
This document collects the Wirepas Positioning errata. The document is updated when new errata item is added, or the errata item is updated either work around or information on fix for Wirepas Positioning release. Revision history summarizes all the updates to this document.
Severity has three levels: Low, Medium and High. Severity is provided just for information to understand the impact on Wirepas Positioning functionality or performance. The workaround outlines if there is a way to overcome the bug visible in Affected Versions (Errata). The Fix Version (Errata) indicates the version where the errata item is resolved (possible workaround is not anymore needed).
Revision history summarizes all the updates to this document.
Errata Summary
Key | Errata Title | Errata Description | Errata Severity | Affected Versions (errata) | Fix Version (errata) | Errata Workaround Exists? | Errata Workaround Description |
Deleting a single network break the area matching for shared areas | When network is deleted/purged also internal area (zone) bounds information is deleted from the other networks. This happens when the area has not been bound into any specific network, but is used by all the networks (for example WNT defines areas in this way). In this case, the deletion of some network leads to a situation, in which nodes from other networks are not anymore located into the floor plan(s) where there were shared areas. | High | v1.6.0 | v1.7.0 | Yes | The issue can be fixed by restarting the WPE services, which will cause the area information to be refreshed from WNT. Please note that if WPE is used in a stand alone mode, then issue can be fixed by configuring the area information again. | |
Area deletion does not work correctly if there are multiple networks configured into WPE | It is possible to configure multiple networks into WPE by adding anchors or areas that are linked to different networks. In such case, if area deletion is called without specifying the network (as done by WNT), the area is deleted only from the common and the first network’s data structure. This causes that the tags might be still located within the “already deleted” area in the rest of the networks. This will cause exception inside WPE, as the data structures are not in-sync. | Medium | v1.6.0 | v1.7.0 | Yes | The issue can be avoided by restarting the WPE services after areas have been deleted. | |
Calculated tag floor might differ from the floor of the matched area | WPE may locate tag to a certain floor and simultaneous match it to and area in a different floor. This kind of situation might occur since tag location calculation and area matching use only the (currently 3) strongest anchors, while floor matching algorithm uses all the anchor information provided in the measurement. The described situation is expected to be unusual and may occur only if the anchors in different floors are densely deployed and overheard without too much of radio signal attenuation between the floors. | Medium | v1.4.0, v1.5.0, v1.6.0, v1.7.0, v1.7.1 |
| No | For the calculation logic there is no direct workaround. However, client system can build logic to check if the area and floor information provided by the WPE is coherent to recognize potential problems with the logic. | |
Backend location calculation time is returned as timestamp if WPE is not able to calculate location | WPE will return backend location calculation time, instead of measurement timestamp, when it is not able to calculate location. | Low | v1.6.0, v1.7.0 | v1.7.1 | No | - | |
Floor matching has limited support for scenarios where some anchors are located on floors and some not | Current WPE floor matching has limited support for situations, where some anchors are located within buildings and floors and some not (in which case they are located e.g. to WNT “world map”). This kind of configuration is not supported, if such anchors with mixed floor and non-floor configuration are within the same radio range. In such cases, WPE locates the tags to a floor within a building, even if the actual calculated location might be correctly outside the building / floor. | Low | v1.4.0, v1.5.0, v1.6.0, v1.7.0, v1.7.1 |
| Yes | If there is a need to have a configuration, where all the anchors are not located on building floorplans, the suggestion is to create a “background” floor for the surrounding areas and attach those anchors that are not in other floorplans to that. | |
Incorrect measurement time | When using WPE with WNT the reported measurement time is not set correctly for all the calculated locations. This is due to WPE using the first measurement time for all the measurements in a batch. This can cause relatively big error in the measurement time value due to different latencies for the messages in the mesh network. | Low | v1.5.0 | v1.6.0 | No |
| |
WPE: SSL error | In some rare occasions ssl_transport_security.cc can trigger an error: OPENSSL_internal:WRONG_VERSION_NUMBER This is a known error of the gRPC library (open Issue #9538). The library will be updated once a fix for this issue exists. In case of occurring WPE will have to be restarted. | Low | v1.3.1, v1.4.0, v1.5.0, v1.6.0, v1.7.0, v1.7.1 |
| No |
| |
WPE: TLS connection to MQTT does not work | Setting up a TLS connection to MQTT from WPE does not work because of lack of CA root certificates in the WPE Docker image | Low | v1.3.1 | v1.4.0 | No |
| |
WPE: Area definition always requires "uid" field | Area configuration does not allow to use only uuid (string) and requires that uid (uint64) field is also defined. | Low | v1.3.1 | v1.4.0 | Yes | The field uid must be defined | |
WPE: When configuration from WNT is disabled areas are still injected | When configuration form WNT is disabled areas can still be injected by from WNT. | Low | v1.3.1 | v1.4.0 | No |
| |
PositioningApp: incomplete measurements in autoscan mode | Due to a potential race condition in autoscan mode the measurement set can in be incomplete in some random instants. This can result in higher position error than expected. | Medium | v5.0.0 | v1.2.1.2 | Yes | The recommended production mode for tags is NRLS and for anchor opportunistic. These modes are not affected by the error observed in autoscan mode. | |
Wrong calculation of rssi when rssi table is full. | Wrong calculation of rssi when rssi table is full. | High | SDK 1.5.x, SDK 1.4.x, SDK 1.3.0, SDK 1.2.x | SDK_2_4 v1.5.4 | Yes | Ensure tags see less than 14 anchors or use memset on m_meas_table.beacons[insert_idx] before reusing the entry. |
Revision History
Date | Version | Notes |
21 Jan 2021 | v1.0A | 1st version of Wirepas Positioning Engine Errata document (with POSAPP-62) |
08 Jun 2021 | v1.1 | Added new errata: POS-298, POS-327, POS-334 and POS-360 |
30 Sep 2021 | v1.2 | Updated POS-360 by adding v1.5.0 to the list of Affected Versions (Errata) |
13 Apr 2023 | v1.3 | Added new errata: POS-541, POS-542 Updated POS-360 by adding v1.6.0 to Affected Versions (Errata) |
03 Oct 2023 | v1.4 | Added new errata: POS-545 |
04 Jan 2024 | v1.5 | Added new errata: POS-473 and POS-554 Updated POS-545 by adding v1.7.0 as Fix Version (Errata) |
01 Aug 2024 | v1.6 | Updated POS-541, POS-542 and POS-360 by adding v1.7.1 to Affected Versions (Errata) Updated POS-558 by adding v1.7.1 as Fix Version (Errata) |
12 Feb 2025 | v1.7 | Added new errata: POSLIB-84 |
17 Feb 2025 | v1.8 | Updated POSLIB-84 with affected versions |
Legal Notice
Use of this document is strictly subject to Wirepas’ Terms of Use and Legal Notice.
Copyright © 2025 Wirepas Oy