Blue Fury Support Thread.

[NorbyTheGeek]

No bigpic:all and Icarus:all will cause problems with each other. I have sent you a pm.

Please, for the rest of us lurking, what is the recommended way to launch bfgminer for those of us who have both USB Block Erupter and BlueFury units?  Do we need to specify each serial port manually to avoid conflicts, or is there a firmware update in the works that will help the issue?

Thanks!

-- Norby

[1715390208]

1715390208

[1715390208]

1715390208

[1715390208]

1715390208

[1715390208]

1715390208

[x3maniac]

according to luke

https://bitcointalk.org/index.php?topic=168174.msg3450533#msg3450533

you can't use them together

[NorbyTheGeek]

according to luke

https://bitcointalk.org/index.php?topic=168174.msg3450533#msg3450533

you can't use them together

Just don't use -S <anything>:all
This tells BFGMiner to probe every port for the <anything> device.
Erupters can't handle BigPic probes, and BigPic can't handle Icarus probes.

I understand that to mean that you can't probe (:all) if you have both.  You can still specify each serial port manually.  I was asking if there's an alternative.

[kabopar]

Interested in how this is working with cgminer.  Anyone using it successfully?  Did cgminer find it on its own?

Tried cgminer 3.5.0, installed the drivers using zadig, but cgminer wouldn't detect the BF device.  Gave up, installed the previous driver and went back to bfgminer.  So far only bfgminer32 ver 3.2.0 as in the guide above works with a low H error rate.  It is detected with bfgminer64 ver 3.4.0, but the H error rate is very high.  On my single BF device I could not get higher hash rate than about 2.26 GH/sec.

[Blood Ninja]

You have a spelling error in your Wheezy install instructions
Essential was spelled wrong should be


sudo apt-get install build-essential

[Blood Ninja]

switched to your specific  Raspbian Wheezy Setup Bfgminer build and still only getting 2.3GH

Look like these are performing 20% lower than spec.

[Swimmer63]

Can someone please post their .bat for bfgminer.  I used win7 install instructions.  Drivers have loaded fine.  But I can't get bfgminer to recognize the BitFurys.  Using bfgminer 3.2.3-win32.  The only thing it's recognizing is OCL - whatever that is.

[Beastlymac]

Interested in how this is working with cgminer.  Anyone using it successfully?  Did cgminer find it on its own?

Yes cgminer should hot plug it.

You have a spelling error in your Wheezy install instructions
Essential was spelled wrong should be


sudo apt-get install build-essential

Fixed, thanks.

according to luke

https://bitcointalk.org/index.php?topic=168174.msg3450533#msg3450533

you can't use them together

Just don't use -S <anything>:all
This tells BFGMiner to probe every port for the <anything> device.
Erupters can't handle BigPic probes, and BigPic can't handle Icarus probes.

I understand that to mean that you can't probe (:all) if you have both.  You can still specify each serial port manually.  I was asking if there's an alternative.

Currently I don't think so, you will need to specify the com port.

switched to your specific  Raspbian Wheezy Setup Bfgminer build and still only getting 2.3GH

Look like these are performing 20% lower than spec.

Can you please try minepeon 0.2.4 on your raspberry pi. Arch is a lot better then raspbian. Also how is it connected up is it directly connected to the raspi?

[kabopar]

Can someone please post their .bat for bfgminer.  I used win7 install instructions.  Drivers have loaded fine.  But I can't get bfgminer to recognize the BitFurys.  Using bfgminer 3.2.3-win32.  The only thing it's recognizing is OCL - whatever that is.

