Enter-Exit locations with BLE zone anchors
Learn how BLE tag locations records are generated as they enter and exit the scanning range of BLE zone anchors.
What are Enter and Exit locations?
For each location record stored in the Sensolus platform, the type of a trigger event is stored because this gives meaning to a series of individual locations. For example, trackers with an embedded accelerometer can indicate that a location record was caused by a START or a STOP trigger. Using this trigger data, more accurate journey information can be provided to users, compared to when just having periodic location records.
With BLE tag tracking, there are some limitations and specific solutions on how locations are interpreted.
- BLE tags are simple devices, and they cannot indicate the start or end of a relocation. Some server-side processing is needed to give meaning to tag movement.
- BLE tag scanning, by design, consists of very frequent periodic scanning of tags. Without extra logic, this would generate a long list of periodic location points that are hard to interpret. The platform will collapse repeated scans into one record; remembering the first time the tag was observed as an ENTER event.
- When BLE tags are outside the range of any scanning device, the location is not known anymore. The platform will mark BLE tags that are not observed anymore as an EXIT event.
- It's not uncommon that a BLE tag is occasionally missed by a scanning sweep of a zone anchor, which would lead to "noise" in the location records while not real asset movement took place. The platform avoids excessive EXIT events by waiting several scan intervals before marking an EXIT event.
In short, ENTER-EXIT mode provides meaning to repeated individual BLE tag scans, and also provides a way to visualize when BLE tags are out of range of any scanning device.
Enter - Exit rules
Enter - Exit logic operates on the following principles:
- Whenever a tag comes into range of zone anchor, it will only store a location the first
time it was seen. The location records is marked with an 'ENTER' trigger. Repeated scans are
not stored as new location records.
- When a tag is no longer detected by the zone anchor, the platform will only generate an
'EXIT' location record after a period of at least 3 times the scanning interval of the zone
anchor has expired.
This '3 x scanning interval' delay is used to avoid noise due to occasional scanning misses. If there was indeed an occasional scan miss, and the tag is reported again on the second scanning interval before expiring, then the timer is reset, and another 3 consecutive scans with detection must occur before exit.
It becomes a bit more complex when a tag is in range of two zone anchors (which is a common scenario when using multiple anchors to cover a larger storage room). The platform needs to avoid to continuously moving between each anchor as it reports a tag observation (that would lead to a continuous 'ping-pong' between locations).
- When a tag is detected by two (or more) zone anchors around the same time, then the BLE tag can only be claimed by a 'new' zone anchor until the platform has declared an exit event (after 3x interval non-observations by the 'old' zone anchor). This generates some "stickiness": the tag will remain at one zone anchor.
- An exception to this rule is made when the BLE tag is recorded at a significantly stronger RSSI value,compared to the last RSSI strength of the older zone anchor. Currently for ZA3505, this threshold is hard-coded at a 15db difference. For ZA3500, it is a configurable value.
The Entry/exit mode of a zone anchor is the configuration of the anchor where the anchor scans for a certain time (set in the Scan interval setting - by default every 5 minutes) for trackers in its environment. The anchor will send every 5 minutes a list of seen trackers to the platform.
Overlapping zone anchors
When using multiple zone anchors, the BLE radiuses will typically overlap. Hence, a tag will be reported by multiple anchors at once.
To avoid tag locations continuously 'jumping' from one to another anchor, you can adapt the RSSI threshold in the user interface.
The strongest RSSI strength takes precedence. An additional threshold is added to the comparison, to counter RSSI fluctuations. The platform will only update to the newer anchor location if the RSSI is stronger than the older RSSI, and the RSSI difference is larger than the configured threshold.