WPE 1.3.x, 1.4.x, 1.5.x, 1.6.x, PosApp, PosLib
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.
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.
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.
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.
v1.4.0, v1.5.0, v1.6.0, v1.7.0
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.
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.
v1.4.0, v1.5.0, v1.6.0, v1.7.0
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.
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.
v1.3.1, v1.4.0, v1.5.0, v1.6.0, v1.7.0
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
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.
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.
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.
The recommended production mode for tags is NRLS and for anchor opportunistic. These modes are not affected by the error observed in autoscan mode.
1st version of Wirepas Positioning Engine Errata document (with POSAPP-62)
Added new errata: POS-298, POS-327, POS-334 and POS-360
Updated POS-360 by adding v1.5.0 to the list of Affected Versions (Errata)
Added new errata: POS-541, POS-542
Updated POS-360 by adding v1.6.0 to Affected Versions (Errata)
Added new errata: POS-545
Added new errata: POS-473 and POS-473
Updated POS-545 by adding v1.7.0 as Fix Version (Errata)
Copyright © 2024 Wirepas Oy