ContextQMD
Back to Ruview

SOTA Survey — RF Sensing and Edge Rust (2026 Q2)

docs/research/sota/2026-Q2-rf-sensing-and-edge-rust.md

1.99.0-pip29.5 KB
Original Source

SOTA Survey — RF Sensing and Edge Rust (2026 Q2)

FieldValue
StatusReference / informs architecture/three-tier-rust-node.md
Date2026-04-25
Authorgoal-planner research agent
ScopeWhat's true in 2026, what holds up in the three-tier proposal, what to reconsider
Word target~3,500 words

Conventions. Each section answers (a) what's true in 2026, (b) what claims in the three-tier proposal hold up, (c) what to reconsider, and (d) primary references. Where no primary source could be located, the claim is explicitly marked "no primary source found, mark as conjecture."

1. WiFi CSI through-wall pose / occupancy estimation

1.1 What's true in 2026

The CSI-to-pose literature has matured along three orthogonal axes since DensePose-from-WiFi (2022) lit the fuse:

  • Lightweight architectures. WiFlow (Feb 2026) demonstrated a spatio-temporal-decoupled network with 4.82 M parameters, 0.47 GFLOPs, PCK@20 = 97.0% and MPJPE ≈ 8 mm on the random-split MM-Fi benchmark, 3–4× smaller than WPformer and ~25× smaller than WiSPPN.
  • Domain generalization. PerceptAlign (DT-Pose) and the cross-environment evaluation in MM-Fi made the cross-subject and cross-layout numbers honest. PerceptAlign reports MPJPE 222 mm on Scene 4 and 317 mm on Scene 5 in cross-layout test, beating prior SOTA by

    50% — but those are still order-of-magnitude worse than in-domain.

  • Topological priors. GraphPose-Fi (2025) and topology-constrained decoders (DT-Pose) explicitly use the human skeleton as a graph, improving plausibility under occlusion.
  • Multistatic geometry. RuView's own ADR-029/ADR-031 line is the practical multistatic story; ISAC-Fi (Aug 2024) and the multistatic ISAC-MIMO papers (2024–2025) describe similar geometry as a 6G research topic. IEEE 802.11bf-2025 (published 26 September 2025) is the standardization vector.

1.2 What holds up

The proposal's claim that "3–6 ESP32-S3 nodes can do meaningful pose work" is consistent with WiFlow's network sizes (4.82 M params, INT8 ~5 MB) and with the MM-Fi multi-link benchmark. The CSI pipeline does not need a Pi per node to run inference; one Pi per cluster is sufficient. RuView's existing ESP32-mesh + sensing-server already demonstrates the shape.

1.3 What to reconsider

  • Through-wall claims are still aggressive. Published WiFi sensing papers focus on line-of-sight or single-wall cases; published through-multiple-walls numbers in 2025–2026 are scarce. The three-tier proposal's "through-wall" framing should be tempered to "through-thin-wall" without primary evidence. No primary source found for through-multiple-walls, mark as conjecture.
  • Nexmon-on-Pi is not obviously a win. Nexmon CSI on a Pi 4 captures up to 80 MHz BW on Broadcom chips and gives more subcarriers per frame than ESP32, but the Pi platform has no equivalent of ESP32 Secure Boot V2, and the Broadcom firmware-patch path is fragile across kernel releases. RuView's existing ESP32-S3 mesh already beats Nexmon-on-Pi on cost, security posture, and provisioning.
  • USRP/SDR is overkill for occupancy and pose, and is far over the proposal's BOM ceiling. It would only become attractive for research-grade beamforming or sub-cm ranging.

1.4 Primary references

2. IEEE 802.11bf and multistatic ISAC

2.1 What's true in 2026

