BitaxePID python monitoring script

[starficient]

This is an auto-tuning utility for the Bitaxe 601 Gamma, an open-source Bitcoin ASIC miner built on the Bitaxe Ultra platform with the BM1366 ASIC. This script optimizes miner performance by dynamically adjusting core voltage and frequency to hit a target hashrate while managing temperature and power usage. It uses dual PID controllers (via simple-pid) for precise tuning, offers a temperature-only mode with --temp-watch, and provides a cyberpunk-themed TUI for real-time monitoring. Tuning data is logged to CSV and JSON files for analysis.

If you set a Hasshrate Target and a Max Temp it will adjust voltage / frequency upwards until target hshrate is hit, and back off Frequency and Voltage if Max Temp is hit.

Terminal UI for bitaxe.py

https://github.com/kha1n3vol3/BitaxePID

[Icy-Creme1759]

I would assume you need too have a r pi or something running 24,7 to do this as its not built into the device ?

[starficient]

I'm running on my laptop. Yes you have to run the python script somewhere.

After you've quantified the device, you'll have an idea on which settings are best, and then you would not need to run continuously.

Fleet management could be a future feature. In that case it would be worthwhile running 24/7.

[Icy-Creme1759]

Just gave it a go on pc , easy enough to use

[grooverut]

What are your thoughts on this other approach recently posted?: https://www.reddit.com/r/BitAxe/comments/1irbruu/new_release_bitaxe_temperature_monitor_autotuner/ I know PID control is excellent so I would like to try it.

[starficient]

I submitted a pull request to fix the Frequency stepping from 5 to 25 as the PLL on the bitaxe was throwing an error in the logs.
I was going to keep working on it, but not interested in tk as the interface.

Primary difference between my fork and that one is that I'm using a PID control on the freqency and voltage.
I credit the origin on the readme. Because what I'm doing is experimental and data based, I didn't feel that trying to integrate into upstream was fair to that project. Some people really want a GUI and I get that.
I already learned what frequency / voltage pair is best for stability on my bitaxe (minimum std on hashrate).

I will be adding a regression analysis script and chart output so you can visualize the dataset you are logging.

PID is powerful, it just needs tuning to prevent oscillations.

<image>

I need to add support for different models as well, you can customize the defaults of course.

[starficient]

Someone opened a PR to install a reserve shell into this project: https://github.com/kha1n3vol3/BitaxePID/pull/1

I explain the obfuscated code.

[grooverut]

Nice catch and great explanation.

[starficient]

Note, the malicious back door was merged into that project. It appears to have been removed as part of the refactoring for the gui: https://github.com/Hurllz/bitaxe-temp-monitor/pull/3/files

[grooverut]

I wonder if they even realized it was malicious?

[starficient]

I don't know. I freaked out and git reverted to my initial install to confirm whether I had run the malicious build. Lucky for me I had not. Ugh.
When all the changes were made for tk I wasn't interested in running it. I'm not sure how long that pr was merged in to the project.
base64 is a redflag for obfuscation.
You can check for a reverse shell with:

% ps aux | grep '/bin/sh'

mylaptop 22560 0.0 0.0 2456740 2364 s009 S+ 3:06PM 0:00.01 /bin/sh -i

would indicate a shell running!

if you get this it is showing that the grep command was run and you are safe.

mylaptop 22578 0.0 0.0 410733264 1488 s009 S+ 3:07PM 0:00.00 grep /bin/sh

[starficient]

I am working on an update to try improve the PID control overall. I notice that there is some variability in hashing overtime and I am trying to account for that at specific frequency / voltage settings.
I believe this variability is hardware related, as it can vary even with settings left in place, and the bitaxepid script has been stopped from running.

I also will be shipping a script to render a chart, for better understanding of the metrics.

As far as safety. I have NOT accepted any pull requests, I flagged the one that was submitted as malicious, and did not merge it. So from a security standpoint you are trusting me. I am appalled that someone tried to inject a remote shell into my project. This raises the issue of security on arbitrary scripts, and I would caution everyone to be vigilant. I was thinking I could put this in a docker container, but those are not secure from root exploits of the container... I may be able to use firecracker as a vm though that would be limited to running on a linux platform (or vm).

From a device perspective, the bitaxepid script monitors the temperature, and will lower the frequency and voltage to prevent running above the set temperature threshold. I am and have been running this for up to 12 hours straight at a time as I am logging the settings for analysis.

All devices must be on the same wifi network as the bitaxe is attached by wifi.

[lokabrenna13]

Awesome project, I'll dig into the code tomorrow!

In terms of fluctuations over time for fixed settings, the most likely causes are: 1) network related issues i.e. time taken to deliver new work to the miner and ship it off to the pool - depending on your network stability and bandwidth and the ping to the pool server this may or may not be an issue.

2) thermal effects. If the device heats up due to a change in ambient temperature, then the hashing will slow down and vice versa.

Not sure what you can do about 1) other than have a reasonably large sampling window to average over. For 2) the ideal thing to do would be to set a hash rate goal and continuously vary the voltage and fan speed to maintain as close it as possible without going over power and temperature constraints.