No. Internal fan will control the PWM fan based on the knob on the board. If you want temp control, you set up a temp measurement and pipe it through the external fan control.

That depends on you. We typically ship them out with internal fan and external-on enabled. If you don't want to be able to turn it on from an external signal, kill EON. If you want to control the fan speed from an external source instead of the built-in knob, turn that on.

Switch 1 enables internal fan control
Switch 2 enables external fan control
Switch 3 enables external-on function

Novak and I are working on a design for a control board that'll interface to six or eight of our PSU boards at a time (both the D750 and DPS2K boards, plus whatever we release in the future since they should all have a standard header) for monitoring and control. The current plan is to make the board-end giblets connect to the control base with ethernet cable, so you can spread things out however you want with what lengths of standard cable are available; the control base would tie to a computer through USB. We'll probably write some basic linux command-line software for monitoring and control, possibly with a basic webpage port for displaying status. If everything works how it should, it's a thing that should run off a Pi without trouble. Still in design phase, but more people expressing interest will probably speed that up. We figure on deploying some at least within our own hosting setup to test and mess with, should make it easy to power-cycle miners remotely as well as monitor PSU status and such.

Partly because of a multi-point failure of finances (deposit computer errors and slow/non-paying customers) we were delayed about two weeks on ordering materials for the next batch of DPS2K boards. The next round should be available starting in about 4 weeks. We'll open up a (pre)order queue probably sometime next week once we have a better idea of when we'll be shipping.

The controller has an internal switching DC regulator, and works with a range of DC inputs. I've got controllers running both 5V and 12V with no issues.

What I figure on doing is helping Novak trace the protocol, cook up a cgminer driver that talks to the boards directly, and then probably not buy ASICMiner hardware again. I know my business is small but I've always enjoyed messing with their hardware and this is a fairly heavy dropped ball that turns things pretty sour.

I'd still like to see some quantitative data to back your claim. Additionally, can you recommend an alternative with a similar power output and price range?

As the 750W PSU was at 110-115% load and well WELL past its peak efficiency, also being used hardware with unknown life already, comparing a different load on a probably relatively new platinum-rated PSU at 20% rated output is sorta irrelevant. If you quadruple your load and subtract an erroneous 20W from fans, you're still about 900W and only 80% load so closer to peak efficiency point. Hook up about six boards to your PSU and see what the efficiency looks like, that'll be a comparable measurement.

Additionally my current meter only had one decimal of precision, so if you care about sigfigs the numbers aren't that reliable, could be high or low (which is mentioned in the linked post). In any case, D750 is definitely not a recommended option for these Tubes as they draw well over the rated load and reliability at such loads is questionable at best. The numbers given are for reference and estimation only.

I'll talk to Novak about getting a Windows build of our slush fork up sometime. Right now he's a bit busy figuring out the UART protocol to see what we can do about making a better controller.

I guess I don't see the potential for damage, so long as your fingers were not buttered beforehand. Additionally if you don't need a thin screwdriver and careful finagling, the entire thing can be done with a power driver and #2 philips bit. I was using a Porter Cable 18V screwgun to assemble all 31 tubes, had zero issues.



Here's the numbers I got, off one of our D750 PSU kits. No temperature data.

MHz   GH   IAC   VAC   WAC   W/GH
270   829   4.4   212   933   1.13
260   799   4.25   212   901   1.13
250   768   4.1   213   873   1.14
240   737   3.9   213   831   1.13
230   707   3.8   213   809   1.14
220   676   3.6   213   767   1.13
210   645   3.5   213   746   1.16
200   614   3.3   213   703   1.14

https://bitcointalk.org/index.php?topic=735982.msg8544454#msg8544454

Once Novak's done playing with my test Tube for controller stuff I'll probably look at hacking the VRMs for undervolting and get some performance data.

A few notes - I've assembled over 30 of these things, and the easiest process I found was to lay out the heatsinks, stick on the thermal pads, stick on the PCBs, then assemble into the housing. This kept all screws (there are 164 total, not 168) visible at each step as you don't have to fight with the endcaps to access some of the board screws.

