This week I prepared for and did the final presentation. Other than that, I’ve been trying to work with one of the devices that we bought for which the pinging seemed to be not working with. Before the final demo, I will be working on getting the devices to work with our system, test the integrated system, and work on writing the paper and preparing for the demo.
Team status report for 04/29
We’re all caught up to our requirements. We spent last week polishing our system and getting it ready for presentation. We will be recording our final data to use tomorrow now that we are all in Pittsburgh.
We will reuse the theming from our final presentation slides for our poster, which is under construction.
The worst-case scenario is our demo breaking the day it gets shown. We will make sure the video can be used as a substitute in case of failure.
Our tests involved unit tests for individual components, i.e. device detection, device pinging, device localization, and self/AR localization, and integration tests. For device detection, we put several devices in a network and tested if it detected all the devices; for pinging, we pinged a known device and observed the ACK packets; for device localization, we localized a known device at known location, and measured the error from the expected to the actual location; and for self and AR localization, we put an AR object in a known location and checked visually. For integration testing, we moved through different traces with devices in different locations and networks.
Ethan’s status report 4/22
This week we worked on preparing for integration and the final presentation. For integration we worked on testing individual parts and putting the pinging and localization script together. We are not fully finished with integration in that we still need to connect having multiple device detection with localizing a device, but other than that we’ve seen steady progress. For my part, I’ve tested that device detection works on multiple devices with the devices we bought. Next week, we will do the presentation and work on finishing integration and making it presentable for the final demo, as well as start working on the report.
Ethan’s status report 4/8
This week, we worked on getting a demo working and started working on integration. The demo was integrating the ESP, pinging, and localization to get a sense of how accurate the localization algorithm is. We decided to not use PicoScenes as we were able to get data we need from the ESPs, so some of what I’ve been doing is no longer useful, but it is good that we can get all necessary data from the ESPs since I wasn’t able to figure out a way to make PicoScenes detect the ACK packets from our pinging. Meanwhile, I worked on testing and cleaning up the device detection script, which it does work. I’ve changed from manually sniffing beacon frames to using iw for the access points, since manually sniffing can sniff access points from adjacent channels which show up as two same access points on different channels. I’ve also tested how long it takes for the devices to respond to my beacon packets, and it seems like about 7 seconds is enough. This can’t get too long, as there may be arbitrary number of access points and our aim is to have everything (from device detection to localization to visualization) be within 5 minutes.
I am testing my part on my local network, and have verified that it detects my phone and ipad consistently. More tests would be possible when our device arrives, with multiple access points that we have control of. Next week, we will continuously work on integration, and I will personally look at device identification to show the users, such as manufacturer, the transmission rate, etc. I am a little bit behind on the device identification, but it should be possible to catch up by next week.
Team status report 4/8
This week, we worked on getting the demo working. Our demo consists of our laptop pinging a phone, and measuring ToF of the ping from an ESP; the data from the ESP is then fed to a MATLAB script that localizes the device. We were able to get localization within 1 meter accuracy in the demo, and we also video recorded the process. We started working on integration of our individual parts, and we ordered some IoT devices that we will use for testing our integration as well.
Not much was changed from the design, except that we could not get PicoScenes to work so we are using ESPs to do the ToF and RSS measurements. We got two ESPs that we worked with, and there is no significant cost because we already had more than enough budget.
Ethan’s Status Report 4/1
This week I worked on cleaning up the scripts I wrote. I couldn’t figure out a way to make PicoScenes detect null/ACK packets, so we might not be able to use it for ToF measurement. I think we can use it to measure RSS data because it doesn’t really matter if the timing is not too accurate, but at that point perhaps using PicoScenes is more of a burden than what it’s worth. For next week, I’ll be working on preparing for the demo and cleaning up rest of the scripts.
Team Status Report for 03/25
This week we started working on integrating our individual parts. We are a little bit behind since some of the parts aren’t working optimally, but we at least have prototypes of the ESP32 pinging, Scapy device analysis, 3D localization, and the localization filter (in Matlab) that we are working on integrating together.
Next week we will be working further on integration and also testing our components with the testing devices we ordered. We hope to have a proof-of-concept (even if it still requires some tuning and polishing) of all of the components integrated together ASAP. Additionally we will work further on building out the end-user interface.
Most significant risks right now are that PicoScenes is not detecting our ping packets, which our approach for measuring ToF and RSS data depends on. The backup would be to rely on a combination of Scapy and the ESP32, which is less accurate but at least we know that it works.
Ethan’s Status Report for 03/25
This week I worked on getting the measurement script working as a whole. Currently, for each channel (1~11), the script sniffs for access points, inject a beacon frame with its TIM bitmap set for each access point to get responses from all the devices (thus getting all devices connected to the access point), and send each device a null packet to get a response (for the ToF and RSS measurement). Current issue that we’re facing is that while the null and ACK packets clearly exist as detected by wireshark and scapy, PicoScenes seems to be failing to detect those packets for some reason. Another possible way to measure might be using the RTS/CTS instead of null packet/ACK for the measurement as described in the polite wifi paper, but it might be only possible with an unassociated device.
The outstanding issue currently is whether PicoScenes can be used to detect the null/ACK packets from the polite wifi mechanism, because without that we may need to find a completely different method.
Ethan’s Status Report for 3/18
This week I wasn’t able to get too much done due to personal reasons, but continued to work on getting the scripts working. Getting the access points and the device connected to that (within 2.4GHz) with the method we designed seems to work, at least testing with my own router and my tablet, but I would like to test on more devices to test that it can reliably detect all the devices under the network. I’m also working to get the script working for using PicoScenes to get CSI (and therefore RSS) from the polite wifi exploit we have. I planned to have it finished by this week, but it seems like it will take another week to get it done.
Team’s Status Report for 03/11
Currently the risks are getting ToF measurements that are not accurate enough, and integration of individual parts that we have been working on.
We’ve committed to using ESP32 for our ToF measurement, as the measurement from PicoScenes would not be accurate enough. Additionally, since PicoScenes only runs on a specific linux kernel version with a specific ubuntu version, we are not going to use Raspberry Pi. The changes are documented within the Design Report. As mentioned in the previous status report, this change would cost us about 1 week of implementation time.
Since we decided on using ESP32, we will have to learn to use its API, but its documentation is fairly well done so it would not be a significant risk.