The Chili – 30+GH/s BFL based Bitcoin Miner Assembly

[i3luefire]

i may just try and replace the ftdi chip

Before doing that, try shorting the center two pins on the unpopulated 0.1" connector labeled PROG. Pin 5 is MCU reset and pin 6 is ground, so it will hold the microcontroller in reset. If it's an MCU issue holding it in reset should cause the device to pop up on your computer as the FTDI chip will be able to connect. If it doesn't show up, it likely is the FTDI.

It still shows as an unrecognized device with the MCU held in reset. So it is probably the ftdi chip then.

[twib2]

When a board first starts up, the firmware makes sure the board and chips are cooled down before it starts the self test.  This helps ensure the maximum number of engines (cores) will pass self test.

LED decoder ring

The LEDs are numbered 1 to 8 with #1 closest to the USB connector and #8 closest to the power and fan connectors.  During first power up, LEDs 5, 6, 7, and 8 will light up and LEDs 1, 2, 3,  and 4 will indicate a failure code if anything is wrong with the hardware.  This happens VERY quickly - in less than a second.

If the initial hardware checks are good, #7 will blink indicating it is waiting for the board to cool down.  This will always blink for a few seconds even if the board is cold.  

Then #7 and #8 will blink indicating ASIC self test.  

After that, 1, 2, 3, 4 will indicate how many jobs from cgminer are waiting to run in the input queue.  LED 5 is just a debug output for me but it roughly indicates a job has completed - but sometimes blinks too fast for the human eye to see.  Just ignore LED 5.

I am working on some firmware updates that will fix most (or all?) of the problems the boards are having.  For example, one failure I think I have figured out is occasionally a board will jump to more than 100 GH/s but have 100% hardware errors.  I have one board that does this once per day or so and needs to be rebooted.  After chasing this for a while, I believe I have finally figured out what is going on and will have a fix in the next release.

My new Chili has been hashing well for a few days now, and I fairly often stop bfgminer and restart it with a different coin.  However, just recently, it's gotten stuck in the startup process - #7 is blinking and it never gets farther than that.  I've reseated the cooling solution 212EVO and even tried my H60 to no avail.  I've reflashed the firmware 14e again to no avail.  If I go ahead and try to use it after waiting "forever" of course bfgminer finds it just fine, but it's doing no hashing:  0 GH/s.

The weird thing is that nothing changed.  Without me even being near it (ssh'd from upstairs to the miner computer), one time when I was switching coins it starting giving 0 GH/s.  So I went downstairs to check on it.  Rebooted the computer, and it, and all sorts of combinations, but nothing.

EDIT:  Of course after I posted this, it decided to start working again.  Not sure why, unless one of my many automatic resets of the USB bus slapped it around enough to realize that it was indeed cool enough.  It's running below 70C now and hashing at 35GH/s with the cheap refurbished Corsair H60 on it - sweet!

Sorry for the "false" alarm, but I'm leaving it here in case a) someone might also benefit from knowing that they can wake up again on their own, or b) someone can help us avoid this altogether.

Cheers,
- Tye

[asjfdlksfd]

Hi,

I want to ask for that bfgminer can read and shows processor (chip) like stats from each board for Jally, Little Single.

• Is it possible to read all the stats to each chip?
• Is it possible to read the status of each chip (how many engines, temp, freq?)
• Is it possible to disable seperate chips e.g. for debugging or disabling?
• Is it possible to limit/set frequency, voltage of each chip(s) for tuning?
• Is there a list/description of all commands for the board?
• I remember about I'd more questions, but can't remember which :-)

My problems at the moment is decribed here:

Code:

ST:14  F:3  NB:720  AS:0  BW:[ 63/ 67 B/s]  E:264.26  I: 1.29mBTC/hr  BS:76.7M
 3       69.0C | 76.91/76.95/72.88Gh/s | A:167238 R:1036+213(.72%) HW:274615/4.9%
