Blue Fury Support Thread.

[-ck]

New version of cgminer out, 3.8.3 with minor improvements for these devices.

[philipma1957]

I will have to give cgminer a try.

as for the pencil mod  2.73 gh/ 2.70 gh  /2.58 gh   vs   2.37 gh /2.35gh/ 2.29gh     


    for newbies the third number is the after error number and is the money number.  whomever invented the mod deserves my thanks.

[tk1337]

New version of cgminer out, 3.8.3 with minor improvements for these devices.

Well, I updated MinePeon was CGMiner 3.8.3 also, was helping out Maidak with his setup & both systems (his and mine) keep zombie'ing all devices within several minutes of running on 3.8.3...

[Ragdollcatman]

I would like to know whom it is who makes these Red Fury and Blue Fury USB miners.

So far my experience of them has been absolutely rubbish.

So far I've had 3 Blue Fury usb sticks, 1 was DoA, the other died inside a few days.  Had 1 replacement so far, waiting for an RMA for the other..

The one I do have does a measly 1.981 Ghps through CG Miner. I thought the Blue Fury was supposed to do 2.2 to 2.7 Ghps?

So far also had 3 Red Fury sticks.. 2 working , 1 @ 2.15 Ghps and the other 1.98 to 2 Ghps when they are supposed to be 2.4 to 2.6 Ghps.

The third one arrived today and is DOA.

Getting really annoyed with the poor quality of these miners considering they cost over £100 a piece.

Is there some reason why they do not get their advertised speed?

And would also like to know why, even after installing/extracting and using the BF1.ini file, the Virtual COM port driver and a WCA driver etc BFGMiner still can't find them on my computer and so I've had to use zadig to overwrite the driver to the winusb one and mine with CG Miner, which I have to restart several times whenever I need to restart because it won't/can't get onto the pool I'm with (Bitminter)

I'm starting to think there is something dodgy going on when everything is so cloak and dagger - like who makes these things.

I've tried all of the miners on 3 different computers. The old Core 2 Duo one I'm using as the mining rig, my old 1366 rig which I gave my dad and my new 1155 gaming rig. Same problems across all three.

[zamot]

I've put up a new version of cgminer, 3.8.1 with improvements to the blue/red fury devices.

Any idea why i get this errors on BF1s ?

Code:

 [2013-11-12 23:08:58] Hotplug: bitfury added BF1 5
 [2013-11-12 23:08:58] BF1 5 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-12 23:08:58] BF1 5: Device disappeared, disabling thread
 [2013-11-12 23:08:58] BF1 5 failure, disabling!

And it is random on time and also on device.
I run cgminer 3.8.1 on Debian 7.1. It is not runing on RPi. There is no pencil mod.
There are 5 BEs and 5 BF1s, each od them on its own USB hub ( 3,5A powered).
It was try with connection of hubs into cascade ( BF1s hub connected to BEs hub and this to computer) and also try to connect hubs directly to computer and always the same result.
If i reset BF1s with reset switch on board it comes back.

Today i "upgraded" to version 3.8.3 and i still get this LIBUSB error:

Code:

 [2013-11-23 12:12:24] Hotplug: bitfury added BF1 8
 [2013-11-23 12:12:38] BF1 8 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-23 12:12:38] BF1 8: Device disappeared, disabling thread
 [2013-11-23 12:12:38] BF1 8 failure, disabling!

Does anyone else have this issue ?

[-ck]

I've put up a new version of cgminer, 3.8.1 with improvements to the blue/red fury devices.

Any idea why i get this errors on BF1s ?

Code:

 [2013-11-12 23:08:58] Hotplug: bitfury added BF1 5
 [2013-11-12 23:08:58] BF1 5 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-12 23:08:58] BF1 5: Device disappeared, disabling thread
 [2013-11-12 23:08:58] BF1 5 failure, disabling!

And it is random on time and also on device.
I run cgminer 3.8.1 on Debian 7.1. It is not runing on RPi. There is no pencil mod.
There are 5 BEs and 5 BF1s, each od them on its own USB hub ( 3,5A powered).
It was try with connection of hubs into cascade ( BF1s hub connected to BEs hub and this to computer) and also try to connect hubs directly to computer and always the same result.
If i reset BF1s with reset switch on board it comes back.

