[ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE!

[kaerf]

Thanks very much for at least that information. I'm still not even sure if it's going to be possible then, but I'll keep poking.

np. You're probably using the code from https://github.com/kerrydwong/MCP2210-Library. This code needs to be modified to send large transactions (> 64 bytes) since the chip only supports 64 byte transmissions. I've spent a few days getting stuff to work and only just today got the chip to start consuming power (first 317 initialization bytes have been accepted)...tomorrow I make it hash =P.

[1714954776]

1714954776

[-ck]

Thanks very much for at least that information. I'm still not even sure if it's going to be possible then, but I'll keep poking.

np. You're probably using the code from https://github.com/kerrydwong/MCP2210-Library. This code needs to be modified to send large transactions (> 64 bytes) since the chip only supports 64 byte transmissions. I've spent a few days getting stuff to work and only just today got the chip to start consuming power (first 317 initialization bytes have been accepted)...tomorrow I make it hash =P.

No I'm not. I've written my own spi communication code on our usbutils. I've been burnt enough by external libraries...

[cscape]

On the plus site, the USB to SPI connection can provide the mining software for more control/flexibility since it can directly send commands to chips/SPI bus. Also, you don't need to flash firmware updates...

True, but the bitfury chips don't have much that is to be controlled. You can set the clock oscillator options, and that's about it. On the other hand, a microcontroller can do other useful stuff like monitor the board temperature, voltages, and even adjust the core voltage to allow smart overclocking: on a cool day, or with good ventilation, the chip will automatically hash faster, and on a hot day, it will automatically slow down to protect itself.

Firmware update could be a problem depending on the chip. The LPC11U have an option to boot as a mass storage device with a FIRMWARE.BIN file that you can overwrite. Alternatively, you could make some sort of bootloader.

[kaerf]

Ohhhh... tell me about it! I hated that documentation when I read it the first time. And then I saw the chip on your boards and went back and reread it ... and hated it even more... I think you pretty much qualify for a hero for figuring it out!

I haven't posted any pix or details about our device (until now)...you're probably mixing me up with someone else.

No I'm not. I've written my own spi communication code on our usbutils. I've been burnt enough by external libraries...

ahh..in that case, you can use that code for reference (if you aren't already) =P. There's also https://github.com/daniel-santos/mcp2210-linux, but much more immature.

True, but the bitfury chips don't have much that is to be controlled. You can set the clock oscillator options, and that's about it. On the other hand, a microcontroller can do other useful stuff like monitor the board temperature, voltages, and even adjust the core voltage to allow smart overclocking: on a cool day, or with good ventilation, the chip will automatically hash faster, and on a hot day, it will automatically slow down to protect itself.

Firmware update could be a problem depending on the chip. The LPC11U have an option to boot as a mass storage device with a FIRMWARE.BIN file that you can overwrite. Alternatively, you could make some sort of bootloader.

Yeah, we were probably wrong to go with the mcp2210 since it didn't save any time...should have investigated the linux API and datasheet more thoroughly. At first glance, the USB-SPI chips seem more amenable to software-only guys since you only need to write host code and don't need to write the firmware.

[vs3]

I haven't posted any pix or details about our device (until now)...you're probably mixing me up with someone else.

oh, my bad. I was thinking of 101BTC.

[ssi]

So I got three more chips placed on my board... all seven are recognized, but it runs SLOWER than it did with four!

Tweaking clock and voltage trying to find a happy medium.  Anyone have any suggestions?

[cet]

So I got three more chips placed on my board... all seven are recognized, but it runs SLOWER than it did with four!

Tweaking clock and voltage trying to find a happy medium.  Anyone have any suggestions?

take all but one chip out?

[klondike_bar]

So I got three more chips placed on my board... all seven are recognized, but it runs SLOWER than it did with four!

Tweaking clock and voltage trying to find a happy medium.  Anyone have any suggestions?

same task being given to multiple chips and/or waiting for repeats of the result? sounds like the isue relates to how the chips are being sent commands

[ssi]

So I got three more chips placed on my board... all seven are recognized, but it runs SLOWER than it did with four!

Tweaking clock and voltage trying to find a happy medium.  Anyone have any suggestions?

same task being given to multiple chips and/or waiting for repeats of the result? sounds like the isue relates to how the chips are being sent commands

I'm using the legkodymov cgminer fork... I haven't dug into how exactly it runs these chips.  I guess I need to get involved in that soon.

I've got it running 9.5GH on seven chips; was running 8.5GH on four.  Pretty disappointing

[needbmw]

I've got it running 9.5GH on seven chips; was running 8.5GH on four.  Pretty disappointing

Something wrong with your setup.
I'm running my longest 90-chips chain at average 237.7Gh/s (today will add 10 more chips to the chain).
Chips require a lot of power to hash faster than 2.5Gh/s per chip (at least 0.88V, 2,5-3A per chip), are you sure your DC/DC is capable of fully power 7 chips chain?

[ssi]

I've got it running 9.5GH on seven chips; was running 8.5GH on four.  Pretty disappointing

Something wrong with your setup.
I'm running my longest 90-chips chain at average 237.7Gh/s (today will add 10 more chips to the chain).
Chips require a lot of power to hash faster than 2.5Gh/s per chip (at least 0.88V, 2,5-3A per chip), are you sure your DC/DC is capable of fully power 7 chips chain?

I've got 40A available; should be plenty!

[ssi]

I've got it running 9.5GH on seven chips; was running 8.5GH on four.  Pretty disappointing

Something wrong with your setup.
I'm running my longest 90-chips chain at average 237.7Gh/s (today will add 10 more chips to the chain).
Chips require a lot of power to hash faster than 2.5Gh/s per chip (at least 0.88V, 2,5-3A per chip), are you sure your DC/DC is capable of fully power 7 chips chain?

What are you using for spiclk speeds and bitfury clock setting?

[cscape]

For 16 chip chain I use 1 MHz SPI clock, and this clock setting: { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x3F, 0x00 };

[ssi]

For 16 chip chain I use 1 MHz SPI clock, and this clock setting: { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x3F, 0x00 };

That's the clock setting I've been using, and I've been at 5MHz.

Lemme turn spiclk down and see where that gets me.

[ssi]

So I unbridged between #4 and #5, going back to four chips, and it's back to fast:

 cgminer version 3.3.1 - Started: [2013-08-29 05:42:33]
--------------------------------------------------------------------------------
 (5s):10.56G (avg):9.477Gh/s | A:160  R:0  HW:0  WU:132.4/m
 ST: 2  SS: 0  NB: 1  LW: 251  GF: 0  RF: 0
 Block: 002f2d30baf48c98...  Diff:65.8M  Started: [05:42:33]  Best share: 360
--------------------------------------------------------------------------------
 [P]ool management Settings [D]isplay options [Q]uit
 BITFURY 0: 11.61G/10.63Gh/s | A:176 R:0 HW:0 WU: 148.6/m
--------------------------------------------------------------------------------

 [2013-08-29 05:42:26] Started cgminer 3.3.1
 [2013-08-29 05:42:26] BITFURY chip #1 detected
 [2013-08-29 05:42:26] BITFURY chip #2 detected
 [2013-08-29 05:42:26] BITFURY chip #3 detected
 [2013-08-29 05:42:27] BITFURY chip #4 detected
 [2013-08-29 05:42:30] BITFURY: 4 chips detected!


Next, bridged 4 to 5 and unbridged 5 to six:

cgminer version 3.3.1 - Started: [2013-08-29 05:47:30]
--------------------------------------------------------------------------------
 (5s):9.923G (avg):8.487Gh/s | A:184  R:0  HW:0  WU:118.6/m
 ST: 2  SS: 0  NB: 1  LW: 379  GF: 0  RF: 0
 Block: 0034005b153db46a...  Diff:65.8M  Started: [05:47:30]  Best share: 1.52K
--------------------------------------------------------------------------------
 [P]ool management Settings [D]isplay options [Q]uit
 BITFURY 0: 10.17G/8.956Gh/s | A:192 R:0 HW:0 WU: 125.1/m
--------------------------------------------------------------------------------

 [2013-08-29 05:47:23] Started cgminer 3.3.1
 [2013-08-29 05:47:24] BITFURY chip #1 detected
 [2013-08-29 05:47:24] BITFURY chip #2 detected
 [2013-08-29 05:47:24] BITFURY chip #3 detected
 [2013-08-29 05:47:25] BITFURY chip #4 detected
 [2013-08-29 05:47:25] BITFURY chip #5 detected
 [2013-08-29 05:47:28] BITFURY: 5 chips detected!


slower!

[cscape]

How about modifying software to skip first chip ?

[ssi]

How about modifying software to skip first chip ?

seeing about 7-7.3GH on five chips, with it skipping the first chip.  In order to skip, all I did was:

Code:

int libbitfury_sendHashData(struct bitfury_device *bf, int chip_n) {
        int chip;
        static unsigned second_run;

        for (chip = 1; chip < chip_n; chip++) {

change chip = 0 to chip = 1.


Maybe I should set it up so I can run any single chip, with the full chain intact, and get a hashrate per chip.

[ssi]

So I modified cgminer to allow me to run only one chip at a time.

All the chips consume power the whole time, but only one hashes.

They all show >2Gh except for one, which is 1.8GH.  Most of them will maintain >2.5GH.


I have a current meter inline with 12v.  It's reading 1.73A while hashing... ~20.76W.  My power module is supposed to be 79% efficient at .9V, so that'd be 16W delivered.  16W @ .9V is ~18A.  Less than half the 40A rating on the regulator.

[cscape]

Our (c-scape & intron) bi•fury board is hashing over 5 GH/sec.

Screenshot from BTC Guild:


Photo of bi•fury prototype board with 2 ASICs, plugged into laptop. A fan is aimed at the board + heatsink, keeping the ASIC temperature at 45 ℃, and the rest of the board (including the regulator) at 40 ℃. Core voltage has been set at 0.84V. 

The extra pushbuttons, jumper, and 3 wire UART are just for testing/debugging.

[ultrix]

Update on power circuit.  1/2 day on regulated AC (through UPS & PDU network) with < 5mV jitter @90A maintaining 92% efficiency average for the circuit and 82% from the wall (additional loss is due to the ATX power supply I'm using, which is a Corsair AX1200i).   Running 1/2 day at my home now using residential AC, there is more noise in the output, but still exceptionally stable.  I have gotten 2 samplings thus far of 7mV spikes.  Efficiency from the wall is still at 82%.  Going to finish assembling my bitfury test boards tonight or tomorrow and will start powering real chips.