Your Bitaxe Dashboard, Explained: Hashrate Error, Stale Shares, and When to Actually Worry

The AxeOS dashboard throws twelve numbers at you before you’ve finished your morning coffee.

Most first-time Bitaxers look at it once, see that “Hashrate Error %” isn’t zero, and immediately wonder if they’ve been scammed. Most of the time: they haven’t. The dashboard just speaks a different language than the marketing page did.

This piece is a field guide to every number on your dashboard. What each one measures. What normal looks like. When to actually worry. And — because we hear this every week — the seven non-problems Aussie Bitaxers consistently panic about.

The panel tour

A typical Bitaxe Gamma running AxeOS 2.7+ shows something like this:

────────────────────────────────────────────
 HASHRATE           1.18 TH/s
 EXPECTED           1.20 TH/s
 EFFICIENCY         14.2 J/TH
 BEST DIFFICULTY    1.18 G
 ────────────────────────
 TEMPERATURE (ASIC) 58 °C
 TEMPERATURE (VR)   72 °C
 POWER              17.1 W
 VOLTAGE            5.03 V (input) · 1.24 V (core)
 ────────────────────────
 FREQUENCY          525 MHz
 FAN                87% (5400 RPM)
 ────────────────────────
 SHARES ACCEPTED    42,891
 SHARES REJECTED    18
 SHARES STALE       112
 HASHRATE ERROR %   1.7%
 UPTIME             12 d 4 h
────────────────────────────────────────────

Let’s walk through it.

Hashrate metrics

HASHRATE (measured)

What it is: the actual rate at which your chip is producing valid nonces, derived from your rolling share submissions to the pool. It’s an estimate — the true instantaneous hashrate fluctuates — so AxeOS averages over the last ~10 minutes.

Normal: 1.0–1.3 TH/s for a stock Bitaxe Gamma. 0.45–0.55 TH/s for a Bitaxe Ultra. 4.2–4.9 TH/s for a NerdQaxe++.

Concerning: consistently 15%+ below the expected hashrate. Check in this order: (1) fan curve, (2) PSU voltage under load, (3) overclock settings, (4) firmware version.

EXPECTED HASHRATE

What it is: the theoretical hashrate if every cycle produced a hash. Calculated from frequency × chip_count × cores_per_chip.

If you see Expected = 1.20 TH/s and Measured = 1.18 TH/s, the 2-ish percent gap is your hashrate error plus network-level latency. This is fine and expected.

Concerning: Expected = 1.50 TH/s but Measured = 1.20 TH/s. Means you’ve pushed frequency up in the overclock settings but the chip can’t actually deliver that in practice — hashrate error will be huge. Back off the overclock.

HASHRATE ERROR % — the big one

What it actually measures: the percentage of hash cycles the chip attempted that didn’t produce a valid result. It’s a hardware-level metric, read from the ASIC’s internal counters. It has nothing to do with pool share acceptance.

A perfect chip running inside its stable envelope: 0%.

A chip pushed past stable voltage/frequency: 3-10%. Each failed hash cycle is wasted power — you’re drawing wattage without the hashrate to show for it.

Normal: 0-3%. Most stock Bitaxes sit around 0.5-2%.

Concerning: 5%+ sustained. Diagnostic path:

1. Roll back overclock. If you’ve touched the frequency or voltage sliders, return them to stock (490 MHz / 1.20 V for Gamma) and let it run for 30 minutes. If error drops to 1-2%, your overclock is the cause — dial back.
2. Check PSU voltage under load. A cheap or marginal PSU sagging from 5.0 V to 4.8 V under load causes hashrate errors. Known-good PSUs (the Mean Well 5V/6A Aussie-plug unit we ship, the official Bitaxe PSU) don’t do this. Random 5 V bricks from Jaycar or Bunnings often do.
3. Check cooling. A too-hot ASIC starts missing cycles before it thermal-throttles. Make sure the fan is spinning. Check VR temp (not ASIC) — if VR is 85°C+, improve airflow.
4. Check firmware. A known-bad AxeOS build can cause elevated error. See our firmware tracker for release-by-release notes.

