Passer au contenu

Nous améliorons nos opérations pour mieux vous servir. Les commandes sont expédiées normalement depuis Laval, QC. Questions? Contactez-nous

Bitcoin accepté au paiement  |  Expédié depuis Laval, QC, Canada  |  Soutien expert depuis 2016

BITAXE_METRICS_MISSING Info

Bitaxe – Power/ASIC Temp/Input Voltage Not Showing in Dashboard

AxeOS dashboard reports a real, climbing hashrate while the Power, ASIC Temp, and Input Voltage fields show as `--`, `null`, or `0` simultaneously. The hashing path (BM1366/BM1368/BM1370 ASIC over UART/SPI) is unaffected, but one or more I2C-attached sensor sub-systems (TPS546 PMBus, EMC1412 dual-channel temp, INA219 current sense) are not returning valid reads. Documented as ESP-Miner Issue #1662 — a regression band centered on AxeOS v2.13/v2.14 where the sensor-read path silently fails on a subset of Bitaxe units while the hashing path continues normally.

Informational — Monitor and address as needed

Affected Models: Bitaxe Supra (BM1368), Bitaxe Ultra (BM1366), Bitaxe Gamma 601/602 (BM1370), Bitaxe Gamma Turbo / GT (dual BM1370), Bitaxe Hex (six x BM1366) — every Bitaxe variant running AxeOS v2.13 / v2.14 family with a working ASIC but a broken I2C sensor read path

