Sunday, 19 September 2010

Gas meter monitor

Since installing an electricity usage monitor we've been a lot more concious of the amount of electricity we're using. We'd like to do the same for gas usage, to answer questions such as how much gas is required to heat the water for one five minute shower, whether it's better to turn off hot water heating during the day, etc.

I've been recording the meter readings for a number of years, but the frequency of reading (roughly the rate at which the power company asks for readings) isn't anywhere near enough to tell what effect individual actions have on gas usage. Here's a plot of the last eight years of usage against week number:

It looks as though usage is up this year - could that be due to the new shower that we fitted recently? This is the kind of question that we want to be able to answer.

So I'm making a monitor that reads the gas meter for me, continuously.

Our gas meter is a common type with numbered wheels that show the reading. The zero of the least-significant digit is a shiny silver circle - obviously intended for detection by an optical sensor of some kind.

It's possible to buy a sensor unit designed specifically for the meter we have, but I didn't find that out until I'd already obtained a generic optical sensor. And besides, I'm a cheap-skate.

I also later discovered (with a cub-scout compass) that there's a magnet attached to the least-significant digit as well, so sensing the movement of that is another option. I don't have any reed switches "in stock" so I'm sticking with the optical sensor for now. Also, I'm hoping that the optical sensor will be able to detect rotation of the wheel as well as the zero-passing point, for a more accurate instant reading.

Here's a photo of the meter with a reflective IR sensor attached. The sensor is glued to a plastic rectangle, with two holes drilled to fit two small plastic protrusions on the meter. It simply pushes into place, so is easily removed. I hope it's obvious that it's not permanently or electrically attached to the meter, as I don't want the official meter reader getting upset when (s)he sees it.

Leaving a PC running 24/7/365 to record the data would sort of defeat the purpose of the exercise wouldn't it? On the other hand, I want to make the data as instantly available as possible, so it needs to be connected to the network (at least inside the house, if not to the Internet at large). I considered an Arduino with an Ethernet shield, but it turned out to be cheaper to use an mbed instead, which has Ethernet and various other nice things already built-in.

So far I have the IR sensor and a two-line LCD (so I can see what's going on) attached to the mbed. During the prototyping stages I'm powering the mbed from a 6V lead-acid battery that I had spare.

The mbed has a built-in power regulator and outputs 3.3V for other parts of the circuit to use. Unfortunately the LCD requires 5V and won't operate at 3.3V (grrr!) so I've had to add a low-drop 5V regulator to power that.

The IR LED is powered from the 5V supply via a 220 ohm resistor (1.7V forward voltage, so 5-1.7=3.3/220=15ma - well below the nominal 40ma but seems to work fine). The IR phototransistor is connected between and an analog input on the mbed, with a 100K pull-up resistor, and a capacitor to ground for smoothing.

Other websites documenting the use of a QRB1134 suggest using a 0.1uF capacitor. I didn't have one of those in my garage stock so used a 100pF instead. The resulting readings contained a lot of seemingly random spikes, so I swapped it for a 4.7uF, but it still has a lot of spikes. Not sure what to do about that.

Here's the circuit:

For now the mbed code is very simple:

#include "mbed.h"
#include "TextLCD.h"

TextLCD lcd(p24, p25, p26, p27, p28, p29, p30);
// rs, rw, e, d0, d1, d2, d3

LocalFileSystem local("local");
BusOut leds( LED1, LED2, LED3, LED4 );

AnalogIn ain(p20);
char filename[25];

int main() {
sprintf( filename, "/local/%d.txt", time(NULL) );
lcd.printf( "%s.txt\nBegin in 5s...", filename );
wait( 5 );
FILE *fp = fopen( filename, "w" );
for ( int i=0; i<4000;>
unsigned short val = ain.read_u16();
leds = val >> 12;
fprintf( fp, "%u\n", val );
lcd.printf( "Sample %u\n%u", i, val );
wait( 0.01 );
lcd.printf( "Finished." );
fclose( fp );

I should really have added a button to start a capture, as getting the captured file onto the PC without it being overwritten is a bit tricky. I just leave the power on when the capture finishes, disconnect the sensor, carry the mbed to the PC, plug into USB and copy off the capture file.

I've been getting a few blue-screens-of-death on my PC when attaching the mbed to USB or resetting it while the USB is attached, which is a royal pain. No idea what's going on there.

Here the data after importing to a spreadsheet to plot it on a graph:

The spikes can be clearly seen, but ignoring those it's also clear to see the three places where the shiny zero passes, the short periods where the meter wasn't turning at the start and end of the capture, and even the "shape" of each of the individual digits 1-9 as they pass the sensor.

I have a way to go with this yet, but the results so far are encouraging.


mark said...

Have you checked to see if your gas meter has a magnetic trigger? My meter looks very similar and has a magnet embedded in the least significant digit so I only needed a reed switch to sense the rotation. This saves power, which in my case is important because I wanted my meter reader to be battery powered and send the reading via 433Mhz wireless. Regards, Mark Leman.

Dr Rob said...

Hi Mark,

Thanks for reading my blog, and for the suggestion.

The gas meter does indeed contain a magnet - I borrowed my son's cub-scount compass to discover it.

However, I'd already obtained the IR reflective sensor when I found out that, and I'm interested to see if I can detect when the gas flow starts and stops, as well as the zero-passing point.

It may well be over-engineered, but as with many of these kinds of hobby projects, it's as much about the journey as the destination. :-)

I may end up switching to a reed switch eventually. As you say, the power requirements could be a lot lower (i.e. edge-triggered wake from sleep...).