Block Erupter USB - Overclocking/ hacking ?

[devalo]

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.

How many MH/s do your sticks run?

[ktbken]

i am using 1.2k resistors with no problem and getting 447Mhs

What crystal and heat skin?? Any photo?

Thanks¡

Here you go the osc is the 16Mhz ones linked on here from digikey  and the heatsinks are some gpu  mem ones i had laying around.

[SolidBitShop]

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.

How many MH/s do your sticks run?

One 448Mh/s one 458Mh/s. I dont think I will go for all BEE replacing 16Mhz ... I wonder what to do with the heatsinks I ordered.
Maybe i will stick them to normal Bees

[Roger100]

I wonder how long until someone kills a BE because they don't know about disconnecting bench PSU outputs before turning it on.

Why would a block erupter be killed when being supplied by correct voltage?.... Not sure what you mean here.

[mjgraham]

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

[mjgraham]

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.

[cableiso]

Thanks for the current measurements right on the 1.4V line, they're very helpful  

Are you still using a crystal?  That's probably it.  BE100 is expecting a clock, so basically you're floating the clock in line.  It's still doing something because the 11MHz atmega clock is likely coupling in.

Never mind, misread your post.  It's still a mystery why you're not getting overclock.

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.

[Bluestreak66]

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 noticed it as well but I just chalked it up as a firmware bug because the higher frequency probably was not accounted for in the design. I wouldn't think it would have anything to do with hashing speed, it is interesting nonetheless. I may start hacking mine again in a couple days I won't be satisfied till I get 560Mhs. 

[mjgraham]

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.

[cableiso]

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.  

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.

[mjgraham]

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.

[ktbken]

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.  

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

[cableiso]

Wow, great news that you recognized the symptom.  Sadly I'm on a plane out of town for a week.  Anyone else want to try this suggestion?  Or...  Anyone with a working O/C want to try cgminer and see if it trainwrecks?

[Dunkelheit667]

As far as I can remember, latest cgminer versions using as well fixed timings. Last version with timing adjustment was 3.1.1. You might use the "--icarus-timing short" option with 3.1.1 for automatic adjustment.

Edit: Here is a nice read regarding icarus-timing option -> https://bitcointalk.org/index.php?topic=187549.msg2285149;topicseen#msg2285149

[mjgraham]

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

[Bluestreak66]

Bitminter seems to have no such timing issues, it does tuning before it starts which may explain why I've had such good luck with overclocking.

[mjgraham]

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

[Dunkelheit667]

...
Tried cgminer 3.1.1, didn't detect the BE

With this old version you have to specify a device, this should work:
# cgminer -S /dev/ttyUSB0 --icarus-timing short

However, good to know you got the BE hasing.

[mbbc]

The icarus driver does infact re-calulcate the timings, if the hash rate is below 370 or above 420 MH/s.

[mjgraham]

...
Tried cgminer 3.1.1, didn't detect the BE

With this old version you have to specify a device, this should work:
# cgminer -S /dev/ttyUSB0 --icarus-timing short

However, good to know you got the BE hasing.

I think that would have worked however after you run it with the latest cgminer I found out the /dev/ttyUSB0 goes away

Aug 23 09:03:52 (none) kernel: [   51.436923] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0

and does not come back until you reboot, it stopped bfgminer from working at first until I saw that, of course cgminer will still work so it must look for something else also.