Skip to content

fix(server): correct RSSI byte offset in frame parser (#332)#336

Merged
ruvnet merged 1 commit intomainfrom
fix/issue-332-rssi-offset
Mar 30, 2026
Merged

fix(server): correct RSSI byte offset in frame parser (#332)#336
ruvnet merged 1 commit intomainfrom
fix/issue-332-rssi-offset

Conversation

@ruvnet
Copy link
Copy Markdown
Owner

@ruvnet ruvnet commented Mar 30, 2026

Summary

Fixes RSSI reading positive values (e.g., +9) instead of correct negative dBm (e.g., -46).

Root Cause

The firmware packs the CSI frame with n_subcarriers as u16 (2 bytes) and freq_mhz as u32 (4 bytes), but the server parser assumed u8 and u16 respectively — causing a 2-byte offset for RSSI and noise_floor.

Field Firmware offset Server was reading
n_subcarriers [6..7] u16 [6] u8
freq_mhz [8..11] u32 [8..9] u16
sequence [12..15] u32 [10..13] u32
rssi [16] i8 [14] ← wrong
noise_floor [17] i8 [15] ← wrong

Test plan

  • cargo check — 0 errors
  • All 26 tests pass (18 vital signs + 8 multi-node)

Closes #332

🤖 Generated with claude-flow

)

The server parsed rssi from buf[14] and noise_floor from buf[15], but
the firmware (csi_collector.c) packs them at buf[16] and buf[17]:

  Firmware:  n_subcarriers=u16(6-7) freq=u32(8-11) seq=u32(12-15) rssi=i8(16)
  Server:    n_subcarriers=u8(6)    freq=u16(8-9)  seq=u32(10-13) rssi=i8(14) ← WRONG

This caused RSSI to read the high byte of the sequence counter instead
of the actual signed RSSI value, producing positive values (e.g., +9)
instead of the correct negative values (e.g., -46 dBm).

Added inline documentation of the frame layout matching csi_collector.c.

Closes #332

Co-Authored-By: claude-flow <ruv@ruv.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The RSSI output from my ESP32 is different from the rssi_dbm received by ws://localhost:3000/ws/sensing.

1 participant