No joy.  Here it is at 12.8V:

Total MHS:   00000
Received:   0000000000
Accepted:   0000000000
Per Minute:   000.00
Efficiency:   000.00%
Up Time:   0d,00h,00m,51s

Current Server: 192.168.1.4:8332
Chip: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--------------------

I switch the server:

Total MHS:   00000
Received:   0000000000
Accepted:   0000000000
Per Minute:   000.00
Efficiency:   000.00%
Up Time:   0d,00h,02m,53s

Current Server: :19501
Chip: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I Switch the server again:

Total MHS:   00000
Received:   0000000000
Accepted:   0000000000
Per Minute:   000.00
Efficiency:   000.00%
Up Time:   0d,00h,03m,26s

Current Server: 192.168.1.4:8332
Chip: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I've seen others report the 19501 previously.

Okay, will up the voltage to 12.7V.  I had been running fine on 11.8V.  Would make less sense to raise the voltage given the board failed because we had an exceptionally warm winter's day here in Georgia and the room went up to 76°F after weeks at low 60°'s and that even with switching supplies/buck converters, the greater the voltage difference the more power lost at the supply.  But I will give it a try.   

I'm mourning a dead Blade today, my one and only.  It's come up with all xxxxxxxxxxxxxxxx for the ASICs.  We had a warm December day in Georgia, 71.6°F out and 76.0°F in the room.

I couldn't bring myself to buy a Neptune.  Just too much for me.  That the Neptunes aren't sold out yet tempts me right now.  But no.  Ah, the falling BTC harvest, now accelerated losing 10GH/s.  It's like aging.

For this reason I think the plugs having both a jumper and a power resistor to the 3v line are a very good bet.  I know you followed instructions, but did you put in the jumper then fire up the supply and check that the voltage was there on the 12V, then shut down the supply, plug the power supply into the Jupiter, then switch on the supply?

If my theory that the current ramp, preventing current surge producing a voltage spike sufficient to blow the caps, the current ramp to ramp up current on the 12V line is actually controlled by a voltage ramp of 0 to 1V produced on the 3.3V line (because the 3.3V will be up to regulated voltage before the 5V or 12V) then putting in the jumper, turning on the supply to check if the jumper is correct and voltage being supplied, then shut down before plugging into Jupiter, since the supply expects that it is plugged into a motherboard having a load on the 3.3V line, it expects that when the supply is turned off the 3.3V line filter capacitors will drain out thru the motherboard.  That can't happen without a motherboard or a resistor to ground from the 3.3V line as well as the jumper.  

So, if  you check the jumper was correctly placed by looking for 12V on the 12V line, then shut down, plugged the supply into the Jupiter, and turned it on, the supply 3.3V line never drained and still had full voltage on its filter caps and the timed ramp voltage that controlled the ramp for the 12v current had remained at max, as if already having timed out its ramp, and BANG, instant max current.

Or IC70 bad.

I'm getting 1.04v and at best it was hashing at something under 12MH/s. (Edit: I misspoke, it was getting just under 11GH/s.)

R121, across - 2.31k, IC102 side of R121 to 12V neg into board 2.31k, far side of R121 to neg 0k

R120, across - 5.64k, IC102 side of R120 to neg into board same as above as that side of the resistor pair is common; this far side of R120 is interesting in that reading resistance to neg into the board in one polarity I get 5.91k, reverse polarity I get 9.77k.

I have the far side of R120 to the in side of C127 an the far side of C127 to ground.  Check for a shorted C127.

Meanwhile I'm not making any progress clearing my ASICs xxxxxxxxxxxxxxxxxxxxxxx problem.  I think perhaps the PIC may have gotten its program scrambled when I blew it off with compressed air because not only are the ASICs showing inoperable but the board can't Switch Servers, coming up with a Current Server: :19501

2.31k R121
7.41k R120

Inexpensive meter.

Have any luck getting your 3.3v?

I have a Chip:xxxxxxxxxxxxxxxxxxxxxxx problem.

Interesting.  When I click Switch Server, I get this: Current Server: :19501

Total MHS:   00000
Received:   0000000000
Accepted:   0000000000
Per Minute:   000.00
Efficiency:   000.00%
Up Time:   0d,00h,04m,24s

Current Server: :19501
Chip: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi Canary,

My Blade had been running 4 days shy of three months then started acting up.

