Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards - page 9. (Read 182348 times)

LED1 blinking :/
I broke something

It's working but overheating for some reason. Check the heatsink placement.

command : java -cp ZtexBTCMiner-120703.jar BTCMiner -m p -f ztex_ufm1_15d4.ihx -ps 01-02-01

it's a correct output ?


old: bus=001  device=42 (`042')  ID=221a:100
   Manufacturer="ZTEX"  Product="btcminer for ZTEX FPGA Modules"    SerialNumber="0001-02-01"
   productID=10.13.1.1  fwVer=0  ifVer=1
   FPGA unconfigured
Firmware upload time: 101 ms
EEPROM programming time: 2441 ms
new: bus=001  device=43 (`043')  ID=221a:100
   Manufacturer="ZTEX"  Product="btcminer for ZTEX FPGA Modules"    SerialNumber="0001-02-01"
   productID=10.13.1.1  fwVer=0  ifVer=1
   FPGA unconfigured

total amount of (re-)programmed devices: 1



and try to mining :

ztex_ufm1_15d4-0001-02-01: New device: bitfile=ztex_ufm1_15d4   f_default=200.00MHz  f_max=248.00MHz  HpC=1.0H
ztex_ufm1_15d4-0001-02-01: MAC address: 0004a39e3fe9
ztex_ufm1_15d4-0001-02-01: FPGA 1: configuration time: 3255 ms
ztex_ufm1_15d4-0001-02-01-1: New FPGA
ztex_ufm1_15d4-0001-02-01-1: Set frequency to 200.00MHz

Disconnect device or press Ctrl-C for exit

ztex_ufm1_15d4-0001-02-01-1: Using LongPolling URL http://polmine.pl:8347/LP
ztex_ufm1_15d4-0001-02-01-1: Got new work
ztex_ufm1_15d4-0001-02-01-1: Set frequency from 200.00MHz to 196.00MHz
ztex_ufm1_15d4-0001-02-01-1: Set frequency from 196.00MHz to 200.00MHz
ztex_ufm1_15d4-0001-02-01-1: Set frequency from 200.00MHz to 196.00MHz
ztex_ufm1_15d4-0001-02-01-1: Set frequency from 196.00MHz to 192.00MHz
ztex_ufm1_15d4-0001-02-01-1: Set frequency from 192.00MHz to 196.00MHz
ztex_ufm1_15d4-0001-02-01-1: Set frequency from 196.00MHz to 192.00MHz
ztex_ufm1_15d4-0001-02-01-1: f=192.00MHz,  submitted 0 new nonces,  luckFactor=0.00
ztex_ufm1_15d4-0001-02-01-1: Set frequency from 192.00MHz to 188.00MHz
ztex_ufm1_15d4-0001-02-01-1: Error: Hash rate drop of 6.0% detect. This may be caused by overheating. FPGA is shut down to prevent damage.: Disabling device

(on 12V 4A power supply)

If a spark comes out from the AOZ1025DI the 1.2V regulator is destroyed. Then the FPGA does not configure. But your FPGA does configure, so this can be excluded.


7.5V/1000mA only delivers 7.5W. Including the fan the board needs about 10W. This PSU is to weak.

If PSU is to weak it will either switch off due to overload protection (the board disapears from the USB) or the load step after configuration causes a voltage drop which causes partial or full loss of FPGA configuration. Then you will see the error message you reported.

I recommend to use a 12V PSU which delivers at least 1500mA, also see http://wiki.ztex.de/doku.php?id=en:ztex_boards:ztex_fpga_boards:power_supply_selection.  (Theoretically 12V/1000mA is sufficient but usually these PSU are not intended to run permanently at the rated current and these PSU often can't handle the load step after configuration.)

I just lost $ 478, today came to me ztex 1.15x, first acted strangely after the 12V and 1000mA, you had to push the fan to be shaking a finger, and it does not detect the USB, the power supply 7.5V 1600mA similarly, the 7.5V and 1000mA also, I plugged into the 12V line from the PSU, started normally, but then flashed a spark from the chip with (i think) symbol Z1025DI, scared and turned off the ztex. After due consideration, I plugged 7.5V 1000mA again, walked normally, firmware upload, LED changed, and ZtexBTCMiner cgminer detect it correctly, but throws an example of such errors: Error: Hash rate drop of 6.0% detect. This may be Caused by overheating. FPGA is shut down to Prevent damage.: Disabling device
cgminer generate only HW errors.
But radiator is cold, does not overheat even changed the thermal grease on him Revoltec Thermal Grease Diamond .... I do not know why and how, but I think i'm broke it

Raspberry Gentoo bitcoin project is closed :/

I ordered and installed these: http://www.digikey.fi/product-detail/en/658-45ABT3/345-1097-ND/1207626

Don't want to rain on your parade....

This is my ztex:


(volt mod thread https://bitcointalksearch.org/topic/ztex-voltmod-90370)

Using stock voltage, there is maybe 4mhash to be gained with bottom cooling (1 step with ztex bitstream), if you are lucky.

I'm also interested in pictures as well. Some thermal or speed measures are also certainly welcomed.

Can you be more specific on how many MH/s increase to expect?

please send pictures of this.

I can provide solid copperplates to cool the backside of the ZTEX platine.
these professionally milled plates are 5mm thick and should increase the MH/s at least a little bit and support the longevity of the board.
prices strongly depend on volume. assuming at least 20 plates for the y-version (4 FPGAs) are ordered,
the price would approximately be 29€.
for singles approximately 15€. you can pay in BTC of course.
postage is extra. every y-plate weights about 400g. I send from germany.
please post your interest or send pm.

Thank you for your analysis. I've already contacted developers of both programs, but was trying to get some more clues as to what is causing this. You see the miner software thinks the board is not responding and thus first declares it as "sick" after 60 or 90 sec of inactivity (don't remember precisely) and tries to restart it. That seems to fail every time. Then it's finally declared "dead" after 10 minutes of inactivity. Interestingly enough, this bug doesn't seem to affect rigs which also have GPUs in them.

It's still alive, it's just twiddling thumbs. If LED2 is on the board is in power save mode. This happens if the board receives no new work for 5min.

I'm not familiar with BFGMiner please report this bug in the BFGMiner thread (or use BTCMiner).

I'm having issues running a cluster of 16 Ztex 1.15x boards with CGMiner or BFGMiner on Raspberry Pi. For some reason, 1random board dies within 1 hour and LED 2 goes on. Then it keeps mining nicely as long as I leave the dead board connected. If I disconnect the dead board, soon another board dies. Everything works on BTCMiner, so I doubt it's a USB cable. LED 2 points to the EZ USB, any ideas?

It equals to a nice round number: 1000 sec.
Only programmers notice these things

Where did you get 16:40 from? just random or is it in some spec.?

It's difficult to send a command over USB if USB cable is broken. Therefore: label it.

Furthermore only 1.15x boards have a general purpose LED which could be used for this purpose.

Not never, only for 16min 40s. This is the read timeout.

It would be nice to use the setserial-function via some "blinkserial"-option so that the called serial(s) begin to blink leds (for e.g. 3min or a time in seconds set via the option) without disconnecting. Also this could help identifying all boards while running and enabling the admin to (re)label them if needed..

Yes, again I know (having written my own pool) but if the longpoll doesen't trigger it's very likely that the longpoll connection is dead (TCP layer) and will never trigger, so to make sure the longpoll is used as much as possible, you should reconnect it!