Bitcoin Forum
December 11, 2016, 04:23:31 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
Author Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards  (Read 174247 times)
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
February 16, 2012, 11:24:42 AM
 #261

Heatsink placement is a bitch.

Heat sink installation on USB FPGA Modules 1.15d should not be difficult if you follow the instructions at http://www.ztex.de/usb-fpga-1/usb-fpga-1.15.e.html#hs.

Only two additional things have to be considered (in comparison to the 1.15x board):

  • Heat sink removal is critical. Always unmount it by twisting (see http://www.ztex.de/usb-fpga-1/usb-fpga-1.15.e.html#hs ) tilting may damage the PCB (IMHO that happened to Turbors board)
  • Some airflow has to be ensured, either by case fans or by using the active cooling upgrade in the shop

The board is working fine. It just needs some pressure from above. I can live with that Wink It's the faster board of the two btw...

1481430211
Hero Member
*
Offline Offline

Posts: 1481430211

View Profile Personal Message (Offline)

Ignore
1481430211
Reply with quote  #2

1481430211
Report to moderator
1481430211
Hero Member
*
Offline Offline

Posts: 1481430211

View Profile Personal Message (Offline)

Ignore
1481430211
Reply with quote  #2

1481430211
Report to moderator
1481430211
Hero Member
*
Offline Offline

Posts: 1481430211

View Profile Personal Message (Offline)

Ignore
1481430211
Reply with quote  #2

1481430211
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481430211
Hero Member
*
Offline Offline

Posts: 1481430211

View Profile Personal Message (Offline)

Ignore
1481430211
Reply with quote  #2

1481430211
Report to moderator
1481430211
Hero Member
*
Offline Offline

Posts: 1481430211

View Profile Personal Message (Offline)

Ignore
1481430211
Reply with quote  #2

1481430211
Report to moderator
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
February 16, 2012, 03:32:11 PM
 #262

Heatsink placement is a bitch.

Heat sink installation on USB FPGA Modules 1.15d should not be difficult if you follow the instructions at http://www.ztex.de/usb-fpga-1/usb-fpga-1.15.e.html#hs.

Only two additional things have to be considered (in comparison to the 1.15x board):

  • Heat sink removal is critical. Always unmount it by twisting (see http://www.ztex.de/usb-fpga-1/usb-fpga-1.15.e.html#hs ) tilting may damage the PCB (IMHO that happened to Turbors board)
  • Some airflow has to be ensured, either by case fans or by using the active cooling upgrade in the shop

The board is working fine. It just needs some pressure from above. I can live with that Wink It's the faster board of the two btw...


I've always wondered what happens when you PULL a heat sink off a BGA chip.
Could some of the solder balls come undone?
The solder ball would still be there, but its contact to the PCB (or its contact to the chip itself) would be something like what happens in a "cold solder joint".
That it works when you apply pressure, and ceases to work when the pressure is gone, fits this picture 100%.
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
February 16, 2012, 04:33:37 PM
 #263

I didn't pull the heatsink ! That much i know. When i removed the pad the first time i could see that it did not made enough contact with the chip. The heatsink is perfectly flat. The latest fail could be too much of thermal adhesive. I tried to put on as little as possible. Either way, i had my chances. Now there is no way to remove the heatsink without serious damage.

Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
February 16, 2012, 04:48:20 PM
 #264

Module 1.15x fan failure during mining
============================

Let me start out with pointing out that it was not ZTEX's luxury fan (retail cost $29.99 or $19.99 or something like that) that failed,
but my cheap fan from China.
Which has 2mm pitch connectors and which I had attached to the 1/10" pitch connectors by a crudely made adapter cable.
 
It failed on Wednesday.

Here's what happened in  detail, starting with a time when it is still mining along happily:

ztex_ufm1_15d3-04A32DC6E1: Set frequency to 216.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 210.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=198.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=198.0MH/s,  submitted 0 new nonces,  luckFactor=1.02
ztex_ufm1_15d3-04A32DC6E1: f=198.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=198.0MH/s,  submitted 0 new nonces,  luckFactor=1.02
ztex_ufm1_15d3-04A32DC6E1: f=198.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=198.0MH/s,  submitted 1 new nonces,  luckFactor=1.02
ztex_ufm1_15d3-04A32DC6E1: f=198.00MHz,  errorRate=0.23%,  maxErrorRate=0.29%,  hashRate=197.5MH/s,  submitted 1 new nonces,  luckFactor=1.02
ztex_ufm1_15d3-04A32DC6E1: f=198.00MHz,  errorRate=0.39%,  maxErrorRate=0.49%,  hashRate=197.2MH/s,  submitted 0 new nonces,  luckFactor=1.02
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 210.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 216.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=204.00MHz,  errorRate=3.67%,  maxErrorRate=3.67%,  hashRate=196.5MH/s,  submitted 0 new nonces,  luckFactor=1.02
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 210.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 216.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 210.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=210.00MHz,  errorRate=7.43%,  maxErrorRate=7.43%,  hashRate=194.4MH/s,  submitted 0 new nonces,  luckFactor=1.03
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 210.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=192.00MHz,  submitted 0 new nonces,  luckFactor=1.05
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 210.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=192.00MHz,  errorRate=0.50%,  maxErrorRate=0.50%,  hashRate=191.0MH/s,  submitted 0 new nonces,  luckFactor=1.05
ztex_ufm1_15d3-04A32DC6E1: f=192.00MHz,  errorRate=0.85%,  maxErrorRate=0.92%,  hashRate=190.4MH/s,  submitted 0 new nonces,  luckFactor=1.05
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=198.00MHz,  errorRate=3.73%,  maxErrorRate=3.73%,  hashRate=190.6MH/s,  submitted 0 new nonces,  luckFactor=1.05
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 210.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=192.00MHz,  errorRate=1.47%,  maxErrorRate=1.62%,  hashRate=189.2MH/s,  submitted 1 new nonces,  luckFactor=1.06
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=192.00MHz,  errorRate=2.49%,  maxErrorRate=2.61%,  hashRate=187.2MH/s,  submitted 0 new nonces,  luckFactor=1.07
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  submitted 1 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=0.00%,  hashRate=186.0MH/s,  submitted 1 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=0.00%,  hashRate=186.0MH/s,  submitted 0 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=186.0MH/s,  submitted 1 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=186.0MH/s,  submitted 3 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=186.0MH/s,  submitted 1 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=198.00MHz,  errorRate=6.29%,  maxErrorRate=6.29%,  hashRate=185.6MH/s,  submitted 0 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=0.47%,  maxErrorRate=0.57%,  hashRate=185.1MH/s,  submitted 0 new nonces,  luckFactor=1.08
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 204.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=204.00MHz,  errorRate=9.74%,  maxErrorRate=9.74%,  hashRate=184.1MH/s,  submitted 1 new nonces,  luckFactor=1.09
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=1.16%,  maxErrorRate=1.23%,  hashRate=183.8MH/s,  submitted 1 new nonces,  luckFactor=1.09
New block detected by long polling
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=1.51%,  maxErrorRate=1.63%,  hashRate=183.2MH/s,  submitted 2 new nonces,  luckFactor=1.10
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=1.63%,  maxErrorRate=1.64%,  hashRate=183.0MH/s,  submitted 1 new nonces,  luckFactor=1.10
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=2.36%,  maxErrorRate=2.40%,  hashRate=181.6MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=186.00MHz,  errorRate=3.13%,  maxErrorRate=3.13%,  hashRate=180.2MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 180.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.00%,  hashRate=180.0MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.00%,  hashRate=180.0MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.47%,  maxErrorRate=0.47%,  hashRate=179.2MH/s,  submitted 0 new nonces,  luckFactor=1.12
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.29%,  maxErrorRate=0.47%,  hashRate=179.5MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.19%,  maxErrorRate=0.47%,  hashRate=179.7MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.13%,  maxErrorRate=0.47%,  hashRate=179.8MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.09%,  maxErrorRate=0.47%,  hashRate=179.8MH/s,  submitted 1 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.07%,  maxErrorRate=0.47%,  hashRate=179.9MH/s,  submitted 1 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.05%,  maxErrorRate=0.47%,  hashRate=179.9MH/s,  submitted 0 new nonces,  luckFactor=1.11
New block detected by long polling
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.04%,  maxErrorRate=0.47%,  hashRate=179.9MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.28%,  maxErrorRate=0.47%,  hashRate=179.5MH/s,  submitted 0 new nonces,  luckFactor=1.11
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 198.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 180.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.73%,  maxErrorRate=0.73%,  hashRate=178.7MH/s,  submitted 0 new nonces,  luckFactor=1.12
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=0.98%,  maxErrorRate=1.23%,  hashRate=178.2MH/s,  submitted 0 new nonces,  luckFactor=1.12
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=1.19%,  maxErrorRate=1.23%,  hashRate=177.9MH/s,  submitted 0 new nonces,  luckFactor=1.12
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 180.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=1.47%,  maxErrorRate=1.54%,  hashRate=177.3MH/s,  submitted 0 new nonces,  luckFactor=1.12
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=1.81%,  maxErrorRate=1.88%,  hashRate=176.7MH/s,  submitted 1 new nonces,  luckFactor=1.13
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=1.78%,  maxErrorRate=2.06%,  hashRate=176.8MH/s,  submitted 0 new nonces,  luckFactor=1.12
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=1.76%,  maxErrorRate=2.06%,  hashRate=176.8MH/s,  submitted 0 new nonces,  luckFactor=1.12
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=1.96%,  maxErrorRate=2.11%,  hashRate=176.5MH/s,  submitted 1 new nonces,  luckFactor=1.13
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 180.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=2.34%,  maxErrorRate=2.37%,  hashRate=175.8MH/s,  submitted 0 new nonces,  luckFactor=1.13
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=2.90%,  maxErrorRate=2.93%,  hashRate=174.8MH/s,  submitted 0 new nonces,  luckFactor=1.13
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 180.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 174.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  submitted 2 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  hashRate=174.0MH/s,  submitted 2 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=174.0MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.20%,  maxErrorRate=0.25%,  hashRate=173.7MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 192.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 180.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 174.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.41%,  maxErrorRate=0.43%,  hashRate=173.3MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.54%,  maxErrorRate=0.60%,  hashRate=173.1MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.41%,  maxErrorRate=0.60%,  hashRate=173.3MH/s,  submitted 2 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.30%,  maxErrorRate=0.60%,  hashRate=173.5MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.23%,  maxErrorRate=0.60%,  hashRate=173.6MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.17%,  maxErrorRate=0.60%,  hashRate=173.7MH/s,  submitted 2 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.34%,  maxErrorRate=0.60%,  hashRate=173.4MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 186.00MHz
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 174.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.73%,  maxErrorRate=0.80%,  hashRate=172.7MH/s,  submitted 0 new nonces,  luckFactor=1.15
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 180.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=180.00MHz,  errorRate=4.15%,  maxErrorRate=4.15%,  hashRate=172.5MH/s,  submitted 0 new nonces,  luckFactor=1.15
ztex_ufm1_15d3-04A32DC6E1: Set frequency to 174.00MHz
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=1.03%,  maxErrorRate=1.26%,  hashRate=172.2MH/s,  submitted 0 new nonces,  luckFactor=1.15
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.77%,  maxErrorRate=1.26%,  hashRate=172.7MH/s,  submitted 0 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=0.80%,  maxErrorRate=1.26%,  hashRate=172.6MH/s,  submitted 1 new nonces,  luckFactor=1.14
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=1.09%,  maxErrorRate=1.26%,  hashRate=172.1MH/s,  submitted 0 new nonces,  luckFactor=1.15
ztex_ufm1_15d3-04A32DC6E1: f=174.00MHz,  errorRate=1.05%,  maxErrorRate=1.26%,  hashRate=172.2MH/s,  submitted 0 new nonces,  luckFactor=1.15
Warning (try 1): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 2): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 3): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 4): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 5): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 6): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 7): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 8 ): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 9): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


