Posted on

Team’s Status Report for 2/25

Going into next week, we will be working on the design report with the feedback we got from the presentation. Mainly, we will be refining our test plan and making sure all of our metrics align with the tests we are proposing.

The most significant risks right now come down to integration with all of the hardware we are using – the two antennas, the RasPi, and our WiFi card(s).  We will order an ESP32 card as a back-up, which we know we can get working based on some of our reference papers.

We’re considering maybe using a different WiFi module for measuring ToF, depending on whether we can get a rough ToF estimation working on picoScenes – the free implementation only comes with rough time measurement, not the 320MHz fine-time measurement possible with WiFi. We would probably end up buying an ESP32 to use and only 1 antenna for measuring ToF, but we haven’t committed to making the change yet. This would increase our implementation time by around a week.

To date, we are mostly up to speed with deadlines, with Thomas falling slightly behind on the localization front due to changing requirements/system topologies. He has started working with a sample data set from Intel to prototype the localization system until we can get real data to work with, which should be able to make up for lost time. Ethan can now start working on scripting measurements now that Polite Wifi is working. Teaming is generally working fine, since most work in the beginning can be done individually and we are communicating via Slack. Once integration starts, we will be working more in teams.

Posted on

Thomas’s Status Report for 2/25

Investigat ed where the errors in our current localization scheme were coming from. It looks like the SIFS (short interframe spacing) time or multipath time is not accounted for by our current data set – which will reflect real-world conditions betters, thankfully. Looking at the plots below, each AP (Access Point) has some spread to the error, with the mean error differing between each unit. The solution to this will be adding a constant error term into the MLE optimizer, which, as it seems, is different for each AP.I’m a little behind schedule now due to this issue. I can’t prioritize this class over exams/travel next week, but I will be working on the localization over spring break.

I hope to integrate the SIFS time into the MLE problem we are currently solving for the location of targets, which will hopefully get the 2m performance I discussed last week.

Posted on

Anish’s Status Report for 2/25

I had a lower time availability this week due to other project deadlines and midterm exams but I still made some progress. I gave the design review presentation on Wednesday and looked closely into the feedback from that (as well as the proposal presentation) that was provided to us later in the week. I took some measurement traces with the directional antenna to validate that it does indeed roughly match the expected radiation pattern (noting that it does not actually work directionally on 5GHz; only on 2.4, as expected). I also investigated how to capture precise timestamps from the WiFi card – we found that the PicoScenes library has some restrictions on timestamp capturing which we may need to work around to do ToF-quality measurements.

Although doing tasks slightly out-of-order, I feel generally on-track in terms of progress relative to the schedule. Next week I hope to figure out how to capture timestamps accurately and with low jitter, as well as start prototyping the AR self-localization aspect so that we can use it to take realistic data traces once the Polite WiFi implementation is complete.

Posted on

Ethan’s Status Report for 2/25

This week, I worked on getting the Polite Wifi mechanism to work. I got the usb dongle and started working with it, but it was harder than I thought to get it to work, most likely due to driver issues. The dongle had official driver support for windows and mac, but not linux, and there were many different open-source drivers that claimed to work but apparently did not. While trying to make the packet injection work and messing with the driver and network interface settings, the Ubuntu setup I had broke and was not able to boot up, which forced me to reinstall everything I had set up. I also don’t have much experience with wifi in particular, so it took a lot of trial and error to learn how Scapy works, or how to work with the network manager and the network interface in ubuntu (the OS we’re using because PicoScenes only works in a specific ubuntu version with a specific kernel). Eventually with the right drivers and right setup for the network interfaces, I was able to confirm that the polite wifi mechanism did indeed work (shown in the screenshot attached).

Next week, I will work on scripting MAC address sniffing and time measurement with the polite wifi mechanism. I did get some of the orderings mixed up in terms of what I should do according to the schedule, but looking at the number of days I’m not falling behind.

Polite wifi in action:

The packet that was sent via Scapy:

Posted on

Ethan’s Status Report for 2/18

I wasn’t able to spend much time this week due to conflicting deadlines. I finished setting up picoscenes initially, and then mostly worked on getting the Polite Wifi mechanism to work, but my understanding of Scapy (python library for packet sniffing and injection) is still incomplete and my laptop only has one wifi card than can’t do packet injection and monitoring at once. I needed a wifi usb-dongle for myself anyway, so I ordered one with the same wifi chip used in the paper. Having one would also help with PicoScenes as it requires me to set my one wifi chip in my laptop in monitor mode, which disables me from using the internet. It should be arriving this weekend, with which I would be able to test better.

Despite this week not being too productive, I am still on schedule. For next week, I plan to use Scapy to successfully sniff mac addresses of devices, and also get polite wifi to work. I also will work with PicoScenes to have some scripts that can measure CSI. Courses that helped the design for me were 18-213 and 18-349.

Posted on

Team Status Report for 2/18

