Bitaxe – Serial Console Outputs Junk / Wrong Baud Rate

Set your serial program to `115200` baud, `8N1`, no flow control. This is AxeOS / ESP-Miner's runtime baud and it's right for 99% of what you want to read. 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`. In Arduino Serial Monitor: choose `115200 baud` from the dropdown. Open or re-open the connection, then tap reset on the Bitaxe or unplug-replug. Within 2 seconds you should see English text 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 ROM prints at `74880` baud (a non-standard rate baked into mask ROM by Espressif), then control transfers to AxeOS at `115200`. If you don't care about the ROM prologue, leave the monitor at `115200` and ignore those first lines. If you do care, momentarily switch to `74880`, capture the prologue, switch back.

Swap to a known-good USB-C *data* cable. Charge-only USB-C cables — common with phone fast-chargers — have only the power pins wired and produce a Bitaxe that powers on but never enumerates as a serial device. Use a cable you have personally seen successfully transfer files or flash another microcontroller. For Gamma / GT (native USB-C), a USB-A-to-C cable from a computer's USB-A port avoids USB-PD negotiation oddities.

Try a different USB port. USB hubs (especially unpowered hubs and USB-C dongles) drop bytes under load and confuse the timing assumptions on either side of the UART. Plug directly into a USB-A 2.0 port on the computer, ideally one not shared with a wireless mouse / keyboard receiver / external drive. If the junk clears, the hub was the problem.

Restart the serial program after every baud change. PuTTY in particular caches 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 in priority order: `115200`, `74880`, `460800`, `921600`, `230400`, `38400`, `9600`. Try each, tap reset on the Bitaxe, watch the screen for 5 seconds. Document which baud produces readable output. Most Bitaxes settle at `115200` once AxeOS is running; if you've flashed a custom firmware fork, you may land on `230400` or `921600` instead.

Verify your USB-to-serial driver on Windows. Device Manager -> Ports (COM & LPT) -> right-click your Bitaxe COM port -> Properties -> Driver tab. ESP32-S3 native-USB Bitaxes (Gamma/GT/Hex/Max) should appear as `USB Serial Device` with a Microsoft-supplied CDC-ACM driver. If you see a yellow-bang exclamation, missing-driver state, or wrong driver, reinstall — Microsoft's CDC-ACM driver is included in Windows 10/11. For older Bitaxes wired through a separate UART chip, you should see Silicon Labs (CP2102/CP2104) or WCH (CH340/CH341).

Try a second terminal program. If PuTTY shows garbage at `115200`, open the same port in CoolTerm or `screen`. Different programs handle line-ending translation, control-character display, and terminal-emulation modes differently. CoolTerm in particular is forgiving for ESP32 work. If a second program shows clean text where the first showed junk, you have a terminal config issue (not baud) — adjust the original program's display settings, often `Translation: UTF-8` or `Implicit CR in every LF` toggles in PuTTY.

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

Disable hardware flow control explicitly. ESP-Miner 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 — symptoms range from no output at all to intermittent garbage. In PuTTY, set Flow control to `None` under Connection -> Serial. `screen` defaults to none. `minicom` defaults to hardware-on; disable in setup.

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

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

Use `idf.py monitor` from ESP-IDF for automatic baud handling. Espressif's official monitor — part of ESP-IDF — handles ROM-to-app baud auto-switch, decodes ROM-level reset/boot messages, and resolves panic addresses to source file and line. Install ESP-IDF, clone ESP-Miner, run `idf.py -p /dev/ttyACM0 monitor`. Steeper learning curve than PuTTY, but it's the right tool for serious firmware work on a Bitaxe.

Build ESP-Miner from source with verbose log level. Clone github.com/bitaxeorg/ESP-Miner, edit `sdkconfig.defaults` to set `CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y`, run `idf.py build flash monitor`. Verbose logging at `115200` produces 5-10x more output than the stock `INFO` level — every UART transaction, every stratum frame, every chip command. Useful when chasing a bug that needs more than the default log surface.

For 24/7 solo-mining sovereignty operators: pipe the serial console to syslog. A Bitaxe running 24/7 generates dozens of useful log lines per minute. Pipe `/dev/ttyACM0` through `socat` or a small Python script into your home-lab syslog or Loki/Grafana stack. You now have searchable, timestamped serial logs for every Bitaxe in the rack, and you can correlate `Serial RX invalid 11`, `bm1366Module` errors, and stratum disconnects across your fleet.

Escalate to D-Central. If multi-baud sweep, multiple terminal programs, and a verified driver all produce garbage on a single Bitaxe — and the AxeOS web UI also can't reach the device — the ESP32-S3 itself may be wedged or damaged (post-brownout, post-OTA-fail, ESD event). Stop the baud chase. The serial line isn't your problem; the chip is. Book a D-Central pleb-mining queue slot.

D-Central bench process for unrecoverable Bitaxes: USB enumeration test on a known-good host, ESP32-S3 boot-log capture at all 7 standard baud rates simultaneously via parallel ports, voltage rail check at the TPS546 buck on Gamma/GT and the AP63203 on Supra/Ultra, JTAG flash dump and re-flash with a verified AxeOS image, ASIC chip response test (BM1366/1368/1370 family) on a known-good firmware image, 24-hour burn-in on Ocean pool. Turnaround 3-7 business days Canada-wide, 5-10 days US/international. We stock spare BM chips and ESP32-S3 modules.

Ship to D-Central with documentation. Anti-static bag, double-box with 3 cm of foam on every side. Include a printed note with: which baud rates you tried, what error (if any) the serial console showed at each, AxeOS version (if known), pool URL, the symptom timeline (`worked yesterday, junk today after firmware flash`). That information cuts diagnostic time in half — which cuts your repair bill in half. Ship to the address on the D-Central ASIC Repair page and ask for the pleb-mining queue.