I’ve recently completed an Honours Degree in Software Development and as part of this I spent a few months off and on working on a proof of concept tracking system utilising Bluetooth Low Energy (BLE) in order to track small asset tags. I believe this system could quite easily be scaled up to an industrial scale with further work but don’t personally plan to follow this up in the near future due to working on other projects. As such I figured I’d release a lot of what I have and hopefully it can help somebody else.

If you do something cool with this then please get in touch, otherwise do with it all as you wish.

This post is one of eight scheduled to be released over the next few weeks, all posts in this series may be found by selecting the tag below.

This post functions as a log of the steps required to implement this project in a practical manner, the goal is that somebody else with minimal knowledge may be able to follow it.

Testing & Results

The testing results here are included to demonstrate the potential issues with using Bluetooth Low Energy (BLE) as the tracking technology and were used during design to evaluate whether it was reliably possible to estimate distance using RSSI.

The primary issues are caused by external factors influencing the received signal strength, this can be local signal interference in some cases, but is more often than signal strength loss due to there being large objects in the way, which can be mitigated by increasing the number of gateways and using the strongest 3 signals rather than all signals, and which can also be mitigated by carefully laying out the gateway system in a manner that minimises line-of-sight issues.

RSSI Test – Direct line of Sight, Raised

The tests below were made to determine the falloff rate for the RSSI signal in an ideal scenario, with little in the way of obstacles and with both the gateway receiver and BLE tag both raised.

Each distance had 7 individual tests taken 30 seconds apart, once all 7 tests were complete the tag was moved a further 0.5 meters further away from the gateway.

Distance (M)	Test 1	Test 2	Test 3	Test 4	Test 5	Test 6	Test 7	Average
0.5	-61	-60	-60	-60	-60	-61	-61	-60.43
1	-62	-60	-60	-60	-60	-61	-60	-60.43
1.5	-64	-63	-65	-63	-63	-63	-63	-63.43
2	-66	-68	-68	-69	-73	-68	-67	-68.43
2.5	-69	-73	-70	-72	-72	-72	-74	-71.71
3	-75	-73	-74	-74	-72	-75	-72	-73.57
4	-75	-77	-80	-77	-75	-76	-75	-76.43
5	-78	-73	-75	-80	-75	-75	-78	-76.29

as can be seen there is a definite correlation between distance and RSSI.

RSSI Test – On Carpet, Floor Level

Distance (M)	Test 1	Test 2	Test 3	Test 4	Test 5	Test 6	Test 7
0.5	-61	-59	-59	-60	-58	-61	-59
1	-62	-62	-63	-70	-73	-68	-68
1.5	-73	-68	-68	-70	-70	-75	-69
2	-73	-68	-68	-70	-70	-71	-75
2.5	-73	-80	-80	-75	-89	-80	-80
3	-70	-77	-70	-76	-78	-77	-77
4	-82	-94	-78	-83	-81	-82	-83

The values have been coloured from green signifying the highest (strongest) signal strength to the lowest (weakest) signal strength, as can be seen there is a definite correlation between distance and RSSI.

It is worth noting that the variance in values tends to grow over distance, which is most likely because of environmental factors having a greater effect on the signal.

There are also significant outlier values in some cases, which indicates that the system must average the past several reported values, otherwise the results are likely to be wildly inaccurate in some cases.

Estimated Distance vs Actual

The table found below compares the average RSSI value as reported in “Table 1 Reported RSSI values at given distances” and actual distances with an estimated distance using the algorithm found in the project.

There are some surprising results, accuracy appears to drop over distance as expected however although there appeared to be a trend where the estimated distance grew quicker than the actual distance, this did not hold true at 5 metres. It would be interesting to attempt the same testing in a different environment and to see if this holds true or whether there was some localised environmental interference that was occurring.

Actual Distance (M)	RSSI Value	Estimated Distance (M)	Difference
0.5	-60.42857143	0.77	0.27
1	-60.42857143	0.77	-0.23
1.5	-63.42857143	1.18	-0.32
2	-68.42857143	2.03	0.03
2.5	-71.71428571	2.87	0.37
3	-73.57142857	3.48	0.48
4	-76.42857143	4.63	0.63
5	-76.28571429	4.56	-0.44

Evaluation

The evaluation below is based on the existing Requirements Analysis performed earlier in the project and records some mistakes which may be avoided or improvements that may be considered if a similar project was undertaken.

Requirements Analysis

The project is split into two separate phases, the first is hardware acquisition which will focus on procuring ready-made hardware that with minimal modification may be of use to a RTLS system, and the second will be the overall performance of the system and how it must operate.

The requirements are written using the MoSCoW Method, with MoSCoW standing for must, should, could, and would, which will be used to prioritise the various requirements of the system.

Requirements marked ‘Must’ will generally have the highest priority as the developed system will not be functional if these requirements are not met.

Requirements marked ‘should’ are not required for the project to function as a minimum viable product but will go a long way to providing a better user-experience.

