Compatibility and potential issues with ESP32-C3 as a CSI Node? #70

New Issue

2026-03-02T02:07:48+08:00

lekoOwO commented

2026-03-02 02:07:48 +08:00

(Migrated from github.com)

Hi @ruvnet,

First of all, thank you for this amazing project!

The ADR-018 frame format and the Rust aggregator implementation are very impressive for WiFi-based sensing.

I am planning to deploy several nodes and am considering using the ESP32-C3 instead of the ESP32-S3 due to its cost-effectiveness and availability. I am aware that I need to recompile the firmware from source since the architectures differ (RISC-V vs. Xtensa).

Based on my initial assessment, I plan to make the following changes:

Update sdkconfig.defaults with CONFIG_IDF_TARGET="esp32c3".
Use idf.py set-target esp32c3 and rebuild using ESP-IDF v5.2.
Use esptool --chip esp32c3 for flashing.
Beyond these build-target adjustments, I would like to ask if you foresee any specific issues or limitations regarding:
SRAM/Memory Constraints: Does the ADR-018 buffering or the UDP streaming logic have memory requirements that might be tight on the ESP32-C3's internal RAM?
CSI Data Structure: In your experience, does the wifi_csi_info_t structure or the number of subcarriers (especially in HT40 mode) provided by the ESP-IDF for C3 differ significantly from the S3 in a way that might break the aggregator's parsing logic?
Performance: Is the single-core 160MHz RISC-V processor sufficient to maintain the ~20Hz CSI streaming rate without dropping frames?

If there are any "gotchas" or hardware-specific quirks I should be aware of, I would greatly appreciate your insights!

Best regards,

Leko

Hi @ruvnet, First of all, thank you for this amazing project! The ADR-018 frame format and the Rust aggregator implementation are very impressive for WiFi-based sensing. I am planning to deploy several nodes and am considering using the ESP32-C3 instead of the ESP32-S3 due to its cost-effectiveness and availability. I am aware that I need to recompile the firmware from source since the architectures differ (RISC-V vs. Xtensa). Based on my initial assessment, I plan to make the following changes: * Update sdkconfig.defaults with CONFIG_IDF_TARGET="esp32c3". * Use idf.py set-target esp32c3 and rebuild using ESP-IDF v5.2. * Use esptool --chip esp32c3 for flashing. Beyond these build-target adjustments, I would like to ask if you foresee any specific issues or limitations regarding: * SRAM/Memory Constraints: Does the ADR-018 buffering or the UDP streaming logic have memory requirements that might be tight on the ESP32-C3's internal RAM? * CSI Data Structure: In your experience, does the wifi_csi_info_t structure or the number of subcarriers (especially in HT40 mode) provided by the ESP-IDF for C3 differ significantly from the S3 in a way that might break the aggregator's parsing logic? * Performance: Is the single-core 160MHz RISC-V processor sufficient to maintain the ~20Hz CSI streaming rate without dropping frames? If there are any "gotchas" or hardware-specific quirks I should be aware of, I would greatly appreciate your insights! Best regards, Leko

👍 1

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dearsky/wifi-densepose#70