Chris built a wireless position-tracking system that enables his university students to monitor his weareabouts. The system tracks him while indoors, so GPS isn’t needed. In this article, he presents the hardware, software architecture, and test results.
One of my important duties as a college professor is to hold office hours during which I help students. As an engineering professor, I often need to help a student in the lab. Leaving notes on my door indicating my whereabouts has proven to be unreliable as I often move from lab-to-lab helping different students. Consequently, there are times when I could help a student if they could just track me down. On the other hand, there are times when I am in a lab and I do not want to be disturbed. This motivated me to create a system that would selectively report my position to my students.
This system would need to track my position indoors, eliminating GPS from the outset. The building which houses our engineering program has a mature Wi-Fi infrastructure providing complete wireless access to the Internet. The wireless access points (WAP) that provide Internet access are stationary and broadcast a unique identifier in the form of a MAC address. Furthermore, one can measure their signal level yielding information about the distance from the WAP. Consequently a device which lists the “visible” WAPs and their signal levels could provide an estimate of its location. Could this idea be turned into a working system to provide reliable position information? To find out, keep reading.
REQUIREMENTS
I always harp on my students to think carefully about the requirements of their design before writing code and grabbing a soldering iron. Where creativity encourages us to expand the design space to include a diverse set of solutions, requirements are a sobering force which push back and exclude solutions from the design space. Also, good requirements tell us what we need to do in order to get a passing grade for our project. The requirements for this project, each with its own name, are listed below.
- Hardware: It must require a minimum of hardware development.
- Distance: It must be able to resolve location to within 1 classroom (10–20´).
- Modify: It must be able to create new room associations.
- Configurable: It must be able to switch location tracking off.
- Energy: It must be able to operate an entire day on a single charge.
- Usable: It must provide a low friction, “set it and forget it,” interface.
HARDWARE DESIGN
Sometimes you come across a piece of hardware that is a solution looking for an application. With its built-in 802.11 Wi-Fi module and powerful dual-core 1-GHz processor, the Intel Edison shown in Photo 1 packs a lot of capability into a small, low-power form factor. When you get first get your Edison, you would be well advised to use the SparkFun Base Block module to reflash the Edison with Debian Linux. Next, you should set up a Wi-Fi connection to your home router and then connect to the Edison wirelessly using SSH. Once you have this process ironed out, swap the Base Block for a Battery Block. Now you have yourself a Linux computer in your shirt pocket. This simple hardware setup met my hardware requirement for the project.
The Intel Edison, shown with an optional external antenna and Battery Block, is about the size of a postage stamp. Most of the ICs are encased in a (grounded) metal enclosure to reduce EMI. The integrated chip antenna is on the near corner, adjacent to a U.FL external antenna connector. A 70-pin connector is located on the bottom side along with another metal enclosure. Orientation axes are provided for later discussion.
INITIAL TESTING
I decided to test out the concept of Wi-Fi positioning with a simple test rig before coding up the tracking system. I performed these tests by wirelessly connecting my Intel Edison to my home wireless router. I also plugged in two inexpensive Netgear wireless routers to provide additional location information. I decided early on to use the iwlist command to scan for available WAPs. As shown in Listing 1, the output from iwlist contains a lot of information, most of which is not needed.
Listing 1
A portion of the output from iwlist revealing detailed information about the WAPs in the vicinity of the mobile device.
Cell 01 - Address: AA:BB:CC:DD:EE:FF
Channel:8
Frequency:2.447 GHz (Channel 8)
Quality=55/70 Signal level=-55 dBm
Encryption key:on
ESSID:"myhomenetwork_nomap"
Bit Rates: 1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates: 24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra: Last beacon: 20ms ago
The “_nomap” extension added to the end of my ESSID name, signals Google (and a consortium of reputable IT organizations) that I do not want my router’s ESSID to be part of their geolocation database. I converted the dBM signal level from iwlist into the more intuitive unit-less signal level by adding 110 to the dBM value. Using the iwlist command, I collected the values in Table 1 from two different locations 10´ apart.
— ADVERTISMENT—
—Advertise Here—
The values in Table 1 show that the basic concept of Wi-Fi positioning can meet the distance requirements set forth for the project. However, the signal levels had a noticeable amount of variation which called for further testing.
The list of WAPs that the test rig picked up during the test in Table 1 was much longer than the four shown and included all sorts of routers in my neighborhood. However, this list was far from stable; on consecutive calls to iwlist some of the WAPs would drop out, only to later reappear. To investigate this further, I left the test rig in one location, made 20 calls to iwlist, each 10 s apart, and for each WAP computed its average signal level and the number of times (out of 20) it was picked up. The results are plotted in Figure 1.
Each point is a WAP located at its average signal level and number of successful readings.
The data in Figure 1 shows that WAPs with low signal level cannot be counted on to reliability contribute a signal level reading. Consequently, I exclude WAPs whose signal level was less than a fixed signal level of 30. While I had the data collected for Figure 1, it was a simple matter to compute the standard deviation of each WAP’s signal levels as shown in Figure 2. This information is important because I needed to know if the changes in the Figure 1 signal levels were a result of the change in location or just noise.
The standard deviation of received signal level versus the average signal level using the same data as in Figure 1.
For WAPs with an average signal level greater than 30, there is an inverse relationship between the upper bound of the standard deviation and the signal level—stronger signals have a lower variation in their signal level. Case closed, or so I thought.
After working with the Edison for a while and encountering odd readings, I went back and reran the experiment in Table 1 only to find significantly different signal levels. The technical documents for the on-board ceramic chip antenna (a Pulse Electronics W3006) show that it has a non-uniform radiation pattern when rotated about the z-axis (see Photo 1). In order to understand this effect better I performed an experiment. However, while doing this experiment, I also wanted to collect data on the received signal strength with an external antenna and compare that against the chip antenna. A Taoglas Limited FXP810 was a perfect fit into the U.FL connector. Figure 3 shows a plot of the received signal level from two WAPs, while rotating the Edison through its z-axis (see Photo 1) with the WAP orientated along the y-axis.
The MAC address of several WAPs and their signal levels measured at two different locations in my house.
The received signal level of beacon frames from two different WAPs as a function of the Intel Edison’s orientation both with and without an external antenna.
Figure 3 shows significant orientation-induced variation in signal level. These 10-to-15-dB changes are in line with the changes in the radiation pattern from the antenna’s technical documents. Since I was unable to figure out a solution to address this variation, the system needs to operate with a level of uncertainty in signal strength.
SOFTWARE ARCHITECTURE
During testing, I developed three concepts that are fundamental to the software architecture of the tracking system.
- A fingerprint is the set of WAPs that the Edison can contact. Each WAP in this set is characterized by its MAC address and signal level.
- An exemplar is a fingerprint associated with a location.
- A data store is a collection of exemplars.
Figure 4 shows the overall software architecture of the tracking system running on three platforms, the Intel Edison, Raspberry Pi (RPi), and the user’s internet device. The Edison, carried around by the professor, periodically wakes up, collects information about the WAPs in range, organizes them into a fingerprint and sends it to the RPi over a socket connection. The RPi compares the fingerprint to its exemplars and records the best match in the queue. The most recent entries in the queue are analyzed to determine the most likely position of the professor. This is wrapped up into a web page and served to any user requesting it on their Internet device. An executive interface web page, served off the RPi, allows the professor to post a message to his/her students and to change the operating mode of the tracker (for example, disable it). We will examine this system in more detail starting with the Edison.
Figure 4
The high-level software architecture of the Location Tracking system showing a user moving from their den to the desk.
The Intel Edison executes a python script that periodically calls iwlist, parses out the MAC address and signal level for each WAP, and then sends these pairs to the RPi using the socket connection shown in Listing 2.
— ADVERTISMENT—
—Advertise Here—
LISTING 2
Here you see socket communication between the mobile Intel Edison and the RPi base station.
Intel Edison
IP address 192.168.1.100
try:
s = socket.socket(socket.AF_INET, \
socket.SOCK_STREAM)
s.connect((“192.168.1.113”,1035))
except socket.error as msg:
s.close()
else:
s.settimeout(1.0)
s.sendall("readyToTX")
fo = open("fingerPrint.txt", "r")
fingerPrint = fo.read()
fo.close()
s.sendall(fingerPrint)
s.close()Raspberry Pi
IP address 192.168.1.113
s = socket.socket(socket.AF_INET, \
socket.SOCK_STREAM)
s.bind((“”,1035))
while True:
s.listen(1)
conn, addr = s.accept()
command = conn.recv(1024)
if (command == "readyToTX"):
macData = conn.recv(1024)
fingerPrintFileName = "fingerPrint.txt"
fo = open(fingerPrintFileName, "w")
fo.write(macData);
fo.close()
conn.sendall("ack")The result of this interaction is that the RPi has a current copy of the fingerprint which it uses to compare against the exemplars. I experimented with several variations of the k-Nearest-Neighbors (kNN) algorithm to find one that gives each exemplar a score that fairly measures its similarity to the fingerprint. To illustrate some of the challenges, consider the fingerprint and two exemplars shown in Table 2.
The homeOffice and homeKitchen columns represent exemplars. Each entry contains a MAC address and signal level.
Since exemplar scores are based on similarity to the fingerprint, the scores in the first two rows of Table 2 are the absolute values of the difference between the signal levels of the exemplar and fingerprint. For example, the homeOffice scores 3 (78–75) for the MAC address C8:D7:19:46:7B:77. The third and fourth rows of Table 2 are examples of a WAP appearing in the fingerprint, but not in an exemplar. In this case, “penalizing” the exemplar’s score by full value of the corresponding fingerprint signal level does not fairly reflect the presence of a threshold for the signal level (see Figure 1). For example, when forming the exemplar for the homeOffice, the signal level for MAC address CC:A4:62:DA:4C:60 may have been just below the signal threshold of 30. Consequently, I set the score equal to the signal level in the fingerprint minus the signal threshold. This approach has the additional benefit of minimizing the impact of weak signal levels on the scoring function. The final case, in the last row of Table 2, is an example of a WAP that appears in the exemplar, but not in the fingerprint. I decided to simply discard this score from the exemplar. My justification for this choice is admittedly weak; I wanted to keep the presentation of the scoring information (see Figure 5) congruent with the format in Table 2. Finally, the scores for each exemplar are added together and, since a lower score mean a better match, show that the homeOffice is a best match to the fingerprint.
The Executive interface enables status review and control of the tracking system.
EXECUTIVE INTERFACE
For this project, I created the executive interface shown in Figure 5. This web page gives an administrator the ability to examine the status of the system and configure the system. The process to connect to the mobile tracker and the process to analyze the fingerprint data must be running in order to produce location information for the user. Through some tricky Python and PHP programming, the top table allows these processes to be started and stopped. The fact that these two processes automatically run at startup, helps the system meet the usable requirement. The largest table in Figure 5 compares the current fingerprint to the exemplars. The MAC entries in the leftmost columns are colored to reflect their signal level (green = strong, yellow = weak). The cells in the matrix are colored red when a WAP appears in the fingerprint, but does not appear in the exemplar; otherwise, the cell is colored green or yellow. A cell is colored yellow only if its score is higher than if the exemplar did not have that WAP (higher than a corresponding red entry); otherwise, the cell is colored green. The exemplars are sorted left to right based on their score and top to bottom based on their MAC address. The lowest-scoring exemplar is selected to be queued up creating a history of previous locations with sample 0 being the newest and sample 4 being the oldest. I choose five locations in order to effectively low-pass filter the location analysis as explained below.
In Figure 5, the table with the “Current location” row is also presented in the user interface. Its contents are derived mainly from an analysis of the queued locations as follows. The Current location is maintained until there is overwhelming evidence that it is incorrect. Overwhelming evidence is when all 5 queued locations are the same and differ from the currently reported location. When all five queued locations agree, there is a high confidence in the location estimate. Medium confidence occurs when four out of five locations agree, and low confidence is anything less than or equal to three out of five locations agreeing. The tracker is assumed to be moving when there are more than two distinct locations in the queue. Finally, the last updated field is the difference between the timestamp of the fingerprint.txt file and the system time. All this information not only gives the user information about the trackers location, but gives them some confidence that they are receiving accurate information.
The bottom-most table in Figure 5 contains three configuration options. The Mobile Tracker Configuration uses the socket connection described in Figure 4 to send the Intel Edison a command to change the WAP polling interval. A higher polling rate corresponds to a higher power setting. The User Interface Configuration enables the administrator to post a message to users. In addition this submenu allows tracking to be disabled. This feature was needed in order to meet the configurable requirement of the project. The rightmost columns contains create, read, update, and delete (CRUD) interfaces to the exemplar data store. This feature was needed in order to meet the modify requirement of the project. The web code for this feature, in Listing 3, deserves some further discussion.
Listing 3
A snippet of the PHP script from the executive interface that adds a new location to the exemplar data store.
<form action="" method="POST">
<input type="text" name="add_name">
<input type="submit" name = "submit" value="Submit">
</form>
<?php
if (isset($_POST['add_name'])) {
$name = $_POST['add_name'];
$name = escapeshellcmd($name);
$name = escapeshellarg($name);
$cmd = 'sudo python macDataStoreAdd.py ' . $name;
$response = shell_exec($cmd);
echo "<pre>pi@raspberrypi:/var/www$ $cmd</pre>";
echo "<pre>response = $response</pre>";
}
?>
The pair of escapeshell commands combine to close a serious security vulnerability referred to as command injection. Without them a malicious user could run arbitrary Linux commands on the Raspberry Pi by inserting a “;” character (the Linux command separator) between a location name and a malicious command. The escapeshellcmd escapes special character like a semicolon. The escapeshellarg quotes the argument, converting strings with spaces into a single string. This has the added benefit of allowing location names with spaces.
The user interface is fairly simple. It consists of the “Current location” table from Figure 5 (if tracking is enabled) along with the latest user message and some other fixed HTML (like my weekly schedule).
EDISON POWER CONSUMPTION
When compared to a low-and-slow, 8-bit microcontroller, 32-bit CPU cores running embedded Linux are power hungry. Given that the Edison is powered from a diminutive 3.7-V, 400-mAh battery, I needed some solid data on power consumption to tune the system for extended use. Instead of just accepting the information provided online, I did some testing. I disconnected one of the battery terminals and inserted my uCurrent in series. The uCurrent uses a cascaded pair of Maxim Integrated MAX4239 op-amps, with a bandwidth in excess of 300 kHz, to amplify the current through a sense resistor into a voltage. Figure 6 shows a long 10-s oscilloscope trace capturing the current consumption during the 4 s required to execute iwlist, followed by a 5-s pause.
The current consumption of the Intel Edison during 4 s of high wireless activity followed by 5 s of low activity. The vertical scale is 1 mA/mV.
I was surprised at the significant variability of the current consumption; there are instances when the Edison is drawing more than 350 mA! Zooming in on this trace reveals a roughly periodic 50 kHz, 60 mA fluctuation of current. Using the oscilloscope cursors, Table 3 lists my best estimate of the average current consumption of the Intel Edison under a variety of operating conditions.
Intel Edison current consumption from a 3.7-V battery under a variety of operational conditions.
I was surprised at the significant variability of the current consumption; there are instances when the Edison is drawing more than 350 mA! Zooming in on this trace reveals a roughly periodic 50 kHz, 60 mA fluctuation of current. Using the oscilloscope cursors, Table 3 lists my best estimate of the average current consumption of the Intel Edison under a variety of operating conditions.
The average power consumption of the Intel Edison is the voltage of the battery times the weighted average of the current consumed while executing the iwlist and the current consumed while the Edison sits idle. With a 400-mAh battery and providing a 30-s idle interval between sampling, yields a little over 7 hours of running time on a single charge. While this does not exactly meet the energy requirement outlined earlier, it does get close enough to make this a usable prototype.
FURTHER WORK
My initial testing shows that it works well, but working with the professor tracker in daily use with be sure to reveal shortcomings and the need for changes. So if you point your browser to http://prof.bd.psu.edu, don’t be surprised if the interface has some changes. I would welcome your feedback on the project and suggestions for improvements. If there is enough interest, I’ll put together a follow-up article on tips and tricks for the Intel Edison that I found helpful in this project. Finally, I would like to thank Major Greg Brault and Lieutenant Colonel Rob Harder of the United States Air Force Academy for their help and inspiration with this project.
SOURCES
Edison Development Board
Intel |www.intel.com
MAX4239 Op-amp
Maxim Integrated | www.maximintegrated.com
W3006 WLAN Antenna
Pulse Electronics | www.pulseelectronics.com
Edison Building Blocks
SparkFun | www.sparkfun.com
FXP810 Antenna
Taoglas | www.taoglas.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2016 #306 – Get a PDF of the issue
— ADVERTISMENT—
—Advertise Here—
Chris Coulston holds a BA in Physics from Slippery Rock University and a BS, MS, and PhD in Computer Engineering from the Pennsylvania State University. He is an Associate Professor of Electrical and Computer Engineering at Penn State Behrend, project editor for Circuit Cellar, and author of several books and papers on electrical and computer engineering subjects. Chris completed this work while spending the past year teaching at the United State Air Force Academy.
