Blue Fury Support Thread.

[NorbyTheGeek]

I disagree in regard to running -S bigpic:all.  I am running my single BF with bfgminer 3.5.1, with the 'alfa driver' provided by Beastlymac, through a batch file called #MINE.bat on Win7 64, the content of this batch file is
bfgminer.exe -S bigpic:all -o [pool url] -u [user name] -p [password]

You can use -S bigpic:all as long as you don't also have USB Block Erupters.  As has been discussed before, using -S bigpic:all will screw up erupters, and using -S erupter:all will screw up BFs.

[zyk0]

Since Vista SP1 Windows x64 requires drivers to be signed and you cannot permanently set testing mode.  If reinstalling some other OS isn't an option I'd use VirtualBox and pass the USB devices through to either some linux distro or a 32bit windows guest OS.

I use VirtualBox a bit, I have never tried passing these devices though, does it really work ?

That's currently how I have my Blue Furies running, Win7 x64 Host, Ubuntu Server 13.10 guest, bfgminer 3.5.1.

[jdkackley]

I disagree in regard to running -S bigpic:all.  I am running my single BF with bfgminer 3.5.1, with the 'alfa driver' provided by Beastlymac, through a batch file called #MINE.bat on Win7 64, the content of this batch file is
bfgminer.exe -S bigpic:all -o [pool url] -u [user name] -p [password]

You can use -S bigpic:all as long as you don't also have USB Block Erupters.  As has been discussed before, using -S bigpic:all will screw up erupters, and using -S erupter:all will screw up BFs.

Thanks Norby! I was trying to say that. I hope everything worked out for you Lou!


BTW G'morning all

[onryo]

I'm using both block erupters and blue furies on the same instance of bfgminer.

Like previous posters have said, you just have to specify your devices.  It's pretty easy to do on Linux.  I'm using RedHat 6, but the process should be similar on Ubuntu.  To find out where your miners are, run:

Code:

ls /dev/tty*

Block erupters show up as /dev/ttyUSB# and blue furies are /dev/ttyACM#

So your basic bfgminer command for 3 erupters and 2 blue furies would be:

Code:

bfgminer -c bfgminer.conf -S erupter:/dev/ttyUSB0 -S erupter:/dev/ttyUSB1 -S erupter:/dev/ttyUSB2 -S bigpic:/dev/ttyACM0 -S bigpic:/dev/ttyACM1

note that I've defined the blue furies as "bigpic".  On Ubuntu I had to use "bitfury" but on Windows it was "BF1".  I actually run 21 erupters and 2 furies.  It makes for a very long command line, but I launch with a shell script so it's no more difficult than specifying 'all'.

A little advice would be to not blindly add all USB devices as Block Eruptors from

Code:

ls /dev/ttyUSB*

Try

Code:

udevadm info --query=all -n /dev/ttyUSB0 | grep ID_VENDOR

Just replace the 0 for each device found. You might see something like
ID_VENDOR=Butterfly_Labs gear etc.

All the best

GNU/Linux Debian armhf on SoC

[Kenshin]

My BlueFury arrived today from Outcast3K. Why is the LED blinking in Red? Should it be Blue?

[Zammo]

My BlueFury arrived today from Outcast3K. Why is the LED blinking in Red? Should it be Blue?

The Blue Fury gets it's name from the Blue PCB, not the LED

My LEDs are flashing red and orange

Huh, I now read it as Blue PCB and Red LED.  I'm sure it said Blue LED earlier...

Yes it did. I was confused with what the EE told me. Didn't realise it was just a blue pcb change.

[Mudbankkeith]

My BlueFury arrived today from Outcast3K. Why is the LED blinking in Red? Should it be Blue?

The Blue Fury gets it's name from the Blue PCB, not the LED

My LEDs are flashing red and orange

Huh, I now read it as Blue PCB and Red LED.  I'm sure it said Blue LED earlier...

Yes it did. I was confused with what the EE told me. Didn't realise it was just a blue pcb change.

So my old red fury should be a green fury  (green pcb, red and amber lights)

[btljuice]

