ESP32 CSI and Wi-Fi sensing: one-board, two-board and experiment design

By Wu Jun · Updated 2026-11-02 · 6 min read

ESP32 is one of the cheapest ways to reach real CSI. Espressif states that every ESP32 series supports CSI, including ESP32, S2, C3, S3, C5, C6 and C61 ^[1]. "Can obtain CSI" and "can run a stable experiment" are different claims, however: sender, packet rate, LTF parsing, channel and evaluation protocol all matter.

This guide follows the official esp-csi examples and ESP-IDF documentation.

1. Three capture routes

The official repository provides csi_recv_router, csi_recv and csi_send. The single-board route does not mean the ESP32 transmits a radar pulse by itself. Another endpoint must send packets before the ESP32 can estimate CSI.

2. Route one: one ESP32 plus a router

This is the lowest-hardware starting point. The ESP32 joins the router, pings the gateway and receives CSI in replies.

git clone https://github.com/espressif/esp-csi.git
cd esp-csi/examples/get-started/csi_recv_router
idf.py set-target esp32s3       # replace with your chip
idf.py menuconfig               # configure Wi-Fi or Ethernet
idf.py -p /dev/ttyUSB0 flash monitor

On macOS, serial devices are usually /dev/cu.usbserial-* or /dev/cu.SLAB_USBtoUART; do not copy Linux's /dev/ttyUSB0 blindly.

Confirm four basics:

1. CSI_DATA appears on the serial console;
2. len matches the expected format;
3. RSSI updates continuously;
4. stopping ping or traffic reduces CSI output.

If only boot logs appear, check Wi-Fi association, packet flow and CSI enablement before blaming the parser.

3. Route two: two ESP32 boards

The official get-started example uses two boards: one flashes csi_send, the other csi_recv. Its current README recommends C5/C6 and says the two antennas should be more than one metre apart. That does not mean older ESP32 chips cannot produce CSI.

# sender
cd esp-csi/examples/get-started/csi_send
idf.py set-target esp32c3
idf.py -p /dev/ttyUSB0 flash -b 921600 monitor

# receiver
cd esp-csi/examples/get-started/csi_recv
idf.py set-target esp32c3
idf.py -p /dev/ttyUSB1 flash -b 921600

# receiver visualiser
cd esp-csi/examples/get-started/tools
python -m pip install -r requirements.txt
python csi_data_read_parse.py -p /dev/ttyUSB1

Both boards must use a target that matches the actual chip. Treating esp32c3 as a universal target is a common build failure.

4. Subcarrier count is not a fixed 30-64

ESP-IDF CSI can contain three LTF fields:

• LLTF (legacy long training field);
• HT-LTF;
• STBC-HT-LTF.

The byte count depends on packet type, 20/40 MHz, STBC, secondary channel and which LTFs are enabled. The official ESP32-S3 table lists len values such as 128, 256, 384, 380 and 612 bytes. len / 2 is not automatically the number of independent subcarriers because the buffer may contain multiple LTF sections ^[2].

Preserve these fields:

Each complex sample is int8 imaginary followed by int8 real. Do not apply the router CSI int16 I/Q layout directly to ESP32 data.

5. Two CSV text layouts

Older ESP32 examples commonly print:

type,id,mac,rssi,rate,sig_mode,mcs,bandwidth,...,len,first_word,data
CSI_DATA,0,... ,128,1,"[imag0,real0,imag1,real1,...]"

ESP32-C5/C6 examples can print:

type,seq,mac,rssi,rate,noise_floor,fft_gain,agc_gain,channel,
local_timestamp,sig_len,rx_state,len,first_word,data

Column order differs. A parser cannot rely on one fixed index:

1. save one raw official CSV line as a format fixture;
2. detect the header or the type/seq column;
3. validate len against the data element count;
4. retain raw text, not only cleaned amplitude.

6. Packet rate is the sampling-rate ceiling

ESP32 CSI is triggered by received packets. There is no guaranteed fixed 100 Hz. Independent sampling depends on the sender rate, channel contention, RSSI, packet length, power save and serial throughput.

Measure these before machine learning:

packets_total
valid CSI frames
duration from first/last local_timestamp
valid frames / duration
packet gap p50 / p95 / max
RSSI min / mean / max
len distribution

The official README also notes that expensive live plotting can overrun the serial buffer and produce mismatched element counts or corrupted display. Increase serial speed, disable high-CPU plotting or write to disk before judging the CSI itself.

7. Minimum reproducible experiment

Do not start with respiration or heart rate. Start with these classes:

Record:

• sender/receiver target, firmware commit and ESP-IDF version;
• channel, bandwidth, TX power, RSSI and noise floor;
• board distance, orientation and height;
• valid frames/s, maximum packet gap and serial loss;
• raw CSV or binary stream and capture-script version.

Split train/test by session or date. Do not randomly separate overlapping windows.

8. Realistic capability boundary

Good uses:

• learning amplitude/phase versus packet rate;
• low-cost presence or motion detection;
• ESPHome/Home Assistant integration experiments;
• small datasets for algorithm validation.

Do not claim by default:

• respiration or heart rate in every room;
• full walking micro-Doppler;
• high-accuracy range, angle or body imaging;
• one development board replacing a dedicated radar.

ESPectre and similar projects provide engineering references ^[3], but accuracy must still be tested in your own environment.

9. ESP32 versus GL-MT6000 router CSI

Router CSI is not a scaled-up ESP32. Binary format, chain count, extraction and sampling mechanisms differ. Algorithms may share ideas, but input dimensions, timelines and calibration do not transfer automatically.

10. From zero to a first plot

Recommended order:

1. run single-board csi_recv_router;
2. save one raw CSV line and verify len versus data;
3. compute actual packet rate and maximum gap;
4. capture five minutes of empty room and five minutes of walking;
5. plot RSSI, CSI amplitude and motion envelope;
6. only then try presence, vital signs or deep learning.

CSIKit supports ESP32 and several other formats; verify that its version and column definitions match your firmware. The Awesome Wi-Fi CSI Sensing list provides further tools and papers ^[4].

11. Conclusion

• every ESP32 series supports CSI, but targets, packet formats and recommendations differ;
• the single-board route depends on router traffic; the two-board route needs an explicit sender and receiver;
• len is not a fixed subcarrier count because LTF composition changes;
• packet rate determines sampling and must be measured from timestamps and valid frames;
• ESP32 is excellent for low-cost entry and IoT, not a generic claim of full radar or medical-grade vital signs.