We spent some time this week reviewing the feedback from our project proposal and ensuring that our project scope was well-defined, including constraining our use-case to static devices in an indoors environment, but also adding the requirement that we be able to distinguish multiple devices physically close to each other. These are already requirements that we had in mind, so the main change is just documenting them properly. As a result, there are no added costs or schedule changes.

We were able to test the CSI data produced by the AX200 wifi card using PicoScenes, and saw that moving the device around / moving ourselves in front of the antenna would affect the measured signal-strength and phase data; so we know that we are able to get meaningful measurements. We also verified that we are able to get individual signal-strength data from each antenna, which is useful for verifying

The main risk we are worried about is whether the fidelity of our data (in terms of noise and quantization) will be high enough to get the level of accuracy we want. Our contingency is based on the fact that we have a variety of different measurements which we are fusing together, so we’re expecting that with all the data combined, we’ll be able to get sufficient accuracy and meet our 1m requirement.

The main principles of engineering we’ve been using so far include electromagnetism and RF (in terms of choosing antennas and the considerations of multipath propagation); signal processing (interpreting the data we get from the wifi card, phase-difference-of-arrival, etc.); and some probability/statistics (in implementing the filtering algorithm to deal with noise in our measurements).

Below image shows our current experiments using an open-source dataset (“Intel Open Wi-Fi RTT Dataset“) of time-of-flight data between client devices and access-points, and attempting to find the location of the APs using this data.

 

 

Posted on

Thomas’s Status Report for 2/18

This week, I created the grid-based localization scheme we will use for finding these devices. Right now, it just adds a likelihood based on the time-of-flight of the devices, achieving about 5m of accuracy. We hope with the higher clock frequency of our AX200 board and the directionality we will have from the antennas, we’ll be able to improve even further. This puts us on schedule, and allows me to spend next week working on improving the localization system and handling the ToF measurement processing from the data in a more sophisticated way than we currently do it.

By next week, I hope to have localization accuracy improved to around 1.5m, and through a system that smooths the ToF better than the knowledge-of-the-crowd (averaging) we currently use.

I tested the implementation on an Intel RTT Dataset (Nir Dvorecki, Ofer Bar-Shalom, Leor Banin, Yuval Amizur, June 8, 2020, “Intel Open Wi-Fi RTT Dataset”, IEEE Dataport, doi: https://dx.doi.org/10.21227/h5c2-5439) and attached a picture below: top left is example output, bottom left is our system, the right-hand side is a visualization of what the likelihood function looks like.

Posted on

Anish’s Status Report for 2/18

This week I worked on trying to implement the “Polite WiFi” attack where we are able to ping devices with 802.11 null packets and get an acknowledgement packet in response (from which we can measure time-of-flight and signal strength). I’m still having some trouble with this; it seems that the library I’m using to send packets (Scapy) is not playing well with my wifi card, and I was constantly getting mangled MAC addresses when sending a null packet between devices. I am continuing to work to debug this. I also set up a hardware test platform with multiple antennas connected to an AX200 wifi card, and tested that I could successfully take measurements across the antennas with Wireshark.

As of now we are on-schedule and making solid progress, and I don’t feel that we need to make any corrections to the project schedule.

In the next week, I hope to figure out the issue with the wifi pinging and be able to measure ToF to different devices; and then start collecting real data using our antenna setup which we can start analyzing with the filtering algorithms.

The engineering principles I’ve been using heavily up til now includes electromagnetism/antennas (which I learned in Physics 2 and 18-220) as well as networks and wireless protocols (which I learned about in 18-213, 18-349, and 18-649).

Images attached of setting up the AX200 card with external antenna connectors, as well as a multi-antenna setup that I’ve been experimenting with using for measurements.

 

Posted on

Anish’s Status Report for 2/11

Most of this past week was spent on literature-review and background – including the proposal slides and working to refine our project plan afterwards. I looked into different hardware options we could use with PicoScenes (particularly the differences between the several Intel WiFi cards) as well as antenna hardware options, and ordered the relevant WiFi card and connectors (as to not have to cannibalize Ethan’s laptop for the final prototype). I also started experimenting with Wireshark and looking at what relevant metadata we can extract about devices. I feel confident in progress so far and being on-track with our schedule. Next week I will continue working with PicoScenes and (once the new WiFi card arrives) testing with varied physical antenna configurations to get some results which Thomas can use to test the processing algorithms against.

 

Posted on

Thomas’s Status Report for 2/11

Good progress this week – I presented on Monday about our overall target and we got some excellent feedback from Professor Kim. We refined our use-case requirements and specified the MVP project a little more tightly afterward (less focused on sensing, more focused on IoT devices specifically). I am still conducting my literature review of WiFi localization and deciding which methods we will use. I still think the time-of-flight-based methods presented in WiPeep, expanded for multiple antennas, will be our best option. Next week I will start creating the actual MATLAB code to run for the processing.