// blog · · by Nathan Baldwin
// Three charts every Bitaxe owner should pull from their Baller CSV logs: efficiency over time, hashrate stability, and temperature drift over a week.
Bitaxe Baller writes one CSV per miner, one row per minute. Most people open it once, see the wall of timestamps, and close it. That file is the only honest record of how your rig actually behaved last week, and three charts pulled out of it will catch problems a live dashboard never will.
The CSVs live in ~/Library/Application Support/Bitaxe Baller/logs/ on Mac and %APPDATA%\Bitaxe Baller\logs\ on Windows. One file per device, named by the miner’s MAC address. Each row is roughly a minute apart and carries the columns you need: timestamp, hashrate_gh, expected_hashrate_gh, power_w, asic_temp_c, vr_temp_c, voltage_mv, frequency_mhz, fan_rpm, accepted_shares, hw_errors. Drop the file into Excel, run Text to Columns if your locale needs it, and you have a week of ground truth in front of you.
The number that decides whether a Bitaxe is worth running is joules per terahash. Hashrate is the brag number. Efficiency is the rent number.
Add a column for J/TH = power_w / (hashrate_gh / 1000). In Excel that is:
=D2/(E2/1000)
where D is power and E is hashrate. Drag it down the column, then make a line chart with timestamp on the x-axis and J/TH on the y-axis.
A well-tuned Gamma running at default 485 MHz and 1150 mV sits between 18 and 19 J/TH almost flat. If the chart drifts upward across a week and crosses 22 J/TH, something has changed. Usually it is VR temp pulling enough current to lose efficiency under thermal stress, sometimes a slow firmware regression after an update, occasionally a dirty fan. The chart tells you something is wrong before the dashboard’s instantaneous reading does, because a 30-second sample lies. A weekly trendline does not.
Instantaneous hashrate jumps around. What matters is whether it jumps around a known mean or wanders off it. The cheap way to see that in Excel is rolling standard deviation.
Pick a 60-sample window (roughly one hour). In a new column starting at row 61:
=STDEV.P(E2:E61)
Drag it to the bottom. Plot that column as a line and you have an hour-by-hour readout of how much your hashrate is bouncing around its average.
A healthy Gamma’s rolling stddev sits under 50 GH/s on a 1.2 TH/s average. Once you see consistent spikes above 150 GH/s, your miner is fighting something: stratum reconnect churn from a flaky pool, thermal throttling that drops you to a lower frequency for short windows, or a power supply that sags under load. The chart turns three different problems into one shape on a graph. From there you go look at temp and shares around the timestamp to figure out which one.
This chart also catches the silent failure case where a miner is technically “up” but submitting almost no shares. The mean hashrate looks fine. The stddev is zero because the device is stuck. That is the line you want: flat at the wrong value.
Two lines on one chart: asic_temp_c and vr_temp_c, both against timestamp. Use a secondary axis if the ranges are far apart, but they usually aren’t.
What you are looking for is the gap. On a Gamma under sustained load, ASIC temp usually settles 8 to 12°C below VR temp. The VR climbs faster, peaks higher, and is the part that will fail first. If the gap closes, the airflow over the chip is fine but the regulator is starving for it. If ASIC catches and passes VR temp, your fan curve is biased the wrong way and the chip is cooking while the regulator sits cool.
The second thing this chart shows is the room-temp delta across the day. A miner in a closet runs 6 to 8°C hotter at 4 p.m. than at 4 a.m. If your delta is over 15°C, you have an airflow problem and the rig is buying its hashrate at peak hours by burning extra wattage. That is the same J/TH problem from Chart 1, just viewed from a different angle.
The reason these three charts matter together is that one bad week shows up in all three at once: efficiency drifts up, stddev gets noisy, temps widen. One bad sensor shows up in only one. That lets you separate “the miner is unhealthy” from “Excel is reading a bad column.”
Save the workbook with the formulas and chart styles already wired up. Each week, drop in the fresh CSV by replacing the data range and hitting refresh. The whole review takes five minutes once the template exists. Compare against last week’s screenshots. If anything jumps, drill into the timestamps and look at fan RPM, voltage, and shares around the spike. Most problems narrate themselves once you have the right plot in front of you.
Two actions after reading this. First, build the template once: pull last week’s CSV, wire up the three charts, save the workbook somewhere you’ll find it. Second, put a recurring 5-minute block on Sunday morning to refresh it. The miners are running 24/7 either way. A weekly review is the difference between catching a fan failure on day three and finding it on day fourteen.
Try it yourself: Bitaxe Baller is a free desktop app for Mac and Windows that surfaces these recommendations automatically across your fleet — live monitoring, tuning suggestions, pool config, all in a native window. Open source on GitHub.