[ANN] Bi•Fury | 5 GH/s USB Miner [IN STOCK!] {SALE !}

[rallasnackbar]

Still no overclocking guide?

[ManeBjorn]

I overclocked by changing the oscillator bits. 
Over clock a bit at a time.  Run for at least 1/2 hr after each OC unless there are tons of errors which means back down.
Once you have a good setting you are all set.
5.8 gh/s seems to be the sweet spot for me.
Make sure your Hub can supply enough power as well or you will just increase errors.

Still no overclocking guide?

[alexandre_ganso]

I still have issues with these and the Raspberry PI.

They are detected, and they mine for a while, on the 7-port d-link usb 2.0 powered hub. Then some of them die. (go ZOMBIE on cgminer) and disappear from lsusb.

Is this a power issue? They work fine on an anker usb 3.0 hub connected to my macbook pro.

I Had two bi*fury connected to the pi, working for some 20 minutes fine... then I connected a third. This happened:

Code:

 Block: 1d1d8f98...  Diff:5.01G  Started: [20:07:33]  Best share: 8.66K
--------------------------------------------------------------------------------------------------
 [U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: AMU 0:                         | 335.3M/333.1Mh/s | A:  87 R: 0 HW:0 WU:  4.7/m
 1: BXF 0:  55.3C                  | ZOMBIE/4.910Gh/s | A:1538 R:13 HW:0 WU: 68.6/m
 2: BXF 1:  49.0C                  | ZOMBIE/4.648Gh/s | A:1363 R:14 HW:0 WU: 64.9/m
 3: BXF 2:  62.4C                  | ZOMBIE/3.760Gh/s | A:  49 R: 0 HW:0 WU: 53.7/m
--------------------------------------------------------------------------------------------------
 [2014-03-31 20:07:34] Pool 0 stale share detected, submitting as user requested
 [2014-03-31 20:07:35] Rejected 10587b38 Diff 16/7 BXF 0  (Stale share)
 [2014-03-31 20:07:46] Accepted 020eb0fa Diff 124/7 AMU 0
 [2014-03-31 20:07:47] Accepted 0730ef18 Diff 36/7 BXF 2
 [2014-03-31 20:07:52] Accepted 247c2363 Diff 7/7 BXF 2
 [2014-03-31 20:08:34] BXF 1: No valid hashes for over 1 minute, attempting to reset
 [2014-03-31 20:08:35] BXF 1 BXFRead usb read err:(-4) LIBUSB_ERROR_NO_DEVICE
 [2014-03-31 20:08:35] BXF 0 BXFWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2014-03-31 20:08:35] BXF 2 BXFWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2014-03-31 20:08:35] BXF 0 BXFRead usb read err:(-4) LIBUSB_ERROR_NO_DEVICE
 [2014-03-31 20:08:35] BXF 2 BXFRead usb read err:(-4) LIBUSB_ERROR_NO_DEVICE
 [2014-03-31 20:08:35] BXF 1 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
 [2014-03-31 20:08:36] BXF 1 failure, disabling!
 [2014-03-31 20:08:40] BXF 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
 [2014-03-31 20:08:40] BXF 0: Error -5 sending BXFWork sent 163 of 163
 [2014-03-31 20:08:40] BXF 0: No valid hashes for over 1 minute, attempting to reset
 [2014-03-31 20:08:40] BXF 0 failure, disabling!
 [2014-03-31 20:08:43] BXF 2 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND
 [2014-03-31 20:08:43] BXF 2: Error -5 sending BXFWork sent 161 of 161
 [2014-03-31 20:08:43] BXF 2 failure, disabling!

[chek2fire]

What version of cgminer did you use? Because in my case and with bifury the most stable version for that is cgminer 4.0.0

[FalconFly]

I still have issues with these and the Raspberry PI.

They are detected, and they mine for a while, on the 7-port d-link usb 2.0 powered hub. Then some of them die. (go ZOMBIE on cgminer) and disappear from lsusb.

Is this a power issue? They work fine on an anker usb 3.0 hub connected to my macbook pro.

I Had two bi*fury connected to the pi, working for some 20 minutes fine... then I connected a third. This happened:

