Gas readings over the network!

Two more small steps today:

1) A couple of variable resistors added to the circuit - one to vary the current through the IR LED and one to adjust the strength of pull-up applied to the sensor, and with a bit of tweaking I've now got readings over a useful range.

2) Readings are now being multicast onto the home network, and being received with the Linux 'emcast' tool. Saved into a file, loaded into a spreadsheet, and converted to a chart, I now have:


Next step is to take the hundred samples a second and turn it into a lower data rate feed of readings.

mbed now a "connected device"

Today's progress: my mbed is now connected to the LAN (using an RJ45 snipped out of a broken router). It obtains an IP address via DHCP, sets the time via NTP, and then just displays the time on an LCD display.


Next step I think I will try multicasting the sensor readings from the gas meter onto the LAN. I've already prepared network and power sockets in the understair cupboard near the meter.

Spikes removed

I've reworked the circuit to put a low-pass RC filter between the phototransistor and the mbed analog input:



and the spikes are now gone:


There's a bit of noise on the flat section at the end where the meter had stopped, but that may only be visible now because the range of values is significantly reduced. Previously, ignoring the spikes, the values ranged from about 4000 to 40000, but now I'm only getting 3100 to 4250.

I'm not sure how to adjust the resistor and capacitor values to increase the range, and it doesn't help that I don't know what's inside the mbed on that analog pin.

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 );
lcd.cls();
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.cls();     
    lcd.printf( "Sample %u\n%u", i, val );
    wait( 0.01 );
}
lcd.cls();
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.