--------------------------------------------------------------------------------
 BFL 0 : 69.0C | 19.43/19.35/18.83Gh/s | A: 43253 R: 288+ 60(.77%) HW: 42887/3.0%
 BFL 1 : 44.0C | 28.22/28.24/26.49Gh/s | A: 60839 R: 355+ 83(.69%) HW:117376/5.7%
 BFL 2 : 51.0C | 29.35/29.36/27.56Gh/s | A: 63151 R: 393+ 70(.71%) HW:114359/5.3%
--------------------------------------------------------------------------------
  BitFORCE SHA256 SC from MrTeal and ChipGeek
Serial: FTWZA0UW
Kernel: bulk queue
Temperatures: 32.0C 51.0C
Voltages: 3.290 / 1.160 / 12.015

The ambient temperature is between 6 and 8 °C. BFL0 has a poor heatsink connected,
but BFL1 should have enough space to get a higher rate. It looks like only that the initialization has to disabled to much enignes, but the frequency looks like increased more and more over the time to th 26,49 effective GH/s.

Code:

 [2013-12-21 12:26:12] Acquired exclusive advisory lock on /dev/ttyUSB1                    
 [2013-12-21 12:26:12] BFL: Attempting to open /dev/ttyUSB1                    
 [2013-12-21 12:26:12] Found BitForce device on /dev/ttyUSB1                    
 [2013-12-21 12:26:12]   DEVICE: Chili SC                    
 [2013-12-21 12:26:12]   MANUFACTURER: MrTeal and ChipGeek                    
 [2013-12-21 12:26:12]   FIRMWARE: 1.2.14e                    
 [2013-12-21 12:26:12]   CHIP PARALLELIZATION: NO                    
 [2013-12-21 12:26:12]   QUEUE DEPTH:40                    
 [2013-12-21 12:26:12]   PROCESSOR 0: 15 engines @ 181 MHz -- MAP: EFFF                    
 [2013-12-21 12:26:12]   PROCESSOR 1: 16 engines @ 185 MHz -- MAP: FFFF                    
 [2013-12-21 12:26:12]   PROCESSOR 2: 12 engines @ 143 MHz -- MAP: 87FF                    
 [2013-12-21 12:26:12]   PROCESSOR 3: 10 engines @ 132 MHz -- MAP: F0F9                    
 [2013-12-21 12:26:12]   PROCESSOR 4: 14 engines @ 147 MHz -- MAP: FBFD                    
 [2013-12-21 12:26:12]   PROCESSOR 5: 10 engines @ 135 MHz -- MAP: 86BF                    
 [2013-12-21 12:26:12]   PROCESSOR 6: 11 engines @ 136 MHz -- MAP: F8DE                    
 [2013-12-21 12:26:12]   PROCESSOR 7: 16 engines @ 153 MHz -- MAP: FFFF                    
 [2013-12-21 12:26:12]   THEORETICAL MAX: 16.05 GH/s                    
 [2013-12-21 12:26:12]   ENGINES: 104                    
 [2013-12-21 12:26:12]   FREQUENCY: 154 MHz                    
 [2013-12-21 12:26:12]   CRITICAL TEMPERATURE: 0                    
 [2013-12-21 12:26:12]   TOTAL THERMAL CYCLES: 0                    
 [2013-12-21 12:26:12]   XLINK MODE: MASTER                    
 [2013-12-21 12:26:12]   XLINK PRESENT: NO                    
 [2013-12-21 12:26:12] Devices detected:                    
 [2013-12-21 12:26:12]  BitFORCE SHA256 SC by MrTeal and ChipGeek (driver=bitforce_queue; procs=1; serial=FTWZA38H; path=/dev/ttyUSB1)                    
1

Here the initialisation stat from the BFL2 which have higher frequencies but less engines enabled.

