Topic: Blue Fury Support Thread. - page 36. (Read 89611 times)

to get it to recognize and hash:


on a mac they will show up as simultaneously under /dev as cu.usbmodem<####> and tty.usbmodem<####>


do bfgminer -S:/dev/cu.usbmodem#### 

Win7 64bit System

I just got the 2nd fury today with the scaled-back black heat sink (pictured above). It is very clearly running about twice as fast as the first one with the heavier heat sink that I received last week.

Something I noticed -- BFGminer shows the estimated hash rate (first and 2nd numbers) on the faulty one to be about 100MH/sec HIGHER than the one I got today (2.23GH/sec vs. 2.33GH/sec). The 3rd number in BFG, the effective rate, is where they differ drastically. Perhaps the firmware in the first one was a little too aggressive -- resulting in it being knocked back in stepping?  That's my feel of it after watching it rather closely these past few days.

Shouldn't I wait and see if BeastlyMac releases the firmware update?  SSINC has replacements in, but I have a sneaky suspicion that the one with the larger and better heatsink would perform the same if it had the same firmware as this more recent one.  I kind of like the ability to tell them apart so easily...  And if a firmware upgrade fixes the problem, that saves on shipping costs (both ways), as well as quite a bit of down mining time.

BFGminer does seem to squeeze about 10% more out of the newer fury, though.  1.97GH/sec in cgminer 3.7.2, and 2.17GH/sec in BFGminer 3.2.0.  That's nearly 200MH/sec difference in favor of BFGminer 3.2.0.  Maybe another 30min in each window would have brought the window narrower, but I don't think by very much.

I don't think it will make a bit of difference except less metal used = more profits and/or lower costs in future units.  They simply didn't get nearly as hot as anticipated.

I am getting about spot on 2.0GH/s on two units using Debian 7.0 x64 with cgminer 3.7.2.


I have also noticed that the units are very temperamental with some USB hubs. Running even one unit in a USB hub (dlink) either one will eventually time out with an error about communication timeouts. If I connect them directly to the computer, they run fine with the numbers show above. I suspect that they are rather picky about power, but that is only a guess at this point.

Reporting of hashrate in cgminer is based purely on return of valid shares, and since that's a luck based phenomenon, it takes thousands of shares to get an accurate representation of hashrate, so over an hour or so.

just got the batch #2 and the heat sinks are difference  hoping this change will help with mining power

Thank you.


Ok, I'm done resetting these things for now...this last time I now have one screaming at nearly 3Gh/s but another isn't even getting 1Gh/s.  The overall hash rate is....close each time, I wonder if this is just some weird reporting going on with CGMiner. 

CGminer 3.7+ on Windows 7 has had only had blinking Red lights no matter what.

Well, no matter what I do, with CGMiner it just blinks red.  And every time I restart the hash rate on each miner is different....

No joy with either BFGminer or CGminer on OSX. Simply will not pick up the device

Confirmed!

Stopping bfgminer 3.4.0 and restarting it gets the red LED flashing on and off.

Stopping bfgminer, pressing the RESET button on the usb stick and restarting bfgminer gets the alternating red / yellow.

There is no apparent difference in hash rate or error rate between the two scenereo's.  The only difference is the pattern of the light.

Received 2 today.

Starting bfgminer 3.5 with -S bitfury:/dev/ACM0 -S bitfury:/dev/ACM1

Recognized

[2013-11-06 12:51:49] lowlevel_scan: Found vcom device at dev_t:01a6000000000000 (path=/dev/ttyACM1, vid=0000, pid=0000, manuf=BFMG, prod=Bitfury BF1, serial=A4931313633351A01281)                   
[2013-11-06 12:51:49] lowlevel_scan: Found vcom device at dev_t:00a6000000000000 (path=/dev/ttyACM0, vid=0000, pid=0000, manuf=BFMG, prod=Bitfury BF1, serial=A4931313633351A01221)       

But never hash.

With erupters, I see something like this

[2013-11-06 12:55:41] Icarus Detect: Attempting to open /dev/ttyUSB0                   
 [2013-11-06 12:55:41] Acquired exclusive advisory lock on /dev/ttyUSB0                   
 [2013-11-06 12:55:41] Icarus Detect: Test succeeded at /dev/ttyUSB0: got 000187a2                   
 [2013-11-06 12:55:41] Found BES 0 at /dev/ttyUSB0                   
 [2013-11-06 12:55:41] BES 0: Init: baud=115200 work_division=0 fpga_count=0                   
 [2013-11-06 12:55:41] BES 0: Init: mode=default read_count=126 limit=0ms Hs=2.976100e-09                   


But after the initial line regarding ACM0/1 I see nothing further in the debug output.


Please advise

He's released two updates but it doesnt actually work

I believe the last that was reported from Bitminter was that they were still working on it (can't remember who it is that maintains the bitminter code atm).

hehe, could always do what I'm doing, replacing the LED's with a 3528 bi-color blue/yellow LED (PN# OSYBS4S2C1A) and I'm considering anodizing the heatsinks blue as well...

Can you give some additional details or thread link about how to "replacing the 22k resistor with a 10k one"

I can't get the sticks to work on OSX - always time out in Bitminter.

When plugging a stick in, it comes up as a modem in networking

Am I doing something obviously wrong or is the Bitminter beta not actually functioning right yet

They have a red light and a blue pcb

just a dummy question. do we talk here about RED fury or BLUE fury ? Why is it named blue when no one talk/write about blue light.
Maybe i forgot ( the years are here) , but i have in memory that BLUE furys will have blue light 

Awesome news!

I have 1 of 8 running on Arch Linux (MinePeon) that constantly gets below 2GH/s, but right at, it's usually at 1.95/196 GH/s, it has the same behavior on Ubuntu 13.