Advanced Tech: Wi-Fi Sensing

I was recently going through IEEE 802.11bf, the Wi-Fi sensing standard published last year. It kind of formalised procedures for Wi-Fi sensing. I think it’s worth diving into how it works.

So a Wi-Fi signal reaches the receiver through several paths. Some travel directly, while others reflect off walls, furniture and people. These copies combine at the receiver. When you move, the path lengths change, shifting their phase and amplitude. Wavelength is about 6 cm@5GHz. In an ideal out-and-back reflection, moving a person 1 cm towards the radio changes the path by 2 cm, producing a 120° phase shift. That measurably changes the received signal.

How does Wi-Fi sensing work?

Wi-Fi receivers already estimate Channel State Information (CSI) to decode data. Wi-Fi splits a channel into many subcarriers. CSI estimates how each one’s amplitude and phase have changed during transmission. That gives much more detail than a signal-strength (RSSI) reading. By tracking CSI over time, software can detect motion and, under controlled conditions, infer gestures or even breathing. Unlike cameras, radio sensing may operate through walls, raising privacy concerns.

Now, can your home router reconstruct a 3D map of your room? In principle, you can estimate locations, but a typical router cannot produce a detailed 3D scan. You need multiple radio links or antennas, bandwidth and calibration. At 60 GHz, wider channels help resolve finer details, but blockage becomes an issue. Your router being Wi-Fi 6 or 7 alone doesn’t enable sensing. The chipset and firmware must expose useful channel measurements, with software to interpret them.

The company Plume already offers Wi-Fi motion alerts, and researchers have demonstrated 3D human pose tracking with multiple receivers. But movement from fans or pets can trigger false alarms. A person sitting still is much harder to detect than one walking. CSI reveals that something changed. Deciding what caused it remains the hard part. As sensing improves, maybe one day Wi-Fi could help automate lighting and alert caregivers to possible falls of elders without cameras. Future is great for this tech.

If you liked the post, Share it with your friends!

Leave a Comment

Your email address will not be published. Required fields are marked *

Tech Explained: Compressed RAM

Last week, I happened to go through a slide deck by Gregory Price of Meta about CRAM, presented at the Linux Plumbers Conference. It’s good stuff. With RAM prices rising, I think the idea is worth understanding.

From fundamentals first. Linux already uses kernel modules zram & zswap that compress less-used blocks of memory called pages. A 4 KiB page might shrink to 1 KiB. That’s 3 KiB saved, letting you store more in the same RAM. But when an application needs it again, it triggers a page fault. Linux pauses the app, decompresses the page and restores access. Repeating this costs time.

How does CRAM work?

Now CRAM asks a simple question. What if the CPU could read that page without Linux first unpacking it? The idea is to put compression and decompression inside the memory hardware. Data stays compressed in RAM, but when the CPU requests it, the hardware returns the original bytes automatically. Applications still use normal memory addresses. Linux doesn’t need to swap the page back in just for a read. This could be especially useful for data you read often but rarely change.

Writes are harder. Our 1 KiB compressed page might expand to nearly 4 KiB if you replace its contents with data that won’t compress. CRAM handles this by keeping compressed pages read-only. A write triggers a move back to ordinary RAM before the change is made. So the benefit depends on the workload. His work reported a 452x throughput gain over zram. But the test used DRAM-backed memory to isolate page-fault overhead. It doesn’t prove 452x faster applications on real compressed hardware.

I think the question is whether this can scale. With RAM prices rising, saving physical memory could matter for servers. But it’s no magic bullet. CRAM needs compression-capable hardware, making widespread use a next-generation change rather than a software update. The approach isn’t limited to Linux either. Will hardware makers and OS developers, including Microsoft, see value in adopting it? I really hope they do.

If you liked the post, Share it with your friends!

Leave a Comment

Your email address will not be published. Required fields are marked *

1 2 3 … 146