Author: asinghan

This week we did our final presentation – we all helped Ethan prepare the slide presentation for that. Other than that, I have been working on refinements to the user-interface so that we can easily show people how our system works during the final demo (by visualizing the internals of the sensing and algorithm). The other thing I have been working on is implementing a few of the remaining unit-tests that we still need to run to validate our system against our design requirements.

I feel like we are on schedule; in the next week we will work on the poster, final report, and finish up running the unit-tests (device detection, as well as the integration-test for accuracy).

These past two weeks were extremely productive – I finalized our hardware stack into a small, battery-powered unit (see the pictures in our “Team Status Report 04/22”) that attaches to the back of the user’s phone. The processing stack runs on a laptop, which can be anywhere in the vicinity (the user doesn’t have to carry it around the room when doing the scan); and the laptop connects wirelessly to the rest of the electronics using a 900MHz (ISM band) radio. I refined the firmware for the ESP32 to use this wireless link to talk to a driver (implemented in Python) on the laptop, as well as programming the ESP8266 to send out the pinging packets (hence completing the time-of-flight loop).

I feel like we are very much on schedule as our integration-testing all works – we can walk around a room with the sensor for ~4 minutes, and see in the AR view that the Wi-Fi devices are located to within the 1m accuracy. There are a few points left to be refined during the next week, including nicer visualization (both on the laptop and in the AR space) and making the device detection run fully asynchronously and feed into the rest of the stack, and after that it’s just working on our report and unit-tests.

This week I made substantial progress on the system integration. I ported the pinging-initiator code to run on an ESP8266, and added an interface to configure and pull data from the ESP32+ESP8266 combo, over the UART, in real-time (the need for two microcontrollers comes from the inability to precisely timestamp outgoing packets, so we must send packets from one microcontroller and timestamp both the request and the response on the other). I’ve tested this against the rest of the system (by generating CSV files and piping them into the MATLAB pipeline) and it works quite well in terms of efficiency and reliability.

My next step is to finish integrating it with the rest of the stack by completing the wireless interface (which means the computer running the system doesn’t need to be carried around with the user while they are doing their scan) and writing the Python interface to allow integrating it with the device-detection and localization code. I’m a little worried about wireless reliability with the XBee radio I’m currently using, but there should be a way to make it work with a proper handshaking interface. As such, I feel like we are pretty on-schedule although will need to do substantial testing and debugging-integration in the next two weeks to get everything working.

The testing we need to do once everything is working is to walk around in a room and collect data; and then take various subsets of this data (to test for different timescales and movement patterns) and determine the accuracy of locating the different devices. This, combined with some unit-testing of the self-localization and visualization accuracy, should allow us to quantifiably verify our use-case requirements and metrics.

Over the past week I worked on fixing some bugs in the ESP32 code and using it to start collecting data traces to test our algorithms with. It works better than expected; after filtering outliers and doing smoothing, the results are pretty consistent with what they should look like (at least over a several-meter range). We’re still trying to get it working on short ranges as well. There are no major roadblocks that I see blocking us going forward. I also started taking data measurements with the Yagi directional antenna to see if that data can be useful to our final algorithm or if the ToF data is sufficient.

In the next week I’m hoping to work on the end-user interface and figure out how we’ll actually stream the results out of our algorithm and display it to the user.

This week I was attempting to figure out how to get PicoScenes to detect the NULL/ACK packets from our pinging attack in order to use it for measuring the time-of-flight to maximum possible accuracy. I was not able to make much progress on this because I kept running into some other issues with PicoScenes where it would crash randomly and sometimes crash my other network interfaces with it (I was initially using a wired connection to SSH into the machine with PicoScenes); I’m still trying to fix this (possibly related to other configuration on the computer; restarting seems to help but the problem does sometimes come back).

I did clean up the ESP32 code a little bit, which, while not the best (very noisy data), is an option to at least start testing full system integration. It’s still unclear whether there’s a more effective way to handle dealing with multipath on the results from the ESP32.

I am slightly behind schedule which I hope to rectify in the next week by spending more time debugging and make a final decision on whether PicoScenes will work, or if we need to rely fully on Scapy + ESP32 for everything. There is also the open question of whether the directional antenna will buy us any more useful data. Next steps after that is to start prototyping the user-interface where we will actually show the results to the user.