In this second blog post we will be delving into the math and code that will calculate our Bluetooth device’s position. We will cover more in detail exactly how our calculations work and the background behind them. We will also address the choices on the values used to perform the calculations. The code has evolved since the last post, and we will cover what has changed in the code and the tools we are using. We will conclude with a debrief of the presentation we gave on the project at the Vermont Tech Jam event.
When calculating the location of a device, we need the RSSI, interference(N), and txPower(A) (strength of the signal at 1 meter). The issue is that RSSI is a poor indicator of distance. Also, txPower is unavailable to us as because device signal strengths vary. So, despite its inaccuracy, RSSI is the best indicator of distance we have access to. For testing purposes, N was set to a baseline of 20 dBm. A was set to -62dBm to account for the average interference of other devices in the area. In a future iteration, we will calculate N using the secondary nodes. To plot the position of a bluetooth device in an area we must use the RSSI to calculate distance. Then we trilaterate the coordinates of the bluetooth device using three points of reference.
The best RSSI reading for calculating distance is the mode of many readings from the device. If a mode cannot be calculated the average RSSI is used instead. Using the formula RSSI (dBm) = -10n log10(d) + A in the form of d=10((A- RSSI(dBm)) / N) provides us with an estimation of range. Distance categories “near”, “middle”, or “far” are also defined using ranges of “near” <10 meters, 10 meters=< “mid” <=20 meters, and “far” >20 meters. This allows us to provide a position for the device. It also leaves room for error. To trilaterate the position, we place the estimated distances in a triangulation formula. The group based this formula off the report “Indoor Positioning System” with the points X and Y being the coordinates of the unknown device:
(Image from https://www.ece.lsu.edu/scalzo/FDR_Final.pdf)
The coordinates derived are the approximate (x,y) coordinate pair of the sniffed bluetooth device. Devices only seen by one or two nodes display with the “near”, “middle”, or “far” system using the nodes that see it.
(for more info on RSSI look at this blog post: https://blog.bluetooth.com/proximity-and-rssi)
As discussed in our last blog post we are making some python scripts to do data aggregation and analysis for us. We are working on two scripts that will run on our microcomputers. As a side-update on the computers, we are using Odroids with the Ubuntu 16.04 minimal OS. One of the three Odroids is the master node, and will be the one doing the calculations. The other two Odroids will be running a stripped down versions of the code. These secondary nodes collect data and send it to the master node upon request.
The current plan is to run the code in a continual loop and redo calculations based on a user supplied time frame. See the diagram below for a pseudo-code example of the machines interacting. The idea behind aggregating all the data before performing calculations is to cut down on confusion between nodes. This way the nodes are not reporting the same device as separate devices.
We are also looking into ways to display the results in graphical manner. For the time being we are having the script output the calculated distance and a value of “near” “middle” or “far”. If we can replace this with a graphical representation it will be far easier to track a device.
Bluetooth Receiver Hardware Update
During our testing phases, we determined that Blue Hydra is not the most effective tool for our purposes. Instead, we have chosen to use the Ubertooth tools to parse and show the data we need. The Ubertooth tools provide more information that updates more. This allows for us to have a more accurate look into bluetooth devices in our area. The output of the Ubertooth tools is much messier. But the extra information it contains will benefit our project. We’ll have to go back and adapt our Python code. But it will benefit our project.
September 20th and 21st, we brought our project to VT Tech Jam! Tech Jam is an annual technology expo featuring exhibits and talks from all sorts of technology companies around Vermont. The LCDI hosted our own booth on both days; featuring our project and some of our newest tech. On one of our displays, we showcased the 2.4ghz spectrum using spectools by Kismet. This way, onlookers could actually see how Bluetooth frequencies communicated around them. When interested, we showed people our prototype script that could calculate how far a Bluetooth device was from our laptop. We had a lot of curious visitors and had a blast talking to all the different companies from around Vermont. If you happen to be in Vermont next October, make sure to stop by and check out our new and exciting projects!
Overall we have made great progress on this project. We have calculated distances to bluetooth devices and are almost ready for a full scale test. With a few last touches to the scripts we expect to be able to run a test with all three nodes operating independently.