using bfgminer32 ver 3.2.0 and the batch file as per the Mining Support instructions
(edit the file #Mine.bat)
bfgminer.exe -S "BF1:all" -o stratum+tcp://stratum.bitcoin.cz:3333 -u ..... works ok w/o H errors

I did not find a way yet to get more than about 2.26 GH/sec from my single BF device.

[kabopar]

Tried ubuntu x386 12.10 with bfgminer, however it failed to detect the BF device  (used -S /dev/ttyACM0)
previously also tried cgminer 3.6.6.1 on Win7, but this did not detect the BF miner (driver was installed using zadig, and showed up in Device Manager)
back to bfgminer 3.2.0 on Win7...
hashing rate is still 2.26 GH, tried on 2 pools (Slush and BTC Guild), the bfgminer display is consistent with what the pools report.

[Blood Ninja]

switched to your specific  Raspbian Wheezy Setup Bfgminer build and still only getting 2.3GH

Look like these are performing 20% lower than spec.

Can you please try minepeon 0.2.4 on your raspberry pi. Arch is a lot better then raspbian. Also how is it connected up is it directly connected to the raspi?

I'm running only two of them in a D-Link Hi-Speed USB 2.0 7-Port Powered Hub (DUB-H7) and 1 raspberry Pi as controller

I tried minepeon 0.2.4 and that's where i was getting the 60% error rates on bfgminer, could not get them to even recognize on cgminer under minepeon 0.2.4.

[Swimmer63]

Can someone please post their .bat for bfgminer.  I used win7 install instructions.  Drivers have loaded fine.  But I can't get bfgminer to recognize the BitFurys.  Using bfgminer 3.2.3-win32.  The only thing it's recognizing is OCL - whatever that is.

using bfgminer32 ver 3.2.0 and the batch file as per the Mining Support instructions
(edit the file #Mine.bat)
bfgminer.exe -S "BF1:all" -o stratum+tcp://stratum.bitcoin.cz:3333 -u ..... works ok w/o H errors

I did not find a way yet to get more than about 2.26 GH/sec from my single BF device.

OK - I have ver 3.2.0 but see no file #mine.bat.  Does the # stand for something else?  I have never seen a file start with #.

[OgNasty]

Interested in how this is working with cgminer.  Anyone using it successfully?  Did cgminer find it on its own?

I can't get cgminer to detect mine either...  zadig worked fine and my computer recognizes them, just no cgminer...  What is the command to recognize them??

Also, when following the driver installation instructions to switch to bfgminer, I get an access denied error when installing...

[tk1337]

Well...

I compiled the latest revision of CGMiner on MinePeon 0.2.4 w/options --disable-opencl --disable-adl --enable-bflsc --enable-bitforce --enable-icarus --enable-modminer --enable-ztex --enable-avalon --enable-bitfury (same options as the tutorial in Rasbian Wheezy). The devices were never detected, so I switched to Raspbian Wheezy, latest updated, first trying CGMiner per the .DEB package and instructions on the tutorial, results were the same, no devices were detected under CGMiner (they would show in lsusb).



I then uninstalled the CGMiner package (dpkg -r cgminer) and installed BFGMiner per tutorial instructions, after which the devices were detected. This is a hub that I can easily run 8 ASIC Erupters, so it should have no power issues running 8 BlueFuries, however I started off with 5 and decided to let them hash awhile to see what kind of rates I was getting...

Granted, I'm not getting any hardware errors (which is awesome),  but also not seeing GH/s rate I should be seeing. Now with this being said, I am going to try a few different pools and see what results I have. As well, I'm going to try to make a build on Raspbian of CGMiner (since I have yet to get CGMiner to work with the devices and apparently CGMiner so far, from what I've read has the best results...).



EDIT:
Just made a fresh build of CGMiner on Raspbian, still won't detect any devices, I also notice that CGMiner disables all the devices as I tried to use BFGMiner after (which was working seconds before trying CGMiner) and get 'All devices disabled, cannot mine!'. I thought that was semi-interesting...

[kabopar]

Can someone please post their .bat for bfgminer.  I used win7 install instructions.  Drivers have loaded fine.  But I can't get bfgminer to recognize the BitFurys.  Using bfgminer 3.2.3-win32.  The only thing it's recognizing is OCL - whatever that is.

using bfgminer32 ver 3.2.0 and the batch file as per the Mining Support instructions
(edit the file #Mine.bat)
bfgminer.exe -S "BF1:all" -o stratum+tcp://stratum.bitcoin.cz:3333 -u ..... works ok w/o H errors

I did not find a way yet to get more than about 2.26 GH/sec from my single BF device.

OK - I have ver 3.2.0 but see no file #mine.bat.  Does the # stand for something else?  I have never seen a file start with #.

I downloaded the bfgminer version from the Win7 instructions earlier in this thread (Download Alpha Drivers Here : http://www.mediafire.com/download/819me4zvdju8lyg/bfgminerWin.zip)
There is a file called #MINE.bat, which you can edit with notepad.  The original content is

Code:

bfgminer.exe -S "BF1:all" -o stratum+tcp://stratum.mining.eligius.st:3334 -O YOUR_BITCOIN_ADDRESS

The important part is the BF driver which is pointed to by the file bf1.inf in this zip file.  You have to install this driver per the instructions in this thread to get the BF device recognized.
Good luck

[kabopar]

Well...

I compiled the latest revision of CGMiner on MinePeon 0.2.4 w/options --disable-opencl --disable-adl --enable-bflsc --enable-bitforce --enable-icarus --enable-modminer --enable-ztex --enable-avalon --enable-bitfury (same options as the tutorial in Rasbian Wheezy). The devices were never detected, so I switched to Raspbian Wheezy, latest updated, first trying CGMiner per the .DEB package and instructions on the tutorial, results were the same, no devices were detected under CGMiner (they would show in lsusb).



I then uninstalled the CGMiner package (dpkg -r cgminer) and installed BFGMiner per tutorial instructions, after which the devices were detected. This is a hub that I can easily run 8 ASIC Erupters, so it should have no power issues running 8 BlueFuries, however I started off with 5 and decided to let them hash awhile to see what kind of rates I was getting...

Granted, I'm not getting any hardware errors (which is awesome),  but also not seeing GH/s rate I should be seeing. Now with this being said, I am going to try a few different pools and see what results I have. As well, I'm going to try to make a build on Raspbian of CGMiner (since I have yet to get CGMiner to work with the devices and apparently CGMiner so far, from what I've read has the best results...).



EDIT:
Just made a fresh build of CGMiner on Raspbian, still won't detect any devices, I also notice that CGMiner disables all the devices as I tried to use BFGMiner after (which was working seconds before trying CGMiner) and get 'All devices disabled, cannot mine!'. I thought that was semi-interesting...

Congrats on getting this going.  I also could not get CGMiner to detect the BF device.  Your hash rates are similar to what I got, which is below the advertised  "Spec: Rated speed 2.6Gh/s. +/- 10%" 

[kabopar]

Interested in how this is working with cgminer.  Anyone using it successfully?  Did cgminer find it on its own?

I can't get cgminer to detect mine either...  zadig worked fine and my computer recognizes them, just no cgminer...  What is the command to recognize them??

Also, when following the driver installation instructions to switch to bfgminer, I get an access denied error when installing...

+1
When you switch back to bfgminer you need to re-install the original drivers (that were modified by zadig).  I went through this and managed to get back to bfgminer (use the file indicated earlier in this thread, which contains the driver for the BF device as well as a bfgminer version 3.2.0 which avoids the hardware errors that later versions have).

[cet]

Beastlymac - Where can I get a windows vista usb driver for blue fluries?  I tried loading the one included in the directions for windows 7 but they wouldn't install. It looks like the bf1.ini file is a text file with some descriptive lines.  Is it possible to build one of these that will work?

/cet

[colemab]

On Ubuntu 12.04.3, I get the following error when running the  'sudo apt-get install bfgminer' command

Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 bfgminer : Depends: libjansson4 but it is not installable
E: Unable to correct problems, you have held broken packages.

I have searched on google but no luck.  Any ideas?

In the mean time, I have them running temporary on a windows 7 box and I am getting about 2.22 - 2.34 Ghps (per unit) with bfgminer 3.2.0.

[tk1337]

Well...

I spent most of the day trying different OS's on different machines (Ubuntu 12.04.3, Raspbian, Arch Linux, Windows7, OSX), different USB Hubs (Rosewill RHB-500, D-Link DUB-H7, Sateshi 12-Port, a few Belkin 7-ports, GearHead 7-port), different physical machines (3 different laptops (Win/Linux/Apple),a iMac, a VM on iMac, a VM on Win7, raspberryPi).

From my experience:
On any platform, from a compiled build or a pre-compiled executable, CGMiner just doesn't work, it never detects the devices and shuts down.

Thus far, the *only* configuration that works for me is BFGMiner 3.0.99 on Raspbian (RaspberryPi). After doing all my testing on different machines, different hubs, different OS's, I ended up back at the RaspberryPi, upon starting BFGMiner up after all my testing, I'm seeing an average of 1.8GH/s per device (currently still 5 on the HUB, I've tried more/less it doesn't change).

Conclusion:
I'm fairly certain the most of the issues being seen are software related, either the firmware is just, well, not ready or there's some missing connection that everyone seems to be having.

As a developer (granted I moved away from os-apps long ago), I would highly suggest you releasing the firmware to the public so that other developers can assist on the issues. I'm not stating the people involved aren't doing everything they can (as I'm sure LukeJr & ckolivas are doing what they can to fix the issues from within their software), but "a different set of eyes" can usually always assist indirectly (sometimes directly). As usually questions get raised as to the methods being used (etc), which will cause the original developer to see the light on things that could be the cause of issues.

Either way, I stay optimistic these are software issues, not hardware issues.