Very similar, now who has the balls to pull off the Pi? Oh wait, is the Pi on top of a board by default? Then That is how they did it.

Ok, now I see. What KNC did is this:

It looks like they took the Neptune board:
Added a cross connect board to map the Beaglebone pins to a Rpi. Added lights and a U4 thingie. Maybe a clock crystal or a VRM.
Plugged cross connect board into Neptune board
Plugged Pi into cross connect board
Uploaded code into the SPI ports on the FPGA
Went to town.

You can probably build your own cross connect board by looking at the neptune pins, matching them to the BB Black pins, then cross-mapping those to a Pi. Power, SPI, GPIO ports, done. Or just pay the guy above who did it.

Miners *can't* be less greedy. It costs money for electricity (yes I know everyone thinks it's free, but it's never really free), money for the ever obsolete hardware, and time to keep the things running (yes, they do blow up). At ten cents a kw/hr it's about break even at .5w/gh. Buying .25w/gh will make a small profit but not cover the cost of the miner anytime soon.

Likewise this will *always* be the case. Note the price of bitcoin doubled, and so did the difficulty. They are tracking right now. When the halving happens, either the number of miners will drop in half or the price will double.

There's really no greed here. Actually everyone is perfectly greedy, that's what makes bitcoin go. The people who make money are people who make miners (which isn't that profitable) and the people who run power plants (who are the final source of power and money).

You can reset the board configuration to factory defaults by pressing the little button on the control board 5 times quickly, then wait 5 seconds, then press 5 times quickly again.

That would be a pretty straightforward fix, out of curiosity do you plug them into a powered supply (that snap spark will cause resistance points on the connectors). When they melt the connectors do you just solder the power supply wires straight to the board?

Searing, can you post a picture of your Titan controller with the Rpi on it? I'm bored while waiting for Santa to bring FPGAs and power circuits from Digi-Key.

Sorry, I was thinking P2/P2A type connections with 4+12 and 4 grounds. Better but would cause a lot of funny crowbars.

Sure, send it over. What kind of problems have you had over the years?

In the meantime here is what a Neptune board looks like ready to have parts pulled:



Note also the Hakko part puller that thing is a literal God for removing stuff. And the Zephlux, the ultimate flux to get stuff off and on boards

Very interesting. With the fpga off the board, the following is going on:

1) The red/white/blue super bright LED is always on. Must be pulled low by the fpga outputs. Hm...

2) The power up command still does not work:

root@Neptune:~# io-pwr init
TPS65217 OK. Modification A, revision 1.2
Wrong SEQ4 value 0x40
Wrong SEQ4 value 0x40
Wrong SEQ4 value 0x40
Wrong ENABLE value 0x00
Wrong SEQ4 value 0x40
DC/DC converter configuration failed!

Interesting. Next up is to pull and swap the TPS chip. Why would that fail? Hm. But with the FPGA off I can check all the power lines to see what's going on.

Ok, so I pulled the FPGA from a broken Neptune controller board. Thoughts:

1) These boards are *thin*. Almost don't need the overhead heat, I might be able to flow the new chip onto the board just with the pre-heater. Nice. Note that the temps on the board were 250c when I hit it with 350c top air for 15 seconds, then picked it with the Hakko. Came up clean. Much thinner PCBs than other miner products.

2) Now I just need to let the board cool down then I'll work on testing the board sans fpga. If the power supplies come up then that was probably it.

Quick thought: I don't see how. My older Rpi has a completely different gender on the pins to the Neptune board (the pins from board to BB are male to female on the BB. My Pi has male header pins). So to start with an adapter would need to be made, you can't just plug a Pi into a Neptune board.

That said, anyone have a confirmed picture of a Titan board with the Rpi off?

Maybe. KNC seems to have come up with the super-dooper-bright idea of putting their FPGA I2C mux and general goat-gathering tool on the outside board instead of inside the miner, they don't seem to have changed the concept between the Jupiter and Neptune.

Not sure how the Titan works though, if you want to send me a Titan hashing board (does it use the same heat sinks as the Neptune?) I can give it a try. The questions you can research include:

Does a Rpi board have the same side connectors and signal points as a BB?
*exactly* What kind of FPGA is used on the Titan controller board?
Are there any other chips on the Titan board?
How does the software in the Rpi download the code to the FPGA and power sequence the DC-DC supplies?
Take some really good pics of the Titan board and post it to this thread. Both sides, focus in on the chips.

If the Titan has an insane amount of hashing engines, they might have had to make changes to the FPGA-CPU interconnections to handle the extra traffic. Maybe, don't know.

Send me a working Titan hashing board and I'll give it a go. Worst case board explodes or something. I'm going to try to fix these two while waiting on another, it's $60 for the FPGA from Digi-Key and BGA replacement is tough but not impossible.

The jupiter had pads for two ports, the Neptune only has one. So putting another one in might not be worth it, once I get one going I'll take a look at how the plugs are handling things. Going to an 8 pin might be doable....

*nod* Indeed, I'm seeing two problems with that connector.

1) The connector is over-loaded. I had a Monarch that ran off a 500 watt power supply that basically fused the PCIe cables to the jacks due to voltage drop and slow melting. That's why they went to 3 when they did the 700gh ones. And let me say removing those PCIe jacks is a pain in the rear (hint: pre-heat. Lots of pre-heat).

2) I see an interesting flaw in the Neptune: The DC-DC's each have a bunch of 25uf capacitors to smooth out the ripple current on the 12v lines before the chip. No biggie for one, but since they use six of them and since the caps are always live there is a nice *snap* of surged current every time you plug and unplug a Neptune to a turned-on power supply. Each *snap* makes a little divot in the PCIe contacts. A few of those and you start to have higher resistance, which leads to heat, which leads to fail.

So one big idea is to *never* have your power supply on or off when plugging or unplugging a Neptune box. Ever. Let your power supply crowbar charge and discharge that mongo set of caps.

If people have Neptunes with burned jacks I can fix those cards without too much difficulty. The Neptune boards have less thick copper planes than other miners, so it's not too bad to do.

Well hm.

Fact is miners live to make money, if there is no profit in mining people will stop doing it till mining is profitable. Right now there is a mad rush to buy .28w/gh mining gear (I'm not quite sure why) and probably a ton of .8-1.0w/gh equipment sitting on the sidelines.

But think about it: If the price of bitcoin suddenly dropped to 225, then the mining difficulty would drop to about 50 instead of where it is now. Because at a 25btc block reward, a difficulty 50 was enough to eek out a profit at 225 a bitcoin. Was the network any "less secure"? I don't really think so, your chances of breaking the chain were basically zero then as now.

So when the block reward halves, either one of three things will happen:

1) 50% of the miners will drop out.
2) The price of bitcoin will double
3) Fees will go sky high.

I doubt #3, although it is nice to see miners demanding fees these days. #2 is possible, but more likely the less efficient miners and people fed up with heating their homes will drop out. No biggie, the network will adjust and it will still take 10 mins to confirm a block.

Now some people will say "yeah, but you can take that 50% that fell out and do a 50% attack!". Sure, but first:

You have to find the miners, they're all over
You have to incent them to mine again on a super-evil blockchain. That will cost 25btc every 10 minutes
You have to get them all to agree to fuck the chain for money
You have to keep paying them to keep their less efficient farms running away.

I strongly doubt this will happen. So no biggie.

So it's time for an initial order from DigiKey. I think I will pick up the following:

25uf SMD capacitors (they blow up a lot on these boards)
EP4CGX22CF19C7N  New FPGA for board.
TPS65217a Power control chip (just in case that's it)

Quick update: I opened another thread on hacking these things but I figured out the problem: The FPGA's output drivers are shorted, causing the little 4 way power supply to crowbar and fail while trying to bring up the I/O rail. Proof is in the ssh session, the bring-up-the-power supply command fails.

Edit: Note the board design sucks IMO. The raw FPGA lines go right to those edge connectors, normally a wise person would put an optoisolator chip or heck even a buffer/Schmidt/Op amp trigger on the outputs. Nope, instead of putting in a ten cent part the $100+ FPGA is exposed.

On to the next problem....

If you have dead shorts in the 12v side, it might be the trimmer caps on the power supplies in the cube. Those things get no cooling and I've seen caps like that blow up in the heat. Bitch to find though you can use a VOM across the 12v line then go around with hot air and see where the resistance changes. I find a lot of bad FETs that way too.

Yep, it's looking that way. I did some serious banging this evening and found that the brains to fire things up is in the /etc/init.d/initc.sh script. The io-pwr command is key:

root@Neptune:/etc/init.d# io-pwr init
TPS65217 OK. Modification A, revision 1.2
Wrong SEQ4 value 0x40
Wrong ENABLE value 0x09
Wrong SEQ4 value 0x40
Wrong ENABLE value 0x09
Wrong SEQ4 value 0x40
DC/DC converter configuration failed!

Either both of these 4 level dc-dc's failed the same way or the FPGA has the output lines (ps 4) shorted. I'd bet on that.

So it's off to the Digi-key store. I have an Aoyue 968 rework gun, a hakko picker, and most importantly god-flux so I should be able to swap that component. Thanks for the confirmation!

First step. Got the boards, took a look at them. One had exploded capacitors on its' power modules and would crowbar a 500 watt power supply. Second and third take power, but have blackened PCB boards under the hashing chip and don't do anything.

The two controller boards are interesting. One has all six ports (10 pin) on top, the other has four. One has a red/green LED pair, the other does not. One had a beaglebone that booted up and needed a software reset (got an IP address) the other comes up and does nothing.

Connecting the 10 pin ribbon cable between either board and any of the three miner chips produces nothing, regardless of power being on or off at the miner.

sshing into the beaglebone has given me some commands, first one I have tried is:

root@Neptune:/boot# waas -g all-asic-info
Error opening /sys/bus/i2c/devices/3-0050/eeprom: No such file or directory
ASIC board #0 is non-functional: Bad EEPROM data
Error opening /sys/bus/i2c/devices/4-0050/eeprom: No such file or directory
ASIC board #1 is non-functional: Bad EEPROM data
Error opening /sys/bus/i2c/devices/5-0050/eeprom: No such file or directory
ASIC board #2 is non-functional: Bad EEPROM data
Error opening /sys/bus/i2c/devices/6-0050/eeprom: No such file or directory
ASIC board #3 is non-functional: Bad EEPROM data
Error opening /sys/bus/i2c/devices/7-0050/eeprom: No such file or directory
ASIC board #4 is non-functional: Bad EEPROM data
Error opening /sys/bus/i2c/devices/8-0050/eeprom: No such file or directory
ASIC board #5 is non-functional: Bad EEPROM data
{
Error opening /dev/i2c-3: No such file or directory
Error opening /dev/i2c-4: No such file or directory
Error opening /dev/i2c-5: No such file or directory
Error opening /dev/i2c-6: No such file or directory
Error opening /dev/i2c-7: No such file or directory
Error opening /dev/i2c-8: No such file or directory

Looks like the i2c bus lines are not operational. Ok. Need to figure this out.

It appears that the beaglebone communicates with the KNC chips and other stuff through an i2c--spi type of interface. Makes sense, however the BB doesn't have anywhere near enough channels. So what I'm guessing is happening is that the BB tries to talk to that FPGA chip which then has a *lot* of I/O ports defined as connections to each of the Neptune cubes and chips. Then the chips talk to the FPGA for housekeeping and such and the FPGA sends the cooked results to the BB to go to bfgminer and whatnot.

Makes sense actually: In this way the FPGA can also do the heavy lifting of polling the hashing engines, sending work down, getting work back, and invalidating results. With hundreds of engines on a chip it's the only way to fly, and oddly enough it keeps the interface logic on the hashing board to an absolute minimum. Nice idea.

However the fpga is powered by its' own power supply, and I am guessing the i2c busses going to the engines have their own independent supply to reduce noise and ringing problems from the hashing engines (which probably run at .6 volts or so if it's a 20nm chip). That is probably the TPS chips, I wonder if it is down. Only way to find out is to put it on the bench and see if it powers up to around 2.x volts or so. Likewise that should be on each of the 10 pin headers somewhere.

Time to find it.