you Sir, rock. 

Under CGMiner 3.8.3 they seem to Zombie a lot (not just on the rPi either)... ck made a change to make CGMiner 3.8.3 "less trigger happy" in regards to the issue with lsusb and the units going Zombie, however since he made that change (a few days ago?) I haven't recompiled CGMiner 3.8.3 from github to try it out. (Other people have reported this issue in 3.8.1, but I have not personally seen it.)

I've got 15 running all at 2.5GH/s - 3.10GH/s all below 4% error rate with BFGMiner 3.6.0 (along with a BFL Jally & 20 erupters). Uptime on the miner is more than a couple of days now, which is only because I took off the Fury units to replace the resistors.

So to the person stating that the rPi could be/is at fault, would be an incorrect statement, as there are many factors involved.

^^ lmao 

I really doubt that, as cautious as I was being, with low air-speed and semi-low heat (enough to get the solder going) on with rework station. No soldering irons were used to get these off, everything was done pretty precision, also, not to mention the one from earlier today, you could see the under the resistor enough to already see where the pad was extended to almost the other pad before anything was done to it.

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.

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).

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).

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.

After you compile the install, you would need to move the executable file (cgminer) to the proper location.

Assuming you did this all from the home directory you would want to do something like:

Granted the way you compiled it, it will only have the drivers for BFL devices, so don't be surprised if nothing else works

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.

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...

The only issue I had with payments was mainly due to MultiBit screwing up, so nothing related to CEX.io/Ghash.io. I've been using the service since 10/25 and receive daily payouts. After they enabled the shareholder feature it's been my favorite, just because I can send % percent of payout to different addresses.

Granted, last I checked, they didn't have any 'safety' on if you %'s totaled up more than 100%, which is very very easily done, especially on a web-form, so I don't know why it wasn't there, but they could have corrected it by now. So, granted if someone really sucked at math and the %'s were greater than 100%, then I could see that screwing up something.

Their website goes down from time-to-time, which so far hasn't effected mining or payouts, if it does effect mining, they reimburse you for it. So, over all pretty sweet deal imo...

Since they implemented an additional server (us1.ghash.io:3333) I use that server and ns1.ghash.io:3334 as a backup, then I have a few other pools as backups to those, but so far, it's never needed to use the backup pools.

Made updates on the Drillbit forums; I've got an image of MinePeon created for Drillbit

Plus I'll supply download links and instructions to those who don't want to image their SD card, but want to get Drillbit devices up and working on MinePeon.

Either I have mis-read this a few times (wouldn't be the first time I've mis-read something) or that was just confusing, since you have to specify stratum+tcp when using GHash.io; Anyhow... if you're using MinePeon, check out my post here... http://minepeon.com/forums/viewtopic.php?f=4&t=491 and it will help ya.

Personally I'm enjoying CEX.io/GHash.io especially since they now have automatic NMC, IXC, DVC merged mining.

I've been just using the NMC to buy GH/s from their hosted trading...

that worked, thanks... could have sworn I tried that last night... meh, all good now though, thanks again.

Ran into my first odd issue since using MultiBit for awhile now...

I have a small incoming transaction, MultiBit has seen said transaction for the past 3 days it's been pending, in MultiBit, Status is 'Seen by 4 peers, Pending/unconfirmed', while at Blockchain 464 confirmations...

http://blockchain.info/tx-index/a314b9d728f17b3c11f2a8c543d68b076cde139711b0857861f18060efc8539d

Considering this is a short drive for me... I'll probably end up coming just to check everything out

Being completely honest, my last BFL Jalapeno I bought for BTC0.9 when it was at $135 USD.

If you wish to be more reasonable in your pricing due to the current exchange, then contact me as I would be interested in the two located in the US.

Location? Curious if shipping within the US.