Code:

 [2013-12-21 12:28:05] Acquired exclusive advisory lock on /dev/ttyUSB0                    
 [2013-12-21 12:28:05] BFL: Attempting to open /dev/ttyUSB0                    
 [2013-12-21 12:28:05] Found BitForce device on /dev/ttyUSB0                    
 [2013-12-21 12:28:05]   DEVICE: Chili SC                    
 [2013-12-21 12:28:05]   MANUFACTURER: MrTeal and ChipGeek                    
 [2013-12-21 12:28:05]   FIRMWARE: 1.2.14e                    
 [2013-12-21 12:28:05]   CHIP PARALLELIZATION: NO                    
 [2013-12-21 12:28:05]   QUEUE DEPTH:40                    
 [2013-12-21 12:28:05]   PROCESSOR 0: 16 engines @ 313 MHz -- MAP: FFFF                    
 [2013-12-21 12:28:05]   PROCESSOR 1: 7 engines @ 311 MHz -- MAP: F00B                    
 [2013-12-21 12:28:05]   PROCESSOR 2: 12 engines @ 330 MHz -- MAP: FFF0                    
 [2013-12-21 12:28:05]   PROCESSOR 3: 9 engines @ 323 MHz -- MAP: 2FB2                    
 [2013-12-21 12:28:05]   PROCESSOR 4: 10 engines @ 318 MHz -- MAP: 85FB                    
 [2013-12-21 12:28:05]   PROCESSOR 5: 15 engines @ 337 MHz -- MAP: FFF7                    
 [2013-12-21 12:28:05]   PROCESSOR 6: 8 engines @ 306 MHz -- MAP: 0FF0                    
 [2013-12-21 12:28:05]   PROCESSOR 7: 16 engines @ 336 MHz -- MAP: FFFF                    
 [2013-12-21 12:28:05]   THEORETICAL MAX: 30.11 GH/s                    
 [2013-12-21 12:28:05]   ENGINES: 93                    
 [2013-12-21 12:28:05]   FREQUENCY: 323 MHz                    
 [2013-12-21 12:28:05]   CRITICAL TEMPERATURE: 0                    
 [2013-12-21 12:28:05]   TOTAL THERMAL CYCLES: 0                    
 [2013-12-21 12:28:05]   XLINK MODE: MASTER                    
 [2013-12-21 12:28:05]   XLINK PRESENT: NO                    
 [2013-12-21 12:28:05] Devices detected:                    
 [2013-12-21 12:28:05]  BitFORCE SHA256 SC by MrTeal and ChipGeek (driver=bitforce_queue; procs=1; serial=FTWZA0UW; path=/dev/ttyUSB0)                    
1 devices listed

And for additional information here the one from the poor heatsink connection:

Code:

 [2013-12-21 12:30:28] Acquired exclusive advisory lock on /dev/ttyUSB2                    
 [2013-12-21 12:30:28] BFL: Attempting to open /dev/ttyUSB2                    
 [2013-12-21 12:30:28] Found BitForce device on /dev/ttyUSB2                    
 [2013-12-21 12:30:28]   DEVICE: Chili SC                    
 [2013-12-21 12:30:28]   MANUFACTURER: MrTeal and ChipGeek                    
 [2013-12-21 12:30:28]   FIRMWARE: 1.2.14e                    
 [2013-12-21 12:30:28]   CHIP PARALLELIZATION: NO                    
 [2013-12-21 12:30:28]   QUEUE DEPTH:40                    
 [2013-12-21 12:30:28]   PROCESSOR 0: 11 engines @ 219 MHz -- MAP: FEB2                    
 [2013-12-21 12:30:28]   PROCESSOR 1: 8 engines @ 326 MHz -- MAP: 0FF0                    
 [2013-12-21 12:30:28]   PROCESSOR 2: 16 engines @ 164 MHz -- MAP: FFFF                    
 [2013-12-21 12:30:28]   PROCESSOR 3: 11 engines @ 327 MHz -- MAP: 07FF                    
 [2013-12-21 12:30:28]   PROCESSOR 4: 15 engines @ 155 MHz -- MAP: BFFF                    
 [2013-12-21 12:30:28]   PROCESSOR 5: 9 engines @ 276 MHz -- MAP: 40FF                    
 [2013-12-21 12:30:28]   PROCESSOR 6: 9 engines @ 265 MHz -- MAP: 40FF                    
 [2013-12-21 12:30:28]   PROCESSOR 7: 15 engines @ 143 MHz -- MAP: FFEF                    
 [2013-12-21 12:30:28]   THEORETICAL MAX: 20.57 GH/s                    
 [2013-12-21 12:30:28]   ENGINES: 94                    
 [2013-12-21 12:30:28]   FREQUENCY: 218 MHz                    
 [2013-12-21 12:30:28]   CRITICAL TEMPERATURE: 0                    
 [2013-12-21 12:30:28]   TOTAL THERMAL CYCLES: 0                    
 [2013-12-21 12:30:28]   XLINK MODE: MASTER                    
 [2013-12-21 12:30:28]   XLINK PRESENT: NO                    
 [2013-12-21 12:30:28] Devices detected:                    
 [2013-12-21 12:30:28]  BitFORCE SHA256 SC by MrTeal and ChipGeek (driver=bitforce_queue; procs=1; serial=FTWZA0XN; path=/dev/ttyUSB2)                    
