Status

Date

Doc Version

Applicable

Confidentiality

RELEASED

04 Jan 2024

v1.5

WPE 1.3.x, 1.4.x, 1.5.x, 1.6.x, PosApp, PosLib

PUBLIC

Key

errata title

errata description

errata severity

affected versions (errata)

fix version (errata)

errata workaround exists?

errata workaround description

POS-554 

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.

POS-545 

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.

POS-542 

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 

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.

POS-541 

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 

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.

POS-473 

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 

POS-360 

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 

No 

POS-334 

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 

POS-327 

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

POS-298 

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 

POSAPP-62 

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.

Date

Version

Notes

21 Jan 2021

v1.0A

1^st 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-473

Updated POS-545 by adding v1.7.0 as Fix Version (Errata)