Bitaxe – Settings Lost After Firmware Update (NVS Wipe)

Connect to the Bitaxe. If it is broadcasting `Bitaxe_xxxx`, join that SSID from your phone or laptop and browse to `http://192.168.4.1/`. If WiFi credentials happened to survive the wipe, find the miner on your LAN — check the OLED for an IP, or look in your router's DHCP table for a `bitaxe-xxxx` hostname or an ESP32-S3 MAC OUI such as `7C:DF:A1`. Browse to `http://<lan-ip>/`.

Open the Settings page in AxeOS and take stock of what was wiped. Default frequencies and voltages: Supra `485 MHz / 1200 mV`, Ultra `485 MHz / 1200 mV`, Gamma and GT `525 MHz / 1150 mV`, Hex `490 MHz / 1150 mV` per chip. If your fields show those values, you were wiped — confirmed.

Re-enter WiFi SSID and password. Save. The miner will drop the `Bitaxe_xxxx` AP, attempt to join your home WiFi, and pick up a DHCP lease. Watch the OLED for the new LAN IP. If it does not appear within 60 seconds, check the SSID for typos, and confirm the network is 2.4 GHz — the ESP32-S3 cannot connect to 5 GHz networks.

Re-enter pool URL, pool port, BTC address, and worker name. Pull these from your pool's dashboard if you did not write them down. Standard public pools: `solo.ckpool.org:3333`, `public-pool.io:21496`, `pool.ocean.xyz:3334`, `pool.braiins.com:3333`. Wrong port is a silent failure — AxeOS will not error, the worker will just never come online.

Re-enter the fallback pool if you used one. Many home miners point primary at `solo.ckpool.org` (lottery hashing) and fallback at `public-pool.io` (steady sats when the solo pool is unreachable). If you had a fallback set, restore it now while you remember the URL and port.

Click `Save` and let the miner reboot. Watch the OLED. After 30 seconds you should see the new LAN IP, the pool name, your worker name, and a non-zero hashrate climbing toward the chip's nominal range — `~100 GH/s` for Ultra, `~700 GH/s` for Gamma at default, higher for Hex. Cross-check at the pool dashboard within 5 minutes — your first share should land.

Re-tune frequency and core voltage to your previous values. Defaults are conservative for safety. If you were running Supra at `575 MHz / 1250 mV` or Gamma at `625 MHz / 1180 mV`, ramp back up: `+25 MHz` per 10-minute stability window, watching `HW Errors` (`HW%`) stay at zero. Stop at the last step before HW% climbs. That is this chip's silicon-lottery ceiling — and yes, it may have shifted slightly since your last tune; chips drift a little every thermal cycle, which is why re-tuning post-wipe is healthy anyway.

For multi-miner operators, use `POST /api/system` for bulk re-entry. Curl example: `curl -X POST http://<ip>/api/system -H 'Content-Type: application/json' -d '{"ssid":"YourWiFi","wifiPass":"...","stratumURL":"public-pool.io","stratumPort":21496,"stratumUser":"bc1q.../bitaxe1","frequency":575,"coreVoltage":1250}'`. The exact field names are documented in the ESP-Miner source (`main/http_server/http_server.c`) — verify against your firmware version.

Verify the settings persisted. Hit `GET http://<ip>/api/system/info` and confirm every field matches what you sent. If a value bounced back to default, you hit a key-name mismatch (firmware version expects a different key than you sent). Try the UI for that one field — it will always use the correct key for the running firmware version.

Confirm shares are landing on the pool dashboard within 5 minutes. If the worker shows offline, double-check pool port (`3333` vs `21496` vs `3334` — wrong port is a silent failure), then BTC address format (no leading or trailing whitespace, correct network — `bc1...` mainnet, not testnet `tb1...`), then worker name format (some pools want `address.worker`, others want `address` alone).

Save a settings backup right now. `curl http://<ip>/api/system/info > bitaxe-<name>-settings-2026-04.json`. This is the file you will need next time. Save it to your laptop, phone, password manager, or private GitHub Gist. Two seconds of work that prevents the next emergency. Multi-miner operators: do this for every Bitaxe in your fleet today.

Document your tune in a notes app you actually open six months from now. Frequency, core voltage, expected hashrate, expected HW%, ambient temperature at the time of tune, firmware version. Six months later when you flash again or move the miner to a different room, your past self will save your future self the retune-from-zero session.

If something feels off post-restore — settings appear saved but do not persist across reboot, or the API rejects values — capture a USB-C serial log. Connect USB-C, open a serial terminal at `115200` baud (PuTTY, `screen /dev/ttyACM0 115200`, picocom). Reboot the miner. Watch for `nvs_flash_init` lines: `nvs_flash_init: NVS partition initialized successfully` is healthy. `ESP_ERR_NVS_NO_FREE_PAGES` indicates real corruption — different page. `nvs_open: ESP_ERR_NVS_NOT_FOUND` for every key is the schema-mismatch fingerprint of this page — wipe was clean, settings just need re-entering.

Dump NVS over USB-C with `esptool.py` for diagnostic curiosity: `esptool.py --port <port> --baud 115200 read_flash 0x9000 0x6000 nvs_dump.bin`. Inspect with the ESP-IDF `nvs_partition_gen.py` tool or `xxd`. You will see your old keys (or, post-wipe, an empty partition). This is informational — you do not restore from a dump (key format may have changed); but it tells you which keys the new firmware kept and which it dropped.

Build a `set-up-bitaxe.sh` script you keep in version control. One file per miner, contains the `curl POST /api/system` calls with all your settings inline. Run it once per flash event, you are done in 10 seconds. Bonus: the file IS your backup — keep it in a private GitHub Gist or your password manager. Variables at the top (SSID, pool, BTC address, frequency, core voltage), curl calls below, exit code 0 on success. Multi-miner operators: parameterize by miner serial / IP and loop.

Use the AxeOS API to validate post-restore. A 30-second sanity script: hit `/api/system/info`, parse the JSON, assert every expected field is present and matches your intended value. Fail loudly if anything bounced. `jq` from the command line, or `requests` in Python — five lines of code that catches the field-name-mismatch case before you walk away thinking the miner is configured but no shares are landing.

Stop DIY and book D-Central Bitaxe Repair only when settings re-wipe on every reboot for three reboot cycles after re-entry (real flash failure), the serial log shows `nvs_flash_init: ESP_ERR_NVS_*` on every boot even after `Erase Flash` + reflash, the AP never comes up at `http://192.168.4.1/` post-flash, you flashed the wrong `.bin` for your chip variant and the device is non-functional, or there is visible burn damage near the SPI flash chip or ESP32 module.

Ship to D-Central safely if real flash corruption is suspected. Anti-static bag, double-box with `≥ 3 cm` of foam every side, include a note: variant (Supra / Ultra / Gamma / GT / Hex / Max), firmware version that triggered the issue, what you have already tried (re-entry, reflash, Erase Flash), and a serial log excerpt if you captured one. D-Central will bench-test the SPI flash chip via JTAG, write a clean NVS partition, verify retention across power cycles, and replace the flash chip if write-cycle exhaustion is confirmed — saving you the cost of a full board replacement.