Skip to content

Add BM1368/BM1370 predictive efficiency telemetry and autonomous tuning#1704

Closed
0xjc65eth wants to merge 9 commits into
bitaxeorg:masterfrom
0xjc65eth:cypher-gamma-max-pr
Closed

Add BM1368/BM1370 predictive efficiency telemetry and autonomous tuning#1704
0xjc65eth wants to merge 9 commits into
bitaxeorg:masterfrom
0xjc65eth:cypher-gamma-max-pr

Conversation

@0xjc65eth

Copy link
Copy Markdown

Summary

This PR proposes a BM1368/BM1370-focused predictive efficiency layer for ESP-Miner/AxeOS.

It adds:

  • Passive predictive-efficiency telemetry exposed under /api/system/info as predictiveEfficiency.
  • BM1368 and BM1370 profile detection for Supra, SupraHex, Gamma, GammaDuo, and GammaTurbo-style devices.
  • Composite efficiency scoring based on hash-per-watt, accepted share ratio, thermal margin, expected hashrate ratio, ASIC error pressure, and pool latency pressure.
  • A conservative autonomous frequency autotune loop behind the predictiveAutotune NVS/API setting.
  • A standalone optional Ollama companion tool that runs outside the ESP32 and can observe AxeOS telemetry, keep local memory, perform research, and suggest/apply settings through the existing AxeOS API.

Important boundary

This PR does not attempt to predict winning Bitcoin nonces and does not claim to break or shortcut SHA-256 proof-of-work.

The intent is operational optimization only: better visibility into miner efficiency, safer frequency exploration, thermal rollback behavior, and external tooling for supervised experimentation.

Firmware behavior

The firmware-side autotune is intentionally narrow:

  • It only acts on supported BM1368/BM1370 ASIC profiles.
  • It only changes ASIC frequency.
  • It uses small 25 MHz exploration steps.
  • It includes warmup, monitor, trial, rollback, and throttle states.
  • It rolls back when score drops, ASIC errors rise, rejected shares rise, or thermal margin is exhausted.
  • It does not change voltage, pool settings, fan behavior, or job scheduling.

API additions

/api/system/info now includes a predictiveEfficiency object with fields such as:

  • enabled
  • autotuneEnabled
  • bm1368Profile
  • bm1370Profile
  • profileName
  • score
  • hashPerWatt
  • usefulShareRatio
  • thermalMarginC
  • hashrateRatio
  • errorPenalty
  • latencyPenalty
  • recommendedAction
  • agentState
  • agentReason
  • tunedFrequency
  • bestFrequency
  • trialFrequency
  • baselineScore
  • lastTuneMs

External companion tool

The Ollama research companion is deliberately external to the ESP32. It is intended for advanced users and supervised test setups. It uses the existing AxeOS API rather than embedding internet access or LLM behavior into the firmware runtime.

Review notes

I expect the telemetry portion to be the safest and most generally useful part of this PR. If maintainers prefer, this can be split into smaller PRs:

  1. Passive predictive-efficiency telemetry only.
  2. BM1368/BM1370 conservative frequency autotune.
  3. External Ollama research companion documentation/tooling.

Testing performed

  • Python syntax validation for the external companion script.
  • CLI help validation for the external companion script.
  • git diff --check clean.

Hardware validation on additional BM1368/BM1370 units would be valuable before enabling any autotune behavior by default in an upstream release.

@0xjc65eth

Copy link
Copy Markdown
Author

Thanks for taking a look.

This PR is intentionally broad because it shows the full Cypher Gamma Max experiment, but I’m happy to split it into smaller reviewable pieces if that fits the ESP-Miner process better.

Suggested split:

  1. Passive BM1368/BM1370 predictiveEfficiency telemetry only
  2. Conservative frequency-only predictiveAutotune
  3. External Ollama companion tool/docs

The telemetry layer is probably the safest first piece: it only exposes efficiency/stability signals through /api/system/info and does not change mining behavior.

Also to clarify: this does not attempt to predict winning Bitcoin nonces or bypass SHA-256 proof-of-work. The goal is operational optimization only.

I can rebase/update the branch with master if maintainers want that before review.

@0xjc65eth

Copy link
Copy Markdown
Author

Closing this for now to reduce maintainer review load, per feedback from @mutatrum. I am keeping #1705 open as the single focused PR because it is small, UI-only, and already has an ack. Happy to revisit this later only if maintainers ask for it. Thanks for the feedback and for maintaining the project.

@0xjc65eth 0xjc65eth closed this May 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant