Slightly less than 100 grams for an H-CARD. So a complete system with 16 cards and M-BOARD + Raspi would be under 2 kilograms.

From center of socket "F" to mounting hole is 7.56 mm. From mounting hole to board edge is 5 mm.

Nearly all the work is done using reflow technique, so there's very little hand soldering involved, but a lot of manual picking & placing with fine tipped tweezers. Each board has 240 capacitors in 0402 size, and about 60 other components.

The queue is 2 deep. One job it is currently working on, and one job scheduled for later. Every time you poll the chip to see if the job is finished, you supply the next job at the same time (it's in the same SPI transfer), so typically the next job will be sent a few times. I've never seen any evidence of aborted jobs. I figure it just overwrites the next job.

The bitfury design continues searching the nonce space and will report all that it finds. Only when the search is exhausted, it switches to the next job. It has a FIFO with the 15 most recent nonces found. If you don't supply the next job in time, it will restart old work and you end up with dupes.

I don't know how the FPGA works, but on the ASIC, the chip is working on job #0, while you send data for job #1. As soon as it finishes job #0, it automatically switches to job #1. Sending job #1 does not abort job #0, so if there's a way to abort #0, it must use a different mechanism.

I meant a prevhash change of course. Like I said, the firmware uses stratum, so it generates new work all the time.

Mounting holes in the PCB are 3.2 millimeter, designed for M3 metric thread.

That just resets the SPI chain. I use that every time before I poll the chips to see if they are ready.

All I know about is bitfury's postings in this thread and his source code, and neither mentions an 'abort job' feature.

How often does the work change ? I don't know if bitfury chips can be interrupted. For normal mining, I just let them finish the old work (takes on average 1.5 seconds), which is acceptable since the work only changes every new block (nominally every 10 minutes)

If there's a way to interrupt bitfury chips, I'd be happy to modify the firmware to support quick work switching.

Edit: I looked it up. Apparently work changes every 10 seconds, which would make the 1.5 second delay too much. So, it all depends on whether the bitfury chips can be interrupt. I don't know that yet.

Yes, the gap is purely for spreading heat. There only a few little components, and a few traces between the chips, so, electrically, the gap could be reduced to almost zero. It's the heat that is a concern.

There are no plans to shrink the size right now. Of course, the closer the boards, the more difficult it will be to get the heat out. Maybe after more real-world data, a size shrink could be done.

The code is correct. Toggling SCK for a reset wouldn't make sense, because that's the same as writing data.


You can see in the code that the initialization code says mode=0, so it's using SPI mode 0 (data valid on rising edges)

AFAIK there's no minimum speed.  Not sure what max speed is (I think it's > 10 MHz). I'm running the SPI bus at 500 kHz, which is about the fastest you can get for 16 chips in fasync mode.


Yes.

If you look at the stratum documentation, you see it involves merging together coinbase strings plus the extranonce, and then performing a double SHA256 hash over the result. Now, the coinbase strings can -- in theory -- be very large, and this will overwhelm the limited memory inside the embedded device. Right now, I have a 4KB buffer for the total coinbase data.

In practice, most mining pools have coinbase strings that are just a few hundred bytes.

Also note that really large coinbase data may also not work very well on devices like the Raspberry Pi. Even though they have more memory, the hashing speed is still limited, and performing the SHA256 hash over a megabyte of data to generate a piece of work may slow down the device to the point where it has an effect on total hashing speed.

There was a mismatch between the capacitor shape on the board, and the capacitor mentioned in the parts list. I ordered the (smaller) caps on the BOM, but noticed it didn't really fit well on the footprint on the board. I put the small ones on anyway (with hand soldering it is just possible to do that), but ordered the bigger ones for a better fit, and used those on later boards.

Electrically they both work, so there was no need to replace the smaller ones on the first couple of boards.

I don't know how p2pool works, but the firmware only supports stratum right now.

Does p2pool require a ton of memory ? Because that's probably going to be the limiting factor on the small CPU.

Edit: Note that every network connection also requires buffers, so maintaining connections with multiple peer doesn't sound like it would fit. However, you may still run the main p2pool software on a PC, and just offload the hashing to the board using getwork protocol.

The firmware already supports stratum and 4 different pools with automatic switching if a pool is non-responsive. The only limitation is the 4KB memory set aside for the coinbase data, which may be too small in some cases.

Yes, you could make the same board, and populate one partly. It still means you have to interconnect them some way. Suppose someone makes a case for it, that case will also need an extra opening for the interconnect, and then you'll have unprotected 3.3V CMOS level signals going from one board to another, with potential ESD and EMI problems.

The board already has an option for RS-485 interconnect (it's on the unpopulated 3 pin connector along the side). That would be more suitable for board-to-board communication. Of course, that would still require the CPU, but that's only $5 @ qty 1000. I'm not too convinced the RS-485 is so great either. This board, with 16 chips, is targeted towards the small home miner with a limited budget. Put it in a nice case with power supply, and you have a neat little standalone unit.

The LPC + Ethernet is more like $15. That's less than a single ASIC. For a complete system with fan, heatsink, maybe a case, 12V power supply, the difference in cost is hardly worth the effort of having two types of PCBs and a new interconnect.

For lots of chips, the M/H board system is a better solution. Of course, an interesting option would be to replace the Raspberry Pi with an integrated CPU/Ethernet on the M-BOARD.

CPU load is less than 10%, so it could easily drive a lot more chips. However, most of the cost is in the DC/DC regulator and the ASICs, so it wouldn't actually save that much money.