BLE-Based Asset Tracking with Particle

The modern world is only possible due to our massive logistics networks that transport goods and people around the globe in short amounts of time. And whether it’s a massive container ship or a parcel in a warehouse, knowing the location of each entity in the system is vital for maintaining accurate inventory and delivery time forecasts. For vessels and vehicles, the problem is largely solved thanks to GPS, but smaller items are a different story. Current approaches involve attaching scannable labels such as barcodes to items and then noting the scanner locations and times when it interacts with the item. But in a warehouse or open area with many possible storage locations, how can tracking these item locations become more granular on an individual basis?

To enhance the granularity of asset tracking within constrained environments, this project employs Bluetooth Low-Energy (BLE) technology. By utilizing BLE beacons, the system can track items without continuous connection requirements or the need for direct line-of-sight, offering a scalable and cost-effective solution.

Using BLE to determine distance

When first coming up with a better way to track inventory, I had considered using a system of many cameras that could each watch for a marker and triangulate a location from it. However, this is quite expensive, generates large amounts of data, and will stop functioning if the camera is unable to see the tag. Bluetooth Low-Energy (BLE), on the other hand, works by sending out small packets of data across the 2.4GHz band, and by making each tag into a BLE beacon, there is no need for a continuous connection.

Before a BLE device can even connect, other devices need to be made aware of their presence. Therefore, they will emit advertising packets that describe the device’s name, available services, and even the power level of the radio. By instructing the receiving microcontroller to listen for these advertising packets and compare the incoming transmission’s actual power level (RSSI) to the advertised one (Tx Power), a distance can be estimated.

Hardware

At the system’s core are three Particle Photon 2 boards and a single Particle Monitor One kit. In this case, two Photon 2s and the Monitor One have firmware that make them into “stations”, or listeners for the incoming beacon packets. At each iteration of the loop, the microcontroller will scan for any iBeacon packets and parse its data if available. This includes the UUID (same for all beacons in this project), the minor version (unique to each beacon), and the advertised Tx power. A JSON payload is then constructed from this information along with the estimated distance from the RSSI and sent to the Particle Cloud. And thanks to the Monitor One’s GPS and cellular connectivity, it can listen to beacons from anywhere while accurately reporting its own location, unlike the Photon 2s which need a WiFi connection.

The last Photon 2 configured as a beacon is running a much simpler firmware. All it does is leverage the built-in iBeacon class within Device OS to configure its advertising data and then send a packet once every two seconds. Except for the Monitor One that has its own battery, the Photons were powered by a single 1000mAh LiPo battery.

Creating a web app

Being able to capture the distance from each beacon to every station in range and storing it in the Particle Cloud as an Event is great, but this information alone doesn’t locate the beacon quite yet. The web app I created and ran locally is made using Nuxt, and it handles several important functions. First, there is a plugin running in the background which opens a connection to the Particle Cloud Events publisher and then handles each BEACON-DIST Event as it’s received.

Second, the server exposes a variety of endpoints for getting/setting the station IDs and their coordinates- all of which is stored in Redis. These are all displayed on the frontend using a Leaflet map that represents each one as a blue, labeled marker and draws a polygon around them.

Trilateration

Every time new data is received for a beacon as either a Particle Event or through the server’s REST API, a cascade of operations is started. The entry, containing the station ID, the beacon ID, and distance in meters is initially added as a time-series datapoint within Redis for highly efficient lookups and later analysis under the key distance:beacon:BEACON_ID:STATION_ID. Next, the latest distance entry is retrieved from each station for the given beacon, and if there are not at least three stations that have an entry for the beacon, the process ends early. Conversely, knowing the last three stations and their latest reading means trilateration is possible.

Similar to how GPS gives a user their location by knowing the position of at least four satellites and the time it takes for a signal to travel from each one to a receiver, trilateration in two-dimensional space works by knowing the distance from a beacon to each station along with the stations’ positions. In this system, the station coordinates are entered via the web app and stored as Redis Set values before being retrieved in the lookup process. With these values, the beacon location can be calculated and transformed into coordinates which are then stored as Redis Geospatial data.

Data display and future ideas

Currently, the map displays each beacon as a clickable red dot that moves according to its last known position. As seen in this GIF, the tracking accuracy is quite good when there is an unobstructed line of sight between the beacon and the nearby stations:

Among other great use cases, one that stands out is applying this technology to know when an item has left or is getting ready to leave a predefined zone, as stations near the perimeter can listen for nearby beacons to help calculate their updated positions. The source code for the station firmwares, beacon firmware, and web app can all be found in this repository.