‘Could’ requirements will be beneficial but are not required and will only be performed if sufficient development time is available.

Hardware Acquisition

Functional Requirements

Requirement	Compliance
Must use Bluetooth Low Energy (BLE) and Wi-Fi chips – this is the focus of this project and therefore needs to be used.	BLE and Wi-FI technologies utilized extensively throughout the project.
The BLE tag must have an expected battery lifetime of at least 6 months.	Based on estimated power usage each tag should last a minimum of 2 years.
The Wi-Fi device should report data using MQTT to the central server as it is the de facto IoT language.	MQTT is used to transfer data from each gateway to the central server.
A minimum of 3 gateways must be configured for trilateration to work.	4 gateways were configured and used in the proof of concept; the data form the strongest 3 gateways at any one time were used to calculate location of assets.

Non-Functional Requirements

Requirement	Compliance
Any purchased hardware should have widespread adoption, it should not be a niche device as that will inevitably increase the total cost of the system.	All hardware used was off-the-shelf components with no physical changes made to the devices.
Outside of initial setup and updates on the server side the devices without external influence should be able to autonomously interact with one another.	The overall system has been running for 2 weeks with occasional power offs due to environmental factors, however all systems have run without issue for that length of time, this includes the BLE-Wi-Fi gateway which have also ran continuously.
The hardware must be ‘off-the-shelf’ components. I.e., they will not be physically modified for purpose at all.	All hardware used was off-the-shelf components with no physical changes made to the devices.
The BLE-Wi-Fi gateways should be able to run continuously with external power.	All devices have run without issues for 2 weeks with occasional power cuts due to environmental factors.

Real-Time Location Service (RTLS)

Functional Requirements

Requirement	Compliance
The system must be able to track multiple BLE-tags.	The website shown in the demo demonstrates being able to select multiple tracked tags.
There must be a way to map data to a specific BLE Tag MAC. This allows for human-readable inventory.	The human-readable portion has not yet been programmed. This would simply be a case of having a mapping table or including a friendly name in the gateway data table
There must be a user-interface for the reporting of current asset location that will allow a user to identify which area a specific asset is located.	There is a user interface where tag data may be viewed as in the requirements, and which also displays the last update time of each asset.
The user interface must show the latest update time of each asset and the last known location.	The user interface mentioned above shows a last updated column.
All location data must be reported to a central database.	All data from the system is currently reported to an SQLite database on a Raspberry Pi, this would be trivial to change to a production ready system such as Cosmos DB.
The interface could auto-update locations live. I.E. changes in tracked location are reflected in the interface without the need to refresh the page.	Unfortunately, this was not implemented due to technical issues implementing a map view which slowed the project down.
The system could securely pass messages. (Must in production environment but not necessarily required for proof-of-concept).	Although security improvements could be made with further development the overall system is secure.   Each beacon implements ECG encryption, each gateway implements a simple BLE Replay Attack and Spoofing detection, the actual devices that make up the gateway are physically connected and finally the gateway only publishes MQTT to a defined IP address.

Non-Functional Requirements

Requirement	Compliance
The system must be able to identify an asset to within 5 metres accuracy at minimum.	The current system identifies assets to within +/- 2 metres, although I believe this can be improved by smart placement of gateways.
The latest location must be polled at least once a minute for each asset.	The location of each asset is updated every 30 seconds.
Any stored data must be encrypted at rest and require authentication to access.	Data at rest is not encrypted in the database as the database was set up as a proof of concept rather than a fully functioning system, all access is via a password on the host device and the database itself is not networked.
The project requires a database to host all the tracking data for each asset, ideally this should be a time series database.	All data is stored in an SQLite database due to this being a proof of concept, in a live environment this is more likely to be a time series database.
Interface should load within 4 seconds at most, this is slightly longer than several sites suggest due to the potential for heavy data-loads. Users are unlikely to wait longer.	Load times for the main interface are currently 840 milliseconds, far below the 4 second aim.
Should be fully functional by the 25th of June at the latest to ensure some time for demo preparation.	The project was fully functional as of the 25th of June.

Conclusion

This report focussed on creating an open-source platform combining already available tools, resources, and hardware to create a scalable and low-cost Bluetooth Low Energy tracking system.

The research contained in this report has shown that it is possible to use very low-cost devices that are in common use for home-based IOT applications to build a functioning commercial real time location system (RTLS). By taking widely available hardware in the manner shown in this research it should be possible to reduce the cost of implementation and maintenance of RTLS systems when compared to the available offerings online which appear to all used closed-source and proprietary hardware and software.

There are several issues utilizing Bluetooth in this context however, with the hardware used, it appears to be very sensitive to environmental factors such as furniture or walls being between the asset and the tag. This is not an issue with data transfer as Bluetooth is quite robust, but it does strongly affect the RSSI value which does affect the distance calculations. Future work involving Bluetooth capable hardware would be strongly suggested to utilize Bluetooth Angle of Arrival (AoA) which allows for efficient trilateration of tracked assets without first having to calculate the distance (Bluetooth SIG, Inc., 2021), effectively bypassing the mentioned issues. However, at the time of writing this report this does appear to be prohibitive based on cost.

