Topic: BFL board project COINTAMINATION - EU facility - ORDERS OPENED for Chili - page 11. (Read 73081 times)

Not sure what is going on. Every board I did send out I manage to get it working. Test were done alone on a power supply so that might be a factor (or even power supply might be a factor as asjfdlksfd figure out) but all did run in less then 10 restarts. Ambient temperature might be a factor... Did you add any fans on a power supply? I notice that if I do that I have problems to. Need to add them after startup. How many restarts did you attempted? What I do is start all boards but connect then two by two to computer. Make two going and go to the next... But it takes time to make them run... But when they do they don't have a problem unless they get to close to 40GH to 42GH... All I did was testing ways to get it run until it run. You might use heat from one to preheat another. Not sure what order you have them since it took all boards asked my girlfriend to move them around and then put them we pack them but I would guess that top are worst hashing and at the bottom you will get better hashing units... But depends how good job of mixing did she made...

There are dedicated sense lines near the ASIC for measuring the voltage. The boards I produced use a 2Oz copper top and bottom layer, as do some of the boards Lucko made (the others are 1.5Oz, which shouldn't cause a huge difference).

The reason you don't see an increase in the temperature in bfgminer when you heat the temperature sensor is that bfgminer is reporting the hottest of the ASIC temperatures. I am not sure what is going on with that other board that runs at 29GH/s and 1.007V. Something is obviously still wrong with it as it should be working better than that. How many cores are enabled on the chips?



For everyone, I am waiting for some information from Lucko on what changes might have been made to the gerbers by the board house and whether the other boards with low voltage problems are causing similar issues to what I was seeing. I really do want you all to get boards the function properly and at full capacity, as I know there are a lot of guys out there who have been waiting a really long time to get a product. Those who have been through the wringer like dwdoc and the rest of you are the reason why I've been coming in to investigate this on the weekends, which is over and above the original agreement to just provide the board files and programming information. I do not appreciate nasty PMs and emails, and it will not help you get your boards any faster.

The 2 I have assembled both crash at:-

40c  120/140w at the wall  27Gh at 5 sec    5/10Gh at the pool   HW10%/15%

when they re-set the log page scrolls very quickly:-

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

EDIT:-
3rd unit almost exactly the same:-
42c    120/140w       26Gh at 5 sec      5/10Gh at pool        HW 30%

EDIT
4th unit SUCCESS HASHING SPOT ON 

69c   power ?  w     37.5Gh at 5 sec     36.5Gh at pool     HW 3%

I WILL POST SOME DIAGNOSTICS HERE LATER TODAY

I'm thoroughly confused - is it still possible to buy one of these things with chips installed?  

Edit: After having read the thread completely, I think I'll pass.  I have enough stress keeping the Cube running reliably. 

Yes but MrTeal has one of the worst boards where symptoms are biggest... That one can't be run at more then 27GH. Some of the rest can even get to 42GH... So just slow preheat might solve 90% of the problems... I do need to remove power supply heetsinks and stop the CPU fans to avoid one board crashing at 27(power supply) and 41(fan) GH... I know that 41 crash can be solved with firmware but I just didn't get to it... And that would also mean that it will not hash at 39 but 36GH... So not sure but I think that the problem is only at a some point in voltage increase and only if right conditions are present...

I asked on december 29th, if the "gentle preheat" could be done from the firmware.

  Question:-
   Maybe the (firmware) needs a bigger time delay between the voltage steps, to give the chips and temperature more time to stabilize, before the next step up.
   This may also help with the low temperature start up problems (sub zero ambient) some users are reporting. (gentle pre-heat)

  Reply:-
   The issue I am seeing doesn't really have anything to do with the voltage steps. What is happening is that PWM for the first phase is causing the second phase to turn on prematurely, which is causing a
   whole host of issues.

I will also ask again, Will this help?

I told you that some need more restarts. I manage to get 7 boards going and they were not the best but the worst. But I do use 2 rail 600W PSU. It might be that every board has it own rail. It takes me about 1 hour to make them all run but once they do run they run stable...

I see this same massage:
BFL 0: Received unexpected queue result response:
BFL 0: Error: Get temp returned empty string/timed out

But after a minute it is gone and it reconnect to board... It doesn't start hashing until selftests are done(blinking 7 and 8 ). And if ambient temperature is too high 7 will not stop blinking since board is too hot.

As bx8389 told you(and I before making them). Board needs restarts and after that it runs OK... It only needs to go over critical voltage... Once over it runs...

EDIT: asjfdlksfd made a good point running boards couple of times heat it up so that might be what solves the problem.

EDIT2: MrTeal what about firemwere that will run board for 5 minutes at 0,9V and then go up? It might be solution for many boards if preheating is all that is needed...

Hello Mr. Teal,

how did you control the output Vcore at chip level? Are there a sense lines added to the bucket controller? Is U12 the related bucket controller? I'm still guessing that the Vcore measured on chips could be higher than on your own produced boards maybe Lucko used a board with better/thicker copper so the potential difference between FETs and BFL chips is less than on your boards. This could be brings the FETs earlier in the limit.
(This is the reason why I want to have a Z-Command to limit the voltage floatable and not fixed in the FW  )

I want to understand why my low voltage resetters are working stable if I preheat the FET with my soldering iron gun. How is the temperature measured which is shown in bfgminer from the M-menu:


 BFL 0 : 51.0C | 28.70/28.46/27.23Gh/s | A: 5909 R:33+1(.56%) HW:14077/3.6%
  BitFORCE SHA256 SC from MrTeal and ChipGeek
Serial: FTX33YKB
Kernel: bulk queue
Temperatures: 49.0C 51.0C
Voltages: 3.290 / 1.032 / 11.890

I wonder me I cannot see an increasement of this temperatures if I use my heating gun focussed on U25 which I guessed for measure temperature near by the Buckets FET.

Remember, this board has to been reset below 1.0 V if I do a cold start. At the moment it is only hashing with 27 GH/s, but it's better than nothing (having sparrow in hands instead pigeons on roof

Also why is this board now working with > 1.0 V after preheating the pcb at bfgminer startup, if it is resets ~1.0 V before I made cold starts? The board is now running stable for 36 hours.
Another board with the same issue is working after preheating with 29 GH/s at 1.007 which has been reset at cold start ~ 0.95 V before.
I have no scope here to check the ripple and voltage near to the bfl chips with ones which have not all these issues. But in fact, more or less all 7 boards which I have now assambled have the same issue, but 5 of them are starting without active cooling of the FETs without preheating mostly.

Cheers and sorry for my mixed sentences...

Very little has gone right with this group buy. Most have been patient despite losing most of our investment. We understand it's a risky endeavor.
But at the very least we need a working board out of this. We paid above and beyond for a proven, 2nd choice board Lucko. Time to make that happen please.
And one that is properly packed when shipped.
Sorry if this is overly harsh but patience is gone.

I'll be honest this is the first I'm hearing of low volt resets. I was under the impression that the Lucko boards were reseting on the high side. At this point I wish I hadn't posted that at the top of this page....

when they re-set the log page scrolls very quickly:-

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

I will have to build them ALL to see if ANY are usable.

Should have stayed with BFL. theirs blow up after delivery.

I still have a board with reset problems and tried firmware 1.1V on it: no change on behavior.
On one other hiting near 39-40 GHs firmware gives good results: now is stable

this is 3 lucko's received friday board results after almost 48 hour hashing ( + one computer  restart to apply windows updates )
takes some restarts to put all at work but after they work without problems


 bfgminer version 3.9.0 - Started: [2014-01-06 23:06:47] - [  0 days 01:06:44]
 [M]anage devices [P]ool management [S ettings [D]isplay options  [H]elp [Q]uit
 Connected to eu-stratum-lb489kj.btcguild.com diff 64 with stratum as user ****
 Block: ...bcb35003 #279016  Diff:1.42G (10.15Ph/s)  Started: [23:37:03]
 ST:13  F:0  NB:11  AS:1  BW:[ 56/ 43 B/s]  E:470.73  I: 1.46mBTC/hr  BS:47.7k
 3      64.0C | 104.2/105.0/97.92Gh/s | A:1436 R:9+12(.65%) HW:5773/5.9%
--------------------------------------------------------------------------------
 BFL 0: 46.0C | 33.45/33.22/32.31Gh/s | A: 485 R:3+ 0(.61%) HW: 687/2.2%
 BFL 1: 58.0C | 35.93/35.91/31.66Gh/s | A: 457 R:4+ 8(.92%) HW:3346/ 10%
 BFL 2: 63.0C | 35.83/35.88/33.94Gh/s | A: 496 R:2+ 4(.43%) HW:1747/5.2%
--------------------------------------------------------------------------------
 [2014-01-07 00:12:56] Accepted 0315082a BFL 2  pool 0 Diff 83/64
 [2014-01-07 00:12:58] Accepted 01c75684 BFL 1  pool 0 Diff 143/64
 [2014-01-07 00:12:59] Accepted 00be9b4a BFL 1  pool 0 Diff 343/64
 [2014-01-07 00:13:00] Stratum from pool 0 requested work update
 [2014-01-07 00:13:00] Accepted 0122d732 BFL 1  pool 0 Diff 225/64
 [2014-01-07 00:13:03] Accepted 039b74e0 BFL 0  pool 0 Diff 70/64
 [2014-01-07 00:13:11] Accepted 01624475 BFL 1  pool 0 Diff 184/64
 [2014-01-07 00:13:15] Accepted 00d41cd6 BFL 1  pool 0 Diff 308/64
 [2014-01-07 00:13:15] Accepted 03049b54 BFL 2  pool 0 Diff 84/64
 [2014-01-07 00:13:21] Accepted 00ecc934 BFL 1  pool 0 Diff 276/64
 [2014-01-07 00:13:26] Accepted 02ada407 BFL 1  pool 0 Diff 95/64
 [2014-01-07 00:13:30] Stratum from pool 0 requested work update
 [2014-01-07 00:13:31] Accepted 03e4349b BFL 1  pool 0 Diff 65/64
 [2014-01-07 00:13:31] Accepted 0152442c BFL 1  pool 0 Diff 193/64


Regards

too many chips in one basket.
I have a bad feeling they are all the same.(2 boards at random from a box of 16)

WOW, I stand corrected. I'm sorry to hear that.

If they are resetting at low power, it is likely not the same issue that requires using the 1.1V firmware. I would guess that it might be similar to what I am seeing on this one, but I am waiting for some confirmation on tests from Lucko that his other boards have the same cause. If that's the case (and he gives me permission to mutilate this PCB) I will try verifying what the problem is more in depth and it's possible a fix can be done going forward for people haven't gotten their boards made yet.

For those that already have their boards, it will depend on what the root cause of the problem is. If all the boards exhibiting the low power shutdown have the same issues as the one I have, it's entirely possible that it cannot be fixed and still function to its potential. If the problems with the power supply are consistent (IE, it's always the same phase causing problems) it's possible that you could send the boards back to Lucko and he could modify them to run with one phase less and a max current of 120A instead of 160A.

messed around for a good 2 hours this afternoon, then re-flashed to the 1.1v firmware, NO DIFFERENT after another 8 hours.
my combined hash rate for 2 chili's is still just under 10 Gh since lunchtime.

From Mr.Teal himself in the chili thread.



Second I don't have my Lucko boards yet so this may really mean nothing, but I was having this very issue with 2 boards from batch 3 (I've actually posted this several times). I'm a little confused as to why NOBODY is trying the 1.1V firmware. I flashed the modified firmware and it fixed them immediately, but I took a small hit on the hash rate until my MOSFET heat sinks came in a day or 2 later and I stuck them on, put a fan on them and my hash rate is a consistent 39GH/s on both of them holding steady at 1.1V using CGMiner 3.9.0. Before I flashed the modified firmware they would shoot up to 40-41GH/s, the voltage would eventually hit 1.16V and then they would reset.  So I guess using the internal safeguards to limit the boards by heating them up would work because they will throttle themselves back but wouldn't it be easier to just flash the firmware and then if you don't mind report back to us what the results are?

