NerdMiner – Serial Output Garbled / Wrong Baud Rate

Set the serial program's baud to `115200`, `8N1`, no flow control. This is `BitMaker-hub/NerdMiner_v2`'s runtime baud per the repo's `platformio.ini`. In PuTTY: Connection → Serial → Speed `115200`, Data bits `8`, Stop bits `1`, Parity `None`, Flow control `None`. In `screen` on macOS/Linux: `screen /dev/tty.usbmodem-XXXX 115200` or `screen /dev/ttyUSB0 115200`. In Arduino Serial Monitor: choose `115200 baud` from the bottom-right dropdown. Open the connection, tap the NerdMiner's `RST`/`EN` button or unplug-replug. Within 2 seconds you should see English text — pool URL, stratum subscribe response, mining-job receipt — scrolling.

If the first ~1.5 seconds of boot is junk but everything after is clean, you're reading the ESP32 ROM bootloader at the wrong baud. The ESP32 / ESP32-S3 mask ROM prints at `74880` baud, then control transfers to NerdMiner at `115200`. If you don't care about the ROM prologue, leave the monitor at `115200` and ignore the first ~1.5 seconds of garbage. If you want the prologue (helpful for diagnosing brownouts, flash CRC errors, stuck-in-download-mode bootloaders), momentarily switch to `74880`, capture, then switch back to `115200`.

Swap to a known-good USB *data* cable (not charge-only). Test the cable by plugging into a phone connected to a computer: if the phone offers `File Transfer` mode, the cable carries data. If only `Charging only` appears, replace the cable. Charge-only USB-C cables from phone wall warts are the #1 silent enumeration-failure cause and produce symptoms identical to baud junk.

Try a different USB port — preferably rear-panel USB-2 on a desktop, or any USB-2 port on a laptop. USB hubs and USB-C docking stations drop bytes under load and confuse UART timing. USB-3 hubs frequently mis-negotiate the ESP32-S3 native USB descriptor handshake. Plug directly into the computer, ideally a USB-A 2.0 port not shared with a wireless mouse / keyboard receiver.

Restart the serial program after every baud change. Some terminal programs (PuTTY in particular) cache the baud setting in a way that makes 'live' baud changes unreliable. Close the connection completely, change the baud, re-open. Don't trust a baud change that wasn't preceded by a disconnect.

Sweep the standard ESP32 baud table: `115200`, `74880`, `460800`, `921600`, `230400`, `38400`, `9600` (in priority order). Try each, tap `RST`/`EN` on the NerdMiner, watch for 5 seconds. Most NerdMiners settle to `115200` once `app_main` is running; some community forks ship `230400` or `921600` as the runtime baud. Document the baud that produces clean output.

Install the right USB-to-serial driver — by board. ESP32-WROOM DevKit / Espressif reference boards: install Silicon Labs CP210x VCP drivers from silabs.com, reboot Windows after install. NodeMCU-32S / cheap ESP32 clones: install WCH CH341SER from wch-ic.com (HTTP-not-HTTPS is normal for WCH). Arduino Nano ESP32: install the WCH CH343SER package. LilyGo T-Dongle-S3 / T-Display S3 / T-QT Pro / any ESP32-S3 native USB board: no driver install needed on Windows 10 build 1709+, modern macOS, or current Linux — these enumerate as generic CDC-ACM. If a yellow exclamation persists on a CDC-ACM device, Device Manager → Uninstall device → unplug → wait 5 seconds → replug into a different USB-2 port.

Try a second terminal program. If PuTTY shows garbage at `115200`, open the same port in CoolTerm, `screen`, or `idf.py monitor`. Different programs handle line endings, control characters, and encoding differently. CoolTerm is forgiving for ESP32 work. If a second program shows clean text where the first showed junk, you have a terminal config issue, not a baud problem. In PuTTY: Window → Translation → Remote character set: `UTF-8`. In `minicom`: setup menu → disable hardware flow (`Ctrl-A` then `O` → 'Serial port setup' → `F` → No).

On macOS / Linux, use the right device path. ESP32-S3 native-USB NerdMiners appear as `/dev/tty.usbmodem-XXXX` (macOS) or `/dev/ttyACM0` (Linux). Older ESP32-WROOM DevKits with a separate UART chip appear as `/dev/tty.usbserial-XXXX` or `/dev/tty.SLAB_USBtoUART` (macOS) or `/dev/ttyUSB0` (Linux). List with `ls /dev/tty.*` (macOS) or `ls /dev/ttyACM* /dev/ttyUSB*` (Linux), unplug the NerdMiner, list again, and use the entry that disappeared.

Disable hardware flow control explicitly. NerdMiner does not use RTS/CTS hardware flow control on the console UART. Some terminal programs default to enabling it, which causes the program to wait for a CTS signal that never arrives. In PuTTY: Connection → Serial → Flow control: `None`. In `screen`: default is none. In `minicom`: setup → 'Serial port setup' → `F` (Hardware Flow) and `G` (Software Flow) both `No`.

