3 ms·

The dense AI docs say a lot to convey little, both the user guide and deployment guide do little to explain what's needed on the router side. For example, thei

The dense AI docs say a lot to convey little, both the user guide and deployment guide do little to explain what's needed on the router side. For example, their diagram has several CSI sources. Does the user need 3 or more CSI sources? I'm capable of pointing an LLM at a GitHub repository, what I want is real documentation written by a human to address users' needs, not emoji-filled docs that read like ad copy.

amluto 10mo ago
It’s right there, clear as mud: from wifi_densepose import WiFiDensePose # Initialize with default configuration system = WiFiDensePose() # Start pose estimation system.start() # Get latest pose data poses = system.get_latest_poses() print(f"Detected {len(poses)} persons") # Stop the system system.stop() AI solves the Emporer’s Nose problem: you have no data whatsoever going in and you estimate the result! After a bit more browsing, I found: # Hardware Settings WIFI_INTERFACE=wlan0 CSI_BUFFER_SIZE=1000 HARDWARE_POLLING_INTERVAL=0.1 So maybe it uses one WiFi interface to collect CSI from multiple BSSIDs? Does 802.11 support this well? (I assume you can get one-way CSI data, single-in-multiple-out, from a beacon if you really want to. [1]) Does commodity hardware support this? Do the drivers support this? But I’d be rather impressed if that’s all that’s needed to get poses without any calibration for the actual positions of all involved devices especially if the CSI available is all of this form. This whole repo smells a bit like it’s almost 100% vibes and no content. Wasn’t 802.11bf supposed to make real channel state information available for vendor-neutral use? What happened to it? [1] Yes, I know, reciprocity. One-way and two-way data ought to be the same. But those nice access points almost all have at least two transmit/receive chains these days, possibly more, and they support multiple frequencies, and unless you can convince them to cooperate with you by sending known test patterns that let you disambiguate between the two antennas or at least collect vector or matrix data in a consistent basis, you don’t get to take advantage of it, and as far as I know Wi-Fi beacons don’t do this. APs do try to get something like this data for downlink MU-MIMO purposes, and stations that are receiving data with a multiple stream code get vector data fairly directly, but I’m not sure any of this works without being associated. I do wonder whether appropriate hardware can passively listen to a transmission intended for someone else and decode enough of it to extract the full CSI matrix from the transmitter to yourself.

amluto 10mo ago

It’s right there, clear as mud: from wifi_densepose import WiFiDensePose # Initialize with default configuration system = WiFiDensePose() # Start pose estimation system.start() # Get latest pose data poses = system.get_latest_poses() print(f"Detected {len(poses)} persons") # Stop the system system.stop() AI solves the Emporer’s Nose problem: you have no data whatsoever going in and you estimate the result! After a bit more browsing, I found: # Hardware Settings WIFI_INTERFACE=wlan0 CSI_BUFFER_SIZE=1000 HARDWARE_POLLING_INTERVAL=0.1 So maybe it uses one WiFi interface to collect CSI from multiple BSSIDs? Does 802.11 support this well? (I assume you can get one-way CSI data, single-in-multiple-out, from a beacon if you really want to. [1]) Does commodity hardware support this? Do the drivers support this? But I’d be rather impressed if that’s all that’s needed to get poses without any calibration for the actual positions of all involved devices especially if the CSI available is all of this form. This whole repo smells a bit like it’s almost 100% vibes and no content. Wasn’t 802.11bf supposed to make real channel state information available for vendor-neutral use? What happened to it? [1] Yes, I know, reciprocity. One-way and two-way data ought to be the same. But those nice access points almost all have at least two transmit/receive chains these days, possibly more, and they support multiple frequencies, and unless you can convince them to cooperate with you by sending known test patterns that let you disambiguate between the two antennas or at least collect vector or matrix data in a consistent basis, you don’t get to take advantage of it, and as far as I know Wi-Fi beacons don’t do this. APs do try to get something like this data for downlink MU-MIMO purposes, and stations that are receiving data with a multiple stream code get vector data fairly directly, but I’m not sure any of this works without being associated. I do wonder whether appropriate hardware can passively listen to a transmission intended for someone else and decode enough of it to extract the full CSI matrix from the transmitter to yourself.