Why people panic about this: the marketing page said “1.2 TH/s” and the dashboard says “hashrate error 1.7%” and the natural assumption is “I’m getting 1.7% less hashrate than advertised.” Not quite. You’re getting 1.7% wasted hash cycles, which translates to about 1.7% hashrate reduction relative to a perfect chip. Bitaxe Gamma chips vary — some silicon lottery winners error at 0.3%, some error at 2.5%. The spec is for average silicon.

EFFICIENCY (J/TH)

What it is: Joules of electricity per Terahash of work. power ÷ hashrate. Lower is better.

Normal: 14-17 J/TH for stock Bitaxe Gamma. 22-28 J/TH for Bitaxe Ultra. 15-18 J/TH for NerdQaxe++.

Concerning: 20 J/TH+ on a Gamma — means either the overclock is pumping extra voltage without commensurate hashrate, or the PSU is delivering more than 5 V, or cooling is marginal and chips are drawing more current.

BEST DIFFICULTY

What it is: the highest-difficulty share your miner has ever found in this session. Bitcoin network difficulty is currently around 144 trillion; if your “Best Difficulty” ever exceeds that, you’ve solo-mined a block.

Normal: for a Bitaxe Gamma, best-difficulty shares typically peak around 1–20 billion within a few weeks of continuous operation. A G (giga, 10^9) is vastly short of network difficulty (T = tera = 10^12; 144 T = 144,000 G) — but hitting high-G shares is what makes solo mining fun to watch.

Concerning: nothing. This number only goes up and has no performance implication.

Temperature metrics

TEMPERATURE (ASIC)

What it is: the die temperature of the hashing chip, read from the on-die sensor.

Normal: 50-65°C on a properly-cooled Bitaxe Gamma in an Aussie room (20-25°C ambient).

Concerning: 70°C+. At 75°C the chip begins thermal-throttling (frequency reduction to maintain safe temperature). At 85°C it will shut down.

Aussie-specific heads-up: in a poorly-ventilated spare room in Perth or Brisbane in February, ambient can hit 35°C. ASIC temps will rise proportionally. If you see mid-70s ASIC in summer, either move the miner to a cooler room or improve the airflow path to the heatsink.

TEMPERATURE (VR)

What it is: the temperature of the voltage regulator that steps the 5 V input down to the 1.2 V core voltage. The VR is a small power-handling component that gets hotter than the ASIC by design.

Normal: 65-80°C. The VR is expected to run 10-20°C hotter than the ASIC.

Concerning: 85°C+. Usually means the fan isn’t moving enough air across the VR, or the VR heatsink isn’t making good contact. Check: fan RPM (is it actually spinning?), that you haven’t accidentally blocked the intake, and — if thermal paste came loose — consider a reapplication.

This is the single biggest source of dashboard panic. “Help, my Bitaxe is at 72°C!” is almost always the VR temperature, which is fine.

Power and voltage

POWER

What it is: total wattage the miner is drawing from the PSU, measured at the input.

Normal: 15-18 W for Bitaxe Gamma stock. 10-14 W for Ultra. 65-85 W for NerdQaxe++.

Concerning: 25 W+ on a Gamma. Means voltage is too high or the overclock is way off.

VOLTAGE (INPUT)

What it is: the voltage at your PSU output, as measured by the Bitaxe. Should be 5.00 ± 0.05 V.

Normal: 4.95-5.05 V.

Concerning: below 4.90 V indicates PSU sag. Above 5.10 V indicates a PSU out of spec (rare but possible with cheap units). Both cause hashrate instability.

VOLTAGE (CORE)

What it is: the stepped-down voltage feeding the ASIC core. Controlled via the AxeOS UI (settings → voltage).

Normal: 1.18-1.25 V for stock Gamma. Higher = more hashrate at the cost of efficiency (and heat).

Concerning: anything above 1.30 V without cooling mods. You’re burning efficiency and accelerating chip wear.

Frequency and fan

FREQUENCY

What it is: ASIC clock speed in MHz. Stock is 490 MHz for Gamma. Push it up for more hashrate; push it down for better efficiency.

Normal: 480-560 MHz range is the common hobbyist overclock band.

