No problem. Hopefully all of these posts will help other home miners and small miners continue to keep going (which is my personal goal thing)

Interesting. Did you power down the die by dropping the DC-DC's to zero, or did you use a command in the KNC chipset? I don't see anything big enough on the board to be a 12 volt interrupt.

Interesting. That explains why when I fired up a 2.00 code set on my Gen 1 Rpi it kept rebooting. It's something in /etc/init.d, I stopped it by moving all the files in there into a "fubar" subdirectory. Whatever works.

Now working on compiling the code to run on a straight beaglebone+neptune. Should work....

Hm. Weird. Now the Titan chips have a lot more junk on them than the Neptunes (Titans have memory, processors, stuff while Neptunes are barrel rollers all the way) so I wonder if overheating would damage those sorts of things instead of just knocking down some hashing engines.

That said, how does the cube turn off? Does the fan stop and everything, or does it just restart the power supplies? Haven't seen that on a Neptune yet (is this Tarkin's software build)?

What do you mean by "unstable"? What does it do/not do? Has it ever been hot clocked, run hard, filled with hay and insects (oh ask, do ask :-)?

C

Hm. Looks like the waas command is similar, I wonder if it can support a titan:

const char *get_str_from_board_type(brd_type_t brd_type)
{
        switch (brd_type) {
        case ASIC_BOARD_TITAN:
                return brdtypestr_TITAN_ERICSSON;
        case ASIC_BOARD_NEPTUNE:
                return brdtypestr_NEPTUNE_ERICSSON;
        case ASIC_BOARD_JUPITER_REVB:
                return brdtypestr_JUPITER_REVB;
        case ASIC_BOARD_JUPITER_ERICSSON:
                return brdtypestr_JUPITER_ERICSSON;
        case ASIC_BOARD_JUPITER_REVA:
                return brdtypestr_JUPITER_REVA;
        default:
                return "";
        }
}

While waiting for the parts (got a number of boards here, so I overnighted some more chips) I figured I would think about the whole Titan/Neptune/Pi/BeagleBone thing and I'm wondering if I can control a Titan with a BB board. Maybe, maybe not.

What I do have is a first generation Rpi board which I loaded the 2.0 firmware on. Oddly enough it boots, but seems to shut itself down and reboot after a few minutes. My guess is it's got a daemon trying to find something on the board and throwing a reboot when not found. First step is to find that daemon and kill it, then look at all of the scripts.

Edit: Heh. I'm good.

Now for the fun: This thing seems to have all the code for how to build the libs and a very nice file called
-rw-rw-r--. 1 pi pi 341359 Feb 27  2015 spimux.rbf
-rw-rw-r--. 1 pi pi 352743 Feb 27  2015 spimux-titan.rbf

Ok, so we have the spimux-titan file. And a bunch of goodies. I think I'm going to try and port this mess.

At this point I don't know, haven't seen that in a Neptune and not enough Titan data points. But a question: How much performance would you gain vs. the downtime?

Just got the first Titan controller boards in for repair, this is the status:

Board 1: Shorted cap took out the high side FET in the TPS. Will replace chip.
Board 2: Different: Powering the board causes the TPS chip to get *hot* to the touch. Trying to read status gets me the following:

TPS65217 error: Bad ID 0xFFFFFFFF
TPS65217 TEST failure

I think the whole chip is shot. Will replace chip.

Next up: Wait for parts delivery.

Searing:

I'm pretty positive a Rpi plus bridge board can work on either a Neptune or Jupiter (late) board. There are several people running the earlier jupiter boards (4 connectors instead of 6, dual LED thingie, etc) with Titans for it to be some sort of really magical thing on the actual FPGA equipped board. KNC just isn't that "make changes to something that sort of works"...

So the fun part is "what do you *NEED* in a bridge board?" If we take out fluff like "light status LEDs" and "control the on-board fan plug" and frippery like that you're down to the essentials. Which might just be power for the board (5v) and spi signal to the fpga and the TPS chip. Maybe serial lines to program the FPGA, not sure about that.

If anyone wants to pull their bridgeboard and take detailed pics and post them I might be able to figure most of it out.

I have a gen 1 Rpi sitting here that I used to use as a bitcoin controller, I'd be happy to see if it reflashes with the KNC code set. If so I would then be fine with building a helliacious set of jumpers to see if I can get the fpga loaded and TPS powered up.....

In the meantime working on a few things with a couple of systems in transit. One is a Neptune board, fails TPS powerup, pulled bad cap and the TPS chip, will put a new one on as soon as the next shipment arrives. It also has a bad beagle-bone (failed from another board) but to be honest beagle-bones are $50 bucks tops and not worth fixing. Odd though that this one fires up the 3.3v supply on the board, so it's not a power issue and seems to pull 120ma so something is there. Just will not boot or run any of the 4 status lights.

Damn that sucks. My latency on my node here is around 2s with an interesting spike to 20s at about 1800 GMT. It slowly creeped up from 1s to 2s.

I think honestly the solution is to run your bitcoind behind a firewall and allow your p2pool node to talk to that. Then the asshats can't fuck with you. But that means you're no longer running a public node, so get another 2tb disk and run a second node externally as a service to the bitcoin community.

