Topic: Open Source Avalon Gen2 55nm Board (Read 35937 times)

afchafch, I will buy a bulk amount of those PCB's too. please tell me the shipment and the cost by 1000. I'll need an assembly service too. I

Thanks!

Somekindabitcoin, I answer you in PM.

I will buy a bulk amount of those PCB's. Tell me price per thousand and where you're shipping from. I'm in hawaii. Direct me to an assembly service as well. I want to place them in my immersion tank. Thanks.

Who want to buy last 8 PCBs?
http://www.ebay.com/itm/251514968840?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1555.l2649
http://www.ebay.com/itm/251506931170?ssPageName=STRK:MESELX:IT&_trksid=p3984.m1555.l2649
Price was reduced.

Im keen on giving this build a go but would like someone to contact me with supporting help
K16 were fun to build but this looks alittle more techy

excuse my English.

Firstly I thank Form for maintenance are sharing open source.
I downloaded the document map on git.
My question is, what software do you use to see patterns, I did not find this information in the readme.
my system is Linux.

I did trying, but with no luck, i cant install winusb driver with zadig, i can install libusb driver and cgminer see "something"    but thats all. i will try it again i just dont have time now ...

On the other hand my boards are here working great with Ostenbacken's firmware, i can pull out even 1.8g from chips but i did try that with 3 chips in both banks, i really did not mesaure power draw and coller needs to be well BIG so, i leave the boards with 10 chips on ~ 14gh and that is working great.

some pics:





And Hubs: 



And that is running on guild ...



Another question, can someone make i2c connection to work ? i am newbie for software so that is HUGE task for me, You can send offers here or PM

Cheers,

Do anyone has windows miner solution? I can't figure it out how to run this on windows...

That's perfect. It seems that you did it right. Now what's left is to optimize your heatsinks, and you could go up to 1.6 - 1.7GH/s per chip.
These chips are inexpensive so I was thinking about building them into my design to replace the thermistor. Though the sensors are accurate, given the above considerations, their measurement would be only good for the purposes of thermal shutdown and some rough monitoring of the module condition. Perhaps the performance of forced air cooling system could be also evaluated based on this sensor data. I'm going to integrate several boards into a rackmount case, and there I'd need to take care of aerodynamics, fan locations, etc.

Yes, frequency of 1000 gets 16GH/s on a 16 chip board. I'm suggesting that measuring the junction between the heatsink and the chip is easier and reusable for reference measurement. I wasn't sure if you were talking about using the MCP9700A to take that measurement for reference or building it into your design.

Ok, so is it correct that you're getting the correct per-chip hashrate with my firmware?
I guess you misunderstood me. You're talking about building a precision thermal sensor whereas what I had in mind is to estimate junction temperature based on indirect off-junction temperature measurements. For instance, you can measure temperature drop at two points in a heat conductor. If thermal conductivity is known, this will give you an estimate on the amount of heat that passes through it. You can then extrapolate the temperature drop into the junction, if thermal conductivity between junction and your measurement points is known. Perhaps with additional measurements and calibration, you can do it pretty accurately, if you dare to perform everything that is needed. A MS degree in physics is recommended

But I don't think that it's really necessary. In my case, the chips work well (1.725GH/s per chip) and this can justify that they don't overheat. I do get the heatsink temperature reading that can be used to judge if the fan has failed or smth, so that the software could stop chip operation to prevent damage.
That's a sustained temperature reading. They work non-stop for several days in this mode.

They're all 16 chip boards. I misunderstood your logic as entering the frequency yielded a specific hashrate. Yes, the frequency seems to correspond with the number of chips on board. When I switch the boards out they yield the same hashrates so something is going on with the power supply or operating system I'm not sure which yet. My step up transformer that runs my 220V BGA station went down so I had the chips placed professionally at Mastek Innerstep, which by the way if anyone wants professional chip placement I already paid for the stencil I think they want $25 a board for 16 chips but the stencil would work for less chips obviously. PM me for contact info.

