The last sentence is interesting and perhaps key.

Why is the relay "buzzing"? A couple o possibilities:
1. The relay is defective. This would be very rare and there are many reported instances.
2. The control circuit is repeatedly activation and deactivating the relay.
I like number 2

Here is my scenario 1:
1a. The control circuit (probably involving a processor) senses the 12v supply is sufficient and energizes the relay.
1b. The extra load causes the supply voltage to drop and the control circuit  senses 12v supply is insufficient and de-energizes the relay.
1c. 1a and 1b repeat.

Here is my scenario 2:
2a) The relay closes
2b) The PSU over current protection drops the voltage.
2c) he Cube sees the voltage drop and opens the relay.
2d) The PSU no longer has an over current condition, restores the voltage.
2e) The Cube sees sufficient voltage, closes the relay
This repeats and the relay buzzes.

The supply voltage drop may be only momentary due to the current surge of powering up the device hashing. This could be caused by a PSU without enough capacity to handle the in-rush current. Or the PCI-E wires having to high a resistance (to long, wire gage to small). The "trick" of adding a substantially sized capacitor at the Cube's connector tends to support this theory.

What we need is someone with a storage-scope (or the modern equivalent) to examine two things: 1) The instantaneous voltage drop at the Cube on relay closing. 2) The instantaneous voltage drop in the PCI-E wire, this along with the resistance of the wire will provide the in-rush current. (I no longer have a storage scope.) Then we would have sone solid evidence to go on.


More info on PSU over current protection:
IEC 60950-1 that states that no single conductor can carry more than 240 W,
The ATX12V specification includes a requirement for an over current protection circuit in order to shut down any rail that pulls more than 240 W.

See: http://www.hardwaresecrets.com/article/Everything-You-Need-to-Know-About-Power-Supply-Protections/905/4 for more information.

Thanks to BillTech for the great photos and relay research!

I notice a couple of interesting things from the closeup. Here is a portion of the image with annotating rectangles I have added:


The orange annotation shows a trace across the fuse, possible for testing and insufficient to handle the full load. I suspect that trying to run the cube without the fuse would vaporize this trace--with no harm.

The two blue annotations are probably used to indicate is one of the PCI_E connectors is not in place. We have noticed that there is different results with only one connected.

From the relay spec sheet note that the max in-rush current is 40A. That the knock-off-nib is in place is probably an error and probably should be removed.

The deal with "Zope" is a mess, from the Zope 4 site:


So, Zope 3 was a fork of Zope 2 but they did not change the name. What it went on to become was not Zope but BlueBream. It was so confusing that Zope 3 was renamed BlueBream and Zope 2 was renamed Zope 4. Thus Zope 3 and Zope 4 are completely different projects, not just different versions. These guys make usb.org look brilliant when it comes to confusing naming (Quick, which is faster "Full Speed" or "High Speed"?)!

So I guess I give up, I knew better than to try but did anyway.

I have Python 2.7.5, OSX 10.9.2.

This is why I did not even try earlier, I figured it was going to be a big ball of hurt.

Yeah, I did all that.
But step 6 failed

I ran "sudo python setup.py install" again and I get:
"Error: The required version of setuptools (>=2.1) is not available"
So I sudo installed a new version of setup tools.
Then ran "sudo python setup.py install" again and I get:
"Error: Installed distribution zope.interface 3.8.0 conflicts with requirement zope.interface>=4.0.2"

As much as I love python the update mechanisms are killing it, ruby does a much better job updating it's libraries.

Tried on three other Macs, all running current release 10.9.2. One failed with the above error, the other two failed with yet different error messages. What a mess.

So I think: "If someone wrote the instructions why didn't they provide the result for download?" I guess because the dependencies in Python are just to much of a mess to insure functionality on any given system. Good thing they don't build bridges with the same care we build software.

<rant>
Typical OpenSource crapola, devs spend thousands of hours developing the software but little to none on the final bit to make it usable. Somehow I knew the build would not work and was staying away from trying to compile and install. But I tried anyway andnd I had to install gcc to boot.

Error: The required version of setuptools (>=2.1) is not available

Error: Installed distribution zope.interface 3.8.0 conflicts with requirement zope.interface>=4.0.2

Whatever "setuptools"  is. And how many other things will I find are not available.

I't all like a game, if I wanted to play a game I would get Angry Birds.
</rant>

