Our range of Bluetooth® enabled gateway devices and tags allow for a variety of low-cost asset tracking solutions. See - Bluetooth Tracker | Bluetooth® GPS Asset Tracking Devices

A key use-case is inventory and asset management across multiple sites. 

1. Gateway devices are placed in warehouses, installed in delivery vehicles
2. Bluetooth tags are placed on pallets or boxes of stock
3. 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.

Device Selection

Each of our Bluetooth gateways have subtle differences (discussed in the following sections) which make them suited to particular applications. 

Hawk (with the Bluetooth+ Card) 

The Hawk is a highly flexible stationary gateway device. As the firmware is suited to periodic updates - and the Lat/Long can simply be set as a parameter, and GPS fixes disabled - making it suitable for use indoors. Additionally, when hard-wired, it can be set to scan for Bluetooth devices continuously - this means that as soon as a tag comes into/leaves range, it will be picked up (and an upload can be sent to the server). In contrast in periodic mode, we only scan every so often - so we only know what tags are in range at the time of the scan.

G120 & G150

The G120 and G150 are designed as a vehicle tracking devices 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 a Hawk for this application.

The G150 is a suitable candidate for a stationary gateway whether supplied with external power or running on battery power alone. This is because the G150 can be configured to operate in Periodic Mode, which reduces the power-hungry characteristics of the G120 which is always in a trip tracking mode. Please note though, like the G120, the lat/long cannot be set on the device. 

Remora3

The Remora3 will operate in a similar way to the Hawk, however, the key difference is that it must be 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. 

To save battery when scanning for Bluetooth tags and acting as a stationary gateway, one can disable GPS fixes on the Remora3, but not fix a position. See the parameter setup later in this article.

Oyster3-BLE and OysterEdge

The Oyster3-BLE is basically a smaller Remora3, both are battery-powered devices that work great for outdoor applications.
For indoor applications (eg. Temperature monitoring of food parcels), the Oyster Edge uses WiFi Geolocation and when the parcel leaves the cool room/warehouse, the low-powered GNSS on the Oyster Edge can provide tracking outdoors. 

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 appear 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 location 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 is 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

As for all Bluetooth functionality, be sure to enable the global BLE parameter

"Default" GPS Position

The Hawk has 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. 

This option is one of the reasons why the Hawk is preferable as indoor-powered gateways in comparison to the G120 and G150.

Disable GPS Fixes on Remora3

A “default” GPS position cannot be set on a Remora3. However, as a way of saving battery when using a Remora3 as a stationary gateway, setting the “GPS fix multiplier” to 0, disables GPS scanning:

Continuous Scanning Stationary Parameters

This is available on the Hawk, G120 and G150. It is best only used on the Hawk when the device is being externally powered. 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.
• 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:

1. Set the device as Stationary
2. 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.
3. Do we upload when a Tag is Found or Lost? If set to know the records will just be sent on the next upload.
4. Tag expiry time - how long without seeing a tag before it is 'lost'
5. 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 Oyster3-BLE, OysterEdge, Remora3, Hawk, G120 and G150.
It is the only option on the Remora3 - since it is battery powered and continuously scanning would drain the batteries.
It should be used on the Hawk and G150 when using batteries instead of external power. 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.

Examples

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. 

Example output:

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.

RSSI Filtering

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 Remora3s 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.