On Linux, kill `ModemManager` and `brltty` before opening the port. Both daemons grab newly-enumerated USB-serial devices on Ubuntu / Fedora / Debian for ~10 seconds at plug-in time, sending random AT commands that crash the NerdMiner's startup logging. `sudo systemctl stop ModemManager brltty` before plugging in the NerdMiner; permanently disable with `sudo systemctl disable ModemManager brltty` on a dedicated dev workstation. Catches a meaningful percentage of 'Linux serial garbage on first plug' reports.

Set the terminal text encoding to UTF-8 explicitly. ESP-IDF and Arduino-ESP32 emit UTF-8. PuTTY's older default was Win1252; Chinese-locale Windows defaults to GBK; Japanese-locale to Shift-JIS. PuTTY: Window → Translation → Remote character set: `UTF-8`. CoolTerm: Connection → Options → Receive Options → 'Receive UTF-8' enabled. In `screen`: `Ctrl-A` then `:encoding UTF-8`. The bytes on the wire are identical; encoding only changes how the terminal renders them.

Capture a logic-analyzer trace. A $15-$60 Saleae Logic 8 clone, Sigrok-compatible analyzer, or DSLogic Plus probes the ESP32-to-USB TX/RX lines directly. Sample at 1 MHz, decode UART at the suspect baud rate. The decoder tells you, byte-for-byte, what the chip is sending — independent of any USB-stack, OS, or terminal weirdness. If bytes decode cleanly at `115200`, your terminal program or driver is the problem. If they decode cleanly at a different baud, you're on a non-standard build.

Read the ROM bootloader prologue at `74880`. This prologue contains boot-mode (`SPI_FAST_FLASH_BOOT` vs `DOWNLOAD_BOOT`), flash CRC, and reset reason — invaluable for diagnosing brownouts, flash corruption, and bootloader-stuck-in-download-mode failures. Connect at `74880`, tap `EN`, capture the first 1.5 seconds. Sample output: `rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)` followed by `flash read err, 1000` (flash issue) or `entry 0x40080xxx` (clean boot). If reset reason isn't `POWERON_RESET` / `SW_RESET` / `DEEPSLEEP_RESET`, you have an underlying issue (brownout, watchdog, panic) that no baud sweep will fix.

Use `idf.py monitor` for automatic baud handling and panic decoding. Espressif's official monitor — part of ESP-IDF — handles the ROM-to-app baud switch automatically, decodes ESP32 panic addresses to source file + line, and color-codes log levels. Install ESP-IDF, clone `BitMaker-hub/NerdMiner_v2`, run `idf.py -p /dev/ttyACM0 monitor` (Linux) or `idf.py -p COMx monitor` (Windows). Steeper learning curve than PuTTY, but the panic decoder alone is worth the install.

Build NerdMiner from source with verbose logging. Clone `BitMaker-hub/NerdMiner_v2`, set `CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y` in `sdkconfig` (or PlatformIO `build_flags`), run `pio run -t upload` then `pio device monitor`. Verbose logging at `115200` produces 5-10× more output than the default `INFO` level — every WiFi event, every stratum frame, every chip command on NerdAxe variants, every job receipt. Useful when chasing silent share rejection, intermittent disconnects, or mid-session resets.

For 24/7 fleet operators: pipe the serial console to syslog. `socat /dev/ttyACM0,raw,echo=0,b115200 - | logger -t nerdminer-01` is a one-liner that ships every line into journald with a tag. Now you have searchable, timestamped serial logs for every NerdMiner in the rack — and you can correlate `Mining job received`, share submissions, and stratum disconnects across the fleet. Mining Hacker fleet-observability for $0 in additional hardware.

Stop DIY and ship to D-Central when: multi-baud sweep, multiple terminal programs, the right driver, UTF-8 encoding, and a verified data cable on a known-good USB-2 port all produce garbage on a single NerdMiner — and the on-board display is also blank or frozen. The ESP32 / ESP32-S3 itself may be wedged or damaged (post-brownout, post-OTA-fail, ESD, water, USB-PD over-voltage). Stop the baud chase. The serial line isn't your problem; the chip is. Visible physical damage (burnt USB, cracked solder, electrolytic smell, swollen RF shield) → ship immediately.

D-Central bench process for unrecoverable NerdMiners: USB enumeration test on a known-good rear-panel USB-2 host, ESP32 / ESP32-S3 boot-log capture at all 7 standard baud rates simultaneously via parallel ports, voltage-rail check (VBUS, 3V3, board-specific intermediates), `espefuse.py --chip esp32s3 summary` to confirm no eFuses got accidentally burned, JTAG flash dump and re-flash with a verified `BitMaker-hub/NerdMiner_v2` release image, full functional test against `solo.ckpool.org` or `public-pool.io` with hashrate stable for 60 minutes before ship-back. Turnaround 3-7 business days Canada-wide, 5-10 days for US/international.

Ship safely to D-Central. Anti-static bag, double-box with 3 cm of foam on every side. Include a printed note: which baud rates you tried, what (if any) error the serial console showed at each, USB-to-serial chip on the board (CP2102 / CH340 / native S3), driver version installed, OS + version, NerdMiner firmware version (or `unknown` if second-hand), pool URL, symptom timeline ('worked yesterday, junk today after firmware flash'). Information cuts diagnostic time in half. Ship to the address on d-central.tech/services/asic-repair/ and ask for the open-source / Nerd-family queue.