Tuning: small iterative steps. +10 MHz, wait 10 minutes, watch hashrate error %. If error climbs, back off. The stable ceiling is silicon-lottery dependent — some chips top out at 510 MHz, others go to 580+.

FAN

What it is: current fan PWM duty cycle (0-100%) and measured RPM.

Normal: auto mode has the fan modulating with temperature — typically 40-80% under normal load, rising toward 100% only if things get hot. You can force it to 100% in settings (quieter chip, louder fan).

Concerning: fan showing 100% PWM but 0 RPM means the fan has failed. Replace it. They’re a few dollars. Don’t run without a fan — you’ll kill the ASIC in minutes.

Share metrics (the pool side)

SHARES ACCEPTED

What it is: the running count of shares the pool has accepted from you during this session. Each accepted share is a valid work proof below the pool’s difficulty target.

Normal: scales with time. A Bitaxe Gamma on a pool with difficulty 1 G submits roughly 1 share/sec = 3,600/hour = 86,400/day. (Pool difficulty varies; Braiins and Public-Pool use different defaults.)

SHARES REJECTED

What it is: shares submitted that the pool refused. Could be: wrong difficulty (firmware bug), duplicate (network glitch), malformed (protocol issue), or low-difficulty (chip produced invalid work).

Normal: 0-0.5% of accepted shares. Most days, 0.

Concerning: 1%+ rejected. Diagnostic steps:

1. Check firmware version — some AxeOS builds had protocol bugs (see firmware tracker).
2. Check pool choice — some pool endpoints reject shares more aggressively than others.
3. Check network stability — flaky Wi-Fi can corrupt share submissions.

SHARES STALE

What it is: shares you submitted but which arrived too late — the pool had already moved to a new block template when your share showed up.

Normal: stale rate scales with network latency. For a Bitaxe in Sydney submitting to:

• ausolo.ckpool.org (Aussie-hosted): typically 0.05-0.2% stale
• Parasite Pool (EU endpoint): typically 1-3% stale
• Ocean (Singapore): typically 0.5-1.5% stale

See our pool comparison piece for latency numbers.

Concerning: 5%+ stale. Usually means Wi-Fi dropping packets (move to ethernet) or a flaky upstream ISP connection.

Stale ≠ rejected. Stale shares don’t earn you money on most payout schemes, but they don’t count against you either. Consistent stale is an infrastructure problem, not a miner problem.

The seven non-problems

Here are the things Aussie Bitaxers panic about in our DMs that are, almost always, not problems.

1. “My hashrate error is 2%!”

Normal. Stock Bitaxe Gamma silicon errors at 0.5–2.5% without overclock. It’s a hardware property, not a fault.

2. “My temperature is 72°C!”

That’s the VR, not the ASIC. Normal. The ASIC is probably at 58–62°C, which is fine.

3. “Measured hashrate is less than expected!”

The 2-4% gap between expected and measured is hashrate error plus latency. It’s baked into the spec.

4. “I have stale shares!”

If you’re pointing at a non-Aussie pool, stale rates of 0.5-3% are normal — it’s geography, not your miner.

5. “My fan is at 100%!”

Fan ramps on a curve. Under overclock or in summer heat, 100% is the correct automatic response. If it’s genuinely noisy, either (a) undervolt/underclock, (b) improve case airflow, or (c) accept the noise as the cost of the hashrate.

6. “My best difficulty is only 50 M, the network is at 144 T!”

Best difficulty climbs over time — you’ll see it crest 1 G, then 10 G, then 100 G as the session runs. Network difficulty at 144 T is ~3 million times higher than a typical Bitaxe best-difficulty. That’s why solo-mining a block is a 0.008% annual lottery, not a weekly occurrence.

7. “I’ve been running for a week and found no block!”

Right. See point 6. At Bitaxe scale, you’ll find a block roughly every 120 years on expected value. Solo mining is a variance play, not an EV play. If you want daily payouts, use a pooled FPPS — see our pool comparison.

The actual things to worry about

To balance the list — if you see any of these, investigate:

1. Hashrate error % > 5% sustained → overclock too aggressive, or PSU marginal.
2. ASIC temperature > 75°C → cooling problem. Check fan, airflow, thermal paste.
3. VR temperature > 85°C → serious cooling problem. Stop miner and investigate.
4. Rejected shares > 1% → firmware bug or network problem.
5. Input voltage < 4.90 V under load → replace PSU.
6. Measured hashrate < 80% of expected → major problem. Check all of the above.
7. Fan PWM 100% with 0 RPM → fan failed. Replace before continuing to mine.

AU-specific debugging angles

A few things we’ve seen in Australian Bitaxe setups that aren’t called out in the North American community material:

Brownouts and dirty power. The Aussie 230 V mains is generally clean, but 5 V USB PSUs don’t all handle voltage sags gracefully. Rural NSW, parts of Queensland, and inland Victoria have periodic mains dips during summer aircon load; cheap 5V/6A bricks sag badly during those. Symptom: intermittent hashrate error spikes correlated with afternoon high-consumption periods. Fix: Mean Well or the genuine Bitaxe-spec PSU (we stock both).

Summer thermals. Stock Bitaxe cooling assumes ~22°C ambient. In a Perth garage in February at 38°C, add 15°C to every temperature on the dashboard. Plan for it. Either move the miner to an air-conditioned space or put an extra fan on the case.

NBN stratum disconnects. Some ISPs (we’ve seen this mostly on HFC plans) drop TCP connections idle for 30-60 seconds. AxeOS stratum connections that go quiet during low-difficulty periods sometimes time out. Fix: ensure your AxeOS is v2.7+ (has the pool-failover logic) and configure a TCP keepalive via the router if possible.

Power board strips. Using a switched power strip rated for 10 A total feeding four Bitaxes plus a heater plus a kettle can brown out the strip’s voltage. Each Bitaxe is tiny, but compound loads on a marginal circuit cause weird hashrate drops. Dedicated circuit, or at minimum dedicated power strip with no high-current loads shared.

TL;DR

1. Hashrate error 0-3% is normal. It’s not rejected shares.
2. VR temperature 65-80°C is normal. It’s hotter than ASIC by design.
3. Measured vs expected hashrate within 5% is normal. The gap is error + latency.
4. Stale shares scale with geographic distance. Pick an Aussie-hosted pool to minimise them.
5. Solo mining not finding a block is the default state. It’s a lottery.
6. Worry when: error > 5%, ASIC > 75°C, rejected > 1%, voltage < 4.90 V.
7. Read the VR temperature, not the ASIC temperature, for thermal anxiety.

Your Bitaxe’s dashboard is telling you a lot more about itself than about whether it’s broken. Most of the time, it’s fine.

---

This piece is written against AxeOS v2.7+ as it appears on stock Bitaxe Ultra, Gamma, and NerdQaxe++ hardware in Australia. Other ESP-Miner firmware variants may expose slightly different metrics. Firmware tracker here.

Frequently Asked Questions

What is a normal hashrate error percentage on a Bitaxe? +

Anywhere from 0% to about 3% is normal for a stock Bitaxe. Above 5% sustained suggests an overclock that's pushed the ASIC past its stable frequency/voltage envelope, a marginal PSU, or a cooling problem. Hashrate error is not the same as rejected shares — it's an internal hardware metric, not a pool-level accounting.

Why is my expected hashrate different from my measured hashrate? +

Expected hashrate is calculated from your frequency and chip count. Measured hashrate is derived from the actual rate of valid nonces found. They diverge due to hashrate error (chips running slightly slow), dropped nonces (firmware couldn't keep up), or network latency affecting job distribution. A 2–5% gap is normal.

My Bitaxe is running at 75°C — should I worry? +

That reading is almost certainly the voltage regulator (VR) temperature, not the ASIC. BM1366/BM1368 ASICs run at 55–65°C in a well-cooled Bitaxe; the VR runs hotter by design. 75°C at the VR is within spec. Worry when you see 85°C+ at the VR, or any temperature above 75°C at the ASIC itself.

What's the difference between stale shares and rejected shares? +

Stale shares are valid shares submitted to the pool too late — the pool has already moved to a new block template. Rejected shares are invalid shares (wrong difficulty, duplicate, malformed). Stale happens from latency; rejected happens from firmware bugs or overclock instability. Both reduce your earnings, but the fixes are different.