IEEE Std 802.11bf-2025 was published 26 September 2025 and is the ratified amendment for WLAN sensing in license-exempt bands 1–7.125 GHz and >45 GHz. The 3rd SA Ballot Recirculation closed 16 January 2025 with 98% approval. P802.11bf/D8.0 (March 2025) was the last public draft. The standard defines sensing operation on top of HE/EHT PHYs and on the DMG/EDMG (60 GHz) PHYs.

3GPP RAN #108 (June 2025) admitted ISAC into the 6G study scope as a "Day 1" 6G feature. ISAC-Fi (Aug 2024) demonstrated monostatic sensing over commodity WiFi by repurposing the communication waveform. Multistatic ISAC over cell-free MIMO (2024–2025) is the analytical direction.

2.2 What holds up

The three-tier proposal's framing of "WiFi mesh + multistatic sensing" is well-aligned with where the standard is moving. ADR-029's existing multistatic mode and ADR-073's multifrequency mesh scan are the kind of pre-standard implementations that 802.11bf is now codifying.

2.3 What to reconsider

  • 802.11bf does not turn an ESP32 into an 802.11bf sensor. It defines a protocol for sensing-aware exchanges between APs and STAs. Off-the-shelf ESP32-S3 silicon was designed before the standard; CSI extraction on ESP32 will keep being a side channel, not a standards-blessed feature, until Espressif ships a chip with the 802.11bf MAC primitives. No primary source found for an Espressif 802.11bf-aware product, mark as conjecture.
  • ISAC-Fi's monostatic-on-commodity-WiFi result is interesting but requires PHY changes; not a path to ESP32 today.
  • The proposal should claim "802.11bf-compatible feature set" rather than "802.11bf-compliant" until silicon exists.

2.4 Primary references

3. Embedded Rust ecosystem for ESP32-S3 (2026)

3.1 What's true in 2026

The esp-rs ecosystem has matured but rebranded:

  • esp-hal is at 1.x. esp-hal 1.0.0 shipped October 2023; 1.1.0 was released April 2024. Stabilized HAL APIs, async drivers, but with the constraint that "async drivers can no longer be sent between cores and executors."
  • esp-wifi was renamed to esp-radio in the 1.x line. The scheduler functionality moved to a new crate esp-rtos. Existing esp-wifi references in tutorials are pre-1.x.
  • Embassy on ESP is split: on no_std ESP-HAL it's a first-class citizen, but the Embassy team and Espressif explicitly steer Embassy use toward esp-rtos over time.
  • Embassy on top of esp-idf-svc (std) has a documented gotcha: embassy-executor is not ISR-safe because it depends on critical-section, which esp-idf-hal implements over FreeRTOS task suspension. The recommended std executor is edge-executor or the built-in esp-idf-hal executor.
  • CSI capture on no_std via esp-csi-rs (third-party crate) exists but is documented as "still in early development." The production-blessed CSI path remains esp_wifi_set_csi_rx_cb() in ESP-IDF C — exactly what firmware/esp32-csi-node/main/csi_collector.c uses today.

3.2 What holds up

The three-tier proposal's choice to put the sensor MCU on no_std (esp-hal + Embassy) avoids the ESP-IDF ISR-safety question entirely, which is the right architectural answer to a real problem. The proposal is correct that heapless + postcard + embassy-time is the modern no_std default.

3.3 What to reconsider

  • Update the toolchain names. The proposal lists esp-wifi; in 1.x this is esp-radio. It lists embassy-executor on the comms MCU by implication; on the comms MCU the executor must be edge-executor or esp-idf-hal's built-in executor, not Embassy.
  • CSI maturity is the gating risk. esp-csi-rs is early development and the production CSI path is still C. Migrating CSI to no_std Rust is a project unto itself, not a free side effect of splitting the dies.
  • esp-idf-svc parity with C ESP-IDF is good but not 100%. OTA, HTTPS, NVS, BLE provisioning, ESP-WIFI-MESH all have wrappers. Some niche ESP-IDF C APIs still need esp-idf-sys raw FFI. This is fine but means the comms MCU is not "all-Rust" — there's a layer of unsafe wrapping at the bottom.

