It's also possible they are having problems with the chip. Would not be the first time, I've noticed that designing a chip is simple, powering it is another matter altogether....

As to how I would improve them:

1) Optoisolators on all signal inputs: Protects the cube against static electricity, plugs loose, ground loops, general fuckage, plugging in backwards, etc.

2) Drivers from the FPGA. You should never power signal lines directly off the output of a small FPGA. Drivers are small, cheap, and save the FPGA.

3) Two power plugs, opposite sides of the cube. Because why not?

4) Power the cube's hotel circuits and SPI lines from an on-board dc-dc charge pump. Simple as hell and you're not powering the thing from a little TPS cube on the controller. Did I mention no more ground faults?

5) Put in 0 ohm jumpers to allow you to isolate a bad die. Then you can build, test, and sell cubes with 75%, 50% dies for whatever. Looking at a dremel to cut signal lines is no way to go through life son....

Likewise how much power does a S9 use compared to a Titan?

Why the hell are Titans so good? Did everyone else just quit or did KNC pull something out of the pits of hell itself?

(Actually with a few small changes they would break a lot less. But that would have cost about $10 more a miner, can't have that....)

Thanks....

:-)

Seriously, it would be nice if they would release the design stuff into the public domain. There are a few mysteries on that board I am not going to solve without a real parts list or something.

Actually this brings up a funny question: What happens to warranty support?

Factory maybe? Didn't seem too bad actually, as I said I'll try pulling the low order chips this week and see what's up. It is different though.

In the meantime got TXSteve's board in, very different failure.

When you plug it into the controller board the board boots and runs, but can't communicate with any of the cubes on the control spi connection. The cube doesn't short out the FPGA, what I am wondering is if the problem is in the LM75 or EEProm chips. Reason being with power off the SPIs to the power supplies are off (so that isn't it) and the only thing alive is the LM75 and Eeprom.

I'll try pulling those chips this week and see if it still shorts out the SPI bus. Weird.

Hm. Try removing the LCD display and see what happens. Maybe it's shorting out the SPI bus.

If not the controller board probably has a shot fpga. Can KNC repair it under warranty? Edit: Yes, I think shorted FPGA if nothing else is connected and it reboots without the LCD.

C

Ok. Questions:

1) Are you running the latest 2.00 Titan code from KNC? If not run it.
2) What does the light on the controller board do? It should flash white for a few seconds, then go off, then turn on green if you are running 2.00 code. If it flashes white quickly, then turns off then flashes white again the controller has a shorted FPGA. If no lights at all the FPGA and TMS chips may be bad.

The gold standard test is to ssh into the titan controller with username pi password whatevertheadminpasswordis, then type

io-pwr init

And watch the light. If it comes on green and there are no errors in your ssh session you're good. If you get errors, post them.

C

If it's over a k of resistance that means you send the board in :-) Interesting. Tell me about the whole process. Like:

You wake up
You eat cereal for breakfast, it takes like wood shavings
You plug the bad cube into a power supply
You turn on the supply
You turn off the supply
You plug it into the Titan controller
You turn on the supply
You realize you forgot to plug the titan controller into the power supply
You feel stupid
You get therapy
You feel better....

That sort of thing.

It could work, can you tell if the pin 4,6 on the 10 pin connectors are shorted to ground?

C

I could, however I can guess what's wrong with it: When the chips get too hot from running too fast with a bad heatsink connection the solder under the dies inside the chips starts to heat up. Reason is the heat starts going down INTO the board instead of up and out via the tower heatsink.

As a result (and since the connection to the board is through a interconnecting junction at the bottom of the chip) that solder gets hot. When it gets hot enough to melt it extrudes solder balls around the die and kills the die. Sometimes it just takes out the .8v supply lines (most of the bga pins are this) however sometimes it hits either the die control lines or (way worse) the die power lines to the hotel circuits on the die.

That line is powered by the FPGA board's TMS chip because KNC was (efficient, cheap, something) and didn't put in a small dc-dc charge pump. However since it is shared by all dies a short will basically kill the cube and short the line to all of the other cubes through the 10 pin. Result=sucks.

The other way this blows up is if the cube has a bad power plug from running too hard with only one supply. If the gound lifts before the +12, the cube will try to draw power from the ground line on the 10 pin, then will try to draw ground *through* the signal lines and the hotel power supply (because 1.8v is closer to ground than 12v is). This blows out the chip, the controller (sometimes) and makes a large mess.

C

