Posted on

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.

Posted on

Anish’s Status Report 3/25

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.

 

Posted on

Thomas Status Report 3/25

I couldn’t get the hardware to start integrating the entire system. Instead, I focused on getting the AR portion working, since, as I said last week, I think the localization system is as good as it will get without improving with real data. Currently, the AR portion is a python script, able to do self-tracking with updates every 50 mS and overlay spheres when a ‘target location’ is passed into it manually.

Next week will be doing what I should’ve been doing last week, integrating the system together and getting the basic ToF measurement working. Since PicoScenes doesn’t seem to be able to work with ACK packets, I’ll just reimplement the Scapy code already written by other members onto the Esp32.

Posted on

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.

Posted on

Team Status Report 3/18

We cleared out a big obstacle this week – doing ToF measurements. We were donated a copy of PicoScenes Premium, which will allow us to integrate ToF and RSS sensing on the same platform/WiFi chip. This will make our system cheaper and simpler to implement than our previous plan of using an ESP32 chip for ToF.

Next week we will be actually wiring and hopefully starting to run our physical system. We feel like we’ve reached the limits of what we can do theoretically so we need to start collecting physical data to get feedback on our system.

Most significant risks right now are that our progress from our individual work may not transfer over into the integrated implementation. Now that we understand the solutions and how they work, we think that we would be able to reimplement them much quicker than our first time.

Posted on

Anish’s Status Report for 03/18

I reached out to the PicoScenes developers and was able to get a donated PicoScenes license (which avoids us having to deal with the issues of the ESP32). The high-precision clock sampling seems  to work and I’m able to read the relevant packet metadata from Python; however it is limited to 40mhz clock speed (because we are on 2.4ghz which has limited width bands). It also does not detect our ping packets for some reason (possibly due to them being malformed packets).

Next week I’ll be working on figuring out how to work around these two issues (the packet issue would likely be by formatting the packets to have additional fields so PicoScenes parses them correctly, but I’m still unsure how to deal with the 40mhz limitation); that should bring us to a point where we can collect data to test our algorithms against.

Posted on

Thomas Status Report for 3/18

Hello.

Currently, my main problem is I feel like the intricacies I’m testing are mainly on this current data set and may not apply to our finished product. I’m going to try and spend next week focused on product assembly. Hopefully, by the end of the week, we will have a working setup to collect data which I can then use to test my localization algorithm.

I’m still investigating the larger errors in the localization. It looks like our data set has errors that linearly correlate (r=0.519) fairly strongly with each other. This means that targets that are further away under-estimate their locations, while targets that are closer over-estimate locations. So, in data traces where we have very directional samples or are slanted towards being far or close, we will see systematic errors. I still need to think of a way to address this, but I think it will involve some weighting based on the ‘diversity’ of a location for each point. So, every ‘location’ which was scanned contributes an equal amount to the final total.

Posted on

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.

Posted on

Thomas Status Report 3/11

I spent a lot of time this week on the design report, redoing our architecture figures to be more detailed and discuss through all subsystems. The report also gave me a chance to formalize all of the equations I’m using for my localization system, which will hopefully make it easier to explain and demonstrate how it works in the future.

I got a chance to implement the improved ToF-based ranging (with SIFS measurement including, as discussed in last week’s post) and even without angle, we seem to be getting close to the margin of performance which we expect. There’s currently an error a median error of around 1 m in both x and y, with some systematic bias based on where the access points are. I’ll be looking into the more extreme cases (namely the middle and bottom) to see if we can detect the faulty measurements that are contributing to the shift in position, either through restricting the SIFS measurements, restricting longer ranges (more likely to be NLoS), or balancing samples depending on the transmitter’s location at the time.

Posted on

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.