No résumé. No name required. We don't care where you studied or who you've worked for. Pick a problem below, go deep, and show us how you think.

Secret Society of Intellectuals

The Problems

Modern WiFi chips hand you Channel State Information (CSI): a per-subcarrier, frequency-resolved picture of how an OFDM signal bounced around the room. People use it to detect presence, count breaths, and read gestures, all without a camera. The physics is generous because OFDM gives you dozens of subcarriers to watch at once.

The catch

Bluetooth wasn't built for this. BLE uses single-carrier GFSK: no OFDM, no subcarriers, no native CSI. So on paper, the trick that makes WiFi sensing work simply isn't there.

But the physical layer leaks more than you think

BLE exposes RSSI, raw IQ samples during the Constant Tone Extension (BLE 5.1 direction finding), and phase across its 40 hopping channels spanning 2.402–2.480 GHz. Bluetooth 6.0's new Channel Sounding measures phase across many frequencies for ranging, the closest thing BLE has to a real channel response. Sample phase across enough hopped channels and you can begin to reconstruct something CSI-like.

The challenge

Reconstruct a CSI-style channel response from BLE and use it to sense something physical in the world. Presence and gross motion are achievable. Breathing rate and gesture recognition are the moonshot. We care more about an honest, working pipeline than a flashy claim.

What a great answer shows

Real hardware capture of BLE phase/IQ, a signal-processing pipeline, and a quantified result (presence-detection accuracy, or breathing rate measured against ground truth), plus a clear-eyed account of where single-carrier, low-bandwidth BLE runs out of road compared to WiFi.

Nordic nRF52833 (CTE / IQ)Nordic nRF54L (Channel Sounding)ESP32HackRF / USRP

Today we borrow sensing data from radios meant for communication, pulling CSI out of WiFi, phase out of BLE. It works, but we're always fighting a waveform that was never designed to feel the room. So flip the problem: what if the waveform itself were the sensor?

Design the waveform for sensing

Pick a signal built to sense: FMCW chirps for range and micro-motion, UWB pulses for time-of-flight, or an OFDM/joint-comms-and-sensing (JCAS) hybrid, the direction 6G is heading. Shape it so its echoes directly encode range, velocity, and displacements as small as a breathing chest (range resolution ≈ c / 2B, so bandwidth is destiny).

Then build the hardware: two honest paths

Transceiver-IC + SoC (the PlutoSDR model, AD9361 / AD9363): maximum freedom, you write the waveform and design the RF front-end, clocking, and antennas yourself. Or a purpose-built radar SoC (TI IWR6843 / AWR1642 mmWave, Infineon BGT60): far less RF risk, so you focus on antenna layout and DSP. mmWave's short wavelength is what makes micrometre chest motion measurable.

The hard parts

Phase coherence between TX and RX (shared LO/clock, this is why half-duplex SDRs struggle), waveform and bandwidth tradeoffs, the range → Doppler → angle DSP chain (range FFT, Doppler FFT, CFAR detection, angle estimation), and antenna arrays for direction.

Deliverable tiers: enter at any level

Concept: waveform choice, system block diagram, link/range-resolution budget, and a simulated range-Doppler map. Design: schematic, RF front-end, antenna design, a coherence plan, and IQ simulation. Prototype: a working capture on a PlutoSDR custom-waveform loopback or a TI mmWave EVM, plus a PCB layout in KiCad or Altium.

ADALM-PLUTO (AD9363)TI IWR6843 / AWR1642Infineon BGT60GNU Radio + PythonKiCad / Altium