it's not frozen or stuck... and the question has been answered several times:
https://bitcointalk.org/index.php?topic=137934.msg3115157#msg3115157

That's pretty much it man, unless you want to support blades then I still think you need to install the libmicrohttpd before making bfgminer.... I'm actually setting up bfgminer with blade support on the 2nd rPi now instead of having the blades point to the other pi (which has all the erupters on it).

Not sure what to tell ya man, the only difference between the setup would be switching cgminer to bfgminer...

The odder part about it is the fact when comm errors were being generated by say adding in another hub, bfg had no issues with it. I originally thought a few hubs I bought had some strange circuitry going on, as while being 5v 3.5a and 5v 4a, *should have* had enough power yet comm errors would start showing after plugging 4 erupters on those hubs w/cgminer.

I wish I had some log files for you, but I couldn't find anything about the crashes within the system logs on the rPi, it's kind of like when it crashed it just completely halted, since the rPi has no RTC, say the crash happened at 23:39, well, looking at the logs it would basically skip 23:39 every where and see the last written as 23:42 (after reboot) and before that at like 23:38... but nothing before that (was expecting to see a backdated log entry due to the lack of RTC).

Negative, 3.4.1 was so far the most stable for me, when upgraded to 3.4.2 problems started, then 3.4.3 problems became worse... still running BFGMiner with not a single issue.

is it trying to load index.php after the login? if so point it to index.html (or the other way around, I can't remember atm)

I'm assuming it groups all the blades together as one 'device' under BFGMiner?
I just pointed 4 blades at it, only seeing SGW 0  - but it's over 30Gh/s atm (and rising).

I'm assuming in the blade config point it to the system with BFGMiner running?

Edit: nvm, found it in the readme

By the way, if anyone has ASIC blades on their network, since you really don't need the rPi to control them unless you're doing a stratum proxy. I've made a php add-on for MinePeon to scrub the stats of each blade and display it. Working on having it bring it into the main area with the other devices at the moment.

Switched to BFGMiner...

haven't had any issues, wireless usb now works, bluetooth usb now works, avg cpu load is <=20% versus about 100-140% average with CGMiner.

Guess the miner makes the difference after all...

Well, I could only get the D-Link H7 to support 5 Erupters total...

As for the crashing though, after upgrading to CGMiner 3.4.2, I was crashing daily with about 15 erupters, upgraded to CGMiner 3.4.3 with 24 total erupters (4x Rosewill RHB-500, one used as root, the others from the root, each hub has 8x erupters) and it would crash about every hour on CGMiner 3.4.3. The other day I switched MinePeon to use BFGMiner, so far my up time is 1day 23hr 19min (as of this posting) without a single restart or issue.

I also have a test rig on a cheap'ish usb hub (that has enough power to run 6), it never would run more than 4 with any version of CGMiner... it's been running 6 after switching to BFGMiner for about the same amount of up time as above. No issues, no problems...

And another odd factor in this, when I did get CGMiner 3.4.3 to run on my 24x setup, I was seeing around 3-5% hardware errors, which I couldn't explain... after switching to BFGMiner, I'm seeing 0.73% since it's been running...

Ended up adding 4 more erupters (total 24) with the rPi on MinePeon, CGMiner 3.4.3 would restart about every 3-6hrs, couldn't find any helpful information in system logs

Changed it to use BFGMiner... haven't had a single issue since (now about 10hours in).

Also on my test rPi setup, I am using a hub that previously wouldn't run more than 4 (but has enough power for 6+), CGMiner would cause comm errors on more than 4. Change it to BFGMiner I now have 6 erupters on that setup running fine, for the last 8 hours.

That's a pretty big difference... I really didn't think the two miners would be that different in nature, however shows I'm wrong. I originally thought I had power issues or the hubs just wouldn't support that many, now I'm starting to wonder if the previous hubs were fine, as I never tried them under BFGMiner, only CGMiner...

The only one I could recommend is the Rosewill RHB-500, check out the post I made here: http://minepeon.com/forums/viewtopic.php?f=16&t=121

Interested in grabbing a some...

But (and I'm sure this is answered somewhere in this thread, just have a headache and don't feel like searching atm) not sure  what the estimated price range will be for the remainder after the 0.40BTC initial. Will try to keep an eye on this thread and read more tomorrow.

Sounds like you might have some power issues there, both my rPi's will recognize all USB miners within 5-10 seconds of cgminer starting (if even that long). Which includes the rPi running 20 erupters. The only time I noticed 'buffering' messages of delayed USB detection is when I was using different hubs and hitting power limitations of the hub.

I will have to agree with the above statements, the website redirect is not assuring at all. Perhaps you could provide more information about the company?

Also, I may be interested, but the payment would have to be escrowed & since there's questionable credibility on your side, I wouldn't be willing to pay for the escrow.

Though, very interesting product, I hope it's legit. As for the product itself, you stated doesn't need a control unit, however it's not being connected to a network from the card itself, so I imagine that you would need a computer (laptop, pc, or raspberry pi) it looks like you would still need a device to control it, correct?


Edit: A little bit of googling brought me to:
https://gust.com/c/seolvit

Which then brought me to:
http://seolvit.wix.com/hexa

Neither of which is very convincing unfortunately.

Yes, you need to sign up for an appKey from MobileMinerApp's website, http://www.mobileminerapp.com/

As far as over-clocking through the app, I'm not even sure that's possible through the app, nwoolls is the author of MobleMinerApp.


I'm actually going to take the download for the MMA integration offline, as I believe the people who wanted it, have it and there are quite a few changes that have already been made. So if you **really** want it, feel free to PM me, otherwise I'd wait for it to get released officially in MinePeon.

I made it so, if you attempt to download the file, you will just download an empty zip file.

iOS skills are all nwoolls, it's his app, I'm just providing the integration (in PHP) for his app on MinePeon. 

Not sure if this is your issue, but the only time I've seen hw errors like that was when the erupters were underpowered, but not causing comm errors. (I did a lot of playing around with hub configurations and 6 different hub models/brands.) Mathematically the configuration that caused my errors like that should have supported the amount of erupters on it, but it couldn't.

Try taking off 1 erupter at a time, rebooting cgminer and watch it. It's worth trying.

Also side note, I just did a full arch linux update with pacman and now everything is waaay more stable, including hw errors (not sure how/why) I was averaging 3-5% on the 20 erupter setup. After a full update (via: pacman) I'm sitting <1%

I didn't really pay attention to the packages that got updated, so I can't speculate as to why this is, seems to be both rPi's as well...

(Also on the test rPi I've got going I decided to install networkmanager and disable wicd finally enabled me to connect to wireless without any issues, probably going to install this on the main rPi tomorrow, going to let the test run for a bit.)

So far I can't get 3.4.3 to run longer than an hour on Raspbian before locking up seems the same on Pidora
Putting it back to 3.4.2, so far still running. So I'm not sure about that...

ahh... year the rPi is really picky about wifi dongles (see info http://elinux.org/RPi_USB_Wi-Fi_Adapters if you haven't already), I've been just buying the cheap ones that are known to have a 90%+ compatibility.