I don't have a lot of USB cables so I wan't sure if one was messed up or not. I'm just shooting darts for the difference between my two sets of boards. I figured mabey high data transfer coupled with lead resistance. It doesn't matter, like you said I used a 6 foot PS3 controller cable and nothing changed.

If someone blows up a regulator please post details In the mean time I'll keep stepping up a 16 chip board to blow one up on purpose and report back. My better thought is to lift the inductor used for the overcurrent protection and take AC and DC measurements there.


I've taken these measurements for several companies, you can't do anything about the inside of the chips to the best of my knowledge but most models suggest platinum with 4 wire yields at least +/- .1 C I think. You take a thin strand of platinum that's zero to at least an ice point reference and a span of 100. Then you thermal paste the platinum in between the heatsink and the chip, any exposed platinum must be insulated. Or you can buy a thin film prt also platinum that's already charted and hook it up to an Agilent meter and something like Benchlink.

You build a model of the metal instead of the system so you can reuse it. Really you can just weld (not solder) the tips of any RTD together as long as you have an idea of the composition, and do the same thing as long as you can generate ice point and 100C. It's probably only worth it if you're going to build a lot of boards. I have one set up to control the heat for an infrared reball station in my shed as well, it's pretty accurate. I favor my hand because it's easier. I was just curious how many days you've had them running at 35. 

Any details? How many chips do you have on your board? Have you recompiled the firmware with the proper number of chips? What speed are you setting in bfgminer? Have you tried lower speeds so as to exclude the effect of heating? Say, try speed=1000 and tell me if you're getting 1GH/s per chip. Are you getting any error/warning messages from bfgminer? If yes, what messages specifically? That could aid in diagnostics.

Also, have you tried to see per-chip performance? There are some APIs/command line tools that let you see how many nonces did each chip produce. Chances are that you have failed or improperly soldered chips on your board(s).

We now have multiple users using our firmware with proper results, so please be sure to verify that you did everything right.
I would consider this highly unlikely. It's like spending a fortune on your HDMI or S/PDIF cables: that won't improve your digital audio quality unless your existing cable setup was completely screwed up.
That also seems to me a bad idea. The sense pins are inputs and they normally draw little to no current, so increasing the resistance will not produce any meaningful voltage drop that is proportional to output current.
Not yet.
With hand or with a sensor, no matter how good is it, there is a fundamental problem of access to junction temperature. You can't measure temperature directly on the chip die, and that's the only one that matters. Temperature on the heatsink may be substantially lower than that on the junction if thermal coupling is poor between the chip and the heatsink. In this case the heatsink will stay cool but the chip will remain hot. Just imagine a heatsink that is not in physical contact with your chip. The same thing happens when it is in physical contact but for some reason thermal coupling isn't very good. Temperature difference also increases when the amount of dissipated power increases, so your estimation of junction temperature will be increasingly less accurate as the amount of power dissipated by chips gets higher. You could of course do all the math if you have thermal models of your system and you correctly estimate their parameters but well that's a very demanding job to do it right.

I've been using your firmware and found personally this isn't true at all. I'm still around 1280 .94V, my two boards running on Debian run around 10 GH/s. The other 2 on raspberry pi, Archlinux run at 17 GH/s. The bfgbuild, drivers and firmware are identical. I've confirmed these speeds on both multipool and givemecoins.

Can someone confirm that shorter and higher quality USB cables yield higher speeds? I'm not entirely sure yet but this may be the most cost effective upgrade you can make. I also appreciate the change to the LED.


I agree, I'm considering moving the regulator to a breadboard in an attempt to get a more accurate measurement of the output current unless someone has a better idea. An easier method might be increasing the resistance at Pin 11 (sense +) through TP1 on the regulator and measuring the change in voltage to get a better idea of the output current. Things like that work in my head, but don't always pan out in the real world. Have you had any regulators fail yet?
 