It was only giving me double digits "accepted" as viewed on the proxy for a few seconds after powering up before hashrate dropped to zero and it started rebooting.  I changed power supplies.  I've reconfigured the routing a number of times and my other miners are running okay so the router shouldn't be the problem.

Then the ASIC chip display changed from all "O"'s to all "x"'s.  I've reset to factory defaults repeatedly, the new config showing 192.168.1.2,btcguild.com, but still all "'x"'s.  Reconfiguring to my proxy's I still see no indication of requesting work.  The web interface works fine.

I note that soon after getting the Blade 3 months ago I soldered a tantalum capacitor between the + & - pins at the power plug.  That is fine.

I measure 11.8vdc in and 1.04volts on the copper pads mid board.

I would almost guess it's the PIC acting  up.

Any suggestions?

Thanks.

soy

Two supplies in parallel are no help.  Same string of x's.

I feel bad.  This Blade had been running for 4 days shy of 3 months.

Now the problem is that no ASICs are working.

I have 1.something volts across the copper pads near the coils.  So I assume the ASICs are getting  voltage.  There isn't a fuse on the 1 volt supply as well I suppose.

There is no indication on the proxys that any communication to them is taking place however the configuration web page is up.  I did manage a factory reset and accessed the webpage at 192.168.1.254:8000 and did change the configuration to have the proxy addresses.

Refreshing the configuration tells me the miner has been up 5 minutes, zero hashing, no asics, all x's.

How long is one suppose to reset these for?

slush


Okay, now it's different.  Cleaned the board, started it up, a quick 40 or so getworks and 28 accepted's now it says no aSICs at all, all x's

Welp, a replacement power supply was in my post office box today.  Just got back.  Swapped supplies.  Fired up.  No change.  Shut it down,   Took a high speed 4 port switch I have half way across the room for my WDTV, put that to the gateway router with a short cat5 jumper, ran the Blade to the newly placed switch, watched the proxy, it quickly ran off 40 get works and just as quickly came back with 28 accepted, then it stopped.  Sitting dead.  Asks for new work, I look at the configuration page and it has rebooted.


ASICs all "O".

When I reset to factory defaults and it didn't, I had the cat5 out, power off, jumper to the ground/factory_reset pins, fired up, watched the flashing LED, same one as the regular reset, shut down, took the switch off the reset, rebooted and it still had the previous IP address which tells me it didn't reset.  

12.1VDC.

My Blade stopped working.  It's to stratum-mining-proxys.  On either one the same thing happens.  I fire up the Blade, it requests work 8 or 10 times and then nothing.  This last time it asked 8x, then ~14x then submitted, got a single accepted back, then after 8 more getworks, another submitted, 2 more getworks, then a single accepted.  Now four New jobs....  Diff1.

It appears to be resetting.

I took off the heatsink, added some compound to the away side of the sheet, smoothed, reassembled.

I tried a factory reset with the cat5 cable removed.  Saw the flashing of the single LED multiple times which then stopped.  Shut it down.  Put the jumper back on the center pin.  Plugged in the cat5, restarted, then couldn't find the device on 192.168.1.254 but did find it on the earlier IP address it had been assigned before the "reset".

Total MHS:   00182
Received:   0000000008
Accepted:   0000000001
Per Minute:   001.17
Efficiency:   012.50%
Up Time:   0d,00h,00m,51s

It shows up 51 seconds but it's been up 10 minutes.

There are two 120mm fans hitting the heatsink.

So, it would seem to be a resetting issue.  May I ask the most common cause of a resetting issue?  Power supply or routing?

Slush hashrate up and return on blocks has dropped.  I'd say they're out and mining.

Looks like the pool gods heard you.  Slow block turnover on Slush.

In Bitcoin-QT, is it possible to send BTC to an address from coins in the wallet that arrived to one address but not take coins that arrived to other addresses within Bitcoin-QT?  

I've had coins arriving to one address for some time.  I've started a new address for receiving the bitcoin.

Right now if I want to comply with a last in first out spending policy it would look like I need to establish a new Bitcoin-QT instance on a machine, send mined bitcoins to that new instance, and spend when I've accumulated the amount of bitcoin I wish.   

Or remove the wallet.dat, put that in cold storage, restart Bitcoin-QT, rebuild the blockchain and accept coins to it.


Any other way to do this?

Thanks.

$3000 btc by February perhaps?