HF - Tool to set voltages

[gateway]

Hey everyone we are able to release a tool that allows you to adjust your voltage settings for your Evo and Habanero boards.  

HF has provided us with a python 3 script that we are allowed to distribute.

Basically in a nutshell this is good to use ONLY if your trying to push your boards past 900Mhz because you will need to increase the voltage on the board in order to give the chip more power.

USE AT YOUR OWN RISK, please read the LICENSE FILE first before using this tool.

This only works with one miner plugged in at a time!

The hftool.py utility is used to query and manipulate hashfast module settings.

Requirements:
 Python 3.x
 pip for Python 3.x
 Pyusb

Installing pip for python 3 on most unix systems (command for ubuntu below)
 sudo apt-get install python3-pip

hftool requires pyusb. To install it:
 pip3 install --pre pyusb

Put these into a file /etc/udev/rules.d/01-hashfast.rules:

You will need root access to create this file and also when done its recommended you reboot in order for these rules to take effect.

Code:

ATTRS{idVendor}=="297c", ATTRS{idProduct}=="0001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev”, ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="297c", ATTRS{idProduct}=="8001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff6", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1"

RUNNING

Start the tool by with:

Code:

$ ./hftool.py -h

Read die frequencies and voltages:

Code:

$ ./hftool.py -r

Write die frequencies and settings:

Code:

$ ./hftool.py -w 0:VLT@FRQ,1:VLT@FRQ,2:VLT@FRQ,3:VLT@FRQ

example would be setting all dies to .930 volts at 875Mhz

Code:

$ ./hftool.py -w 0:930@875,1:930@875,2:930@875,3:930@875

You can grab it from Bitbucket Git depo here https://bitbucket.org/gateway69/hf-tool

AND no I dont work for HF, we pushed them to get a tool released so our customers of our Habanero boards could tweak and push their boards.

Order your Habanero from Batch 2 today for $850 here

[1714797703]

1714797703

[1714797703]

1714797703

[1714797703]

1714797703

[1714797703]

1714797703

[1714797703]

1714797703

[1714797703]

1714797703

[xjack]

Just wanted to throw this out.  There is no Python 3 package of pip for Ubuntu 12.04 LTS.  So I installed this way...

sudo apt-get install python3-setuptools
sudo easy_install3 pip

Got it installed but can't test it remotely since it crashes with two miners connected.  Will report back later.

edit: See post below.

[gateway]

Oh, yea I should mention only use this with one miner plugged in at a time

[xjack]

Any thoughts on this error?  I'm getting it on 12.04 LTS, and Debian 7.4 on the beaglebone black.  Stumped.

Code:

jack@jack-nT-A3000-series:~/hf-tool$ ./hftool.py -r
HFBulkDevice Found!
ConfigurationValue 1
        InterfaceNumber 0,0
                EndpointAddress 131
        InterfaceNumber 1,1
                EndpointAddress 129
                EndpointAddress 2

EndpointAddress for writing 2
EndpointAddress for reading 129

Generic exception handler: (<class 'AttributeError'>, 'list' object has no attribute 'copy', <traceback object at 0x15c6f80>)
Traceback (most recent call last):
  File "/home/jack/hf-tool/hf/load/routines/settings.py", line 50, in one_cycle
    self.transmitter.send([])
  File "/home/jack/hf-tool/hf/load/hf.py", line 83, in send
    mybyteslist = byteslist.copy()
AttributeError: 'list' object has no attribute 'copy'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./hftool.py", line 67, in <module>
    main(sys.argv[1:])
  File "./hftool.py", line 55, in main
    while setter.one_cycle():
  File "/home/jack/hf-tool/hf/load/routines/settings.py", line 129, in one_cycle
    self.end()
  File "/home/jack/hf-tool/hf/load/routines/base.py", line 304, in end
    self.transmitter.send(op_usb_shutdown.framebytes)
  File "/home/jack/hf-tool/hf/load/hf.py", line 83, in send
    mybyteslist = byteslist.copy()
AttributeError: 'list' object has no attribute 'copy'

[jimmychopps]

Getting the same error when I try to read current freq and voltages.

[gateway]

