Setting up Stationary Bluetooth® Gateways
Table of Contents
Our range of Bluetooth® enabled gateway devices and tags allow for a variety of low-cost asset tracking solutions. See - Asset Tracking With Bluetooth® - Application and Device Guide.
A key use-case is inventory and asset management across multiple sites.
- Gateway devices are placed in warehouses, installed in delivery vehicles
- Bluetooth tags are placed on pallets or boxes of stock
- As the pallet or stock moves around warehouses and in and out of vehicles, the nearest Bluetooth Gateway
automatically reports on its location.
The warehouse scenario is an example of where we need to set up stationary gateways. The context we give to device data is different for the stationary gateway case compared to if the gateway moves about. For example, with stationary gateways we know that if a tag can be seen by a gateway at one time, and then later on it is not in range - that the tag has moved, and not the gateway. We cannot make this assumption if the gateways are moving about. Due to this we need to specifically set the gateway up as stationary. There are a number of configuration options available to suit different logic used on the server. Care needs to be taken as different scenarios can 'confuse' the server - and lead to strange reporting behaviour.
Each of our Bluetooth gateways have subtle differences (discussed in the following sections) which make them suited to particular applications.
||'Default' GPS Position|
|Hawk (BLE Card Coming Soon)||
3.5A Rechargeable LiPo
2 x D Cell LTC Batteries
|Periodic or Continuous||
|G120||8-45V DC Power||Periodic or Continuous||No|
|Remora3||2 x D Cell LTC Batteries||Periodic||Yes|
Bluetooth Card Coming Soon!
The G120 is designed as a vehicle tracking device providing a range of features like accident/rollover, harsh driving, driver ID, speeding alerts etc. The addition of Bluetooth allows for other sensors to be connected e.g. Bluetooth Fuel Level Sensors, and tag location reporting as per the other devices.
The G120 will work well as a stationary gateway if power can be supplied. However it is not the best choice for an indoor stationary gateway - as many events (e.g brief accelerometer activity) can trigger the device to attempt a GPS fix. We want to know the GPS location of a vehicle tracking device, so it tries hard - meaning there is no option to set a fixed GPS position, and the better choice would be an Eagle or Remora2 for this application.
The Remora3 is entirely battery powered - there is no external power option. Due to this there is no option to set the device up to scan continuously for Bluetooth devices, as this would quickly drain batteries. So it is useful to tell us what tags are at a location every hour (or whatever scan interval is set) for example, but can't tell us a tag arrived at an exact time.
The GPS and Tag Data Fields
Those using a 3rd party software platform should consult the integration documents for information on how information about Bluetooth tags appears in the device data. We will refer to them generally here as it helps to understand what parameters impact what bits of the data. We are concerned with 3 data fields:
Field 0 - GPS Data
This is the device location data, as obtained by getting a GPS fix (or set as a parameter as described later).
Field 29 - Bluetooth® Tag List
This is the list of tags sent after a periodic scan is completed - e.g. a Remora3 scans for 15 seconds, every 30 mins, and just reports the list of all tags it could see. Comparing one list to the next lets us work out if tags have been 'found' or 'lost'
There is no time or position information in this field - the time and location of the scan can be worked out from Field 0.
I.e. if 3 tags are in the list in a record, then at that time they were at the device's lat/long.
Whenever a periodic scan is completed, after the scan a GPS fix is attempted and field 0 updated if successful.
Field 30 - Individual Tag Data
Used when scanning continuously. This field contains the lat/long and timestamp of when an individual tag was found or lost (entered/left range of the gateway). If a tag is found or lost a GPS fix will be attempted to update this location information.
Stationary vs non-Stationary Gateway Key Differences
The key difference in device behaviour is which tag RSSI value is logged in Field 29 or 30.
Consider a periodic scan lasting 30 seconds. If the tag is beaconing every 2 seconds - it may be picked up by the gateway 15 times.
Stationary gateways simply report the most recent RSSI value on tag lost/found (i.e just the last chirp seen)
Non-Stationary gateways will report the strongest RSSI seen during the scan interval - this makes it likely that the location of when the tag was closest to the gateway will be sent to the server - i.e. the most accurate position will be shown on a map.
Stationary Gateway Parameter Setup
Bluetooth - Getting Started
Make sure to check out our Bluetooth Getting Started Guide - Bluetooth® Getting Started - Tags & Scanning
As for all Bluetooth functionality, be sure to enable the global BLE parameter
"Default" GPS Position
The Remora3 and the Hawk have the ability to enter a "default" GPS Position. The lat/long is entered as a parameter, and fixes are disabled. The device will simply report the set position with each heartbeat. For those using a 3rd party system - this means the lat/long in Field 0 (GPS Data) will always be reported as the parameter value.
This is ideal for installing a device indoors, as a stationary Bluetooth® Gateway - so that it can scan for and detect Bluetooth® tags. Fixes are unlikely to be able to be achieved indoors and the device will waste power attempting and failing to get one.
To configure, add the Advanced Tracking Tab
- The Tracking Mode must be set to Periodic Tracking Only (it does not make sense to fix the location when tracking trips)
- Set the GPS Fix Multiplier to 0
- Set your Lat and Long.
This option is one of the reasons why the Hawk is preferable as an indoor-powered gateway in comparison to the G120.
Continuous Scanning Stationary Parameters
This is available on the G120. Given the Bluetooth module is scanning continuously for tags, we have a few key concepts:
- We know when a tag is 'Found' - i.e. it cannot be detected and then it suddenly comes into range and is picked up by the gateway. A "Tag Found" log reason is sent by the gateway when this occurs.
- If our gateway is not stationary- a tag may be found if either:
- The tag is sitting still, and the gateway moves near it (i.e. gateway is in a vehicle driving around a site)
- The gateway is sitting still, and the tag moves near it
- They both move towards each other and into range
- If our gateway is stationary - we know that the only time we should get a "Tag Found" log reason is when the tag has moved into the area the gateway is located.
- If our gateway is not stationary- a tag may be found if either:
- We know when a tag is 'Lost' - when after some time it can no longer be seen by the gateway. A "Tag Lost" log reason is sent by the gateway when this occurs.
- The same scenarios apply as for the 'found' example, but in this case the gateway and tag are moving apart. So in the stationary example, getting a "Tag Lost" log reason means that the tag has left an area (if it is still transmitting - i.e. batteries aren't flat, and isn't somehow being shielded)
The continuous scanning parameters are shown below, 1 and 2 are the key parameters for setting up a device as a stationary gateway:
- Set the device as Stationary
- Set a fixed latitude and longitude for the Tag Data (Field 30 for integrators). So the tags will report their position as this Lat/Long in Telematics Guru if this field is set. If the device is easily able to get GPS fixes - it is best left as 0 to use the GPS position. The power consumption of getting a GPS fix isn't a concern for an externally powered device.
- Do we upload when a Tag is Found or Lost? If set to know the records will just be sent on the next upload.
- Tag expiry time - how long without seeing a tag before it is 'lost'
- These filters let us configure how strong/weak the signal needs to be before a tag is considered found or lost.
Periodic Scanning Stationary Parameters
Periodic Bluetooth® scanning is available on the Remora3 and G120.
It is the only option on the Remora3 - since it is battery-powered and continuously scanning would drain the batteries.
It isn't really needed on the G120 - it is just there for completeness.
The final two parameters in the Bluetooth® Tag Scanning tab allow the gateway to be set up as a stationary gateway.
Setting Device is Stationary to Yes results in the behaviour described above - last RSSI value is reported.
Setting Log Tag Lost to Yes means "Tag Lost" logs are generated when a tag drops out of the tag list.
Tag lost and found logs are generated by comparing the list of tags the gateway can see on each periodic scan. If one joins/leaves the list from one scan to the next, a tag is therefore lost or found.
When using multiple gateways in an area, it is best to not enable Tag Lost logs - as this scenario can occur:
- Stationary gateways at site A and B
- Tag is found at site A.
- Tag moves to site B and is found there
- Site gateway A now scans and says the tag is lost
- Server sees the most recent location as the lost location rather than the found location
This scenario would confuse Telematics Guru as it uses the most recent location - but other servers may implement different logic.
Periodic Scan Setup
Now the gateway has been configured as stationary - we can set it up to scan periodically.
Since trips have been disabled, Bluetooth® scans must now be enabled using the below parameters - found under the BLE Tag Scanning parameter tab.
The device never makes any trips - so we can't use the 'In-Trip' parameters.
To configure scanning:
- Set Out of Trip Scan Period to your desired scanning interval.
- If you want the device to upload every scan interval, set Upload On Out of Trip Scan to Yes.
- If set to no, the device will upload all the scans each heartbeat interval.
Out of Trip Scan Period = 30 minutes, upload = Yes
Every 30 minutes scan for tags AND upload.
Useful if you need to know where your tags are throughout the day at this interval.
Out of Trip Scan Period = 30 minutes, upload = No, Heartbeat Period = 1440 minutes
Every 30 minutes scan for tags, upload all the data once daily.
Useful if you just need the data for reporting later on - maybe you just want to know approximately when your tagged assets left and returned to your office/depot.
Displaying Information on Telematics Guru and 3rd Party Platforms
See our Bluetooth getting started guide for information on how to View Tag Locations in TG.
The tag functionality on Telematics Guru designed with the 'where is my tagged asset located?' use case in mind. Device parameter defaults are also geared towards this. Telematics Guru will record all information coming in about a tag in the Tag Telemetry view - and the latest update will dictate what the tag location is displayed as. The multiple gateway scenario described earlier illustrates how parameters must be carefully selected so that this logic on the server does not result in unintended or potentially confusing behaviour. A 'Tag Lost' log which comes in after a 'Tag Found' log is one situation which can upset the balance.
Tagged Asset Lost and Found Report
The Tagged Asset Lost and Found Report is available in Telematics Guru - for use with stationary gateways. It can be used to log the entry (tag found) and exit (tag lost) of tags into areas where gateways are located and set up as stationary. Once device parameters are configured as above - simply run this report to see a list of Tag Lost/Tag found events.
This report allows us to say that at 0920 on 2020/07/01 the tag left the area the gateway was located, and returned at 2120 (and so on). This gateway is configured for periodic scanning so the entries/exits only line up at timed intervals - this is not the exact time the tag left/returned.
If you just want a list of where your tags are currently - the Tagged Asset report should be used.
What is RSSI?
RSSI stands for Received Signal Strength Indicator. It is an indication of the strength of a received radio signal. So in our case, the gateways report the RSSI of the tags - how strong the signal is that they are seeing from each tag.
When RSSI is represented in dBm (like our devices) - the value is negative. The higher the number (i.e. closer to 0) - the stronger the signal. So -2dBm means stronger signal than -10dBm.
RSSI is impacted by a few factors:
- The distance between the tag and the gateway. The further away, the weaker the signal.
- The power the tag is broadcasting at. If it broadcasts with higher power, the power seen by the gateway will be higher. If we use the same tag type, and same output power (Guppy default is +8dBm) - then we don't need to consider this factor.
- The path the signal travels. If the signal is blocked by many obstacles e.g. walls, noise, other obstructions - the signal at the receiver (gateway) will be less.
Problems with closely spaced gateways, and the solution
We can use the RSSI filters to help filter out tags that are seen by the gateway which are very weak - or thinking of it in the other direction, only consider tags which we see strong signal from (i.e. they are probably closest to the gateway). This is quite effective but not 100% reliable - consider a tag very close to the gateway but behind thick wall for example. The RSSI value might be very weak in this case - even though it is nearby to the gateway, the signal is being blocked.
This feature is especially useful when setting up multiple gateways in close proximity.
Consider the above diagram. A Guppy tag is centred between 3 gateways A,B,C in open space. It is within range of all 3 gateways, so the Remoras would report it in their tag lists.
If they were set up to scan for tags on 15 minute intervals (slightly offset from each other by 5 min), the following could occur:
0600 - Gateway A scans and sees the Guppy, it uploads this scan to the server, the Guppy is reported as being at position A on the server.
0605 - Gateway B scans and sees the Guppy, uploads, now the Guppy is at position B on the server
this continues with the Guppy bouncing around every 5 minutes.
The way we would solve this is to set an RSSI threshold. This effectively means that the Guppy must be closer to a given gateway to appear in it's tag list. Preventing this issue. One way to choose the value is to check the reported RSSI values of the tag without a filter applied in various locations - and adjust accordingly.