Additionally, mmpool.org was tested functional with Tubes.

Unless there's something I've overlooked in the last week of jacking with the software on these, Tubes do not speak Getwork so using slush's standard proxy will not work with port 8332. Additionally using slush as a stratum forwarder will not work because of the extranonce2 length issue. I have just tested this with the version you linked to and found it to still be the case. www.gekkoscience.com/misc/mining_proxy.py should work on linux and incorporates the code required to fix that problem with slush-based pools (I've been using it on ozcoin successfully for a week). Additionally https://bitbucket.org/ckolivas/ckpool run in proxy mode (ckpool -p) has the same fixes.

Novak is our resident tech wizard, case anyone's wondering. We were already looking into this issue and have no problem helping someone else out that's already farther down the path.

I'm not sure if slush has failover; if it does I've never used it. ckpool in proxy mode I think implements round-robin, which is to say if your first pool fails it mines at the second, until the second pool fails.

I've got three different installs of 5 Tubes on 2x DPS2K that have been running for a week solid. One had issues I thought might be heat-related, but it was a faulty PSU. Replacement has been going steady since Sunday.

Miner tested doesn't mean jack if it's not also miner approved.

Unless I screwed something up, running the mining_proxy.py in www.gekkoscience.com/misc/slush_gekko.tar should fix stratum packets to work on other slush-based pools. I've been running it for ozcoin connection for three hosting customers since Saturday or so.

We're still working on what it'd take to make them properly compatible with brickpools.

We also are gonna look into the board-level protocol (as these are based on an open-source design, there might be good enough reference code) and see if we can't fork cgminer to talk to them in a way that doesn't suck, using a Pi or something else decent embedded linux. Just throwing that out there. Might be nothing happens, but we're looking into it.

They also have always kept a pretty tight reign their code. Every Blade or Cube that came across my bench I tested to see if I could get a firmware dump, every one was code-locked. The best I could get out of Friedcat as far as a hex dump to repair controllers was a replacement controller board with a preflashed IC. Nobody that I've talked to had better luck, and I highly doubt these Tubes will be any different. Unless they do something about firmware, the best bet might be to sniff the serial protocol for how work is divided up among the chips and make your own controller that doesn't suck with its own code that doesn't suck.

How many units have you tested? Is your 82% based off a statistical mean of samplings or a single data point? If you like I can set up an adjustable dummy load and some AC metering to get an accurate sample of in/out efficiency numbers across the load range from a dozen or so random PSUs for a bit of rigor.

I was basing the efficiency estimation off the 80Plus certification for the model PSU as found here: http://www.plugloadsolutions.com/psu_reports/DELL%20INC_Z750P-00_750W_SO-81_80+_Report.pdf
The indicated form factor is different but the manufacturer, model number and all other specifications are the same so I assume it's the same design/circuitry in a different package, which is not uncommon.

As far as anecdotal evidence goes (and I might ask bobsag3 to confirm this), when Minersource started shifting their hosted units to the Dell Z750P and our boards, they reported a noticeable drop in power consumption over the ATX PSUs they'd been using up to that point (as well as increased reliability). I'd think a large-scale hosting facility would have mentioned sometime in the last six months if their power bill had gone up 10%.

If it's desired that I set up some testing, I'll try to find the time to do so and get some good data for the community rather than relying on the evidence of customer feedback and official documentation. If it turns out that one of the primary selling points for these boards is disingenuous then I guess we have a problem.

If you're mining somewhere with no issues, what reason is there to switch? Slush recoded their backend specifically so people could mine there on these Tubes.

Though... what's up with that error rate?

www.gekkoscience.com/misc/slush_gekko.tar

That there should be the current (experimental) code we're working on slush proxy to make Tubes compatible with slush-based pools. I've got an instance running on ozcoin without any problems, haven't really tested any other pools but it's worth a shot. I don't think the install script works properly something or other, but ./mining_proxy.py should fire up what you need

He probably meant ghash went down so he joined mmpool as an alternative.