Topic: Blue Fury Support Thread. - page 42. (Read 89606 times)

Win7

To my knowlege DrHaribo hasn't incorporated blue fury support into bitminter yet.

start bfgminer with -D 2>debug.log tacked on the end to produce a verbose log of startup and post it somewhere online like on gist.github if you have an account

what OS?

I am getting them detected on bfgminer and bitminter but they won't initialize. On bitminter they time out.

are you able to see it as a COM port in device manager?

to answer your question. one can only safely draw 510 mA@5V from a USB2.0 socket across a wide variety of powered hubs and host ports. there are a few that allow drawing more (e.g. non conforming hardware or like the DLINK 7 port which has 2 fast charge ports which allow 1.2A@5V)


using the nanofury development thread as a reference and drawing some parallels, the nanofury can only (safely) be clocked with 50 osc6 bits(used to set the ßitfury internal clock), this produced ~1.9 to 2.1 Ghash/second and drew ~485-500 mA@5V from the USB port(depended on each device, which each slightly different due to the hand soldered development boards).

clocked at the upper usable limit of 54 osc6 bits this produced ~2.3 to 2.4 Ghash/second and drew ~500 to 520 mA@5V

to achieve  2.6Ghash/sec running speed, it would need to run at 56 or 57 osc6 bits and would most likely draw significantly more mA@5V than a standard USB2.0 port can provide (Note that a fast charge port like on this Dlink Powered hub can supply double the standard amperage, and in theory should be able to fully power the chip, but at that point the power regulator on the BF1 or nanofury as well as temperature of the chip if there is no fan blowing at them.


I hope this was rather informative and will shed some light on why the BF1s all seem to be slightly underperforming their stated ~2.6Ghash/sec +/-10% ( he's close, we all seem to be getting about 2.2 to 2.3Ghash/sec which is -15.385% off from 2.6Ghash/sec)

-Taugeran


any further questions, feel free to quote this and ask away

good catch, didn't even think about that, just went to grabbing off github.

In "software and updates", "other software"  you have to change "saucy" to "raring" in the ppa.

I am getting this also on Ubuntu 13.10

Received my BF today thanks.

However I've been unable to get the Blue Fury to be recognized on my Windows 8.0 computer using BFGminer 3.2.0 or CGminer 3.2.1.

Yes, I tried installing the drivers and also just using the drivers Zadig installed but no joy yet.

I switched as I was using 12.04... after switching it appears the rep is having some issues (didn't on 12.04) of which won't let you install bfgminer (that way). I checked the server, the server connection is fine, just files aren't there.

Got one working on the Win7 box, cleaned up the zip file for installation. By cleaned up I mean I removed the 'Encrypt these files' option, so you could use the driver properly. Also removed the _MACOSX folder which had windows binaries in it. Not to mention, it's not on MediaFire (which since that is a fresh Win7 install it didn't have flash installed causing Chrome to loop-crash due to trying to forcefully install flash, thanks mediafire... you suck).

If anyone wants the cleaned up zip file: http://256mining.com/downloads/bf1_bfgminer_win7.zip & use the directions on on this thread after downloading.


Back to working on Ubuntu now...

I am using 13

Are you using Ubuntu 13 or 12.04.xx? Just curious.

Yes I run them on VMware fusion on my mac with Ubuntu on the vm. I found that a vim hashes around 200-300mhs so I would definetly recommend if you can setting up a desktop with Ubuntu and using the guide bellow the first post. Yes they where designed to give off as little heat as possible.

Also I would recommend to everyone hit the rst button on the device and wait for the led to turn red before you start the mining software.

I tried on Ubuntu, granted I can't stand what they've done with that distro over the years, however, I first tried a VM using VMWare Fusion, BFGMiner had issues finding the devices when they directly specified (which was awkward) I thought this was an issue due to the VM (however I see a few people that have it working as a VM). The irregular behavior between users and the variance of rates would definitely suggest software issues, at least that's the conclusion I took from it. I am going to attempt to do some more builds on Ubuntu, as I've got one on a windows box, one on my iMac with a Ubuntu VM, one on a linux asus laptop, then my 5 hashing on Raspbian.

Which I am impressed by still not seeing a single hardware error also noticed these barely generate any heat. I think if you took the 5 hashing for the last hour, combined their temps it still wouldn't equal to what one ASIC USB Erupter would in 5 minutes (temperature-wise).

That is a very good point i will push to try and get it released publicly. I do find it weird that my units are hashing away at 2.7+ on Ubuntu and people haven't been able to replicate it so i am sure it isn't a hardware issue. It could be the way the hardware error rate is calculated but we are still trying to figure it out.

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.

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


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.