This is the same behaviour you get in bfgminer if you use the "-S erupter:all" cmd line. In bfgminer if you revert to using "-S all" the issue goes away.. I suspect that by using the "erupter:all" setting it is using the wrong timings when running erupters that are over clocked. The "-S all" setting seems to do more auto calibration of the connection. I do not know if this system is used in cgminer but suggest if you are having issues try bfgminer 3.1.4 instead
I built bfgminer 3.1.4 on gentoo and you were right "-S all" made this with a 17 MHz clk. a small amount over but I'll run a longer test. When I ran it I saw this [2013-08-24 09:29:54] ICA 0: Seems too fast to be an Icarus; calibrating with short timing when I killed it off. [2013-08-24 09:29:19] Runtime: 0 hrs : 16 mins : 9 secs [2013-08-24 09:29:19] Average hashrate: 497.2 Megahash/s So good job. who knows how much time I may have wasted working on this when it was working, I guess this means all my theories were wrong and the problem was on the PC. But after reading some of the code I guess they only poll the device when they know it has used all the hashes up.. nice
|
|
|
I'll give both those things a try, sadly the box is a remote gentoo box on a raspberry pi so building things takes a little time.
Tried cgminer 3.1.1, didn't detect the BE
|
|
|
What's the chance that these are firmware limited in later builds? Just trying to explain how some people are changing crystals but not getting overclock. Are they changing the wrong crystal? My 16MHz oscs are on the way, hope to mod this week. I continue to suspect the firmware. I modded a device to 16MHz today, and got the same behavior as other failed overclockers. I'll describe it as follows: Startup fine, recognition fine. Then green LED goes out for a bit as cgminer takes over, and gives fast blinks on first few accepts. But as soon as the reported hash rate starts ramping up, it trainwrecks: you get a long-ish blink and hash rate starts over from 0. It really looks like if the hash is returned quicker than the micro expects, it flushes everything (I'm assuming it's pipelined, to get one hash per clock) and starts over. Valid accepts are certainly generated when it's running, just the device keeps resetting after a bit. Hash rate definitely exceeded 335, but I'd say I never saw higher than about 380Mhz peak with a 16.000M osc before it resets. I tried several feedback resistors (1.2k, 1.33k, 1.4k) and the action was the same except for increased supply current. Scope tells me the clock is good, the core supply is good and chip is definitely not in overcurrent (better inductor + external 5V). Heat was not an issue: With a big slab heatsink, chip temp was lower than running stock, and way lower than running stock with no forced air. So this sounds like one of a couple of things. 1) It's an honest bug, due to a slowly clocked micro (clock limited to 12MHz using 3.3v supply, check the d/s). Starts reading too late, gets the wrong answer and bails out. Or gets totally munged and a watchdog eventually kicks it. If there is no interrupt or anything, and it's really pipelining up to 1 clock per hash, it could be a very delicate balancing act to push and pull data quick enough to feed the asic without trainwrecking. Anyone who knows a little more nuts and bolts about this chip, please chime in. It could also be 2) It's a new "feature" to best monetize dollars per hash rate. My devices are not the first build, so maybe firmware was updated in response to all the overclocking interest. It would probably be quite easy: Check a timer, and if the asic is giving results too fast - user must be cheating. Not that this is bad, or dishonest - it's asicminer's device, and you're paying your $50 for 335MH/s. No more, no less. But for us, it represents a limitation in the hardware we bought, and we have the desire to try to improve it. I have not slurped the serial comms with a logic analyzer, but that's the next logical step in trying to figure out what's causing the resets. Or fetching the firmware, but chances are it's locked. This is true, we can squeak a small amount more out, I have noticed the same behavior, my plan was to speed up the MCU and see, however that changes the baud rate to the PC, looking at the data sheet for the CP2102 they are a few non standard baud rates 128000 and 153600 which would be going from the 11.0592 MHz to 12.288 MHz and 14.7456 MHz , I was attempting to try this but the MCU uses a crystal not an oscillator so I could not generate a signal that seem to work reliably, I am guessing the firmware is set for a crystal so when I fed in an oscillator it didn't like it to much. Strange thing it seemed to work for a while then I thought I lost it but after I put the stock crystal back in it went back to work. If this had worked my next problem was getting cgminer to use a different baud rate which looks like it could be recompiled with the new setting, but alas I didn't get that far.
|
|
|
Well I left it running at 17 Mhz, getting an average of 390 MH/s, it could be a power issue but I don't know, I feel that there is something else going on but w/o access to the MCU program it will be hard to tell. For some reason I am unable to leave well enough alone, my next plan is to build a schematic of the board and hook a bus capture on the MCU <-> BE100, I want to believe it is as simple as converting a serial stream to a parallel one and back. If it is simple enough , sometimes it turns out that way, then the BE100 could be interfaced more directly, thinking about it the data bus can not be to fast the MCU is only @11Mhz I would not image it could go to fast, although I don't have any atmel experience , it the MCU was a silabs then maybe. I find it kind of curious that lsusb reports this
Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
The myAVR is interesting to me, I know some of the Ti MCUs can be programmed though the serial port.
|
|
|
After a little more tinkering I was wondering, the ASIC is a hard wired device so changing the clock should have a direct effect on the output, I wondered if there is a timing issue between the BE100 and the MCU so I though I would change the speed of the MCU, of course it turns out it did not use an oscillator but a crystal so that made it a little harder, it really does not tolerate much speed increase due to changing the serial baud rate on the output side but it turned out to be to finicky and I don't guess there is an easy to change what baud rate the program communicates at (cgminer(re-compile I guess)), all the things I tried did't work at all so I but the crystal back on and went on. After some testing I wound up with this. This is using 1.4v at the board, current is BE100 not 5V USB. This is a 10 min average. Clock MHz Actual MH/s(Avg.) Expected MH/s Current 12 328 336 2.4A 13 346 364 14 363 392 2.73A 15 359 420 2.87A 16 376 448 3.02A 17 390 476 3.12A 18 381 504 3.20A 19 would not run 532 3.30A
Something I did notice, I put a logic analyzer on the end connections and at 12 MHz don't see much, but 12+ I see the pin that has been labeled in an early photo to invert for as long as the LED is on. I am glad it has worked for a lot of people, I am just not seeing what I wanted to.
|
|
|
I wonder how long until someone kills a BE because they don't know about disconnecting bench PSU outputs before turning it on.
True, but to me as long as people realize that what they are doing can kill one and not act surprised when they smoke it. I have noticed it also. (the green led thingy) but, when I addd some cooling ... it does not longer happens. So I think maybe the BE100 is overheating? Also on my 108BEE's farm it happens from time to time. But it is a very short strong bleep.
Right now at 16Mhz 458 448 Mhz one on 1.4V the other on 1.3, Can tell right now wich one is which after 13 hours... it seems that its working but replace the crystal is darn hard.
Well I am not sure, I did mount it on a quite large heatsink and it looks to run about 107F normally, before it was around 135F with the stock piece of metal. I have gotten it going at 16MHz, with 1.43V @ 2.91A at the board, before made a rookie error , forgot to account for voltage drop in the cables, this supply does not have a remote sense so have to adjust it above what I want which is OK when it is running but when it goes idle the voltage of course jumps up. After a couple of hours the average is 378 MH/s which at 16 MHz should be closer to 448 MH/s. Yes replacing the parts is a little hard, unless you have a hot air station which helps a lot. Off to experiment more...
|
|
|
Hi everyone been following this thread quite a lot, so I decided to get one of these devices and of course modify it. I decided to run the clock from a Tektronix function generator, all works as expected at 12 MHz. Although I have not modified the power supply yet I notice at any rate about 12 MHz the green led starts staying on longer than the short blip. If I go to 13 MHz it stays on a little longer and at 14 longer still. While it is hashing it seem to be faster but the delay after it gets done acts like it limits it back to the stock freq. I don't know this for sure yet. I also attempted to remove the regulator IC and feed power directly form the lab supply, while the voltage was correct I could not get it to work at all, green LED went off but cgminer said no devices found, put the IC back in and went back to work, I just pulled the chip and fed where the inductor was. It did draw 1.4A at 1.05V not sure why it didn't work unless there is some kind of power sequence thing. I hope to play with it more tomorrow so we'll see if I make any head way.
|
|
|
I have to say there is a lot of information on here. I have been messing around with the open FPGA core and have built it for a few different Altera dev. Boards with some success. Recently I have been interested in modifying a block erupter, I know changing oscillators and power requirements, what I was going to try is to replace the core psu with the nice bench supply I have and running the clock form the signal generator. I plan to use a TEC to maintain it at a decent temperature. I know there is a pretty good thread on both subjects. Hope to be able to contribute some.
|
|
|
|