First of all our dev boxes are running ubuntu desktop 13.04 or .10 64 bit .. so if you have an image of that try that out.

secondly, their are a few things to check since this requires python 3 and the running python by default is usually 2.7 or something close not 3

Code:

netcom@chromy2:~/Documents/firmware/tools$ python --version
Python 2.7.5+

Code:

netcom@chromy2:~/Documents/firmware/tools$ python3 --version
Python 3.3.2+

so u need some flavor or python 3...

You could try running the command like so..

Code:

python3 hftool.py -r

Please make sure you also have pip3 and pyusb installed for python 3.

[xjack]

Got it working on 12.04 LTS...

Code:

sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev

Then install the python3 from source code:

wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz
tar xvf Python-3.4.0.tar.xz
cd Python-3.4.0
./configure
make
make test
sudo make install

sudo pip3.4 install --pre pyusb
(or sudo pip3.4 install pyusb I can't remember now)

python3.4 hftool.py -r

[gateway]

Got it working on 12.04 LTS...

Code:

sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev

Then install the python3 from source code:

wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz
tar xvf Python-3.4.0.tar.xz
cd Python-3.4.0
./configure
make
make test
sudo make install

sudo pip3.4 install --pre pyusb
(or sudo pip3.4 install pyusb I can't remember now)

python3.4 hftool.py -r

awesome good news.. prob should start a little faq for various linux versions..

btw not sure if you need these..

Code:

libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev

[xjack]

awesome good news.. prob should start a little faq for various linux versions..

btw not sure if you need these..

Code:

libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev

I blindly followed a guide from Stackoverflow.  

[gateway]

Just added a post about pushing your Habanero on our blog, this includes proper cooling and using this tool.

Post: https://peppermining.com/pushing-your-habanero

[xjack]

Still tweaking board #2

Board #1 has all dies at .975v/950MHz

Both boards hashing stable with .975/950MHz settings. (clocking at 925MHz)

Code:

 cgminer version 4.3.4 - Started: [2014-06-06 22:50:16]
----------------------------------------------------------------------------------------------------
 (5s):1.136T (1m):1.290T (5m):1.371T (15m):1.396T (avg):1.404Th/s
 A:14260992  R:44032  HW:3972  WU:19617.1/m | ST: 176  SS: 0  NB: 75  LW: 14958907  GF: 0  RF: 0
 Connected to xxxxxxxx 1.02K with stratum as user xxxxx
 Block: c0e29fcd...  Diff:11.8G  Started: [11:05:05]  Best share: 18.4M
----------------------------------------------------------------------------------------------------
 [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: HFB Dabs    : 925MHz  99C 100% 0.90V  | 722.1G / 700.6Gh/s WU: 9787.2/m A:7135104 R:28160 HW:2104
 1: HFB Chip    : 925MHz 101C 100% 0.90V  | 569.0G / 703.6Gh/s WU: 9829.9/m A:7125888 R:15872 HW:1868
----------------------------------------------------------------------------------------------------
 [2014-06-07 11:05:15] Accepted 0acf8627 Diff 6.06K/1024 HFB 0 pool 0
 [2014-06-07 11:05:15] Accepted 01a3e358 Diff 40K/1024 HFB 0 pool 0
 [2014-06-07 11:05:18] Accepted 16f68815 Diff 2.85K/1024 HFB 0 pool 0
 [2014-06-07 11:05:18] Accepted 28e32c95 Diff 410K/1024 HFB 1 pool 0
 [2014-06-07 11:05:32] Accepted 20eb99a9 Diff 1.99K/1024 HFB 1 pool 0
 [2014-06-07 11:05:34] Accepted 297d0612 Diff 1.58K/1024 HFB 0 pool 0

Just awesome - thanks Peppermining!

YMMV.

[xjack]

Good guide for getting your Habanero "close" to target speeds.

Frequency	Hashrate	Voltage Setpoint	Board Power (W[DC])	Efficiency (J/GH)
925	704	0.97	783.0	1.11
900	685	0.95	727.9	1.06
875	666	0.935	682.5	1.02
850	647	0.92	636.0	0.98
825	628	0.91	598.4	0.95
800	609	0.89	559.1	0.92
775	589	0.88	528.8	0.90
750	570	0.87	498.7	0.87

Test notes
-Single board prototype tested, not a production unit
-Power measurements are DC at the board input
-Coarse-grained voltage optimization was used, no attempt to individually optimize each die was made

For the picture of the board with the heatsink, I can't provide that yet. Next week.

[JakeTri]

Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.

The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.

Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.

Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:

Code:

cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970:970:970:980"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970"

Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb

Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.

[gateway]

Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.

The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.

Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.

Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:

Code:

cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970:970:970:980"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970"

Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb

Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.

Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.

Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?

[JakeTri]

Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.

The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.

Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.

Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:

Code:

cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970:970:970:980"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970"

Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb

Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.

Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.

Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?

So far I used the Pepper Mining App to check if voltage was same with hashfast python tool and with the updated cgminer.

I can measure the voltage with a multimeter if you give me hints about good test points on the board for each die voltage.

[gateway]

Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.

The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.

Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.

Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:

Code:

cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970:970:970:980"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970"

Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb

Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.

Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.

Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?

So far I used the Pepper Mining App to check if voltage was same with hashfast python tool and with the updated cgminer.

I can measure the voltage with a multimeter if you give me hints about good test points on the board for each die voltage.

Where the chip is, on the edge of the board are a few test areas one for each die.. I forget the names off the top of my head.

btw you should push this change to con to see if he accepts it..

cheers!

[JakeTri]

Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool.

The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments.

Original syntax was "name:clock".
Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax.

Here are some exmaples of cgminer command line assuming board name "hab1":
- select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV:

Code:

cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970:970:970:980"

- select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock):

Code:

cgminer --hfa-options "hab1:950:970"

Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cb

Look like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv).
It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event.

Very nice ill test it out, we wernt 100% sure this could be done with the current firmware.

Have you tested the points on the board to see if your getting that voltage out of them with a multimeter?

So far I used the Pepper Mining App to check if voltage was same with hashfast python tool and with the updated cgminer.

I can measure the voltage with a multimeter if you give me hints about good test points on the board for each die voltage.

Where the chip is, on the edge of the board are a few test areas one for each die.. I forget the names off the top of my head.

btw you should push this change to con to see if he accepts it..

cheers!

I'll check for the test points tonight when I get back home and let you know the measurements results.

I plan to push the change to con but I was thinking to clean it up a little before pushing it upstream. As it is right now it will brake any Sierra or any other Hashfast device with more than 4 dies ... 
Not that I'm thinking of it ... the easiest fix would be to enable this code only when device have 4 dies I'll fix that and push it to con today.

[gateway]

I'll check for the test points tonight when I get back home and let you know the measurements results.

I plan to push the change to con but I was thinking to clean it up a little before pushing it upstream. As it is right now it will brake any Sierra or any other Hashfast device with more than 4 dies ... 
Not that I'm thinking of it ... the easiest fix would be to enable this code only when device have 4 dies I'll fix that and push it to con today.

True.. hmm you mean chained boards right?

Also note that some dies fail, crack or what ever so we use the hf tool to disable a die because w/o doing this you cant mine and it spits our crazy errors.

So a die#:0 is set to turn it off, this allows the board to continue hashing with 3 dies for example.

Also prob should put some sort of limiting factor so someone doesn't put in a huge number, which im not sure what would happen but prob a few checks an balances.. or a --i-agree-to-use-this-expirmental-feature option

[MrTeal]

I'd be careful about using this method. What you're basically doing is overwriting the default voltage stored on the flash of the device and then resetting it.

If you want to use it, we would suggest running it in the same way that you would use the python script; run it once to set the voltages, but don't run it as a normal part of your cgminer command line. I haven't tested it, but it should work great as a one-time setup you call when you want to tweak something, but don't call otherwise.

[gateway]

I'd be careful about using this method. What you're basically doing is overwriting the default voltage stored on the flash of the device and then resetting it.

If you want to use it, we would suggest running it in the same way that you would use the python script; run it once to set the voltages, but don't run it as a normal part of your cgminer command line. I haven't tested it, but it should work great as a one-time setup you call when you want to tweak something, but don't call otherwise.

True..