Hardware components | ||||||
 |
| × | 1 | |||
| × | 1 | ||||
Software apps and online services | ||||||
| ||||||
| ||||||
| ||||||
Build a next generation IoT positioning system using only WiFi signals with these 4 easy steps!
- Assemble STMicro Nucleo hardware.
- Program the ready-to-go firmware.
- Sign up for a free Skyhook Wireless account.
- Configure firmware settings.
With this system you can walk, ride or drive around your own neighborhood or city to collect results and get a sense of how WiFi-based positioning could solve your IoT asset tracking challenges.
But before we get into the specifics, let's go over a little background material.
BackgroundNext generation IoT asset management devices will need to be smaller, cheaper and more robust. As part of this evolution, WiFi signals that permeate urban areas can now be used to offer a lower power alternative to GPS/GNSS positioning techniques employed in current generation asset management devices. Along with emerging LPWAN technologies, next generation IoT Smart City devices can be realized opening up a whole new set of use cases.
GPS trades off higher overall power consumption for more accurate positions. For many applications however, a less-accurate, approximate, position is acceptable, on the order of 10's of meters, in order to realize the long-sought-after months or years of battery life and small size.
A GPS module can take minutes to acquire the signals and data necessary to fix its position. The GPS's radio receiver is on during this entire time, consuming energy. If position fixes are frequent, the average current consumption of the module can be significant, and typically leads to relatively short battery lifetimes and/or larger battery requirements.
Compare to a system that sniffs existing WiFi signals. A WiFi positioning system works by passively scanning the environment for the periodic beacon packets that most WiFi access points (APs) emit. These beacons are free to be captured, and provide enough information to uniquely identify each AP. With a collection of AP beacon data in hand, an IoT device can forward that information to a cloud-based location lookup server to perform the triangulation computations using a database of known AP locations. WiFi location lookup providers such as Skyhook Wireless and Google use a variety of techniques to build and maintain their AP databases. This project will use the Skyhook "ELG" service.
When all is said and done, for about the same order of magnitude power consumption as a GPS module (10's of mA), the WiFi module can take a second to perform its scan. It is pretty obvious why we want to do this: increased battery life which leads to smaller, more compact and inexpensive devices.
Steps to complete the projectThis project will show you how to easily assemble an IoT device using STMicro components: STM32L1 MCU and SPWF01 Wifi module technology, load it with pre-built and ready-to-go firmware, collect Wifi AP data, and with your cellular-enabled mobile device, submit the results to Skyhook in real time for a location lookup.
The location lookup results are returned to the device and made available in either KML or CSV format. The KML data can be easily plotted on a map with free tools like Google Earth. The Skyhook service is an easy signup with free service for evaluation purposes. Drive or ride around your neighborhood and see what kind of positions you can get with only WiFi!
You can be performing WiFi positioning in your area with these 4 or 5 steps discussed in detail below.
- Assemble the hardware. Nucleo-STM32L152RE + X-NUCLEO-ID1M01 expansion board, about $40.
- Program the downloaded firmware binary.
- Sign up for a free account with Skyhook Wireless @ my.skyhookwireless.com and start a sample "ELG" project.
- [Optional] Setup your mobile device hotspot.
- Configure the firmware with your Skyhook project's AES key, User ID, and with your mobile device hotspot's WiFi credentials (SSID, passkey, security type).
Since this project already makes use of a WiFi module, we are also using it to contact Skyhook through your mobile device's hostspot. This is of course not how a real IoT device would work - it would instead use an LPWAN (we'll get to that on another project). We could capture the AP beacon data during a drive-around and submit the data to Skyhook afterwards, but we'd rather submit the scan results in real-time (like a real IoT device) to take advantage of behind-the-scenes functions like location smoothing and filtering. [Update: Skyhook's ELG service is currently stateless. Thus, batching the AP scan data to Skyhook would return the same results].
Step 1 - Assemble the hardwareAttach the X-NUCLEO-IDW01M1 to the NUCLEO-L152RE as shown. No other configuration is required. Connect to your PC/laptop/tablet with a USB mini cable and proceed to step 2.
Step 2 - Program the firmwareDownload the 'WPS Firmware Image' file (WPS_EVAL_STM32L1_SPWF01SA_v1.bin) to your PC, available from the attachments section of this project. With STM32-NUCLEO, you can drag and drop this file to the 'NODE_L152RE' mass storage device that appears in your file system. That's all we need to do here.
Head over to Skyhook's user portal and create an account. Here we want to create a new ELG project and record the two parameters we need to configure the firmware with: 'ELG Key' and 'Partner ID'.
Once inside, from your dashboard choose the "New Project" tile then "Precision Location".
When prompted for a platform, select "ELG" as shown.
Select a name for the project, click to finish setup. Your new project's dashboard will appear as below. Both 'ELG Key' and 'Partner ID' can be copied and pasted in a terminal emulator such as Tera Term in order to configure the firmware in step 5. Record these elsewhere for now.
The WiFI AP data collected by the firmware running on the NUCLEO hardware needs to go to Skyhook in order to get a location fix. The easiest way to do this is with your existing mobile device configured as a WiFi hotspot. NOTE! The firmware is designed to ignore your mobile device's SSID when submitting results.
The method to setup your mobile device's hotspot varies by model and manufacturer. This project was carried out with a Samsung Galaxy S8 using its default hotspot settings (WPA enabled). The default AP SSID and passkey as generated by the phone should be fine. Record these for step 5.
Step 5 - Configure the firmwareMake sure you have the following information in hand, perhaps in an open text file:
- Skyhook ELG Key e.g. 1BA3D7F013B321137CCD7DB7CE46A4F4
- Skyook Partner ID e.g. 78221
- Hotspot SSID e.g. SM-G951U4721
- Hotspot passkey e.g. kmss242j1
Get your terminal program running and connected to your NUCLEO-L152RE's COM port at 115200 baud. Reset the board and you should see the following if you've not configured anything before.
Starting wifi positioning evaluation platform
Cannot start: please set wifi settings with 'mta' command then reboot.
Press enter to see the command prompt '0000: Contiki>'
Use the 'mta' command to set the following parameters as shown.
0000: Contiki> mta set wifi ssid SM-G951U4721
OK
0000: Contiki> mta set wifi passkey kmss242j1
OK
0000: Contiki> mta set wifi sectype 2
OK
0000: Contiki> mta set device secret 1BA3D7F013B321137CCD7DB7CE46A4F4
OK
0000: Contiki> mta set device account_id 78221
OK
0000: Contiki> mta save
OK
0000: Contiki> mta get
Wifi ssid: [SM-G951U4721]
Wifi sectype: 2
Wifi passkey: [kmss242j1]
Device secret: [1BA3D7F013B321137CCD7DB7CE46A4F4]
Device account_id: [78221]
Device device_id: []
OTA update server: []
0000: Contiki> reboot
Rebooting the node in four seconds...
Waiting for Provision ready...
0000: Contiki>
Starting wifi positioning evaluation platform
Starting wifi module.
Connecting to AP: SM-G951U4721
Connection result: 0
Get wifi MAC.
Scan process stopped, waiting for start command.
0000: Contiki> skyhook start
0000: Contiki> Starting scan loop.
--- scan cycle 1 ---
>> Running WiFi Scan (0)...
>> Got 6 scan results
>> Running WiFi Scan (1)...
>> Got 5 scan results
>> Running WiFi Scan (2)...
>> Got 7 scan results
Connecting to elg.skyhook.com (0/3)
Result: 0
Sending location request 90 bytes
Wrote: 90 bytes.
Socket closed: 0
Read location response [0] 118 bytes
---------------------
latitude: 51.08321099
longitude: -114.15788799
street:
address: 49 Street NW
Adding location entry 1 (size=1)
Once they are set, they need to be saved with 'mta save'. Then type 'reboot' to reboot the device to start connecting your hotspot. Once connected, you may type 'skyhook start' to start acquiring AP beacon info and requesting location lookups every 10 seconds. NOTE: you could use your local home or office WiFi's credentials to setup a quick demo. It should return a position close to your location!
Firmware Design DetailsThe firmware running on the IoT device factors heavily into the quality of the location results because the location lookup result is only as good as the data it is based on.
To get the best set of Wifi AP data per sample period, the firmware application will perform 3 consecutive AP scans (each scan takes about a second) and populates a list of unique AP SSIDs sorted by RSSI. The top 5 APs according to strongest signal (RSSI) are submitted to Skyhook's ELG service. [Update: a random selection of APs may return better results than simply selecting the best in terms of RSSI.]
This is the system that provided the experimental results discussed below. There is a tradeoff between bandwidth (time-on-air) required to submit the detected APs and the location lookup result quality. More APs equal better accuracy but higher battery consumption due to increased TX time. The value of '5' was arbitrarily chosen for this first evaluation.
The WiFi application will scan for APs and perform a location lookup request with Skyhook's ELG server approximately every 10 seconds.
Experimental ResultsThe location lookup result data is printed to the console and also retained in an internal 512-element buffer. The buffer can be formatted as either CSV or KML and printed to the console with the 'skyhook print <csv | kml>' command. The KML data is suitable for directly pasting into an empty '.kml' file, which can then be loaded into Google Earth, as was done for the following screenshots.
The test data was generated by driving around my city (Calgary, Canada) on a very cold day. The Nucleo board was inside my warmed up car exposed through the back window as shown. I had a tablet connected to the board to both power it and capture kml data with Tera Term. My phone was setup as a mobile hotspot and left in a cup holder.
I drove through a variety of areas, including single-family housing suburban, through-fares with fairly wide right-of-ways, including parks on one side, as well as commercial/industrial zones. I did not go through downtown on this trip - that will be left for another day.
Shown below is the overall drive. The starting point was on the left side of the image, ending at point "78" in the bottom area of the image. There are a few gaps around areas where WiFi signals were not readily available, such as beside Nose Hill park and along Deerfoot. Regardless, the overall route is readily apparent. The end of the drive occurred on a local road overlooking downtown. You will notice a brief anomaly where the WiFi system appeared to select a few points that were across the river for whatever reason (I did not go downtown).
A zoomed in area within Brentwood (single family housing) shows good, accurate tracking as I drove along Northmount Drive @ 50 kph.
Another zoomed-in area along 32nd Ave and down Barlow, then west on 16th (Highway 1), all roads are larger through-fares. You can see where I stopped at lights as the points bunch up, then where I sped up as the points spread out.
Overall we see really good tracking in the denser suburban areas as well as the commercial zones. Along side parks, wider right-of-ways and highways the system was generally not able to make accurate position fixes or produce them.
The location fixes were for the most part estimated to be within 50 m of the actual location, and in some cases, within 10 m or less. There's a lot that goes into computing these position fixes, and what goes in determines what comes out. Setting a limit 5 APs is going to negatively impact the result obtained compared to that obtained, for example, with data for 10 APs. It should also be noted that many APs produce two unique SSIDs (such as 'Guest'), which can quickly clog up a scan list with redundant information. The tradeoff between battery usage (on-air time) and the number of APs to get the optimal result will need to be investigated.
It would be really interesting to see this system work in smaller roads / denser areas, industrial complexes, inside buildings such as malls and of course downtown! I'll leave that to you.
WiFi positioning did perform well, and coupled with some on-board processing and a little sensor fusion, a low-power, low-cost IoT asset tracking solution can be realized. IoT's killer app anyone? Happy tracking!
Note: if you'd like to see features added to the firmware, or to report issues, please head over to the WPS Firmware Project repository on GitHub and submit your request or issue.
Comments