Every WiFi chip needs to be able to synchronize to the received signal down to a few I/Q samples (the remaining synchronization error is accounted for by the cyclic prefix of OFDM). For example, with 40MHz of bandwidth, there is an I/Q sample every 25 nanoseconds (the wave travels 7.5m during that time), so the level of synchronization will be on that order. The ESP32 reports the time of arrival, the code for extracting a nanosecond-precision timestamp is here: https://github.com/ESPARGOS/pyespargos/blob/main/espargos/po...
Additionally, you can use the phase information in the estimated channel coefficients (CSI) to determine the more precise time of arrival. Very briefly, a time delay in time domain will be visible as a frequency(=subcarrier)-dependent phase shift in frequency(=subcarrier)-domain. Now synchronization is only limited by impairments like thermal noise and phase noise. In practice in nice lab conditions, the time of arrival accuracy is on the level of <<1m.
On top of phase differences between subcarriers (--> timing information), we also measure phase differences between antennas, which provides angle of arrival and, with multiple arrays, phase of arrival information.
You can go even further by measuring phase differences between subsequent packets, which provides frequency offset and Doppler (--> velocity) information. I have some nice results on that, but that's a topic for the future ;)
Thank you for your reply, I have been reading the code and there are some things that I am not sure to understand.
- The Espargos code uses rxstart_time_cyc & rxstart_time_cyc_dec for the ns timestamp calculation
- Both values are not documented in the Espressif code and just marked as /*< reserved */
- The timestamp parameter is documented but it is in "microseconds"
Is there anywhere I can find more documentation on the "rxstart_time_cyc" and "rxstart_time_cyc_dec" fields? Are these cycle counters from the wifi chip?
I'm currently experimenting with ESP32-C5 engineering samples provided by Espressif, so hopefully some future ESPARGOS revision will be 5GHz-capable :)
But yeah, as far as I can tell, the chip can only extract CSI from WiFi (unless there is some hidden raw I/Q sample debug mode or something).
This project is amazing! I know there's some prior art, but I feel like I've never seen anything wifi-related moving so... smoothly? (With that high of an update/sample rate, I guess?) as your visualizations do.
I do have one question that wasn't quite clear to me, in case you happen to see this. There's a bunch of mentions of Channel State Information, but Google doesn't give a ton of info on it. So I'm just wondering, is CSI a "client-side" thing provided by the ESP32 for any Wi-Fi connection, or is it some special protocol feature that the AP or client have to enable?
Most wireless standards transmit some kind of pilot sequence next to the payload. A pilot is a sequence that is well-known to both TX and RX, and which allows the receiver to estimate the effect that the propagation has on the signal. The channel estimate is then used for equalization, i.e. undoing the channel effect.
For WiFi, some of the pilot symbols are called L-LTF (802.11g+n) and HT-LTF (802.11n). Every packet contains them as they are needed for successful communication. The ESP32 can provide channel estimates based on L-LTF and HT-LTF for any packet it receives. No need to enable anything, you can get CSI from every packet.
I've been pondering over the idea of offering the option to use physical device, like e.g. a Bluetooth bracelet, for contact tracing in addition to apps.
For contact tracing to have an impact at all, we need a quite large percentage of the population to use one of these apps.
Even if 60% of the population had some kind of app installed and this app worked properly, we would still only detect just 36% of all new infections, since both parties (infected person and person to be infected) need to use the app.
There is a significant portion of the population that does not want to or cannot use such an app, e.g. the elderly, kids too young to have their own smartphone, people with certain disabilities, people that can't carry their phone with them all the time (e.g. while doing sports / working) etc.
This population can still be relevant in spreading the virus - for instance, when loosening lockdowns, young children attending kindergarten / school can bridge the gap between families.
Moreover, even among those that own a smartphone and that want to use the app, I just can't see it all work flawlessly.
Outside of the tech bubble, I see many people with older Android / iOS versions that don't receive updates (which might be crucial for contact tracing to function without having to keep the app open at all times) or people simply failing to install updates.
We also don't want the app to be too sensitive (an infected person that happens to be at the opposite end of the same subway car shouldn't trigger quarantine for you), but also not too insensitive (people might put their phone in handbags or attenuate BLE radio waves with their body).
I think that these problems could be solved by offering something like a standalone Bluetooth bracelet, compatible with whatever App becomes the standard.
It should be possible to mass-produce these relatively cheaply (<5$, which a BLE beacon currently costs).
They would use a Bluetooth chip with know characteristics and are worn at a defined location (wrist), so it's going to be much easier to correctly tune their sensitivity.
The time-to-market will of course be longer than that of a potential app, but it currently seems like we're going to have to live with the virus for a couple of months to come.
The only technical problem I see is that the physical bracelet would need to receive a (trusted) "list of infected IDs" somehow.
Maybe a mesh network of bracelets with smartphones as information providers could work? Maybe bracelets could connect to public WiFi? Or maybe we could leverage some existing low-tech data broadcast infrastructure such as RBDS/RDS (Radio Data System)?
Apple's press release seemed to say that much of the functionality will be pushed in the coming months via iOS updates (since the iPhone to iPhone communication isn't exposed normally except for Find my iPhone). It's unlikely that you'll need to install an app except to say you are infected.
Google could do a similar thing via a Google Play Services update (or, you know, use this as the kick-in-the-pants to get manufacturers to start updating Android to protect the public from COVID-19).
Citing from the paper:
We refer the frequency shift satisfying the
above requirements as artificial Doppler shift, implying that
it has minimal impact on existing systems just like Doppler
shifts caused by normal movements.
So they're just calling these "Doppler" shifts because they are so small that they don't really have any effect on the WiFi link, just like real Doppler shifts should be compensated for, while the tiny frequency shifts still contain enough information to be picked up by the BLE radio.
Additionally, you can use the phase information in the estimated channel coefficients (CSI) to determine the more precise time of arrival. Very briefly, a time delay in time domain will be visible as a frequency(=subcarrier)-dependent phase shift in frequency(=subcarrier)-domain. Now synchronization is only limited by impairments like thermal noise and phase noise. In practice in nice lab conditions, the time of arrival accuracy is on the level of <<1m.
On top of phase differences between subcarriers (--> timing information), we also measure phase differences between antennas, which provides angle of arrival and, with multiple arrays, phase of arrival information.
You can go even further by measuring phase differences between subsequent packets, which provides frequency offset and Doppler (--> velocity) information. I have some nice results on that, but that's a topic for the future ;)