References

AirFinder, 2020. A Breakdown of 7 RFID Costs, From Hardware to Implementation. [Online]
Available at: https://www.airfinder.com/blog/rfid-cost
[Accessed 11 January 2021].

AliExpress, 2021. 1/5/10pcs NFC Ntag215 Coin TAG Key 13.56MHz NTAG 215 Universal Label RFID Ultralight Tags Labels Phone. [Online]
Available at: https://www.aliexpress.com/item/4001084872889.html
[Accessed 22 February 2021].

AliExpress, 2021. NRF51822 2V-3.3V Bluetooth 4.0 Wireless Module For iBeacon Base Station Intelligent Control System Beacon BLE Module 4MA W/ Case. [Online]
Available at: https://www.aliexpress.com/item/32826502025.html
[Accessed 15 February 2021].

Anon., 2016. Optical Tracking – Vero Solutions. [Online]
Available at: https://vero.solutions/technology/optical/
[Accessed 15 February 2021].

atlasRFIDstore, 2019. Active RFID vs. Passive RFID: What’s the Difference?. [Online]
Available at: https://www.atlasrfidstore.com/rfid-insider/active-rfid-vs-passive-rfid
[Accessed 11 January 2021].

Columbus, L., 2020. Forbes. [Online]
Available at: https://www.forbes.com/sites/louiscolumbus/2020/04/28/how-covid-19-is-transforming-e-commerce/?sh=249d28a03544
[Accessed 10 October 2020].

DB-Engines, 2021. DB-Engines Ranking – popularity ranking of database management systems. [Online]
Available at: https://db-engines.com/en/ranking
[Accessed 06 May 2021].

Fanstel, 2021. BWG840F, Open Source, secure, Industrial WiFi to Bluetooth, Thread, Zigbee gateway. [Online]
Available at: https://www.fanstel.com/buy/bwg832f-g6fdz
[Accessed 15 February 2021].

Huber, N., Katina, M. & McCathie, L., 2007. Barriers to RFID Adoption in the Supply Chain. s.l., IEEE, p. 4.

Infineon technologies, 2004. The 15 most Frequently Asked Questions about RFID. [Online]
Available at: https://www.infineon.com/dgdl/FAQs_RFID_e_0304.pdf?fileId=db3a304412b91b910112baad0cc021bd
[Accessed 18 February 2021].

Influx Data, 2021. Time Series Database (TSDB) Explained | InfluxDB | InfluxData. [Online]
Available at: https://www.influxdata.com/time-series-database/
[Accessed 6 May 2021].

IntraNAV, 2021. Multimodal industrial real-time location. [Online]
Available at: https://intranav.com/en/iot-rtls-suite/rtls-uwb-tracking-system/
[Accessed 5 May 2021].

Koster, R. d., Le-Duc, T. & Roodbergen, K. J., 2007. Design and control of warehouse order picking: A literature review. European Journal of Operational Research, 182(2), pp. 481-501.

Laine, M. & Saila, K., 2012. Performance Evaluation of XMPP on the Web, s.l.: Aalto Univ. Tech. Rep.

Localino, 2021. wifi-ble Z Localino – We keep we on track!. [Online]
Available at: https://www.localino.net/en/wifi-ble/
[Accessed 5 May 2021].

National Retail Federation, 2020. National Retail Security Survey 2020. [Online]
Available at: https://cdn.nrf.com/sites/default/files/2020-07/RS-105905_2020_NationalRetailSecuritySurvey.pdf
[Accessed 7 January 2021].

Nordic Semiconductor, 2014. S120 nRF51 SoftDevice Specification v2.1. [Online]
Available at: https://infocenter.nordicsemi.com/pdf/S120_SDS_v2.1.pdf
[Accessed 4 May 2021].

RedPoint, 2021. RTLS Software | RedPoint Positioning | UWB Technology. [Online]
Available at: https://www.redpointpositioning.com/technology/software/
[Accessed 21 February 2021].

RFID DIscovery, 2021. Secure Technology for a Connected World. [Online]
Available at: https://www.rfiddiscovery.com/en
[Accessed 6 May 2021].

Shobha, N. A. K. B. M. a. S., 2016. NFC and NFC payments: A review. International Conference on ICT in Business Industry & Government (ICTBIG), p. 2.

Tile, 2021. Find wer keys, wallet & phone with Tile’s App and Bluetooth Tracker Device. [Online]
Available at: https://uk.tile.com/
[Accessed 15 February 2021].

U.S. Government, 2020. GPS.gov: GPS Accuracy. [Online]
Available at: https://www.gps.gov/systems/gps/performance/accuracy/
[Accessed 3 May 2021].

United States Census Bureau, 2020. Manufacturing and Trade Inventories and Sales, October 2020, s.l.: Economic Indicators Division.