I've seen similar behaviour on my setup (powered USB hub connected to a Notebook) and not limited to the BiFury device (happened with my BlueFury v2 's as well).
IMHO it appears to be some form of small power surge on the hub when inserting an USB miner to a setup of other already running USB miners. Enough to interrupt the normal mining process and send one or more devices into some form of confused AWOL.

Solutions I found :
- remove the failed (Zombie) miner and re-insert slowly (some USB devices seem to prefer to be inserted rather slow in order to register)
- if that doesn't work (inserting any USB miner causes other running ones to fail), seek another distribution across the USB hub if feasible, sometimes this helps
- if all else fails - with all USB miners installed - unpower the entire hub and turn it back on... normally that gets all USB devices to register normally and start working again

PS.
All that happened to me despite the hub's power supply delivering more than sufficient energy; however despite the quantity of electrical power being sufficient, I sure don't know about the quality of the power supplied to the hub. Therefor I'd suspect the power supplies for many hubs may not be top notch in terms of voltage/ampere stability under conditions of sudden load changes.

[rallasnackbar]

I still have issues with these and the Raspberry PI.

They are detected, and they mine for a while, on the 7-port d-link usb 2.0 powered hub. Then some of them die. (go ZOMBIE on cgminer) and disappear from lsusb.

Is this a power issue? They work fine on an anker usb 3.0 hub connected to my macbook pro.

I Had two bi*fury connected to the pi, working for some 20 minutes fine... then I connected a third. This happened:

I've seen similar behaviour on my setup (powered USB hub connected to a Notebook) and not limited to the BiFury device (happened with my BlueFury v2 's as well).
IMHO it appears to be some form of small power surge on the hub when inserting an USB miner to a setup of other already running USB miners. Enough to interrupt the normal mining process and send one or more devices into some form of confused AWOL.

Solutions I found :
- remove the failed (Zombie) miner and re-insert slowly (some USB devices seem to prefer to be inserted rather slow in order to register)
- if that doesn't work (inserting any USB miner causes other running ones to fail), seek another distribution across the USB hub if feasible, sometimes this helps
- if all else fails - with all USB miners installed - unpower the entire hub and turn it back on... normally that gets all USB devices to register normally and start working again

PS.
All that happened to me despite the hub's power supply delivering more than sufficient energy; however despite the quantity of electrical power being sufficient, I sure don't know about the quality of the power supplied to the hub. Therefor I'd suspect the power supplies for many hubs may not be top notch in terms of voltage/ampere stability under conditions of sudden load changes.

Happens for me too, but mine dosnt go zombie. The HW errors just keeps going up, from 1% to 100% and then it stops hashing with it.


I just restart the raspberry after that, and it runs fine again for a couple of days.

BTW. i use bfgminer instead of cgminer, but it seems to be the same problem.

[tadzio]

I still have issues with these and the Raspberry PI.

They are detected, and they mine for a while, on the 7-port d-link usb 2.0 powered hub. Then some of them die. (go ZOMBIE on cgminer) and disappear from lsusb.

Is this a power issue? They work fine on an anker usb 3.0 hub connected to my macbook pro.

I Had two bi*fury connected to the pi, working for some 20 minutes fine... then I connected a third. This happened:

I've seen similar behaviour on my setup (powered USB hub connected to a Notebook) and not limited to the BiFury device (happened with my BlueFury v2 's as well).
IMHO it appears to be some form of small power surge on the hub when inserting an USB miner to a setup of other already running USB miners. Enough to interrupt the normal mining process and send one or more devices into some form of confused AWOL.

Solutions I found :
- remove the failed (Zombie) miner and re-insert slowly (some USB devices seem to prefer to be inserted rather slow in order to register)
- if that doesn't work (inserting any USB miner causes other running ones to fail), seek another distribution across the USB hub if feasible, sometimes this helps
- if all else fails - with all USB miners installed - unpower the entire hub and turn it back on... normally that gets all USB devices to register normally and start working again

PS.
All that happened to me despite the hub's power supply delivering more than sufficient energy; however despite the quantity of electrical power being sufficient, I sure don't know about the quality of the power supplied to the hub. Therefor I'd suspect the power supplies for many hubs may not be top notch in terms of voltage/ampere stability under conditions of sudden load changes.

Happens for me too, but mine dosnt go zombie. The HW errors just keeps going up, from 1% to 100% and then it stops hashing with it.


I just restart the raspberry after that, and it runs fine again for a couple of days.

