|
@giorgiomassa: did you check the input voltage ? Is it stable ?
|
|
|
|
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.  |
|
|
|
|
How about modifying software to skip first chip ?
|
|
|
|
|
For 16 chip chain I use 1 MHz SPI clock, and this clock setting: { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x3F, 0x00 };
|
|
|
|
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. |
|
|
|
- any sequence
- at least 3 MOSI toggles (better more) on CLK high
- speed < 20MHz
Note that you need 3 MOSI toggles for each chip in the chain. |
|
|
|
|
We're using LPC11U. I'm just finishing the firmware for it. PC interface is a simple virtual com port over bulk endpoint. The PC software just sends 'work <job id> <work>' to send work to the chip(s), and the firmware sends back 'submit <job id> <timestamp> <nonce>' whenever it finds something.
|
|
|
|
|
Instead of using a dedicated USB-SPI chip, it would be a lot easier to use a small USB microcontroller. Price and area would be the same, and all the hardware specific details of the bitfury design would be in the firmware, rather than on the PC.
That's what we're doing for our 2-chip bi*fury USB design, but it would be easy to replace the 2 ASICs with a H-CARD socket.
|
|
|
|
The command list is IMO pretty much irrelevant.
The issues are simply USB and hardware design considerations.
How to send commands?
Seriously? People think that is an issue?
Our USB device has a simple bulk endpoint, implementing a virtual com port. The rest is a matter of sending commands over it. What other "USB and hardware design issue" is there ? |
|
|
|
|
If you want to make it attractive, it needs to be as simple as possible.
Forget JSON, and just use CR-LF terminated lines, for instance. Start with 2 essential commands: one to send work to the hardware, and one to get the nonces. Make the rest optional.
By keeping it simple, it is possible to implement all of it on a cheap microcontroller on a USB stick, for instance.
|
|
|
|
Do you have the last chip in your chain feeding SPI outs back into the Pi as on the M / H boards?
I've yet to figure out why this is done.
It's not necessary, but you could use this to verify the SPI chain is working correctly. |
|
|
|
Is the level-shifter required to transform the voltage coming out of the GPIO pins of the raspberry pi(5v?) down to levels that the bitfury chips operate on(3.3v?)?
Yes, but the voltages are 3.3 and 1.8. |
|
|
|
Curious - will you be removing the resistor divider from IOREF pins on the next revision of the S-Hash board?
Correct. In fact, on the prototype of the first revision, the resistor divider wasn't even mounted. Instead a small 0-Ohm resistor was placed between the IOREF pad and a nearby VDD pad. |
|
|
|
I have 3 questions:
The level shifter in the original schematic works just fine==> the one bitfury posted?
To be safe core power was applied first, then IOVDD.==> is this needed or?
VDD => lets's forget the IOREF line. ==> so connect the VDD to the IOREF?
On the Bi*Fury USB miner we have a level shifter made from a 330/390 Ohm divider. That works fine. I've run several chips with IOVDD = 1.8V, and Vcore = 0, sometimes due to mistakes, sometimes on purpose. Nothing bad has happened. Chip doesn't get warm, and still works. IOREF = VDD works great. |
|
|
|
|
When shopping for a PC power supply, don't look at the total power, but check the manual for the power that's available on the +12V wires. It is usually less. Also, when have a multi-voltage supply, like a regular PC PSU, and you only draw power from the 12V, the voltage may drop more than in an application where the 5V and 3.3V is also loaded. The H-CARDs don't mind if the voltage drops a bit, but you'll get increased current, and this stresses the PSU even more.
|
|
|
|
CMP, CM+ and CM- that you've connected to ground are usually left not connected...
On our boards they are connected to ground. On this version of the test board, there are solder jumpers on the bottom that connect them to ground. |
|
|
|
hmmm … anyone notice anything I'm doing incredibly wrong here?
Try it without the clock connection, and let both chips use the internal clock. What are the individual hash rates for each of the chips ? How are your IO and core voltages ? |
|
|
|
I woudn't think that M-boards would be nearly as big an issue.
Correct. The m-boards are 2 layers by design. |
|
|
|
Just in case anybody is wondering, I'd like to confirm that we are really working together to make this happen. Happy mining  |
|
|
|
Yes, that was the very first prototype board, only a very few
were made. Later H-CARDs have mounting holes.
In fact, only the very first two cards were ordered without mounting holes. |
|
|
|
|
Show Posts
