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.

Posted on

Ethan’s Status Report for 03/11

A lot of the time last week was spent on writing the design report. I started working on getting the front end of the project working, which is to do packet sniffing to identify access points, send beacon frames with TIM set up such that all devices connected to that access point responds (in order to quickly get a list of devices in the vicinity), and using those devices’ MAC address to get data such as ToF or RSS. Wi-Peep’s paper suggests that exploiting the TIM should get responses from the devices within the access points fairly quickly, but it seems that my setup is somehow incorrect since it doesn’t reliably work. I will work on getting these parts done next week, along with using the devices’ MAC addresses and picoscenes to get RSS data.

Posted on

Anish’s Status Report for 03/11

A significant chunk of time in the past week went into writing up the design review report and documenting our plans for the project. Because of limitations on timestamp capturing in PicoScenes that I don’t think we’ll be able to work around, I started looking into how we can use an ESP32 microcontroller to get similarly-precise timestamps, like is done in the Wi-Peep paper. I wrote some code to run the ESP32 in monitor-mode and take timestamps when the interrupt is received. I took some test measurements and noted it was significantly noisier than the Wi-Peep paper’s results; it also seems to vary quite a bit with changes to the optimization and driver settings for the ESP. Next week I will be looking further into if there are any more build-time settings that can be changed or other ways to improve the measurement quality.