I do wonder why there is no pre-compiled version available for the Mac--like for Windows.

Where did you get the Stratum Proxy or did you compile it yourself? Does it support 'Long Poll"? I would really like to try that.

To bolster what dogie states here are a couple of things:

1) What is needed is power at 12 volts, the advertised rating of a PSU is total, here is an example PSU spec:
 Notice that the 600W PSU has a lower 12V rating than the 500W model! Yeah, the image doesn't make sense but it is a true copy.
The image is from my witeup on the cube at: http://zaph.com/cube

2) There is an in-rush current on power-up or change to high power, that is something that's not specified, the way around that is a high quality PSU and a rating substantially higher than the minimum required.

One more hint on JLebowskiTheDude's post: Instead of "Slide the main board out." I suggest placing the cube fan end up and removing the case, this helps provide support to the heavy electronics by the table it is resting on. It eliminates doe juggling of the main board and cards. The same applies to reassembling.

Have you checked that the IP addresses have not changed? If you are running DHCP they could have changed.

BTW, it is possible to "pin" IP addresses under DHCP to the MAC address or Client ID.

Great going getting allengrad setup!
I had forgotten how difficult this IP stuff could be for someone new to it. So many variables.

I was wondering how he was communication to the Cube when the Cube was on a 192.168.0.x network.
Hopefully allengrad is good to go now.

The first thing that jumps out is the "+" in the second Pool address, it should not be there.
The gateway is 0.0.0.0 which I understand is OK but I personally put in the address of the router.
The proxy (pool) address is 192.169.0.17
The Cube address is 192.168.1.254
The Mask is 255.255.255.0
This means that the Cure and the proxy are on different networks (logically) and will not be able to communicate.
Question:
What is the IP address of your router, with that information I can provide instructions for setting up the Cube..
Need to do:
Get both the Cube and proxy on the same network but need the router address with no address conflicts.

Note: JLebowskiTheDude is assuming that your router is on the 192.168.0.x network but that may be incorrect, your router may be on the 192.168.1.x network.

From the thread: How do you upload a photo on bitcointalk.org?

To upload photos:
Upload then to http://imgur.com/
Then click on and copy/paste your image link between the two [img] tag.

Also consider just copying and pasting the information.

Care to share that information and image?

Tell us where you are in the process, what problems you are having, what is working?

The "cross" is a protective measure. From the site: http://www.ami.ac.uk/courses/topics/0136_ec/

The main concern is internal heat and gas generation, and fault conditions may cause sufficient internal pressure to rupture the can. This is why large capacitor cases have an integral pressure relief: with small capacitors, this may take the form of a ‘rubber plug’ at the lead exit or, more commonly, a deliberately weakened area (often seen as a pressed cross on the end of the package) which determines where the rupture takes place.

So if there is no rupture that is not an indication of "cheapness" and no reason to suspect the capacitors.

In my case which seems typical the wire is 20 AWG (gage). Running at high there is 0.2 volts drop with two cable assemblies (strands) 2 feet long. With one there will be twice as much current and the voltage drop will be twice as large, probably around 0.4 volts which is starting to be meaningful. Also the wires will be getting hotter, I feel them.

You really need to to use two cable assemblies (strands), one for each connector.

It seems like the Android router problem has to do with it ignoring the DHCP lease times.

Full information can be found on theAndroid Open Source Project - Issue Tracker: https://code.google.com/p/android/issues/detail?id=11236 "DHCP client ignores lease time".

One thing that may help is to make sure the Cube(s) and any proxy are on addresses outside the DHCP pool so there will not be any collisions.

With or without Android insure the proxy address is either statically assigned outside the DHCP pool or set to always get the same address from DHCP, this will prevent a new proxy address stopping mining.

When the Cube's default address (192.168.1.254) is in conflict the router there is no need to change or re-configure the router there is a simple solution: Connect the computer directly to the Cube with a standard Ethernet cable, a cross-over cable is not needed.

1) Change the Computer to an address on the same network as the Cube like: 192.168.1.2.
You should be able to access the Cube at 192.168.1.254:8000

2) Change the Cube's IP address to an unused address on your network.

3) Restore your computer's settings.
You should be able to access the Cube with the new address.

If it is flux that is just cosmetic. In the old days we used to use trichloroethylene or trichloroethane with a toothbrush to clean up hand soldered boards.