Live RSSI Mapping System

SWARTHMORE COLLEGE DEPARTMENT OF ENGINEERING SENIOR DESIGN PROJECT Live RSSI Mapping System Authors Supervisor Timothy NGUYEN Matt ZUCKER Neeraj SHAH IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF BACHELORS OF SCIENCE May 10, 2019 i Abstract For our final engineering project, we wanted to explore a quality assurance problem related to networking. We successfully built a heat-map that intuitively displays the strength of wireless signals. The project has two major components: a Raspberry Pi and an AWS-based server. The Pi acts as a measurement device for signal strength and the server receives and processes the Pi’s data to generate a map. The project is optimized for real-time updates and has features that can isolate the strength of individual routers. ii Acknowledgements We would like to thank Professor Matt Zucker for mentoring our project. His input and feedback helped us constantly move forward. We also would like to thank the engineering department for helping us obtain materials and for facilitating the entire project. iii Contents 1 Introduction 1 2 Raspberry Pi 1 2.1 GPS............................................. 1 2.2 Wireless Monitoring . 2 2.3 Handling the Data . 3 2.4 JSON Format . 3 2.5 Additional Hardware . 3 3 Lightsail Server 4 3.1 Cloud . 4 3.2 Map Generation Theory . 4 3.3 Data Processing . 5 3.4 Image Generation . 5 3.5 Python Script Optimization . 6 3.6 MAC Address-Based Heatmap . 7 3.7 Web Development . 8 3.8 Google Maps API . 8 3.9 Hosting Files with Node JS . 9 4 Results 9 5 Future Work 11 6 Appendix 11 6.1 Python Code on Raspberry Pi . 11 6.2 Python Code on Server . 13 iv List of Abbreviations RSSI Received Signal Strength Indication MAC Media Access Control BSS Basic Service Set SSID Service Set Identifier DBM Received Signal Strength Indication AWS Amazon Web Services JSON Javascript Object Notation API Application Programming Interface 1 1 Introduction As our connection to the internet becomes increasingly important and as new forms of dispens- ing internet services emerge, it is important to identify weak-spots in any internet network. We propose developing Raspberry Pi devices which will continuously monitor the strength of a WiFi signal (Eduroam in our case) and output the values to a web application to continuously update a heatmap. As the devices move around campus, the heatmap will then show areas of weak and strong coverage. We can imagine a system where multiple people, at different points around Swarthmore, roam the campus and provide valuable data to students, professors, and network engineers on the current state of Eduroam. This will allow everyone to identify the exact location of dead spots or areas of weak coverage. We hope that the final system can be used for identifying weak spots on larger scale networks like LTE or satellite based internet services. We will rely on common signal strength measurements like Received Signal Strength Indi- cator (RSSI) to quantitatively represent different areas on campus. These can be outputted with the linux module iw. We will also obtain locations for these readings with the GPS module at- tached to our Pi. All readings will have associated degrees of confidence that can be improved over time. This is an interesting problem to solve because of how it applies many engineering disci- plines to tackle a common issue. We would be using knowledge of networks, hardware-design, probabilistic models, and software engineering principles to approach this task. The project can be broken down into two major components. The first revolves around the Raspberry Pi and its associated hardware extensions. The Pi handles all of the data collection. The second component relates to our server, which processes all of the data and ultimately serves a web page to the user, displaying all of the information about the current state of the wireless network in question. 2 Raspberry Pi Our choice for processing inputs was a Raspberry Pi 3B+, running the latest version of Rasp- bian OS. This is a Unix-like OS, giving us the full functionality of a UNIX command line. 2.1 GPS In order to keep track of our location, we purchased an Adafruit Ultimate GPS Breakout module which outputs latitude, longitude, and altitude with a 10Hz update frequency. This GPS module was connected to the Pi via a USB Serial connection. The GPS module can be seen in figure 1. Four pins on the GPS were wired to the Pi: TX, RX, GND, and VIN. 2 Originally, this GPS module was not en- tirely accurate, giving an error of over 30 me- ters. In order to remedy this, an additional antenna was purchased for the GPS unit, in- creasing the rate at which it fixed to satel- lites and improving indoor and outdoor pre- cision. Figure 1: Ultimate GPS Breakout Module 2.2 Wireless Monitoring Across most UNIX distros, the iw command comes pre-installed. This is a new command line utility for wireless devices. This command often gets confused with iwconfig, a now deprecated tool. The new iw utility handles newer generations networking protocols. The commmand that we run on our Pi is iw dev wlan0 scan The command invokes the iw utility with the first word. The second word, dev, stands for device. The third word, wlan0, specifies which device we want to look at. In most modern machines, wlan0 refers to the integrated networking card. The last word, scan, looks at all the available networks and outputs their details. The output of this command is all the wireless networks the Pi can pick up and all of its associated metadata. The only information we are interested in are the SSIDs, MAC addresses, and signal strengths. So we filter the results by those fields with the following extension to our original command: iw dev wlan0 scan | egrep “^BSS|Signal|SSID” sudo iw dev wlan0 scan I egrep ""BSSlsignallSSID" c8:b5:ad:34:38:60(on wlan0) : -68. 00 dBm : eduroam c8:b5:ad:34:38:62(on wlan0) : -69 . 00 dBm : SwatGuest cH:b5:ad:34:d1:10(on wlan0) : - 57 . 00 dBm : eduroam c8:b5:ad:34:d1:12(on wlan0) : -57 . 00 dBm : SwatGuest c8:b5:ad:34:e7:80(on wlan0) -72 . 00 dBm : eduroam c8:b5:ad:34:e7:82(on wlan0) : - 71.00 dBm : SwatGuest c8:b5:ad:34:3a:62(on wlan0) : -81 . 00 dBm Figure 2: Output of iw Command 3 2.3 Handling the Data The entirety of the data collection is done in one Python script, which handles the GPS and WiFi data. The GPS data is obtained with a library known as AGPS3. Originally, we used the library associated with Adafruit; however, we quickly ran into an issue where a backlog of older GPS readings were being saved. This was solved in the newer library with threading. Threading is a tactic employed by programmers to speed up computation for a single process. This new library had threads that handled clearing the old buffer that accumulated overtime. Once the GPS data was streaming in real time, we incorporated the WiFi data previously mentioned. In order to run the shell command in Python, we utilized a builtin library called subprocess. This enables us to run these shell commands as processes from Python and col- lect their output. Thus, for every iteration that we grab a GPS reading, we also run the shell command and obtain the associated WiFi data. 2.4 JSON Format After obtaining the GPS and WiFi data every iteration, we must parse through the data, ensure it’s properly formatted and free of errors, and package it into a readable format. The format we chose was a JSON file. JSON format is the industry standard for transferring data between web applications and servers, storing the data as readable tree of nested dictionaries and lists. As we traverse around campus and gather data, our JSON file will continue to grow, eventually reaching over 100,000 lines. This occurs because in addition to saving data for Eduroam, we also hold the data for SwatGuest and SwatDevice. This was a design choice, should we choose to extend our project to other SSIDs as well. In order to handle random bugs and program interruptions, we have a fail-safe protocol: every 100 iterations, we will save the current copy of our JSON data. Once we have finished all of the data collection, the Python script will push the final JSON file to our AWS server. 2.5 Additional Hardware While traversing campus, we required a constant source of power to keep the Raspberry Pi running. We purchased an additional battery pack from the official Adafruit site. The choice of battery pack is important because the Raspberry Pi may run into undervoltage issues if not provided a consistent 5V source. Additionally, the cable to power our Pi must be as short as possible, since longer cables tend to have a higher resistance. Furthermore, an additional touchscreen monitor was purchased to monitor the output of the program on the go. 4 3 Lightsail Server 3.1 Cloud In order to serve our desired product to the end-user, we must have a place where we can perform the computationally intensive task of producing the heatmap and hosting our web- site files. Cloud based storage is becoming an increasingly popular choice for consumers and companies to store data. As opposed to traditional storage methods which involve owning large racks of hard-disks on site, cloud storage takes away local storage and hosts your data in a remote location with an easy, intuitive way to interact with it.

Load more