3.4 Primary references

4. Edge ML for CSI on ESP32-class hardware

4.1 What's true in 2026

  • TFLite Micro on ESP32-S3 is the most-cited path. Reported numbers: wake-word inference at 50–60 ms latency, model size ~240 KB flash, ~350 KB RAM. INT8 quantization reportedly delivers >6× speedup over float on S3. Espressif's esp-tflite-micro is the reference port.
  • tract (Sonos's pure-Rust ONNX/NNEF runtime) targets std Linux primarily; there is no widely-adopted no_std no-alloc port.
  • candle (Hugging Face's Pytorch-flavored Rust ML library) is std Linux/macOS/Windows; not designed for MCU class.
  • ONNX Runtime (ort Rust binding) is a wrapper over the C++ runtime; on ARMv8 (Pi Zero 2W) it works, on Xtensa it does not.
  • ESP-DL is Espressif's own DL framework for ESP32-S2/S3, optimized for the AI extensions of the Xtensa LX7 (which ESP32-S3 has). It is C, not Rust.

For a 4.82 M-param INT8 WiFlow at 0.47 GFLOPs:

  • On a Pi Zero 2W (Cortex-A53 quad, NEON), inference is plausibly in the 50–100 ms range. No primary measurement found for WiFlow on Pi Zero 2W; mark as conjecture.
  • On an ESP32-S3 (Xtensa LX7, 240 MHz, AI extensions), even INT8 4.82M is outside the 8 MB flash + 8 MB PSRAM envelope when intermediate tensors are counted. WiFlow on S3 would require additional pruning or a smaller model class.

4.2 What holds up

The proposal's split between "sensor MCU does ISR-clean DSP" and "Pi runs the model" is the right shape. ML inference at the WiFlow scale is not an ESP32 workload in 2026.

4.3 What to reconsider

  • The sensor MCU's ML role should be tiny-feature inference, not pose. Motion classification, presence binary, anomaly thresholding — the ADR-039 Tier-0/Tier-1 outputs — fit on ESP32-S3 with TFLite Micro or hand-written DSP. They do not fit tract or candle no_std.
  • For Rust-on-MCU-ML, the realistic path is hand-rolled INT8 inference (RuView's wifi-densepose-nn already has FFI hooks) or a Rust port of a tiny TFLM-style runtime. No mainstream Rust no_std-no_alloc ONNX runtime exists in production at 2026 Q2.
  • The Pi Zero 2W's 1 GB RAM is fine for WiFlow but tight for larger pose models. A CM4/CM5 with 4 GB unlocks Hugging-Face-class models; whether the deployment needs that is a use-case question.

4.4 Primary references

5. QUIC for IoT backhaul

5.1 What's true in 2026

  • quinn + rustls is the production Rust QUIC stack. Both target std Linux, both work fine on ARMv8 (Pi Zero 2W). rustls is FIPS-validatable via the AWS-LC backend.
  • MQTT-over-QUIC is the emerging IoT pattern. EMQX 5.x and NanoMQ both ship MQTT-over-QUIC; published benchmarks show comparable or better tail-latency than MQTT-over-TLS-over-TCP, especially under packet loss and mobile-network handoff conditions.
  • For low-rate telemetry (a few KB at minute granularity), the difference between QUIC and TLS-over-TCP is small in steady-state. The win is in connection-establishment cost (~1 RTT vs ~3 RTT) and in graceful behavior across IP changes.

5.2 What holds up

The proposal's choice of quinn for the Pi-to-cloud ring is sound and matches what EMQX, NanoMQ, and Microsoft (MsQuic) are converging on. rustls is a strong default.

5.3 What to reconsider

  • Heartbeat-only deployments don't need QUIC. If the Pi wakes 2 minutes/day to push aggregated features, an MQTT-over-TLS publish on port 8883 is one library, well-supported, and cheaper to operate.
  • QUIC pays off when bidirectional or large-payload traffic is real. Model updates, fleet sync, on-demand video — these are the cases where the 1-RTT handshake and connection-migration matter.
  • Don't terminate QUIC inside the comms MCU. ESP-IDF has no production QUIC stack; QUIC belongs on the Pi or gateway, not on the MCU.

5.4 Primary references

6. LoRa for sensor mesh fallback

6.1 What's true in 2026

  • SX1262 — Semtech's mainstream Gen-2 sub-GHz LoRa transceiver, +22 dBm TX, 4.2 mA RX. The default for low-rate, long-range battery applications. Mature ecosystem, low BOM cost, supported by lora-phy and most Meshtastic boards.
  • LR1110 — adds GNSS scan + WiFi scan. Designed for asset-tracking workflows where the device opportunistically reports GNSS+WiFi fingerprints to a cloud-side resolver.
  • LR1121 — Gen-3, sub-GHz + 2.4 GHz + S/L-band satellite. ~4.5 dB better Sub-GHz sensitivity vs SX1262. Cost premium and more system complexity.
  • Duty cycles: EU868 imposes 1% in most sub-bands and 0.1% in the 863–865 MHz sub-band. US915 uses dwell-time (400 ms) instead of duty-cycle limits. Raw-LoRa peer-to-peer must still respect the regional regulatory constraint, even though LoRaWAN is not on the wire.

For a 20-byte heartbeat at SF7, BW 125 kHz, the airtime is ~40 ms. At the EU868 1% duty cycle, that's 36 s/hour available — more than 900 heartbeats per hour theoretical max.

6.2 What holds up

SX1262 for fallback heartbeats is the correct, well-priced choice. The proposal's "bytes per minute" framing is well within EU868 1% and US915 dwell-time budgets.

6.3 What to reconsider

  • LR1121 is not justified for fallback heartbeats. The satellite/2.4 GHz capabilities are deployment-shape choices, not fallback-radio choices.
  • Raw LoRa P2P, not LoRaWAN. The proposal already implies P2P; this should be explicit. LoRaWAN gateways add infrastructure cost without improving fallback reliability, and they don't help direct node-to-node fallback recovery.
  • LoRa cannot carry CSI features at any meaningful rate. SF7 BW125 raw rate is ~5.5 kbps; ADR-081 rv_feature_state_t at 5 Hz is 2.4 kbps gross, 480 B/s, well within budget if compressed and gated. Raw ADR-018 frames at 100 KB/s/node are not LoRa-shaped.

6.4 Primary references

7. Solar + Li-ion power-path for 350 mA bursty IoT loads

7.1 What's true in 2026

  • TI BQ24074 — small, simple, linear charger; dual input (DC + USB); has the input-voltage-limit feature that crudely approximates MPPT for small panels. Adafruit's "Universal" charger product is built on it. Low silicon cost, no inductors.
  • TI BQ25798 — newer (2025-class) buck-boost charger with true Voc-sampling MPPT, dual-input, supports 1–4S Li-ion, 5 A capability, 3.6–24 V input range. Adafruit launched a development module in May 2025.
  • Analog Devices LTC4015 — multi-chemistry, two-phase MPPT (15-min global sweep + 1-second local dither). High-cost, high-capability; overkill for sub-5 W panels.
  • Silergy SPV1050 — purpose-built for sub-watt IoT solar (e.g. energy-harvesting sensors). Constant-voltage-ratio MPPT, 70 mA solar / 100 mA USB charge limit. Best for very small (<1 W) panels and micro-energy budgets.

7.2 What holds up

For a 2 W panel and a node-average load that bursts to 350 mA, the BQ24074 (linear) is sufficient. The proposal's choice is fine.

7.3 What to reconsider

  • MPPT becomes attractive when panel power × variability is high. At 2 W, the efficiency delta between linear-with-input-voltage-limit and true MPPT is on the order of 10–20% in cloudy conditions. For a 4× harvest-to-load headroom, this is not the binding constraint.
  • If the deployment ever scales to a 5–10 W panel (e.g., to support a Pi that wakes more often than 2 minutes/day), BQ25798's MPPT pays off.
  • A super-cap on the input rail is cheap insurance against the Pi's ~350 mA boot inrush; the proposal should consider one.

7.4 Primary references

8. Mesh routing alternatives to ESP-WIFI-MESH

8.1 What's true in 2026

  • ESP-WIFI-MESH documents support up to ~1,000 nodes in 25 layers, with a recommended fan-out of 6/node (hardware AP-mode limit is 10). Espressif's own newer esp-mesh-lite is the lighter, IP-layer-routable alternative.
  • Thread / OpenThread — IPv6-native 802.15.4 mesh, self-healing, designed for 250+ node networks per partition. Strong scalability and security story. Hardware: ESP32-C6, ESP32-H2, Nordic nRF52840, Silicon Labs EFR32.
  • Zigbee — 802.15.4 like Thread, but with a much older application layer. Scales reasonably to ~100 nodes in practice, with congestion challenges in dense deployments.
  • BLE Mesh — managed flooding, optimized for sporadic traffic. Good for ~50 nodes; not the right shape for always-on infrastructure.

8.2 What holds up

For < 25-node deployments, ESP-WIFI-MESH (or esp-mesh-lite) is the direct continuation of today's RuView mesh and the proposal's choice is defensible.

8.3 What to reconsider

  • For 50–500 node deployments, Thread is the better fit. It was designed for that scale; ESP-WIFI-MESH was not. Using Thread for the control plane (TIME_SYNC, ROLE_ASSIGN, CHANNEL_PLAN, HEALTH) while keeping ADR-018 CSI frames on WiFi is a viable hybrid.
  • The comms MCU choice changes. ESP-WIFI-MESH stays on ESP32-S3. Thread/Zigbee/BLE Mesh prefer ESP32-C6 (which has 802.15.4 + WiFi 6) or a separate radio. The proposal's two-S3 die choice forecloses on this hybrid; a one-S3 + one-C6 split is worth evaluating.
  • Thread's IPv6-native routing pairs nicely with QUIC. Both speak IP; ESP-WIFI-MESH does not (it uses its own L2-style routing and bridges IP).

8.4 Primary references

9. Pi Zero 2W secure-boot reality

9.1 What's true in 2026

  • Raspberry Pi Foundation's official secure-boot path is Pi 4 / Pi 5 / CM4. It uses the RPi-bootloader ROM, USB-rooted RSA chain, and the usbboot tooling. There is no equivalent on the Pi Zero 2W (BCM2710A1).
  • Buildroot does support Pi Zero 2W (April 2025 defconfig update uses the same ARM64 bcm2711_defconfig as the Pi 4).
  • dm-verity + signed FIT image is the realistic Pi-Zero-2W path: buildroot produces a read-only rootfs, dm-verity covers it with a signed Merkle tree, the boot partition has signed kernel/initramfs. This delivers integrity but not "secure boot" in the immutable-ROM sense.
  • A/B partitions for OTA is straightforward in buildroot. swupdate and RAUC are the well-known frameworks; both work on Pi Zero 2W.

9.2 What holds up

The proposal's "buildroot, not Raspberry Pi OS" instinct is correct. RPi OS does not support secure boot on any Pi.

9.3 What to reconsider

  • The "Pi 4 + buildroot is the strongest path" line is true but not a Pi Zero 2W story. If true secure boot with an immutable ROM-rooted chain is required, the heavy-compute die should be a CM4 or Pi 5, not a Pi Zero 2W.
  • For the proposal's deployment shape (mostly-off Pi, infrequent wake-ups), dm-verity + signed FIT + A/B is probably enough threat cover and avoids the cost of a CM4. Document this as an explicit tradeoff, not as "the strongest path."
  • fwupd is the package-manager-style update agent; or a self-rolled "update-agent" binary signed by the project key. Either works; project-style fits with the homogeneous Rust toolchain better.

9.4 Primary references

10. Cross-cutting takeaways

A short list of items that affect more than one section:

  1. The biggest single risk in the proposal is the no_std CSI maturity gate. If esp-csi-rs (or whatever replaces it under esp-radio) does not match esp_wifi_set_csi_rx_cb in capture quality and ISR-jitter, the sensor-MCU shape collapses back to "C ESP-IDF on the sensor MCU too" and the value of the split shrinks.
  2. The cost story improves dramatically if the heavy-compute die is shared across nodes. "One Pi per cluster of 6" is closer to today's $9-per-sensor BOM at the per-sensor edge while still adding the QUIC/ML/secure-boot story at the cluster level.
  3. IEEE 802.11bf-2025's ratification changes the regulatory and ecosystem landscape but does not change what off-the-shelf ESP32 silicon can do today. RuView's pre-standard work (ADR-029, ADR-073, ADR-081) is well-aligned with the standard's direction; nothing in the proposal makes it more or less compatible.
  4. The right "comms MCU" might be ESP32-C6 instead of a second S3. C6 has 802.15.4 (Thread/Zigbee), WiFi 6, and BLE 5.4. For a deployment that scales beyond ~25 nodes, the Thread control plane is a meaningful upgrade.
  5. Power gating the Pi is the load-bearing power decision. Soft suspend leaks; hard FET cut does not. The proposal's instinct is right, but the supercap/transient story has to be designed in.

11. Items where no primary source was found

This section is required by the project conventions and lists each non-trivial claim where a primary source could not be located in this research pass:

  • Through-multiple-walls CSI pose accuracy at room scale. Published papers focus on line-of-sight or single-wall environments. Mark as conjecture for now.
  • WiFlow inference latency on Pi Zero 2W (Cortex-A53). Estimated at 50–100 ms; no measurement found. Mark as conjecture; benchmark before claiming.
  • Espressif silicon roadmap for 802.11bf-aware MAC primitives. No public announcement from Espressif as of 2026 Q2. Mark as conjecture.
  • Pi Zero 2W gated cold-boot wake-up time under 5 s with the proposed buildroot image. Mentioned in the proposal as a constraint, no measurement found. Mark as benchmark target.
  • ESP-WIFI-MESH stable-state tested deployment beyond ~25 nodes. Espressif documents 1,000-node theoretical ceilings but published third-party deployment data at scale is sparse. Mark as conjecture pending field test.

12. Source list

(Primary references are inlined per-section. This is the unique domains list for quick reuse.)

  • IEEE Standards Association — standards.ieee.org
  • arXiv — arxiv.org
  • IEEE Xplore — ieeexplore.ieee.org
  • Espressif documentation — docs.espressif.com
  • Espressif GitHub — github.com/espressif
  • esp-rs project — github.com/esp-rs, crates.io/crates/esp-csi-rs, docs.rs/esp-idf-hal
  • Embassy project — embassy.dev
  • The Things Network — thethingsnetwork.org
  • Texas Instruments — ti.com
  • Adafruit — adafruit.com, blog.adafruit.com
  • Buildroot — lists.buildroot.org
  • Silicon Labs — silabs.com
  • DigiKey forum — forum.digikey.com
  • NIST — nist.gov
  • MDPI Sensors — mdpi.com
  • EMQ technical blog — emqx.com
  • Raspberry Pi forum / GitHub — forums.raspberrypi.com, github.com/raspberrypi/usbboot
  • nicerf comparison guide — nicerf.com
  • DFRobot wiki — wiki.dfrobot.com

Sources