Repository navigation
Conversation
Adds a slider in the web UI to control WiFi TX power, persisted to NVS and applied via esp_wifi_set_max_tx_power(). Range is 34–80 (raw units), mapping to 8.5–20 dBm. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…onfig All TX power logic (NVS save/load, boot-time apply, HTTP handler, web UI slider) is now compiled out unless SNAPCLIENT_WIFI_TX_POWER_CONTROL=y. The web UI slider is additionally hidden at runtime when the capability is absent from the settings JSON, so mixed firmware/UI scenarios are handled. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
capabilities was a local variable scoped to loadSettings() but referenced in renderUI(). Introduce a module-level hasTxPowerControl flag set during load and use it in renderUI() instead. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Could you provide a Screenshot? |
|
|
This looks OK to me but there is a PR #225 in the pipe and we should probably merge that one first. |
|
Oh and I l'd prefer to remove the dependency to settings manager here too. Could you add API to control this from main()/http_task() ? |
|
Sure I'll take a look. Also, I want to think a little more on how to even characterize the improvements this might make other than "it seems to play more reliably for me". I'd rather use boards that didn't even need this 😅 |
NVS key comment and function parameter names incorrectly said "dBm" when the stored value is in ESP-IDF quarter-dBm units (0.25 dBm each). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Hmm, I've fine-tuned my sdkconfig settings and don't seem to have connectivity issues now. Nevertheless, it is sometimes reported to be helpful. Do with that what you will lol |
If you found some good improvements please share them, maybe in #222 |
|
If I get the time I'll try seeing which of these made the difference, but my sdkconfig overlay is here. So sdkconfig.defaults -> sdkconfig.defaults.esp32s3 -> Mine |
|
I'll test these changes on the S3 board I have. The key difference I see is that you use octal mode for PSRAM, and a few memory optimisations related to that. I think for 8MB PSRAM boards, this is totally valid, but 2MB boards should stay with quad. @CarlosDerSeher @luar123 do you think the defaults for esp32s3 should assume safe quad mode? Should octal mode then become an override in board-specific config (assuming that will improve performance)? |
|
Only 2MB variants uses quad, so I would stay with octal as default as it gives twice the bandwidth. |
|
Yup, I just happen to be using a 2MB variant. |
0c86819 to
2573b03
Compare
wifi_start() never called esp_wifi_set_ps(), so IDF's WIFI_PS_MIN_MODEM default applied and the modem slept between DTIM beacons. That adds ~100-300ms to either leg of a time-sync exchange — well past what the protocol tolerates. Round-trips stop completing, diff2Server freezes, and the player resyncs hard indefinitely while RSSI stays healthy. Add CONFIG_SNAPCLIENT_WIFI_PS_NONE (bool, default y) and apply the resulting mode once at the end of wifi_start(), after both the provisioning and non-provisioning esp_wifi_start() call sites. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit ed7506b95942a1ed897a31f71565acea1d2813ed)
For some boards the default TX power is too high and can cause self-interference. I find greater stability with a slightly reduced TX power (<18dB) using an ESP32-S3 Supermini.
Adds a WiFi TX power control to the General Settings page. The value is persisted to NVS and applied at both boot time and immediately on change.
The default (raw 80 = 20 dBm) matches ESP-IDF's default behaviour, so existing devices are unaffected until the slider is moved.