good news. It took me and my friends about a week to debug the 16-chip board but now it's nearly finished. To be brief: there were quite some bugs in the firmware. Also we've fixed some suboptimalities in the firmware operation. But now it's very reliable and predictable with bfgminer: you tell the board how fast should it operate the chips, and you get exactly that speed all the way between 500Mh/s per chip to 1700MH/s per chip. With the 16-chip board modifications to bfgminer were also necessary: at high speeds the board completes its work queue too quickly so that a significant amount of time was lost in idle.

With careful thermal design and at 1.025V power, we can run the 16-chip board at 27.2GH/s rated speed. bfgminer currently reports 26.3GH/s but it may change due to averaging.

I'm going to post the firmware updates shortly. A question: what is the optimal way of posting the firmware updates? I could send it to the author of the original project to be incorporated in the github repository. The bfgminer software also has to be modified for operation at maximum speed.

The Texas Instruments voltage converter is pretty overloaded at these speeds. Both inductors and FETs on it heat a lot despite forced air coolong. At least, small heatsinks must be mounted on them. Also I'd recommend making 10-chip boards or placing less than 16 chips on the 16-chip boards such as 12-14 in order not to overload the voltage converter.

I'm going to post the firmware updates shortly. A question: what is the optimal way of posting the firmware updates? I could send it to the author of the original project to be incorporated in the github repository. The bfgminer software also has to be modified for operation at maximum speed.

Great work!I can merge your code into the github-repo, or giving you direct access to it.Can i just verify your work? Just send a PM with a link to an archive with your firmware and bfgminer-patch please.

It turns out Jeffery wasn't bluffing, he just didn't explain it well. He paid a developer $2000 USD for what turned out to not be what he expected. I believe that is what he meant by great contributers and he has emailed me what he has stable at 21 GH/S.

I don't see a reason to fork seeing as he paid for this and Ostenbacken and Form have this under control. Tips incoming when I get these running. I'm also leaving my offer open to flash free minus shipping for anyone that can't do it prior to this fiasco.

We are asking everybody who benefited from our firmware and driver troubleshooting, to support our incentive of sharing our achievements with the community by making a small BTC donation to:19bWQt5ix6u7hgZyYUcADy72MLsuGzCRYn

The updated firmware supports speeds down to 500MHz. It is possible to implement support for lower frequencies as well by using nonzero values for the OD parameter. While making the updates we've hit some Microchip XC8 compiler bugs so that expression evaluations in the UpdateClock() resulted in wrong values. Updating the compiler to the latest version did not help. The workaround was to split big expression evaluations into smaller statements.

Here is the performance achieved with two 10-chip boards and one 16-chip board running at speed 1717 (rated 1.717GH/s per chip). Again, careful thermal design is mandatory to achieve this performance. Heatsinks are required on both sides of the PCB with high-performance rubber inserts between the heatsink and PCB/chips. You can look up overclockers' resources for tips in thermal design.http://s020.radikal.ru/i710/1402/a6/818c5c336781.png

One question: There has been a lot of back-and-forth on the firmware, but little discussion on the PCB itself. Which PCB design file/s are you guys using for your boards? I just don't want to risk building up an old PCB with current firmware.

Which PCB design file/s are you guys using for your boards? I just don't want to risk building up an old PCB with current firmware.

PCB changes were minor, so any PCB design version, if it works at all, should also work with the latest firmware (the one that I posted). I would NOT recommend building the 16-chip board for the reason of overloading the voltage converter. Or if you build it, mount 10-12 chips on it. With chips working in turbo mode, it's 2.5W per GH. At 1.6GH the power per chip is 4W which corresponds to 4A current draw per chip. So with 12 chips you'll get 48A which is just below the maximum rated load (50A) of the voltage converter module. This way your circuit should run safely. To have a little extra margin, 10 chips would be even better.

The updated firmware supports speeds down to 500MHz. It is possible to implement support for lower frequencies as well by using nonzero values for the OD parameter. While making the updates we've hit some Microchip XC8 compiler bugs so that expression evaluations in the UpdateClock() resulted in wrong values. Updating the compiler to the latest version did not help. The workaround was to split big expression evaluations into smaller statements.

Here is the performance achieved with two 10-chip boards and one 16-chip board running at speed 1717 (rated 1.717GH/s per chip). Again, careful thermal design is mandatory to achieve this performance. Heatsinks are required on both sides of the PCB with high-performance rubber inserts between the heatsink and PCB/chips. You can look up overclockers' resources for tips in thermal design.

The firmware loaded fine but I can't get BFGminer to compile that driver. I think it's due to the .o file but I'm not sure how to fix that.

The firmware loaded fine but I can't get BFGminer to compile that driver. I think it's due to the .o file but I'm not sure how to fix that.

It seemed he used an older version of bfgminer.You can use the normal version and just change 2 lines:

#define MAX_WORK_COUNT 8#define LATE_UPDATE_MS ((int)(0.5 * 1000))

These changes did a good job for me. I never saw a duplicate/idle message anymore since that, even with the board-firmware from before. (Including a slightly higher hashrate)His new firmware for the board didnt work so well for me, the old one is faster at even lower frequencies, but i still have to debug it a little further...

His new firmware for the board didnt work so well for me, the old one is faster at even lower frequencies, but i still have to debug it a little further...

Can you post any details? The frequency formula in the original firmware was incorrect, so you had to pick frequencies without any clear understanding how frequency relates to the hashrate. With my firmware, speeds 1650-1717 yield maximum performance, while lower speeds (down to 500MHz) also work well and in a predictable fashion so that the actual hashrate matches with the speed you specify, i.e. speed 500 -> 500MH per chip and so on. Here's a screenshot:http://s019.radikal.ru/i601/1402/ca/70cccdc0e4bc.pngHere's an example command line:./bfgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u <username> -p <password> --klondike-options 1718:70substitute your pool credentials, username and password where appropriate.

Also we checked the most recent bfgminer sources. The reduced value of the LATE_UPDATE_MS delay is not yet incorporated in it, so you have to do it yourself.

---

One more thing. We are asking everybody who benefited from our firmware and driver troubleshooting, to support our incentive of sharing our achievements with the community by making a small BTC donation to:19bWQt5ix6u7hgZyYUcADy72MLsuGzCRYn

It turned out the request work updates were due to a short in the board. So 4/5 running not bad I guess. I am having a strange issue with the raspberry pi. It doesn't seem to like more than 2 of these connected at once. The cards aren't bad because I can interchange them. Anyone else run into this? Mabey, just too much for the little guy.

Im interested in giving this a shot. I hope no one saw my original comment it was seriously retarded. I can breadboard it out. The design below the ISP on the schematic is reference for the chain right?

Im interested in giving this a shot. I hope no one saw my original comment it was seriously retarded. I can breadboard it out. The design below the ISP on the schematic is reference for the chain right?