1 devices listed

Comments are welcome.


Cheers...

[Hands]

Silly question on thermal pads..

1 40mm solid thermal pad to cover all 8 chips

OR

8 small thermal pads (one for each chip)?

Does anyone have any opinions?

[Spieder]

i may just try and replace the ftdi chip

Before doing that, try shorting the center two pins on the unpopulated 0.1" connector labeled PROG. Pin 5 is MCU reset and pin 6 is ground, so it will hold the microcontroller in reset. If it's an MCU issue holding it in reset should cause the device to pop up on your computer as the FTDI chip will be able to connect. If it doesn't show up, it likely is the FTDI.

It still shows as an unrecognized device with the MCU held in reset. So it is probably the ftdi chip then.

Have you tried plugging it into a different computer or loading the windrivers? I had this problem with one of my pc's, the units would randomly drop out of device manager and list unknown device. It turned out to be an issue with the usb hub and maybe funky with the win 8 install. After replacing hub and reformatting the problem went away.

[Spieder]

Silly question on thermal pads..

1 40mm solid thermal pad to cover all 8 chips

OR

8 small thermal pads (one for each chip)?

Does anyone have any opinions?

I've done both, no difference either way. I always add a dab of grease between the pad and heatsink if I use a pad. For most boards the pad wasn't necessary though.

[agibby5]

When a board first starts up, the firmware makes sure the board and chips are cooled down before it starts the self test.  This helps ensure the maximum number of engines (cores) will pass self test.

LED decoder ring

The LEDs are numbered 1 to 8 with #1 closest to the USB connector and #8 closest to the power and fan connectors.  During first power up, LEDs 5, 6, 7, and 8 will light up and LEDs 1, 2, 3,  and 4 will indicate a failure code if anything is wrong with the hardware.  This happens VERY quickly - in less than a second.

If the initial hardware checks are good, #7 will blink indicating it is waiting for the board to cool down.  This will always blink for a few seconds even if the board is cold.  

Then #7 and #8 will blink indicating ASIC self test.  

After that, 1, 2, 3, 4 will indicate how many jobs from cgminer are waiting to run in the input queue.  LED 5 is just a debug output for me but it roughly indicates a job has completed - but sometimes blinks too fast for the human eye to see.  Just ignore LED 5.

I am working on some firmware updates that will fix most (or all?) of the problems the boards are having.  For example, one failure I think I have figured out is occasionally a board will jump to more than 100 GH/s but have 100% hardware errors.  I have one board that does this once per day or so and needs to be rebooted.  After chasing this for a while, I believe I have finally figured out what is going on and will have a fix in the next release.