Warning (try 10): libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command.


ztex_ufm1_15d3-04A32DC6E1: Error: bus=bus-0  device=\\.\libusb0-0002--0x221a-0x0100: Read hash data: libusb0-dll:err [control_msg] sending control message failed, win
 error: The device does not recognize the command.

: Disabling device


So, it kept throttling down, the error rate went up, it throttled down some more and finally it seems the USB microcontroller got too hot from the radiated/conducted heat and stopped working properly, which in turn prevented the FPGA from getting more work (well, the FPGA's flip-flops would still be toggling, right?)

This morning, I re-attached the Xilince "luxury" cooler and restarted the mining software, whereupon...
(scroll down to read the shocking facts)




























































...IT WORKS AGAIN!  Grin
catfish
Sr. Member
****
Offline Offline

Activity: 270


teh giant catfesh


View Profile
February 16, 2012, 06:31:31 PM
 #265

The kit looks nicely built - it doesn't look like I can make any use of the microSDHC card slot built onto the 1.15d, sadly, because the FPGA is too close to the card slot and the heatsink required will block any use of the card slot. OK, it'll have to be programmed via USB - not the end of the world...

microSD card can be used if you mount the heat sink within the frame in the silk screen: http://www.ztex.de/usb-fpga-1/usb-fpga-1.15.e.html#hs
Excellent - I'll look into doing this instead. I like the flexibility of the 1.15d for other potential applications so plan to build my BTC mining rig with 1.15d boards only - the microSD card will be useful for one other application I've got in mind, though whilst I'm on a steep learning curve, an old college mate is a VHDL expert (and ex-consultant) so I'm in touch with him regarding other possibilities...

Quote
I don't want to have to buy the expensive FPGA SDK, for obvious reasons. However, all your free tools *ought* to compile under Mac OS X - at least on Intel powered Macs. Will let you know if I hit any roadblocks...

The ZTEX SDK is free: http://www.ztex.de/firmware-kit/. The Xilinx ISE is not required.

For porting BTCMiner to a other OS's the JNI library has to be compiled for that target OS, see http://wiki.ztex.de/doku.php?id=en:software:porting. Under Mac
Code:
make -f Makefile.macosx
in the libusbJava-src directory of the SDK  should do the job.  Copy the library to the working directory of your BTCMiner and it should work.

Yup - though the Xilinx SDK *is* required if I want to change the 'code' the FPGA runs, or write a new app for the FPGA as hinted at above - am I correct? My mate used to do this for a living so has the tools. This is far-future stuff for me though. Right now I only need *your* SDK running, which I know is free, and the dependencies for this are also (luckily) free. And they all compile on OS X (even SDCC).

Many thanks for the tips though! Smiley

Great to have vendor support right here in the forum, especially as your BTC miner customers are likely to be less familiar with the environment than your *usual* market, and supporting noobs is a frustrating business Smiley Fortunately I've got a mate who can walk me through the tricky stuff - but what's great is that this thread will allow consolidation of information, tips and tricks. I'll make sure I document here any 'gotchas' and will offer my OS X environment once it's built.

Hopefully it'll become almost like a FAQ - and Ztex can put 'read this thread before emailing me' on his BTCMiner website Smiley


Need to save my pennies (though if I can pay with BTC... that's an idea) because I want my rigs to *look* good too... and after working out the power budget of each 1.15d plus 1.3 Exp-Board, plus the peak power taken by the planned fans in the enclosure, and the total power should be just over 60W for 5 boards.

This is ideal since I've got one of Ztex's 5-into-1 power cable splitters. From the thread it appears that I'm going to need to ensure that my PSU doesn't kill the boards - it's a switching supply for CCTV units, rated at 12V DC - sadly I only have a decent multimeter and no oscilloscope, but Stefan said 'if it's switching, it's regulated' and I'll be testing with one board first anyway.

The design for 5 boards is handy since the volume discounts kick in at 5 boards or more - and from what Stefan's said, make a difference. I was going to buy one-by-one but it's insane with the discounts on offer. Hopefully I'll be able to buy 5 boards next, fill the box design, and have one spare 'bench build' for testing.

It's effectively going to be like the Mac G4 Cube - transparent acrylic box with a couple of PC case fans at the bottom of the box, pulling air in (there will be fresh air available to these fans), then vertically mounted Ztex boards with the supplied heatsinks, then a couple more fans at the top pulling hot air out. I've learnt from my multi-GPU rigs that taking advantage of physics and having upwards airflow works better than horizontal flow. The enclosed rectangular 'tube' should ensure that air is forced *through* the experimental board gap and 1.15d FPGA as well as the FPGA's heatsink, and the input air should always be at ambient temp. Adding additional boards shouldn't affect the boards already in the box, unlike horizontal designs - hopefully the longer Experimental Boards should separate the airflow on the way in and ensure each FPGA heatsink gets a fresh blast Smiley

I've seen the horizontal 10-board rig with the blue heatsinks on this forum - which uses 6 case fans and (IIRC) custom twin-FPGA boards - and it looks gorgeous. I'm aiming for something of equal aesthetic standard using Ztex 1.15d boards that keeps everything well within thermal and power spec, but is less capital-intensive initially. If I had £10k to spend then I'd buy a batch and build a single rig with lots of boards, but it's a LOT of capital to lose if a PSU fails. Multiple 5-board rigs seems most sensible to me, and once I've got the Mac software built (thanks for the advice Stefan - I'm confident it'll work - I've got all the dependencies that need compiling, even SDCC works on the Mac), it will *solely* be a question of acquiring capital.

I'm not buying any more GPUs, and will be selling them off as soon as I can replace their hashing power with FPGAs. It's definitely the way forward, IMO.


The only concern I have is too many BTC miners flooding Ztex with orders, allowing Stefan to raise the price Smiley and causing delays. It's definitely a niche market for his business, and also a capricious one that could vanish if BTC collapses. I remember the initial rush to hack the mk1 iPhone - before George Hotz and a few others got a JTAG interface to the baseband and eventually went from a crude hardware hack to a software hack, the only way to use the iPhone with a non-AT&T SIM (i.e. anyone outside the USA and anyone without AT&T coverage) was by using a 'dodgy SIM' proxy such as the TurboSIM products. These were a niche product for a niche market, and suddenly thousands of new global customers were demanding these special SIM proxy cards. The owner of that business sold out immediately - then scaled up production to meet all this new demand.... which evaporated as soon as a viable software hack became available. I don't know whether that business survived as a result - certainly he was left with a LOT of unwanted stock!

Hence I'm sure Stefan is wise enough not to build *too* much extra capacity in *just* for the Bitcoin mining market - there is a real risk that the market will vanish. I respect his support for BTC massively (by offering the 1.15x and the BTCMiner bitstream) but hope that BTC remains a small niche in his overall market, so there are always enough to go round Smiley

...so I give in to the rhythm, the click click clack
I'm too wasted to fight back...


BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
February 16, 2012, 06:44:41 PM
 #266

From the thread it appears that I'm going to need to ensure that my PSU doesn't kill the boards - it's a switching supply for CCTV units, rated at 12V DC - sadly I only have a decent multimeter and no oscilloscope, but Stefan said 'if it's switching, it's regulated' and I'll be testing with one board first anyway.

I think a multimeter should be good enough to check. I run my x's @ 12V and the d's at 13.8V.

CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
February 16, 2012, 09:48:21 PM
 #267

Quote
Module 1.15x fan failure during mining

Interesting to see what happens when a fan fails during mining.  I guess the FPGA doesn't completely clock down to 0 right away due to the heatsink, but the USB controller poops out first.  Good to see that no serious damage to the board though.  Anybody suspect that it causes any damage to the USB controller/board components when the fan dies?
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
February 16, 2012, 11:02:53 PM
 #268

Quote
Module 1.15x fan failure during mining

Interesting to see what happens when a fan fails during mining.  I guess the FPGA doesn't completely clock down to 0 right away due to the heatsink, but the USB controller poops out first.  Good to see that no serious damage to the board though.  Anybody suspect that it causes any damage to the USB controller/board components when the fan dies?

>clocks down to 0

No, Stefan set the minimum at 174 MHz, but at this clock rate a PASSIVE heat sink (which my active heat sink turned into after the fan failure) seems to completely suffice (read the log that I posted).

>damage to the USB controller/board components

I think it was just operating out of spec, and thus failing to execute its program properly.
As I said, there is no evidence of any damage, and it's mining just fine.

That said, prolonged exposure to out-of-spec temperatures may cause electrolyte capacitors, but also other components, to age more rapidly than usual. But this is typically not a "bang, you're dead" event, more like "instead of an anticipated life span of, say, 6 years, we're now moving closer to 3 or 4 years".
CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
February 16, 2012, 11:24:27 PM
 #269

Quote
No, Stefan set the minimum at 174 MHz, but at this clock rate a PASSIVE heat sink (which my active heat sink turned into after the fan failure) seems to completely suffice

I see.  I didn't know Stefan set the minimum at 174.  It doesn't look like the error rate was too high either at 174 from your log.  I was initially concerned that in a cluster, some fans are bound to fail at one point.  I wouldn't want to have to check on the boards every so often, but I guess you will be able to pick up that a fan failed based on the block rates.   
catfish
Sr. Member
****
Offline Offline

Activity: 270


teh giant catfesh


View Profile
February 16, 2012, 11:28:40 PM
 #270

For the 1.15d boards - worth sticking a passive heatsink on the USB chip then? Small heatsinks intended for RAM (on GPU boards and the like) are easily found and small enough to sit on that second IC on the board.

On the 1.15x you probably couldn't do this because the main heatsink covers part of the second chip, but the 1.15d has more room, and the USB chip is a couple of centimetres from the FPGA.

I've got plenty of these little RAM heatsinks... could easily equip each 1.15d board with one... reckon it'd cause harm rather than good?

Ultimately I'd like a thermistor somewhere on the board to monitor temps, but I've found a 25mm fan to sit on my 1.15d heatsink for testing, and it has a three-wire connector intended for PC logic boards, so the speed should be easily monitored with extra logic or a separate fan controller...

...so I give in to the rhythm, the click click clack
I'm too wasted to fight back...


BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
February 16, 2012, 11:46:45 PM
 #271

For the 1.15d boards - worth sticking a passive heatsink on the USB chip then? Small heatsinks intended for RAM (on GPU boards and the like) are easily found and small enough to sit on that second IC on the board.

On the 1.15x you probably couldn't do this because the main heatsink covers part of the second chip, but the 1.15d has more room, and the USB chip is a couple of centimetres from the FPGA.

I've got plenty of these little RAM heatsinks... could easily equip each 1.15d board with one... reckon it'd cause harm rather than good?

Ultimately I'd like a thermistor somewhere on the board to monitor temps, but I've found a 25mm fan to sit on my 1.15d heatsink for testing, and it has a three-wire connector intended for PC logic boards, so the speed should be easily monitored with extra logic or a separate fan controller...

>passive heat sink on the USB chip

I don't believe in trying to fix SYMPTOMS as opposed to CAUSES.
The USB chip got too warm by conducted [via the PCB] and radiated heat - putting a black heat sink on it
might actually cause it to pick up MORE radiated heat. Thus, I'd say "no" to your heat sink idea.

>speed should be easily monitored with extra logic

Stefan does feed the fan's RPM signal into the USB microcontroller, but AFAIK it's not [yet] being monitored by the microcontroller's firmware. While that would be easy enough to do, it'll then thwart people like me who intentionally want to use [low-profile] 2-wire fans. 2-wire meaning, they don't have an RPM signal output.
(I have this vision of slotting several 1.15x boards into some kind of "card cage", vertically, and the 2 inch or 3 inch tall Xilence fan would not be compatible with that.)

Btw., I don't think it is my low-profile fan that failed - quite likely it was just my makeshift fan power wiring that came undone.
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
February 17, 2012, 05:02:39 AM
 #272

Quote
No, Stefan set the minimum at 174 MHz, but at this clock rate a PASSIVE heat sink (which my active heat sink turned into after the fan failure) seems to completely suffice

I see.  I didn't know Stefan set the minimum at 174.  It doesn't look like the error rate was too high either at 174 from your log.  I was initially concerned that in a cluster, some fans are bound to fail at one point.  I wouldn't want to have to check on the boards every so often, but I guess you will be able to pick up that a fan failed based on the block rates.   

Actually, on second thought, you may be right. During one of the "downclock of death" episodes I encountered, it went as low as 126 MHz before I stopped it. Thus, I now think you're right - it simply stabilized at 174 MHz, worked at 174 MHz for a while, before the microcontroller crashed.
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
February 17, 2012, 05:43:06 AM
 #273

Actually, on second thought, you may be right. During one of the "downclock of death" episodes I encountered, it went as low as 126 MHz before I stopped it. Thus, I now think you're right - it simply stabilized at 174 MHz, worked at 174 MHz for a while, before the microcontroller crashed.

Thats correct. I had several DCODs with my 1.15d and the controller never crashed !

Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
February 17, 2012, 05:52:35 AM
 #274

Actually, on second thought, you may be right. During one of the "downclock of death" episodes I encountered, it went as low as 126 MHz before I stopped it. Thus, I now think you're right - it simply stabilized at 174 MHz, worked at 174 MHz for a while, before the microcontroller crashed.

Thats correct. I had several DCODs with my 1.15d and the controller never crashed !

Apples and oranges.

DCOD...caused by the Bitstream not doing something 100% right when programming the DCM (digital clock manager) on the FPGA, turning DCM programming into something  like a lottery.

Cypress controller crash...believed to be caused excessive conducted and/or radiated heat from a PASSIVELY cooled FPGA.
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
February 17, 2012, 08:02:47 AM
 #275

Yup - though the Xilinx SDK *is* required if I want to change the 'code' the FPGA runs, or write a new app for the FPGA as hinted at above - am I correct?

Yes, Xilinx ISE is required if you want to do FPGA development.


ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
February 17, 2012, 08:04:58 AM
 #276

For the 1.15d boards - worth sticking a passive heatsink on the USB chip then?

The power disspiation of the USB controller during bitcoin mining should be less less 100mW.


ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
February 17, 2012, 08:28:21 AM
 #277

Interesting to see what happens when a fan fails during mining.  I guess the FPGA doesn't completely clock down to 0 right away due to the heatsink, but the USB controller poops out first.  Good to See that no serious damage to the board though.  Anybody suspect that it causes any damage to the USB controller/board components when the fan dies?

If the original heat sink is used and if there is at least free convection the board is still save if the fan fails. This only costs about 5-10 MH/s of performance. (With some well placed case fans and good airflow the 40mm fans are obsolete.)

AFAIR Inspector2211 did not use the original cooler. The board was either shut down by a USB controller overheating (there is only a small gap between heat sink and USB controller) or the overcurrent protection was triggered (more likely) by the overheating of the FPGA or a disfunction caused by overheating.

Quote
No, Stefan set the minimum at 174 MHz, but at this clock rate a PASSIVE heat sink (which my active heat sink turned into after the fan failure) seems to completely suffice (read the log that I posted).

There is no such limit. (There is an internal limit in the Firmware at 100MHz bit this limit is not visible to the host software).

I don't agree that your (non-original) heat sink without fan was sufficient. There must have been temperatures around 100°C.

But it is an good idea to shut down the board if an frequency drop (of 10%) occurs. I will add this feature to BTCMIner.


Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
February 17, 2012, 11:49:52 AM
 #278

Actually, on second thought, you may be right. During one of the "downclock of death" episodes I encountered, it went as low as 126 MHz before I stopped it. Thus, I now think you're right - it simply stabilized at 174 MHz, worked at 174 MHz for a while, before the microcontroller crashed.

Thats correct. I had several DCODs with my 1.15d and the controller never crashed !

Apples and oranges.

DCOD...caused by the Bitstream not doing something 100% right when programming the DCM (digital clock manager) on the FPGA, turning DCM programming into something  like a lottery.

Cypress controller crash...believed to be caused excessive conducted and/or radiated heat from a PASSIVELY cooled FPGA.


I never had a DCOD because of something else than passive or bad cooling, ever. But you are right that the layout of the boards is different.

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
February 21, 2012, 04:17:10 PM
 #279

A new BTCMiner version with improved overheat protection has been released. Read https://bitcointalk.org/index.php?topic=40047.msg761071#msg761071 for details.

catfish
Sr. Member
****
Offline Offline

Activity: 270


teh giant catfesh


View Profile
February 24, 2012, 11:16:25 AM
 #280

Bring on the Fear!

Test Board number 1 is connected up, 25mm heat sink applied with supplied thermal tape, baby 12V fan screwed on top (a bit wobbly - but it's not going to fall off, and I have a case fan (if needed) for horizontal airflow), and 12V feeds soldered onto the Experimental Board (I've used the Vin pin and GND since the board will be receiving a nice 12.14V from a switching bench test supply)...

Basically it's ready to switch on... I have an infra-red laser-dot thermometer handy and will be monitoring the temperature of the key components on the PCB.

What temperature should I consider 'something is wrong - panic' and cut the power? These FPGAs are rated to 70˚C according to Stefan's website - is this a sensible working temperature for the IC, or a 'maximum, not recommended continuous' temperature?

Obviously I'll be running it flat out as a Bitcoin miner, but I'd expect that Stefan's software doesn't overclock the hell out of the unit like all my GPUs, which are slowly dying due to severe lifespan reduction Smiley

I'll watch the software output, but if I've done something really idiotic and the board doesn't even report to the OS, but is consuming power somehow and overheating (shorts, etc.) then when should I pull the plug?

Also, since I'm running the 1.15d with the *much* smaller heatsink and non-Ztex-approved fan, what FPGA temperature (area temperature, as I can only measure with the IR thermometer) is a 'happy BTC mining stable temperature'?

Basically, I've decided to make sure I can get these things running first by mounting my first 1.15d board on a bench rig, then if all goes well and I've sold this spare Macbook Air and iPhone 4, I'll be contacting Stefan with a 4 or 5 board batch order. Hence the first rig is using the supplied heatsink but a tiny fan on top. My 'display case' multi-board design will have an enclosed tube with four 80mm PC case fans, two blowing air in and two sucking air out. This *should* give enough airflow to allow each board to use the heatsink only, and not require HSF stacks, which make each board too tall for my aesthetic design sensibilities Smiley

I'll also test the bench-test board with no fan on the heatsink but a single 80mm case fan mounted horizontally behind the board unless advised not to.


If I'm just about to kill my board, shout now! Cheesy Power meters and thermometers at the ready - this is going to be interesting!

PS. Stefan - BTW, you're right, I've been able to fit a microSD card onto the board with the 25mm heatsink fitted as per your instructions. It's a bit dodgy getting it in and out, a full power-down and anti-static job - but if any future further-optimised bitstreams that make use of onboard memory and mass storage become available, it's up to the job.

...so I give in to the rhythm, the click click clack
I'm too wasted to fight back...


BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!