Got my blue fury yesterday. Got it going with cgminer 3.7.2, it was hashing for several hours at 1.1-1.2GH/s, and when I woke up this morning it's not hashing at all. Below is what I'm getting now.

Code:

[2013-11-08 11:10:36] Hotplug: bitfury added BF1 0
 [2013-11-08 11:10:36] BF1 0 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-08 11:10:36] BF1 0: Device disappeared, disabling thread
 [2013-11-08 11:10:36] BF1 0 failure, disabling!
 [2013-11-08 11:10:36] Thread 15 being disabled

[sunsofdust]

These devices are just flat out buggy.  I had all my units hashing (at avg 2.0 Gh/s) last night and just checked them this morning and two were found listed as ZOMBIE.  Now I can't get these two units detected on either cgminer or bfgminer. 

This is very frustrating!!!

[BigDaddyWooWoo]

Out of my two units I've got one hashing 1.7gh/s and the other at 411mh/s.  Yes you read that correctly.  411mh/s.  That's barely faster than a block erupter.  Using cgminer 3.7.2 under win 7.  Disappointed with these as the setup was convoluted at best and the results are underwhelming.  These are buggy as hell.  Good luck if you guys decided to produce a second batch.  My recommendation is don't and save everyone the hassle.

By the way, what's the process to exchange the obviously broken one for one that works at least within 20% of your advertised target?

[bitterdog]

I have one unit out of the 2nd batch of 10 I need replaced

LOL check out the Serial # of the bad one

#####D0A

[Epinnoia]

I have one unit out of the 2nd batch of 10 I need replaced

LOL check out the Serial # of the bad one

#####D0A

Interesting.  My misery loves your company...  lol    That's exactly what my first one did.  Barely above half of what it was supposed to get.  My ser# was a 150... number, so I thought it might be limited to the earlier runs.  Guess not.

SSINC was very good about replacing mine -- it's already in the mail.  I tried re-flashing the Firmware, and it did nothing...same crappy ghps.  It's probably either a buggy Bitfury chip, or a bad component on the board is causing a serious shortage of power to the chip.  I'd suggest you seek a replacement.

Also, I notice in bfgminer 3.5.1 that changing the work diff level above 2 (ie. 4 or 8+) seems to cause much more severe HW errors.  And you really should set it to 4 or higher if you have more than 2 furies.  I think your diff level of 16 is probably too high for 25ghs.  I'd stick with 4 or 8.

[bitterdog]

Is there a way in WINDOWS to reflash?

[XenoCypher]

Been almost a full 24 hours hashing and mine seem to be holding steady atm.

I've got 3 of them running with 3 block erupters on the same hub and they all seem to be working fine for the most part.

http://imageshack.us/a/img547/2945/l08c.jpg

[Epinnoia]

Is there a way in WINDOWS to reflash?

You could run vmware and run a virtual ubuntu machine on it.  That's how I re-flashed mine. 

The firmware should be the same -- it has not been revised, I have been told.  The reason I re-flashed was because I had one that only got 1.3-1.4ghs and thought a firmware flash couldn't hurt.  It didn't hurt, but it didn't help either. 

[Taugeran]

I have one unit out of the 2nd batch of 10 I need replaced

LOL check out the Serial # of the bad one

#####D0A

Interesting.  My misery loves your company...  lol    That's exactly what my first one did.  Barely above half of what it was supposed to get.  My ser# was a 150... number, so I thought it might be limited to the earlier runs.  Guess not.

SSINC was very good about replacing mine -- it's already in the mail.  I tried re-flashing the Firmware, and it did nothing...same crappy ghps.  It's probably either a buggy Bitfury chip, or a bad component on the board is causing a serious shortage of power to the chip.  I'd suggest you seek a replacement.

Also, I notice in bfgminer 3.5.1 that changing the work diff level above 2 (ie. 4 or 8+) seems to cause much more severe HW errors.  And you really should set it to 4 or higher if you have more than 2 furies.  I think your diff level of 16 is probably too high for 25ghs.  I'd stick with 4 or 8.

btcguilds rationale behind diffs
2 (default)
4(4+ghs)
8(8+ghs)
16(16+ghs)
32(32+ghs)
....
to
1024 (1+Ths)