The fact that the DC-DC converters are showing voltage means they are probably working. If they were shorted you would see 0 volts on that die. My guess is nothing is pulling power from those particular ones, that's why they are cold.

Ergo, chip problem. You can try a low frequency on those dies, see if they respond to that.

Try reflowing the chips. The problem is the chip overheated underneath and melted the solder so that the fpga can't communicate with the chip's hashing engines. Question: Is there any burned marks on the bottom of the circuit board?

Just updated the FAQ post (post 2) with more stuff on identifying what's wrong and fixing the beaglebones. Back to work...

Another control board, this one is a bit of a doozey. First, the beaglebone does not appear to be booting. The power light comes on, but the 4 LEDs on the left side do not do their little light show. Second I can see that the TPS chip is out of action as well, probably another short in the voltage lines.

So it's off to the bench after lunch to take a look into both of the issues. I'd like to get the BB fixed first if I can, then take a look at the rest of the board.

So go out and buy a small $40 IR temp sensor with a laser thingie. I've been having a ball with KNC Neptune/Titan boards, the hashing chips get so hot when people overclock they melt the solder underneath enough so when they are bumped you get shorts. Chip temp <> board temp...

No wonder there are scorch marks under the chips.

Is anyone doing this yet?

Hm. Well, I'm running these test Neptunes at 600gh and here are the numbers:

Temp : 52.0 °C


Power : 263.651 W

DC/DC   Voltage (V)   Current (A)   Power (W)   Temperature (°C)
0   0.7782   34.8125   27.091   75.625
1   0.7831   34.6250   27.115   82.625
2   0.7760   44.2500   34.338   85.000
3   0.7777   44.5000   34.608   86.625
4   0.7821   45.6875   35.732   81.750
5   0.7809   45.0000   35.141   76.000
6   0.7765   44.6875   34.700   80.625
7   0.7794   44.8125   34.927   85.000

That's with 350mhz on the first die, 450mhz on the other three. A tad bit hot.

On the water cooled 3/4 unit, 400gh

Temp : 43.5 °C

Power : 170.360 W

DC/DC   Voltage (V)   Current (A)   Power (W)   Temperature (°C)
0   0.7825   33.8125   26.458   85.125
1   0.7834   33.5625   26.293   83.625
4   0.7783   38.7500   30.159   75.250
5   0.7786   38.8125   30.219   80.875
6   0.7804   36.6250   28.582   83.000
7   0.7822   36.6250   28.648   86.250

Running 350,400,375mhz on the three remaining dies.

Now checking the actual temps with the laser IR tool I see the temps on the top of the high side FETs are 77c. To me that's kinda hot, and about as high as I would want to run them. The 12v filter caps are right there, and the question then comes "what is the max operating temps of the caps?

Cheap crap caps are 85c max. Good caps are 105c, and the best ones will take 125c. What do you think KNC went with?

Back to the 40a thing my quess is if you trim then down to 40a draws you will probably find the temps drop a lot. Once you start going above 40a, that's when internal temps start to climb. I would say keep the temps below 85c and you will be ok. Less if you're a Titan since the extra hashing speed you gain is probably not worth the risk of fireballing your unit.

That chip's might have a weird die. Clock it down a bit, clock the others up a bit. Also note that the position of the power supply on the board with respect to the fan can make a difference. Or the dc-dc is covered in dust, dirt, animal droppings (it's happened...) and is not able to dissipate its' heat as well as the others.

Edit: Oh you're worried about the CHIP temp. Didn't see that. Hm. Maybe the heat sink has come a bit loose? Fan obstructed by dust, dirt, animal stuff? Thermal compound gone bad? If it's hotter, don't move the cube while it is runnning, let it cool or you could smear the solder.

But my guess would be some heat dissipation issues in the chip top to heatsink world.

I'll watch the thread for a bit. I've got the tools and probably some skills, but it's a balance: If Bitmain is doing RMAs then of course the best option is to go with them.

However if anyone has a fireballed S7 or one that is not rma-able due to "dirt" or something like that they want to send to me to research on, drop me a PM.

As I say on my Neptune/Titan threads, what's the worst that can happen? :-)

Been a productive week, turns out the 600gh Neptune I fixed continues to hash at 600gh, the controller boards continue to work fine, and all the solder is off the wrecked neptune board.

I did promise a picture of the board showing the shorts, in this picture look for the little bridges in the middle of the board, typically 3 balls wide, right where the burned part is. That is the proof that the boards are overheating under the chips, melting the solder, and shorting the power lines to the spi bus which is why the board goes into the drink.



Now to find a reballing stencil that will fit this thing. It's too big for the normal 90*90mm reflow table, so I will have to either cobble together a custom stencil or do it in quarters. That will be a *lot* of fun... Fortunately there is a lot of redundancy in the balls on this chip, so missing one or two won't sink the whole project. For the record it's .6mm balls, 1.0mm spacing.

Next up, Titan work!

Hm. Are s7's worth my time to learn to fix for other people?

Most of the miner problems seem to be the same things: Heat and power distribution. Thoughts?