I favor the method of holding my hand slightly above the heatsinks, I've suspected via IR gun that the reported 25C is closer to 30 on my boards. I might be able to borrow a slim PRT that could take this measurement pretty accurately. Like you said all temperature measurements utilizing resistance in this method are approximate. Utilizing a 4-wire resistance and an ice point reference is probably the cheapest. I cut up a 10 ft hunk of aluminum C-Channel from the Home Depot and thermal pasted it

Ok, i dont know what was the problem with building/programing firmware last time but now works fine, i have same results with both hex, but when i change chip to 4 i have a lot of work ignored messages, i did try to change delay in the klondike driver to 0.5,0.7,1.0,1.5,2.0,2.5 the best results are on 0.5-0.7 as you said before, but i did not test board for a long time. i have real hashrate with 4 chips and after some time hashing hash rate drops a bit but not because of firmware problem but temperature problem ( very bad heatsink ATM on boards )

I will post complete test results next week when i completely populate one board with 10 / 16 chips and adequate heatsink/fans.

@Ostenbacken Can u please upload compiled hex for 10 chips too, just to have it when i start to test boards.

Please try everything I've suggested and post your results.
I've reprogrammed the LED to be on when the board is doing work and to be off when the board is idle. This was handy during debugging of idle conditions encountered when all 16 chips are mounted. Also it's more informative. Some people like when a LED is flashing fast but in case of our board, that flashing doesn't really give you much useful information about the board condition. The primary purpose of LEDs is to display some information that can aid in diagnostics. I think that the "busy/idle" display is a good application for that LED.

Hi,

the chips are soldered 2 in the first bank and 2 in second bank, yes i did change chip count to 4 and there is no much difference with that, i have some time now so i will try few things.

Ohh i forget to mention LED is always on. do you have same situation ?

Can you tell more details? What kind of errors are you getting (HW error rate or smth else)? Did you try lower speeds? Do you get the exact speed per chip according to the software setting? When you built the code, did you change ChipCount to 4 in the file "klondike.c", line 127? Also, to what locations of the board did you solder your 4 chips? There are two chains on the board up to 8 chips each. If you mount a smaller number of chips, you must distribute them evenly across chains, or the firmware will treat them incorrectly. Also the total number of chips must be even so that both chains contain the same number of chips.

Yes, it's DVDD adjustment. The max hash rate with my firmware is achieved at speed=1650 to speed=1750-1800 which may not be the same as the chip's operating frequency but it yields precisely that hashrate (i.e. 16.5GH/s for speed=1650, etc). The DVDD voltage we're using at these speeds is always below 1.06V. When measuring the voltage, be sure to attach both of your voltmeter's probes to decoupling capacitors near the chips. Otherwise measurement results may be distorted due to voltage drops across wires as high currents are flowing through them.

You should start with lower speed values like 1000, slowly raising them up while improving your thermal design and VDD setting. Once you have established a reliable operation at a lower speed, you can go higher.
I was measuring power consumption of the board and then recalculating values into DVDD current given a rated voltage converter efficiency and budgeting some 3W for 3.3V supply current. It's hard to measure DVDD current directly because the current is high and because it's hard to break DVDD circuit at one location in order to insert an ampermeter there.
Indefinitely. Our thermal design is very capable, involving heatsinks on both sides of the PCB. The thermistor was physically attached to one of the per-chip top side heatsinks and protected from forced air cooling by a layer of glue and a piece of plastic, so as not to distort measurement results due to sensor cooling. The top side heatsinks were also not very hot on touch. However, these results may still be inaccurate because of the very nature of measuring temperature with thermistors. I'm going to try the more accurate chip thermal sensors, namely MCP9700A. Also there are no means of measuring the chips' junction temperature. With heatsinks occupying all the space around the chips, you could only mount a thermal sensor on the heatsink, and then your results will depend on quality of thermal coupling between the chip and the heatsink. So even with better sensors, any temperature measurement of this kind should be considered only approximate.
http://i031.radikal.ru/1402/10/87bad2fb9ab8t.jpg

i am building a bit more boards ( 150 ) so i need that feature if its working, if not well ... hubs ...