Sorry, off topic too.


You forgot to mention that there are volume discounts, see https://bitcointalk.org/index.php?topic=49180.0, e.g.:

5 x UFM-1.15x:  $2100 /  950 MH/s = $2.21/MH
10 x UFM-1.15x:  $3900 /  1900 MH/s = $2.05/MH
25 x UFM-1.15x:  $9000 /  4750 MH/s = $1.89/MH
...

Not worth it. Used 1.15y's (and a few remaining ones that are sold-off in the shop) deliver more MH/s per price than USB-FPGA Modules 2.16b would deliver, see the message above.

You may not believe it, but there is hardware which is not only developed for BTC mining. Screw drivers, for example.

Estimated hash rate of these FPGA's is indeed 350 to 400 MH/s

Here is an interesting article about an "Efficient Bitcoin Miner System Implemented on Zynq SoC": http://www.xilinx.com/publications/archives/xcell/Xcell84.pdf

Fans are connected directly to supply voltage. Obviously you didn't supply it with power.

9V to 12V PSU that deliver at least 50W are recommended

There isn't anything strange:

> 1. Chip 3 is running with 8 degrees more then chip 4 - something to worry about?

Accuracy is about 5°C A difference of 8°C beetween hottest and coldes temperature is normal.

> 2. Chip2 is producing more errors then the other three, which results to a lower frequency and lower hashrate (of course).


I'm not involved in bfgminer and can say how these values are computed. But if you would downclock it, you probably see no hardware errors anymore.

Goal of mining software (at least BTCMiner) is to achieve maximum hash rate. And often you achieve a higher hash rate if you overclock and accept a few errors.

I can confirm that an FPGA Board with the MAC address "0004a36dd5f2" was not produced by ZTEX.

The FPGA delivers wrong results from start-up. It's no overheating issue (but may be a defect caused by overheating). Probably the only thing you can "repair" by yourself are shortcuts, e.g. caused by electrical conductive thermal grease or metal (solder) remnants.

I would only repair it if it was produced by me. Please contact me via http://www.ztex.de/contact.e.html for verification details.

Temperature sensors IC16 to IC19 (see schematics) are placed on the PCB near the FPGA. The measure a mixture between PCB temperature and air temperature below the heat sink. It's not an exact science but this sensors can detect overheating of the heat sink as well as improper installed heat sink (heat sink cold, PCB hot).

For a reparation request please use the contact form http://www.ztex.de/contact.e.html

If you bought it broken I wold charge a fee if it can be repaired successfully.

12V * 20A  = 240W,  theoretically sufficient to power 5 1.15y FPGA Boards (approx. 200W).  But if the PSU shuts down that is an indication of over current.

A guide for using ATX supplies can be found at
http://wiki.ztex.de/doku.php?id=en:ztex_boards:ztex_fpga_boards:cluster_power_supplies#usb-fpga_modules_115ysmall_clusters

A few additional hints:
* only use the 12V wires (yellow) and GND wires (black)
* Use CON3, connect 2 GND wires and one 12V wire to the terminal block
* as larger the cluster is as more critical the GND resistance becomes (current through the USB cable, never use unshielded USB cables)
* do not split the wires

Another issue: There is a load step during/after FPGA configuration. BTCMiner configures the FPGA's serially and adds delays. So there shouldn't be any problem if you use this software. But if you are using different software which configures the FPGA's at the same time this may be a problem.

Lead time for PCB's is 2-3 weeks.

Just an update about availability.

Since a few weeks there is a large interest in FPGA boards for BTC mining. (More than ever, Obviously a matter of BTC price). Because I'm not willing to produce these FPGA Boards on my full own risk anymore they are only produced upon request now. Estimated lead time is 8-12 weeks. A fraction of the production costs have to be paid in advance, before the parts are ordered. Details can be found at http://www.ztex.de/usb-fpga-1/usb-fpga-1.15y-orderinfo.e.html and http://www.ztex.de/usb-fpga-1/usb-fpga-1.15x-orderinfo.e.html .

Production of one 1.15y batch has been started last week. It can't be increased anymore.  Another one will probably start by end of next week and can be increased within a few weeks. That means I also can accept 10 and 20 unit packs until mid of May (or until the capacity limit has reached.)

Both kinds of FPGA boards are out of stock.  Since a red fat waring did not restrain customers form purchasing it (and sending money) I removed the products from the shops.

There should be an update regarding the delivery. It will also posted here.

ATM, singles are only produced on request. Minimum order quantity is 50.

Capability 0.7 is multi-FPGA support. Singles definitely do not have this.  It seems that support of singles has been removed from cgminer.

Rejected shares are mostly duplicate shares. If pool server responds to slow BTCMiner re-submits shares. Usually a few stales occur too because by default (if submitold flag is not set) BTCMiner always submits shares which are already found.

BTCMiner will be updated from time to time as long the software is used.  (ATM I'm engaged with new SDK implementations. Next BTCMiner release will not appear before February.)

Implementation of one network bandwitdh saving protocol is planned. But I have not decided which one.

Rupy, why did you ask for this feature (at least two times)? Do you have bandwitdh shortage? Your cluster requires about 100 Bytes per second.

A new BTCMiner release is available, see https://bitcointalk.org/index.php?topic=40047.msg1358157#msg1358157

A version has been released at http://www.ztex.de/btcminer.
Binaries: http://www.ztex.de/btcminer/ZtexBTCMiner-121126.jar
Source: http://www.ztex.de/btcminer/ZtexBTCMiner-121126.tar.bz2

New features are :
    * Target checking bug fixed
    * (D)isconnect command

The disconnect command is helpful if you lost only one miner from a quad board (e.g. due to an communication error) because rescan only scans for new devices on USB. In such a case disconnect the whole device (using the (d)isconnect command) and then do a rescan (using the (r)escan command).

Syntax is