All of you that are having issues with the boards resetting should at least for shits and grins flash the modified firmware

I'll be honest this is the first I'm hearing of low volt resets. I was under the impression that the Lucko boards were reseting on the high side. Ignore the above.

For the Linux households out there from a helpful forum member. For the usb to work you also have to add your user to the virtual box group (I hope I said that right).


MudBankKeith I was under the impression you had already flashed them with the modified firmware. If so are you still having issues after?

EDIT: BTW I am using the CoolerMaster 212 EVO for coolers on those 2 boards. I have others with the Accelero TT2 and they don't have this issue but they run much hotter than the others and hash at 32-34GH/s.

Come on Lucko & MrTeal we need a proper fix for this,

For the prices paid for these devices they are not very good.(as hashing goes, a box full of asic erupters would be more reliable)

Thats exactly what I have mostly with all boards from Lucko. Mostly I could fixed them by do not cool the psr so the ambient temperature will limit the core voltage. FW 1.1V Fix shoulf fix the problem. But some of them allready resets at 1.0 V. Cooling doesn't helped so I used my soldering heater to warm up the board at starting bfgminer. This looks like a workaround because the limit which is shown in "Manage devices" section rises the 45 °C earlier than the voltage arives 1.1 V. With this Voltage and ~27 + ~29 GH/s the 2 problem boards are mining stable at the moment. If I cool the vrms the boards resets again.
Facts: Preheating will bring the boards to mining status but it's not optimal to hash lower 30 GH/s :-(

Still my suggestion is to limit or set the voltage manually to a point which left the boards been stable.
Maybe it could be integrated in bfgminer/cgminer.

The box is ok but the contents were a bit loose(moving within the bubble wrap)

As to the boards working....................................
I have assembled 2, both have the same fault....................
eventually they start and hash for about 2 minutes, hash till the power rises to about 140 watts then reset.
BFG tries to do a restart after 60 seconds, sometimes they restart, sometimes they cycle again for another 60 seconds.