These field notes are organized around the order in which a miner operator should make decisions: understand the firmware layer, verify the equipment, measure the baseline, and only then compare a new profile with real operating data. The goal is a reusable reference, not a download directory or a promise of returns.
Rubric 01 — Firmware & Compatibility
Read Firmware & Compatibility when your question is about what ASIC firmware controls, how stock and alternative firmware differ, which hardware details matter, or how to keep a rollback path. It combines the practical material that would otherwise be scattered across separate “basics” and “safety” pages.
The section explains why a model name alone is not enough. Control-board revision, installation method, cooling and power conditions can change what is appropriate. It also provides a compact checklist for documenting the current state before a firmware change.
Rubric 02 — Profitability & Power
Read Autotuning & Power when you are ready to work with numbers. It covers wall-power measurement, accepted rather than advertised hashrate, hardware errors, rejected shares, uptime, fees and a simple daily electricity-cost equation. The page includes a table you can copy into an operating log.
Use it to compare profiles, not to forecast guaranteed income. Market price, network difficulty, pool economics, electricity, cooling and machine condition can change after any calculation.
How to use the notes
- Start with identification and compatibility.
- Save the known-good state.
- Measure the current operating baseline.
- Change one variable or profile at a time.
- Review the result after the machine has had time to show errors and temperature behavior.
What is deliberately not here
There is no vendor endorsement, investment recommendation, guaranteed ROI claim or universal “best” setting. Current firmware files, exact fees and supported models should be checked against the applicable vendor documentation at the moment of installation.
Decision path for a new operator
If you are new to ASIC firmware, do not start by searching for the highest advertised hashrate. Start by identifying the machine and writing down what it does today. The first useful result is a baseline you can reproduce. Once that baseline is known, ask whether a profile changes output, power, heat, errors or uptime in a direction that matters.
Separate reversible decisions from irreversible ones. A profile change with a saved configuration is easier to reverse than a physical power modification, but software changes are not risk-free. Bound the test, observe it and stop when a limit is reached.
Decision path for a farm
Group devices by model, board revision, cooling and power arrangement rather than assuming the same file belongs everywhere. Define acceptance criteria before rollout: temperature range, maximum error rate, maximum wall draw, minimum accepted hashrate and rollback trigger. Keep individual device rows; averages can hide one unstable machine.
How to use a field note
Copy the measures from the Profitability rubric into a log. Use one row per device and the same units before and after. Add notes for temperature, restarts, pool changes and maintenance. The result is a dated operating observation, not a permanent forecast.
Pause when the answer is uncertain
Pause when the control-board revision is unknown, recovery access is missing, power is unstable, cooling is inadequate or the measured result cannot be reproduced. A careful pause is better evidence than a rushed rollout.
Build a repeatable baseline
A useful baseline is more than a single hashrate number. Let the miner run long enough to pass the normal warm-up period, then capture a representative window. Note the accepted hashrate reported by the pool, the local dashboard hashrate, wall power, temperature, hardware errors and uptime. If the readings disagree, keep both values and investigate the reason instead of choosing the more flattering number.
Use consistent units and timestamps. Watts measured at the wall include the power supply and may differ from a firmware estimate. Pool hashrate is affected by share luck and the length of the observation window. A longer window usually gives a more useful comparison, especially when the expected difference between two profiles is small.
Write a test brief
Before changing a miner, write a short test brief: objective, device, current state, proposed change, duration, measurements, limits and rollback action. This prevents a common failure mode in which an operator changes several settings, sees a different dashboard value and cannot explain what caused it. The brief also makes the work easier to review later or repeat on another device.
Keep a separate note for observations and conclusions. “The temperature rose by six degrees” is an observation. “The profile is unsafe” is a conclusion that needs context such as ambient temperature, cooling capacity and the limit you selected. This separation makes field notes more precise and less likely to turn into universal advice.
Questions to ask before rollout
Ask whether the target devices really share the same model, control board, power supply and cooling environment. Ask whether remote recovery is available and whether the hosting provider allows the change. Ask what happens if the device does not return after reboot. Ask who will monitor the first hours and who can physically intervene. These questions often matter more than the profile name.
What a good guide should leave behind
At the end of a test, leave behind the configuration, measurements, decision and next action. If the result is positive, state the conditions under which it was positive. If the result is negative, record why it was rejected. A rejected profile is useful operational knowledge when the reason is clear, while an unexplained rejection cannot guide the next experiment.
Make the result transferable
A field note becomes more valuable when another operator can understand and repeat it. Include the exact starting state, the reason for the change, the observation window and the limits used to judge the result. Mention what was not measured. This makes the guide useful without pretending that one device or one season represents every mining environment.