Friday 2 December 2011

CurrentCost meter updates

Recently, I’ve been leaving my main PC on 24 hours a day to collect the readings streamed out of my CurrentCost meter.

This obviously wastes 100 watts, which is about 25p/day.  Clearly that’s a waste.

So, I’ve decided to take the plunge and build my first ever hardware project, based on an ARM mbed processor that my son who’s doing electronics had sitting around gathering dust.  I’m a software guy, and I hate hardware.

I’m powering the circuit from a DC adapter I had in the loft, generating 6V DC, 600mA, so it shouldn’t cost me more than about 3.6w when I’m finished.

P1020820

Here’s a bad picture of the breadboard and the device.

The idea is simple, keep the output format of my device similar to the original, but add buffering.

The mbed code captures data from the serial port (Pin 8 on the RJ45 from the current cost meter, and pin 4 ground if I remember correctly) which I crimped together into an RJ45.

I then spool the data into an SD card (writing raw blocks).  The current SD card is 16MB (I had it from an old Canon Camera), but I’m planning to put in a 256 MB card which will give me about 2 weeks of buffering with my existing setup that includes 4 sensors in addition to the main sensor, though there’s no reason a 1GB or larger card couldn’t be inserted instead.

The PC will then poll for data in the mbed by sending a carriage return, and in response the mbed will send out the next LF delimited xml message it has stored, which will be transmitted back to the PC at 921600 baud, and processed by my software.

One pitfall with the current cost data is that there isn’t any way of finding out what date the data was logged on.  To deal with that, I’ve reserved the first 4 bytes of each block in the 512 byte SD card sectors to store the real time clock of the mbed, and the PC can then query what date/time the message was actually collected on.