My new Chili has been hashing well for a few days now, and I fairly often stop bfgminer and restart it with a different coin.  However, just recently, it's gotten stuck in the startup process - #7 is blinking and it never gets farther than that.  I've reseated the cooling solution 212EVO and even tried my H60 to no avail.  I've reflashed the firmware 14e again to no avail.  If I go ahead and try to use it after waiting "forever" of course bfgminer finds it just fine, but it's doing no hashing:  0 GH/s.

The weird thing is that nothing changed.  Without me even being near it (ssh'd from upstairs to the miner computer), one time when I was switching coins it starting giving 0 GH/s.  So I went downstairs to check on it.  Rebooted the computer, and it, and all sorts of combinations, but nothing.

EDIT:  Of course after I posted this, it decided to start working again.  Not sure why, unless one of my many automatic resets of the USB bus slapped it around enough to realize that it was indeed cool enough.  It's running below 70C now and hashing at 35GH/s with the cheap refurbished Corsair H60 on it - sweet!

Sorry for the "false" alarm, but I'm leaving it here in case a) someone might also benefit from knowing that they can wake up again on their own, or b) someone can help us avoid this altogether.

Cheers,
- Tye

This happens to me sometimes and unplugging power for a few seconds helps.

[Hands]

Silly question on thermal pads..

1 40mm solid thermal pad to cover all 8 chips

OR

8 small thermal pads (one for each chip)?

Does anyone have any opinions?

I've done both, no difference either way. I always add a dab of grease between the pad and heatsink if I use a pad. For most boards the pad wasn't necessary though.

Is there a non dangerous way to test if a pad is needed or not?  Don't want to blow up a chip because it needed a pad and I only used grease.

[i3luefire]

i may just try and replace the ftdi chip

Before doing that, try shorting the center two pins on the unpopulated 0.1" connector labeled PROG. Pin 5 is MCU reset and pin 6 is ground, so it will hold the microcontroller in reset. If it's an MCU issue holding it in reset should cause the device to pop up on your computer as the FTDI chip will be able to connect. If it doesn't show up, it likely is the FTDI.

Ok I performed the test and it still came up as an unrecognized device. So that means it is the ftdi chip correct? And if so what is the mfg part number?

[Hands]

ok, first (of 10) chili's setup.

This is with an h80 water cooler, and mosfet heatsinks (that are at 150 degrees (f) so we know those are working).

That being said, does this output from cgminer look "good" or right?

 cgminer version 3.8.5 - Started: [2013-12-21 13:42:38]
--------------------------------------------------------------------------------
 (5s):32.54G (avg):34.68Gh/s | A:7268  R:0  HW:386  WU:458.8/m
 ST: 2  SS: 0  NB: 1  LW: 7497  GF: 0  RF: 0
 Connected to stratum.mining.eligius.st diff 16 with stratum as user 18eSm9qE51Y
 Block: 89ca1981...  Diff:1.18G  Started: [13:42:38]  Best share: 45.9K
--------------------------------------------------------------------------------
 Pool management Settings Display options Quit
 BAL 0:  max 49C 1.04V | 34.19G/34.85Gh/s | A:7300 R:0 HW:387 WU:460.2/m
--------------------------------------------------------------------------------

The setup has been running for about 15 minutes.

Thanks

EDIT: The commandline is just the hostname, username & password no special flags.

[MrTeal]

i have 14 chilis and 10 of them have been running for weeks and weeks without problems. the other 4 are new. 1 of the new ones runs fine for about 1-2 minutes then starts showing an error messages then it goes sick. in the midst of starting and stopping bfgminer a million times while trying to get that one working 1 of the 10 that had been running fine stopped working and now it never shows up in bfgminer even after power cycling it and switching usb ports and switching power supplies.

What do the LED lights on the chili that has the issue look like.

Remember when you power cycle, etc.. you should wait until all of the LED lights on the chili stop blinking before starting the mining software. This can cause it to hang and not be found.

What error messages are you seeing with your other chili? Have you tried switching it to a different USB port/running it solo to see if it continues with those same issues?

Hopefully we can help you out!

the one that never shows up in bfgminer goes through the normal led bootup sequence but after the leds go out and i start bfgminer nothing happens. i have not tried that one by itself yet but i did change usb ports and cables. i am trying the one that goes sick by itself right now and am waiting on it to fail to copy the error message. but it always runs at ~41-42gh with 10-15% hw.

Edit: the message is

Code:

BFL 0: Received unexpected queue result response:
BFL 0: Error: Get temp returned empty string/timed out

Edit2: the miner that does not get recognized by bfgminer shows up as an unknown device on windows. does that mean the ftdi chip is toast? because i have never had this problem before. my normal mining machine is xubuntu but i have mined with these on windows before. and i am currently mining with the other problem child on windows currently so i dont think it is a driver issue. also the one that was getting sick before has not gotten sick for over an hour. so... i am not sure what the problem was there. but eventually i will need to move it back to the mining room and out of my living room.

I have one of mine that has been giving me issues lately, and it sounds very similar to your problem. A little debugging of the VRM to read the logged faults show that it's hitting a current limit fault and the DC/DC is tripping off. It's also a great performer, 16 engines on all 8 chips. The problem was that my cooling was good enough that the temperatures stayed under the limits, and with every engine enabled and ramping up to the full voltage (1.15V) I was pulling more than 160A out of the power supply. It was hashing over 40GH/s, but it would trip the protections on the DC/DC and shut down. Limiting the voltage to 1.1V has dropped the hashrate to 39GH/s, but it also runs stable now.

I'll email you the file I used.

Ok I performed the test and it still came up as an unrecognized device. So that means it is the ftdi chip correct? And if so what is the mfg part number?
[/quote]
It sounds like it. You could try opening it up in FTDI's FT Prog utility to see if it's detected there as well.

[Hands]

I was trying BFG miner and all it does is crash with an error about locating the com  "FT_GetComPortNumber"  I can get the Chili's to hash great (well low to mid 30's) in cgminer..