Today i "upgraded" to version 3.8.3 and i still get this LIBUSB error:

Code:

 [2013-11-23 12:12:24] Hotplug: bitfury added BF1 8
 [2013-11-23 12:12:38] BF1 8 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-23 12:12:38] BF1 8: Device disappeared, disabling thread
 [2013-11-23 12:12:38] BF1 8 failure, disabling!

Does anyone else have this issue ?

If the device disappears and shows up as ZOMBIE and never re-hotplugs, there's nothing there on the USB any more for cgminer to talk to, so something is causing USB flakiness there. Check what 'dmesg' shows you after this has happened. There's not much the software can do if the device is effectively disappearing from the USB hub. If on the other hand the device is still there and it's just cgminer dropping out, it's possible that cgminer is too trigger happy - but if that were the case it would re-hotplug soon after.

[zamot]

I've put up a new version of cgminer, 3.8.1 with improvements to the blue/red fury devices.

Any idea why i get this errors on BF1s ?

Code:

 [2013-11-12 23:08:58] Hotplug: bitfury added BF1 5
 [2013-11-12 23:08:58] BF1 5 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-12 23:08:58] BF1 5: Device disappeared, disabling thread
 [2013-11-12 23:08:58] BF1 5 failure, disabling!

And it is random on time and also on device.
I run cgminer 3.8.1 on Debian 7.1. It is not runing on RPi. There is no pencil mod.
There are 5 BEs and 5 BF1s, each od them on its own USB hub ( 3,5A powered).
It was try with connection of hubs into cascade ( BF1s hub connected to BEs hub and this to computer) and also try to connect hubs directly to computer and always the same result.
If i reset BF1s with reset switch on board it comes back.

Today i "upgraded" to version 3.8.3 and i still get this LIBUSB error:

Code:

 [2013-11-23 12:12:24] Hotplug: bitfury added BF1 8
 [2013-11-23 12:12:38] BF1 8 BF1RequestWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-11-23 12:12:38] BF1 8: Device disappeared, disabling thread
 [2013-11-23 12:12:38] BF1 8 failure, disabling!

Does anyone else have this issue ?

If the device disappears and shows up as ZOMBIE and never re-hotplugs, there's nothing there on the USB any more for cgminer to talk to, so something is causing USB flakiness there. Check what 'dmesg' shows you after this has happened. There's not much the software can do if the device is effectively disappearing from the USB hub. If on the other hand the device is still there and it's just cgminer dropping out, it's possible that cgminer is too trigger happy - but if that were the case it would re-hotplug soon after.

That's strange, cgminer re-hotplugs soon and that happens few times but on the end BF1s are ZOMBIEs
If i start cgminer -n in another windows and this cgminer with ZOMBIEs is still running it see all BF1s, and also with lsusb i can see BF1s, just in the "working" cgminer they are disconnected.
Damm and with 3.8.3 it looks even worser than with 3.8.1

[tk1337]

Just got a new shipment of resistors in...

Decided to go with 9.53k on R15, looks like it's a sweet spot 2.6GH/s after errors, sometimes jumps as high as 3.13GH/s, but for the most part sits at 2.6xGH/s with 1% HW Errors. So far it seems to be the steadiest out of all the other furies (some with 10k ohms resistors, some with pencil mod) in terms of GH/s and error %.

Kind of awkward in a way, as with 10k on R15, they sit at a high hash rate, but jump a lot and sometimes a high error rate. Wish I would have bought more 9.53k resistors, as I think I only picked up 10 to play with.

[tk1337]

Update:

Since I haven't heard from ssinc in awhile concerning my replacement for at least one of my fury's (which would always sit at around 1GH/s with 41% errors, always 41% errors, even after pencil mod).