BTW. i use bfgminer instead of cgminer, but it seems to be the same problem.

I have similar behavior with my devices on the HUB. Problem is that I do not have access to the device for a couple of days - just remote connection...
Is there any way to re-enable devices without unplugging them from the HUB? I was trying restart the system (WIN7). Also uninstalling devices ...
In device manager I get: This device cannot start. (Code 10)

[-ck]

I just posted a new version of cgminer, 4.3.3, which has a fix for a huge memory leak which has always been there with the driver for this particular hardware. All users mining with this hardware on cgminer are urged to upgrade.

[dogie]

Dogie's comprehensive setup guide is now up!

[Luke-Jr]

Anyone know why these might "reset" randomly while inactive (ie, clock 0 0)?
I'm messing around and trying to use it as a dumb temperature sensor at the moment, and noticed it starts to get hot and sending invalid submits... :/
Re-sending clock 0 0 fixes it again, until the next random occurrence.

Temperatures I've seen this happen at (seems to be unrelated): 39.3, 37.2, 34.6, 33.9, 33.1, 32.9, 32.8
For reference, my ambient temperature is 26.1, so it's never cooling down completely.

[doktorwhy]

POWER TO THE USB HUB (noob hobby style)
 
 I had problems with this type of adapter in that it burnt out killing the usb hub (nasty smell) or it could
 not supply the power needed for more than 2 red 5gh red bifurys on a 10 port usb hub.

  http://i57.tinypic.com/308jn02.jpg

 So more power was needed and this is my solution to the problem.
 After reading many blogs and watching youtube posts which were all helpful i did this.
 Thanks to all.

 I got a 680w pc power unit to MOD.

 http://i62.tinypic.com/2rr9pxy.jpg
 
 I then soldered the green wire to one of the black wires this switches it on.
 Secondly very important is to solder a 12v - 10w - 22ohm coil resister to a yellow 12v and black N wire.
 It thinks its running a motherboard or it will make a high pitch whine and dies.
 This leaves a bunch of black Neutral, red 5v yellow, 12v & orange 3.5v wires free.
 Cap off any redudant wires i.e purple & gray

 (Dont forget to insulate all bare wires)

 https://i.imgur.com/QKAN3Ep.jpg

 Then i striped the ends of the individal wires and soldered the wires to make single ends
 and fitted them into a large terminal block I had hot glued to the side of the power pack.
 Black Neutral, red 5v, yellow 12v & orange 3.5v and a spare N bridged from the main N
 terminal to an end terminal just in case its needed for the 3.5v.

 https://i.imgur.com/wC9Kpaj.jpg

 https://i.imgur.com/fA6j5kU.jpg

 Then i Bridged terminal 3 blocks 12v yellow, 5v red, black Nutral and fixed them to a board to
 give more power outputs so i can add more usb hubs when needed

 https://i.imgur.com/SRxyTxE.jpg

 The next thing i did was bridge the fuse on a 4 port 5v powered usb hub at the moment
 has its own power adapter  but will be powered from the terminal.

 https://i.imgur.com/2DIHLQO.jpg

 Blue 10 port usb hub. this hub is the one to chose for the job.

 Needing to get a good flow of power to the bifurys was next.
 I directly soldered onto the power points on the blue 10 port hub and bridged the 5v points to each
 port & bridged the trip fuse.

 https://i.imgur.com/I8qpxcu.jpg

 https://i.imgur.com/jMihKOQ.jpg

 I am running minepeon on a raspberry pi so i also added heat sink to the cpu by sawing an old
 pc heat sink to the right size and fixing with heat sink compound.
 The raspberry pi has its own power adapter.

 https://i.imgur.com/WjBMV5x.jpg

 https://i.imgur.com/0LW4FAG.jpg

 Fans are needed as bifurys get hot,There are two fans for the bifurys, they have their own power supply
 (an old 12v adapter for scanner) at the moment but will be powered from the power unit when i get a fan controler.
 One is for cooling the pi and the other two are for the Bifurys.
 Plus there are three usb cables with the red wire snipped so there is no power passing through them.
 An ethernet cable if you dont use wifi.

 https://i.imgur.com/FtB2dKZ.jpg

 8 red bifurys 5 ghs each 40gh total they dont all flash but they do hash.
 i have zadiged them and tweezered to update firmware.
 http://c-scape.nl/bi-fury/bifury_upgrade.pdf

 https://i.imgur.com/6QPZelC.jpg

 raspberry pi running minepeon BFGminer 3.10.0
 the whole lot put together runs well 40 - 42 ghs

 https://i.imgur.com/tL62Kvf.jpg

 bfgminer version 3.10.0 - Started: [2014-09-24 15:13:29] - [  3 days 23:48:40]
 [M]anage devices [P]ool management ettings [D]isplay options  [H]elp [Q]uit
 Connected to stratum-lb48.btcguild.com diff 32 with stratum as user /////////////////////
 Block: ...a51d3b9d #322934  Diff:34.7G (248.1Ph/s)  Started: [14:59:58]
 ST:18  F:0  NB:578  AS:11  BW:[ 52/ 39 B/s]  E:206.73  I:24.24uBTC/hr  BS:5.7M
 8/16   57.8C | 42.49/42.56/40.29Gh/s | A:102001 R:451+45(.40%) HW:127338/3.8%