I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm).  but all I get is instant crash.

Any ideas?

Win 8.1 64bit,  BFG Miner 64bit 3.8.1 and I tried 3.8.0

[lightfoot]

Is there a non dangerous way to test if a pad is needed or not?  Don't want to blow up a chip because it needed a pad and I only used grease.

Honest answer: I use pads on my jallies that have the old and new style chips (the newer ones are lower profile) on the new chips only. On the old ones I use a dab of Radio Shack $2.00 thermal grease.

Where I win is putting thermal grease on the bottom of the jally, then either putting the bottom plate on or another heat sink. Do not underestimate how much heat you can draw off the bottom of these things.

C

[Mudbankkeith]

I was trying BFG miner and all it does is crash with an error about locating the com  "FT_GetComPortNumber"  I can get the Chili's to hash great (well low to mid 30's) in cgminer..

I have installed the required BFGminer drivers ( I installed the VCP drivers at the bottom of this page, and I made sure the connected device was using those drivers http://www.ftdichip.com/Drivers/VCP.htm).  but all I get is instant crash.

Any ideas?

Win 8.1 64bit,  BFG Miner 64bit 3.8.1 and I tried 3.8.0

I have never been able to get anything to hash on win8x64

win7x86 works all the time with all my gadgets.

[hephaist0s]

I finally found a backplate I'm happy with. They're free, they come in sets of two, and only require one cut and then drilling 4 holes to get them ready. They're only 1mm thick aluminum, but they're curved on two sides which adds to their rigidity. They're also sexy black and the curved sides turn into feet when you flip them over so it makes a convenient stand for the Chili.

Just drill four holes:



Bolt it on (I put a piece of thermal padding in between the board and the backplate, mostly for spacing, though you can't see that here):



Convenient feet!








Where can one find these handy aluminum plates?

[GrapeApe]

I'm having similar issues as well. The 2 I got from batch 3 auction will reset constantly. The voltage gets up to 1.16 and then they disable themselves. If by chance the voltage stays below 1.16 all is well but it's a crap shoot. I have heat sinks on the MOSFETs.

EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.

[lightfoot]

*snort*

Actually I think part of the spate of recent jally-usb issues is related to BFL pointing the fan *down* for some reason. If you have the sides off it's a good idea, but with them on what happens is that hot air washes over the FTDI232 chip, which is the fastest way (aside from a massive ground fault) to kill the chip.

On a Chili note, I have one of those super big AL sinks and a $50 water cooling block coming on Tuesday with my new board. Would it be better to put the water block on the top or bottom of the board, and can one mount the fan heat sink to the board without a pad (just thermal grease)?

C

[MrTeal]

I'm having similar issues as well. The 2 I got from batch 3 auction will reset constantly. The voltage gets up to 1.16 and then they disable themselves. If by chance the voltage stays below 1.16 all is well but it's a crap shoot. I have heat sinks on the MOSFETs.

EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.

As of right now there isn't an option to limit voltage. Below is a version of 14e compiled to limit the voltage to 1.1V instead of 1.15V. Give that a try.
https://www.dropbox.com/s/i4rj2k1m9vrj00e/Chili14e1V1.hex

Over the break for the next couple weeks I plan to get some changes to the firmware done to allow limits to be imposed on different variables like frequency setpoint and voltage through command extensions.

BTW- Not super useful for most people since you can't use it while hashing since the mining software has the port open, but the ZlX command (lowercase "L") will return the temperature of all the chips. If you're compiling your own cgminer, you might want to add in a way to read that.

[MrTeal]

*snort*

Actually I think part of the spate of recent jally-usb issues is related to BFL pointing the fan *down* for some reason. If you have the sides off it's a good idea, but with them on what happens is that hot air washes over the FTDI232 chip, which is the fastest way (aside from a massive ground fault) to kill the chip.

On a Chili note, I have one of those super big AL sinks and a $50 water cooling block coming on Tuesday with my new board. Would it be better to put the water block on the top or bottom of the board, and can one mount the fan heat sink to the board without a pad (just thermal grease)?

C

Depends on the water block, probably. I have a Water 2.0 Extreme which is just an AseTek unit, and the base from the factory was actually pretty terrible. It was noticeably convex just eyeballing it with a straight edge. I'd put the waterblock on the top though, you're still dissipating most of the heat that way. Unless you find you really need it, I'd just use grease.

[GrapeApe]

I'm having similar issues as well. The 2 I got from batch 3 auction will reset constantly. The voltage gets up to 1.16 and then they disable themselves. If by chance the voltage stays below 1.16 all is well but it's a crap shoot. I have heat sinks on the MOSFETs.

EDIT:Forgive but how do I limit the voltage I'm using a self compiled cgminer 3.8.5 (ubuntu) I don't see device management it used to be there.

As of right now there isn't an option to limit voltage. Below is a version of 14e compiled to limit the voltage to 1.1V instead of 1.15V. Give that a try.
https://www.dropbox.com/s/i4rj2k1m9vrj00e/Chili14e1V1.hex

Over the break for the next couple weeks I plan to get some changes to the firmware done to allow limits to be imposed on different variables like frequency setpoint and voltage through command extensions.

BTW- Not super useful for most people since you can't use it while hashing since the mining software has the port open, but the ZlX command (lowercase "L") will return the temperature of all the chips. If you're compiling your own cgminer, you might want to add in a way to read that.

This is a Linux house no windows here. Is there a way to flash the firmware using Ubuntu?

Edit: Had to partition a space on the drive and install xp (aaarrggg) got them flashed and took a small hit on the hash rate but they are running. Thank You

Sorry for asking you to hold my hand Mr.Teal and thanks for uploading the modified firmware. I look forward to being able to tweak these settings myself thanks again.