so diff roughly correlates with hash rate. and hist just happens to fall in the middle of 16 and 32. if he were to add hashing to put him at 33ghs or so it btcguild would bump him to diff 32

[nhminer]

I have 50 running at 90Gh/s total. Two throw tons of hardware errors. Shares found on same two are very low even though hashrate is reported normal.

These things run very cool. Begging to to overclocked. Hoping to be able to tweak in the future.

Pictures?   I posted above how it is possible to hardware overclock. Firmware over clocking might be available in the future I just don't want to cause more issues that would then need to be fixed.

I went back and reread this whole thread.  Maybe I'm just blind, but could you help out with a link to where you have the OC info?

Back in https://bitcointalk.org/index.php?topic=319419.msg3486886#msg3486886 you wrote "Edit. It is possible to overclock the units and push them to potentially 2.7 by replacing the 22k resistor with a 10k one."
but a little more info would be helpful...


BTW: I'm currently running 7 (thanks ssinc)  with w7x64, cgminer 3.7.2; 10 port cheap powered hub with max of 4 units in each hub
RESULTS: avg 2.3 per unit

~nh

Anyone that *should* be over-clocking these, would have the knowledge to look at the board and see which resistors are 10k; However, with that being said there are two resistors on the board at 10k, R8 & R11 (R8 next to PRG button, R11 next to RST button), so I'm assuming by Beastlymac's statement that both 10k resistors would need to be swapped out to 22k, but would like confirmation that it would be both, if not both which, R8 or R11?

EDIT:
Also, you would be replacing it with a SMD 1206 22k ohm 1/8w resistor (Beastlymac, correct me if I'm wrong please), which seem to be pricey at DigiKey at the moment due to stock shortages it looks like. However Mouser does have a good amount in stock at the moment and are much cheaper than DigiKey.

Beastlymac said "replacing the 22k resistor with a 10k one", you are suggesting "that both 10k resistors would need to be swapped out to 22k" - didn't you get 'your resistors crossed'?

yup, I did... so, R15

how I reversed that... no fking clue...

Nutz -- and I just bought (50) 22K SMD 1206 from ebay for $1.00 shipped --- that's 0.003 BTC I'll never see again :p

[fizzmine]

Just got an Ebay RedFury up and running.  Working great so far.  Here's my info - might help anyone having trouble:

RPi - latest Rasbian

BFGminer 3.5.1
./configure --disable-avalon --disable-opencl --disable-adl --disable-x6500 --disable-modminer
make

lsusb | grep -i atmel
Bus 001 Device 006: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project

added to /etc/udev/rules.d/50-usb-hd.rules:
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"

After that a simple sudo ./bfgminer picked up my jally and the RedFury:

--------------------------------------------------------------------------------
 BPM 0:       |  2.42/ 2.41/ 2.36Gh/s | A: 392 R:1+0(.25%) HW:47/5.2%
 BFL 0: 42.0C |  5.34/ 5.33/ 5.20Gh/s | A: 959 R:1+0(.10%) HW: 0/none
--------------------------------------------------------------------------------

once those launched, I fired up the block erupters with sudo ./bfgminer -S erupter:all and both instances of bfgminer are running great.

[madpoet]

Well I finally got my BF and BE both working but only by using one on cgminer and one on bfgminer.  *shrug*  My BF is slow... 2.09.  All in all fairly disappointing, well below the 2.5 I was expecting when I bought it. Hope additional tweaking ekes more out of it.

[btljuice]

Got my blue fury yesterday. Got it going with cgminer 3.7.2, it was hashing for several hours at 1.1-1.2GH/s, and when I woke up this morning it's not hashing at all. Below is what I'm getting now.

Code:

[2013-11-08 11:10:36] Hotplug: bitfury added BF1 0
 [2013-11-08 11:10:36] BF1 0 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-08 11:10:36] BF1 0: Device disappeared, disabling thread
 [2013-11-08 11:10:36] BF1 0 failure, disabling!
 [2013-11-08 11:10:36] Thread 15 being disabled

Once I got the bluefury going again, after it's long zombie state... now it's only hashing at ~580Mh/s. Seems to be getting worse and worse as time goes on.