Symptoms

  • Hashrate field on AxeOS dashboard reads a real, climbing number (e.g. 1.20 TH/s, 4.85 TH/s) while telemetry fields are blank
  • Power field reads `--`, `null`, `0 W`, or is missing entirely from the dashboard
  • ASIC Temp field reads `--`, `null`, `-1.0 C`, `0 C`, or is missing
  • Input Voltage (or `VIN` / `Voltage In`) field reads `--`, `null`, `0 V`, or is missing
  • /api/system/info JSON returns `"power": null`, `"temp": null`, `"voltageInput": null` while `"hashRate"` shows real value
  • Core Voltage (VCORE) and Frequency setpoints still report correctly - only the measured / read-back values are dead
  • VRM Temp (Gamma TPS546 die temp) may also read `--` depending on how deep the I2C failure extends
  • Symptom appeared immediately after an OTA upgrade to AxeOS v2.13 or v2.14
  • Cold power-cycle restores telemetry for the current boot session, but it disappears again on next reboot (intermittent pattern)
  • Or, telemetry stays `--` permanently, regardless of power-cycle, factory-reset, or reboot pattern (consistent pattern)
  • Fan curve appears stuck at one PWM (firmware can't drive the curve without temp feedback) - fan either screaming at 100% or stuck low
  • Serial console at 115200 baud shows `i2c: open failed`, `i2c_master_transmit_receive` errors, or `ESP_ERR_TIMEOUT` near boot
  • Multiple Bitaxes in a swarm hit the same fault on the same firmware version simultaneously (rules out per-board hardware damage)

Step-by-Step Fix

1

Hard power-cycle at the wall outlet for a full 30 seconds. Not the AxeOS reboot button - that calls esp_restart() and leaves I2C peripherals in their wedged state. Pull the cord, count 30 seconds, replug. Watch the dashboard for the first 60 seconds after boot. This single action restores telemetry on the current boot for roughly half of affected units. It does not prevent recurrence on the next boot - that requires a Tier 2 firmware rollback or Tier 3 hardware fix.

2

Roll back AxeOS to v2.12.x or the last release before the Issue #1662 regression band. Visit github.com/bitaxeorg/ESP-Miner/releases, download the factory .bin for your chip family (bm1366 for Ultra, bm1368 for Supra, bm1370 for Gamma/GT, bm1366 six-up for Hex). Flash via the Bitaxe Web Flasher at bitaxe.org - Chrome browser, USB-C cable, hold BOOT, click Flash. Reconfigure WiFi and pool credentials after first boot. Verify all three telemetry fields populate within 60 seconds. If they do, you confirmed the firmware regression and you are done.

3

Try the latest AxeOS build only if release notes confirm the Issue #1662 sensor-read fix has merged. Do not blindly roll forward - read the release notes first. Mining Hacker rule: never trust the `Latest` tag, verify the specific bug is referenced in the changelog. If the fix is confirmed in, flash forward and verify telemetry returns. If the fix is not yet in, stay on v2.12.x and watch the upstream issue thread.

4

Erase NVS and factory-reflash. A corrupted NVS partition from a partial OTA upgrade can keep stale state alive after a fresh firmware flash. With esptool.py and USB-C: `esptool.py --chip esp32s3 erase_region 0x9000 0x6000`, then flash the factory image of your chosen AxeOS version. You will need to reconfigure WiFi and pool credentials afterward. This wipes any sensor-init state that survived the regression.

5

Disconnect any optional peripherals from the I2C header. If you have added an SSD1306 OLED display or wired in a custom external sensor, disconnect it. Optional peripherals share the I2C bus with the EMC1412, TPS546 PMBus, and INA219. A flaky external connector or stuck slave on a custom add-on can wedge the bus for the on-board sensors. Strip the Bitaxe back to stock and retest.

6

Capture the serial boot log at 115200 baud 8N1. USB-C cable, serial terminal (`screen /dev/ttyUSB0 115200` on Linux/Mac, PuTTY or Arduino Serial Monitor on Windows), log to file. Power-cycle and capture the first 30-60 seconds. The log identifies which subsystem is failing: PMBus / TPS546, EMC1412, INA219, or the I2C bus itself. This single file saves 30+ minutes of bench diagnostic time if you ship to D-Central.

7

Multimeter the input power rail under load. DC mode, probe the barrel jack tip (5 V Bitaxe variants) or XT30 connector (12 V Hex / GT variants) while the miner is hashing. Expect at least 4.85 V sustained on a 5 V Bitaxe, at least 11.5 V on the 12 V Hex / GT. PSU sag below those thresholds extends the I2C cold-boot race window where sensor handle init fails. Swap to a known-good supply, retest.

8

Multimeter check the I2C pull-up resistors. Power off, probes from SDA to the 3.3 V rail, then SCL to 3.3 V rail. Healthy resistance: 4.7 kOhm to 10 kOhm. Open circuit (OL) means the pull-up is gone or its trace is broken. Above 100 kOhm means the pull-up has migrated, lifted pad, or cold joint. Out of spec means escalate to Tier 3 to replace 0603 SMD pull-ups.

9

Probe VDD at each I2C peripheral. Power on, multimeter on DC. EMC1412 (MSOP-8 near the ASIC): pin 1 should read 3.3 V plus or minus 0.1 V. TPS546 (Gamma/GT): VIN should read 5 V plus or minus 0.15 V. INA219 (where fitted): pin 1 should read 3.3 V. A peripheral starved of power cannot ACK; check the upstream regulator and look for a short pulling the rail down before assuming the chip itself is dead.

10

Visual inspect each sensor under magnification. 10x loupe minimum, 20x preferred. EMC1412 first - MSOP-8, U-prefix designator near the ASIC. Look for darkening, lifted package corner, carbonized residue. Then TPS546 (smallest QFN on Gamma/GT, near the barrel jack) - same checks. INA219 is a SOT-23-8 if present. Visible damage means silicon fault, escalate to Tier 3 replacement.

11

Power-cycle ten times back-to-back and pattern-match. Cycle wall power 10 times in a row, with 30 seconds off between each cycle. Log how many of those 10 boots have working telemetry. 10/10 working means you fixed it. 7-9/10 means race condition still present, needs a Tier 2 firmware patch or Tier 3 hardware fix. Less than 5/10 means consistent hardware fault, jump to Tier 3.

12

Two-channel scope on SDA + SCL, ground at EMC1412 pin 8 or TPS546 AGND. Trigger on either edge, power up the Bitaxe. Healthy bus: clean approximately 3.3 V square waves, fast edges (~50 ns rise time), ACK pulses on every transaction. Sluggish rise time means pull-ups bad. SDA stuck low means slave wedged. No clock activity means ESP32-S3 is not transmitting (firmware fault). This single scope capture pinpoints the failure mode faster than any other diagnostic.

13

Replace the I2C pull-up resistors. Hot-air rework, 4.7 kOhm 0603 SMD resistors (verify against the schematic for your specific Bitaxe revision). Lift the old, clean pads with flux + braid, place the new resistors, reflow at 280-300 C for 10 seconds, cool naturally. Re-test with multimeter (4.7 kOhm between each line and 3.3 V), power up, watch /api/system/info for telemetry recovery.

14

Reflow the suspect peripheral in place. For intermittent fault patterns where the chip looks fine but reads sometimes fail: apply liquid flux to all pins, hot air at 290-310 C for 15 seconds for EMC1412 (MSOP-8) or INA219 (SOT-23-8); 280-310 C for 20 seconds for TPS546 (QFN40). Light pressure with tweezers to encourage joint reflow. Cool naturally, reassemble, retest. Reflow alone resolves around 30% of intermittent telemetry cases on the D-Central bench.

15

Replace the EMC1412 if reflow does not fix the temperature read. Source from Mouser, Digi-Key, or Arrow - not random AliExpress (counterfeit MSOP-8 sensors are real). Lift the dead chip with hot air at 310 C, clean pads with flux + solder wick, place the new chip honoring the pin-1 marker, reflow at 290-310 C. Part is approximately 1 USD. Power up, scope confirms bus is healthy, dashboard shows real ASIC Temp.

16

Replace the TPS546 if PMBus reads stay dead. QFN40 5x7 mm package, doable on a bench with hot air, flux, and patience. TPS546D24S from Digi-Key or Mouser. Honor pin-strapping resistors (they encode VCORE setpoint for the BM1370). Lift the old, clean pads, place new, reflow at 290-310 C. Same procedure as the VCORE Init Failed repair. Verify VIN, VOUT, and PMBus telemetry on first boot.

17

Replace the INA219 (where fitted, on board revisions that use it). SOT-23-8 or MSOP-8 depending on the revision. Lift, clean, place, reflow. Same workflow as the EMC1412 but a different chip family. Confirm the I2C address jumpers (some INA219 packages support 0x40 to 0x4F via address pins) match what AxeOS expects on your variant. Verify the schematic for your specific Bitaxe board revision before ordering.

18

Stop DIY and ship to D-Central. Triggers: (a) all three I2C sensor chips replaced and bus still does not return clean telemetry, (b) you cooked a pad during rework and lifted copper, (c) multiple Bitaxes from the same batch / firmware version exhibit the fault and you suspect board-level QC issue, (d) repeat death of the same sensor within days of replacement, or (e) you do not have hot-air / scope / SMD chops. Ship the board with serial log, firmware version history, and symptom description. Turnaround 5-10 business days, Canada-wide, US / international welcomed. D-Central has been in the Bitaxe ecosystem since the first board shipped.

When to Seek Professional Repair

If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.

Related Error Codes

Still Having Issues?

Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.