--------------------------------------------------------------------------------
 BIF 0: 53.1C |  5.37/ 5.42/ 5.24Gh/s | A: 13131 R: 55+ 5(.35%) HW:  8421/2.0%
 BIF 1: 47.5C |  5.24/ 5.25/ 4.83Gh/s | A: 12332 R: 59+ 4(.40%) HW: 31511/7.5%
 BIF 2: 46.5C |  5.34/ 5.35/ 4.95Gh/s | A: 12547 R: 57+ 7(.41%) HW: 18137/4.3%
 BIF 3: 49.5C |  5.52/ 5.53/ 5.15Gh/s | A: 13148 R: 56+ 8(.40%) HW: 25041/5.7%
 BIF 4: 48.6C |  5.17/ 5.17/ 4.89Gh/s | A: 12271 R: 57+ 7(.44%) HW: 17822/4.3%
 BIF 5: 46.3C |  5.12/ 5.13/ 4.97Gh/s | A: 12575 R: 55+ 6(.41%) HW:  8507/2.1%
 BIF 6: 57.8C |  5.28/ 5.30/ 5.16Gh/s | A: 13073 R: 58+ 5(.40%) HW:  5472/1.3%
 BIF 7: 53.2C |  5.41/ 5.42/ 5.10Gh/s | A: 12924 R: 54+ 3(.39%) HW: 12427/2.9%
--------------------------------------------------------------------------------

 I have a few errors i am trying to fix.
 I have probably missed something being a bit of a noob, but its giving me the 40 gh that i wanted.

 I hope this is helpful in solving the power problem with multi port usb hubs and their adapters
 for powering ASIC block eruters .
 
  Dave.

    Any donations will be greatfuly received. -->  1PWfcDuMKFvyKYNyC3Ka9F8We9tV9kg8NM

[mister.vis]

Hello Eveyrone,

We tried many times to run the 4Gh/s Bi Fury miners (2 units), but unsuccessfully the BFG miner 5.4.2.7 doesn't detect miners (changing usb ports didn't help).

The importer insists units are tested and fully working.

I hope you can help me.

Thanks,
M.

[NotFuzzyWarm]

Hello Eveyrone,

We tried many times to run the 4Gh/s Bi Fury miners (2 units), but unsuccessfully the BFG miner 5.4.2.7 doesn't detect miners (changing usb ports didn't help).

The importer insists units are tested and fully working.
I hope you can help me.
Thanks,
M.

All I can suggest is to look into the BFGminer or CGminer Github repository for a version dated to when those were being made.

Better yet, here is the link to the mining software section here https://bitcointalk.org/index.php?board=42.0
Post your question there in the BGFminer and CGminer threads...

edit: and the 1st page of this threads says what versions to pull from the Github repos...

[josean_rt]

Hello everybody,

Somebody knows how to solve thermal cutoff disabled. I try to change the firmware but it happens again. I try on Ubuntu, Windows and OSX but no way. The Bi*fury is with a 14 inch fan blowing air all the time and the temperature is 103.4C if i put my fingers on it is cold. I try to put low values on the oscillator... im became crazy.

Bfgminer 3.10.0

King regards

[josean_rt]

SOLVED...

adding to comand line --temp-cutoff X, where X its a value highier than the actual temperature, in my case 105 C

Regards