I wonder why this happens. Note I unplugged both the cube and the display so that is not it. There's something going on in the FPGA.

Maybe it's the lack of driver buffers, maybe the chips just suck. Regardless it's odd.

I'll order 4 more FPGAs, replace the two bad ones I have here and fix two other boards someone sent in to me. Need to get this stuff done :-)

Something else I am noticing: Have a reference Titan plugged into a controller here. Just noticed the FPGA is getting hot. Pulled the Titan, put nothing else on the controller, still hot. Odd. I think it's going to blow the FPGA soon, no biggie as I can fix it, but is this a symptom of some sort?

Anyone else have a hot FPGA? I've seen a few repairs come in where people put heat sinks on the thing, it's not supposed to run warm. Something else is happpening.

C

No problem. That front screw spot is not very strong, the torque from the heat sink coupled with the slight bending needed to put down the sides to get to the screw can cause it to come loose. Then there is no pressure on the die.

The second die probably has a bad power supply. Note I have seen a number of people try to "repair" the supplies it is very difficult to remove them without a lot of bottom heat, air, and patience. Otherwise you wind up pulling up the traces which can wreck the cube. Run it at 150mhz (half of 300) on the remaining supply and feel good knowing that it is keeping the overall power draw at a reasonable level.

C

Nice. I ran a Neptune for awhile with a Corsair H100 water block secured to the top, it worked very well for a few months keeping the chip cool until the water block sprung a leak. Then all hell broke loose :-)

Leak detection is a big problem: The stupid things don't have temp sensing in the chip dies and little to no thermal mass, as a result the chip can overheat very quickly before software manages to shut things down. One of the leading causes of Titan Die death is when the die inside that chip carrier overheats, as soon as that happens the solder BGA grid under the chip melts, extrudes as solder balls, and either shorts the +.8v supply lines (if you are very lucky) or shorts the signal lines (which are shared by all dies) which kills the whole board.

So you might want to continue running that big heat sink thing: It actually cools very well and as long as the compound they used (which is crap) is secure you should be in good shape. Just remember that if you have an air gap on a corner of the chip, that die will extrude, melt, and fail.

Meantime I tried to source the displays and failed (got the wrong part) for the blown display boards. Anyone know what the right DigiKey or Mouser part number is?

New Pi's right? When the Pi blows it takes out the bridgeboard.

Switched over to my backup controller, Titan is back to hashing. Board has 3 ohms on the FPGA 3.3 volt power supply, indicating the fpga drivers are out. Interesting.

Son of a BEAR! My reference controller had the FPGA fail!

The screen was frozen at 42mh
The logs from the Pi were:
pi@raspberrypi ~ $
pi@raspberrypi ~ $
The system is going down for reboot NOW!(console) (Sat May  7 10:38:18 2016):

The unit now powers up no display with the flashing light. Meaning TPS is good, FPGA is bad.

Oh well, them's the breaks. However I now can see what causes a controller board to fail. Interesting. Physician heal thyself...

Oh yeah, I finished your board, those titans are a wreck, someone else tried to repair them. You can always tell when you see a power supply with the 10 pin connector hovering off the board :-)

Anyway, I'll send that back. Simple little fix actually but a new board at .2 is quite competitive with my repair price so in the future I would say check with that guy first.

C

Sorry to hear that. I can fix them but it is a bit of a pain for shipping and all (I use 24g wire wrap wire which is better than the foil, but will still blow if the Rpi shorts). Actually what one *really* should have is a small resistor in line with the power there so that if the Pi shorts it's not a zero ohm circuit across a potentially large amp source.

If your bridgeboard blows out, check your Pi first: I have had Pi's that had shorted CPUs where they threw full 5 volts down into the FPGA and the TPS power chip (blowing both). I have had Pi's with bad CPUs that got hot enough to burn fingers when touched (that sourcing of current will blow up the board). And I have had Pi's with dead shorted charge pumps.

Because we plug these boards into big supplies, all lines should be able to support max current. They don't, and this is the source of a lot of blown out boards. A simple 1 amp removable mini fuse on the board's +5 and +12 inputs would have gone a long way to protecting things. But then again so would a set of optoisolators on the signal lines to the cubes to prevent ground loops and the resultant hilarity. But that would have cost money, and that's a problem as well.....

C
(Just fixed two more bridgeboards, both with bad Pi's)

PS: Say has anyone tried powering a new Pi with the Rpi's onboard USB supply/plug in the event of a blown bridgeboard? That would bypass this bad line, and it *should* come up. Try it and see....