Making Mission Control

A while back I found this generator switch panel on Ebay, and knew I had to have it. It would originally have been used to switch between dynamo and battery, monitor voltage and current, and adjust the dynamo voltage (there’s a giant rheostat at the back, and a know labelled “raise volts” connected to it). We visited Hollycombe Steam Collection yesterday, and they’ve got a similar panel controlling the output from a steam-driven dynamo on their steam farm. The panel is made of slate, and it’s really really heavy. It’s taken ages for me to figure out what to do with it.

Well, it’s now part of my laboratory/mission control centre in my study. No regular cabinet would have been the right size, or taken the weight, so I tried my hand at furniture making. I think it came out pretty well. And it hasn’t pulled the wall down yet, so I must have done something right. If I never see another can of wood stain or varnish, I’ll be quite happy though.



The intent is for the meters and switches to all be live; maybe they’ll display network traffic, computer CPU usage, or something like that. To this end, I’ve rewound the meters. Driving them with 20 amps just to make the needles move would have been a little excessive, so I removed the original winding (carefully, so it can be restored if I ever want to) and hand-wound a new 1000-turn winding. Now they register fullscale deflection with 100mA, which is more reasonable.

So, how now to drive the meters?

You can get these wireless clamp meters that clamp around the main power circuit to the house (or any other circuit) and transmit current readings every few seconds. My one is made by CurrentCost. The receiver has this digital display that can tell you power consumption, money spent, etc. But digital displays are no fun.

This particular model also has a serial port that can connect to the USB port on a computer, and even better they’ve got drivers for Linux and MacOS and the raw output is just XML, so it’s pretty trivial to parse. The computer logs all this data, but more importantly drives the two ammeters to display the actual current being consumed. Why both ammeters? The left one displays actually current in amps we’re using. But when there’s no high-current devices running, we draw less than five amps, and you can’t really see this on the meter, so the right one displays amps x 5, so it’s obvious when even relatively low power usage such as the kitchen lights have been left on.

Ok, so how to drive the ammeters from the computer? Well this board does that trick, and is controlled over USB from my Mac Mini.

It uses an FTDI chipset, so again is easily programmed from Linux or MacOS. The digital outputs can be pulse-width modulated from fully off to fully on to set the output level, and can handle 0.5A, which is plenty to drive the meters now I’ve re-wound them. They can also switch enough current to trigger the big relay on the panel, when I decide what to use that for.

By the way, these power monitor meters are a great way to economize. I hooked it up, and it was reading around 500W. So I went round wondering what that was, when suddenly it jumped to 3.5kW and stayed there. What could that be? Must be a heater of some sort, nothing else uses that much power. But it wasn’t the kettle, washing machine, dryer, toaster, oven. Nothing obvious. Spent a while scratching my head, then went to look in the airing cupboard. Lo and behold, at some time the electric immersion heater in the hot water tank must have got switched on by mistake. The hot water should be heated from the gas boiler, and should be on a timer so we’re not heating the tank at times we don’t need a lot of hot water. I reckon this little monitor already paid for itself – likely we wouldn’t have noticed for many months, if ever. The switch is hidden out of the way where you can’t see it unless you’re looking for it.

I definitely recommend getting one of these monitors, even if you don’t use it to drive analog meters.

meter

Software

The software for this turned out to be more of a pain than I expected. Reading the XML from the CurrentCost meter is easy, and driving the pulse-width modulation on the I/O board is even easier. But none of the hardware is proving completely reliable.

The MacOS driver for the PL2303 USB-to-serial convertor used in the CurrentCost meter is really flakey. Often a read() just hangs. Sometimes the driver gets wedged and returns a short burst of old data when you open the device, then nothing more. Unloading and reloading the driver frees it up again, and returns to normal operation. And about once a day, the device driver crashes the machine. Aaaargh!

Occasionally the BV4626 also stops responding too, leaving the meters stuck at whatever setting they were on at that point.

After a week of experimenting, I’ve found workarounds for all of this.

The software now comprises one master process that forks multiple child processes to gather data – power monitoring from the CurrentCost meter, CPU load, etc. The master process monitors the children, and if one doesn’t respond in the expected time, it kills it and restarts it. This works around the read() call hanging. Every few minutes it just kills the power monitoring child and restarts it anyway. During the restart, it unloads the PL2303 kernel extension and reloads it. It you don’t let it run for too long, it doesn’t seem to crash the machine. Reloading the kernel extension is pretty drastic, but it’s the only thing that seems to work.

And before the master process writes to the BV4626 to set the meters, it reads back the software version number from the BV4626. This allows the master process to detect that the BV4626 has wedged; if so it simply closes the device and reopens it. Except sometimes even when it hasn’t wedged, the read sometimes fails, so I require three consecututive read attempts to fail before resetting it.

There are also loads of magic time delays in the code, because nothing seems to cope if you’re too fast with consecutive commands to the hardware. And you do have to send commands pretty quickly to the BV4626, because these old moving-iron meters have a lot of inertia, and when you drive them suddenly from one value to another, they overshoot a lot, then oscillate for a while. So you have to compensate for this in software too, and damp sudden value changes to make the meters track more smoothly.

With the exception of resetting the BV4626, none of this hackery is detectable from observing the meters. But seriously – what a pain to have to do all this to work around flakey hardware. This should have required only 50 lines of code, but instead it’s more like 700 and that’s just to get the panel meters to display power consumption and the smaller desktop meters to display CPU load. Finally though it’s all reliable and working well.

CPU meters

Lamps

The lamps on the top of the panel started out as a pair of desklamps that I found in TK Maxx. I removed the bases, drilled some 1/2 inch holes in the top of the panel cabinet, and bolted them in. I also spraypainted the insides with copper paint, as the original white colour cast a bit too harsh a light. And I sprayed a small mask directly onto the bulbs with Hot Paint so they cast light nicely onto the panel and desk, but no direct light onto me – only the glow from the copper shades. That way there’s no bright lights in my peripheral vision when I’m working, but the light levels are adequate for reading.

The big circular switch at the lower right of the panel now controls the lights. They’re spring-loaded switches for controlling large currents, so it turns on and off with a delightful loud “clunk-sproing” noise. It makes me grin every time I turn the lights on because it’s such overkill.

panel