After a 9.53k resistor, 2.50GH/s with 7.5% errors...  (and the error % keeps going down the more it's hashing atm)
So, I'm considering that one fixed...


I've got two with some insanely high error %'s, which I'm going to put a 9.53k resistor on and see if that cures their issue. Granted they are running at 3.62GH/s and 3.34GH/s, however if the 9.53k resistor fixes the high error rate and calms it down to 2.6GH/s I'll be a happy person.

[tk1337]

I think I may have identified a production issue...

While replacing the resistors on R15, I noticed the furies with extremely high error rate or extremely low GH/s rate all had one thing in common versus the ones that sat comfortably around 2.2GH/s-2.3GH/s with 1-3% errors.

What I found wasn't limited to just Blue Fury either, also Red Fury.

Now, I'm not entirely sure this would be the cause of the issues, but I can say if the production machine was the slightest off during production, it could have caused an issue. On the ones that seeming were hashing fine, the solder points for R15 were spot on rectangular points for each end. Now for the ones that all had issues, the soldering points, well, weren't... see the pictures below. Each picture is of a different fury, the first one was the one that I would see 900MH/s to 1.3GH/s with 41% errors, the second one I would 35-50% errors, the third one 25-35% errors -- apologies for the shitty cell phone camera, was all I could find while in the middle of replacing the resistors.







I'm pretty sure you can see the obvious differences between the pictures, where as the other furies I replaced the resistor were non-problematic had no issues and R15 looked to be a dead-on rectangular solder point, no randomness like what is found in these pictures.


Edit:
After replacing 9 R15 resistors with 9.53k ohms, running for 30 minutes (and being extra careful on the soldering points for the ones above mentioned):


I am very happy with the results thus far...

I replaced R15 with a Vishay 9.53k ohms SMD 0805 Resistor Part No# TNPW08059K53BEEN from Mouser (link) also available at DigiKey (link).

[philipma1957]

New version of cgminer out, 3.8.3 with minor improvements for these devices.

Well, I updated MinePeon was CGMiner 3.8.3 also, was helping out Maidak with his setup & both systems (his and mine) keep zombie'ing all devices within several minutes of running on 3.8.3...

fuck it I will stick with bg miner the pencil mod has been rock solid 2.61  4% error rate.   nice spot on the resistor issues

[-ck]

New version of cgminer out, 3.8.3 with minor improvements for these devices.

Well, I updated MinePeon was CGMiner 3.8.3 also, was helping out Maidak with his setup & both systems (his and mine) keep zombie'ing all devices within several minutes of running on 3.8.3...

fuck it I will stick with bg miner the pencil mod has been rock solid 2.61  4% error rate.   nice spot on the resistor issues

Probably just trigger happy then for slower hardware. I've relaxed the timeout duration in git master but if you've lost interest that's fine.

[philipma1957]

getting more sticks around thanksgiving I will try then

[HellDiverUK]

Wow, terrible pictures.    Putting yellow boxes round blurs doesn't really help either. 

[Kronkvist]

Any updated peon start-up commands ?
Have been using :

Code:

#!/bin/bash
sleep 10
/usr/bin/screen -dmS miner /opt/minepeon/bin/bfgminer-fury -S bitfury:/dev/ttyACM0 -S ICA:/dev/ttyUSB0 -S ICA:/dev/ttyUSB1 -c /opt/minepeon/etc/miner.conf

For the last few days.

This one can only run 2 BE's and a blue fury at the time being.

Any help ?

[Knicknac]

I know it's been posted some where in this thread but I just need a link to clear instructions to run Blue Fury chips with BE. Here's where I'm at:

Win7
Anker usb 9-port powered hub (3 BF running on BFGMiner 32). This hub was running 7 BE a week ago using BFGMiner 314.

I know I can do it with code but I'm not sure what that code is. Does anyone know what the OCL readings are from? or For? When running BFGMiner32, that is.
 

[tk1337]

Wow, terrible pictures.    Putting yellow boxes round blurs doesn't really help either. 

Maybe you should get your eyes checked? Also, good noting this after I mentioned it was from a cell phone and crappy quality  it's like stating something that was already stated 

Anyhow, I had 3 more to do today, so I attempted to get some better pictures...

This is what R15 should look like:



This is one (of many) different ways R15 looks, especially in the ones that hash lower or have a higher error % than the fury sticks that have R15 solder points like the above picture:


Judging from my small sample of furys I own, if the rest of the batches are like this, then 40%-50% of the batches would have the issue. Like I said, it's not limited to Blue Fury as the two Red Fury's I own, one hashes 2.3GH/s spot on (determined it has regular soldering points), the other hashes lower (1.8GH/s) and has irregular soldering points.

However I'm not entirely sure this "problem" would cause the issues seen by most people, however I will state that after I was extra cautious with solder paste and resistor placement, I fixed the worst fury I had that sometimes would be seen hashing 900MH/s with 41% errors. I was awaiting a replacement, but since I haven't heard from my GroupBuy leader regarding replacement in over two weeks, I decided to try and fix it and succeeded (I might add, the pencil "mod" had no effect this unit either).

[thegoldbug]

Thanks for posting the pictures and doing all this testing and experimenting and more importantly sharing it with all of us.

I'll take fuzzy photos over no photos at all.

Thanks again.

[kabopar]

tk1337,
Thanks for the photos (and the improved ones ), as well as the rest of the investigation.  Looks like the Quality Assurance department was asleep as the rush to build and ship the units took priority.  Hopefully Beastlymac and other members of the Blue/Red Fury organization will take this into account if/when there are additional batches built.
Just wondering if some of the inconsistencies that you found were in the 'solder mask' (the paint layer that covers the copper tracks to prevent solder adhesion during wave soldering or SMT placement) or were the tracks partially missing or shorting?

Cheers

[tk1337]

tk1337,
Thanks for the photos (and the improved ones ), as well as the rest of the investigation.  Looks like the Quality Assurance department was asleep as the rush to build and ship the units took priority.  Hopefully Beastlymac and other members of the Blue/Red Fury organization will take this into account if/when there are additional batches built.
Just wondering if some of the inconsistencies that you found were in the 'solder mask' (the paint layer that covers the copper tracks to prevent solder adhesion during wave soldering or SMT placement) or were the tracks partially missing or shorting?

Cheers

Some of the mask layer was missing in some areas, other areas had full run-on when it shouldn't have (example R15 pad1 actually connecting to pad2), some went as far as connecting R15 to R16 on two or more pads. My guess is underneath the resistor (since there was such an extremely close gap (1-2mm?)) that it could have caused a connection underneath the resistor (possibly bypassing it ). I'm no PCB expert, I usually stick to coding, however I have been replacing/fixed/soldering circuit board components (as a hobby) for a good 20 some years. Also to note, I don't have a completely 'dead' fury, so I'm not going to attempt this yet (I might, who knows) but inspecting most of the board under a magnifying glass pretty thoroughly, I found for the most part, it seemed like this was only an issue around R15 and R16.

What I will say is earlier in my posts I couldn't get a reading on R15 with a multimeter, thought it might be the multimeter (as it was one I borrowed), later bought a new one... still no reading this bugged me, as I was getting a reading on other resistors in the area on the board. I was of course trying to read the fury sticks I had issues with... now here's the more interesting thing... now that they seem fixed with the 9.53k ohms resistor and careful placement, I get a reading. So, that raises a question of, was it somehow bypassing that resistor with the pad underneath being extended/spilled over into the other pad(s), since it would make a direct connection pad to pad first or maybe sometimes? I'm not sure, I'm speculating right now.

And I the 3 I did tonight I put 10k ohms on and they run 'okay' but it really seems that 9.53k ohms is a sweet spot, so I'm going to put an order in for more of those, maybe a few 9.1k/9.2k.

Oh and btw, I always have cooling on all my components. (Even if they are stated to not require it...) and I will say I don't have any of the Blue Furies with the black heatsink (anyone wanna sell me one so I can test?), mine have the larger silver heatsink (which I'm debating on sanding down some and giving giving a little bit more space between the fins for better airflow when I anodize them blue), however the Red Furies with the red heat-sinks which have a slimmer heat-sink profile, while it's a longer heatsink, it doesn't do the job as efficiently as the Blue Furies I currently have, without air on it, it heats up much hotter than the blues.)

I would also like I am in no means trying to disrespect Beastlmac, Big Picture Mining, or the Red Fury team. I am simply trying to help them out, as I hope for another production run, just with possible issues addressed (if these are indeed valid issues). I know they've had a lot of hard times trying to get things thus far, personally if the production factory which did the PCB's failed at some level and tried to rush things just to get the boards out due to all they delays they were causing, if I were in Beastlymac's shoes, I would definitely want to know about it so I can correct it for future production.

With all that being said;

If anyone has any Fury devices deemed, 'broken' and they don't want to deal with it, I'll be glad to buy them...
Likewise I would like to get my hands on a Blue Fury with the Black Heatsink, so looking for one of those to purchase as well...

I would really like to do some more testing and try a few other things I've noticed other than just replacing the R15 resistor.