Gas Meter - real time monitoring

[KenB]

Electricity monitors only provide half of the picture.  Much of the CO2 produced by the domestic sector is from burning gas in your central heating system.

After some 5 years since I first tried sensing the reflective digit "0" on my odometer style I decide to make up a more permanent fixture and get counting pulses again.

The meter was replaced in November 2004 and is an Actaris U6. It produces one pulse for every 10 litres of gas consumed.  It was designed with pulse counting in mind, because as well as the reflective zero, there is a cut away section of the register housing which allows an opto- reflective sensor to be fitted. Meters like this are known as "pulse-ready" - just that the manufacturer does not supply the pulse detector, so I had to make my own.

I used a miniature infra red  opto-reflective sensor.   This one made by Kodenshi available from Farnell for about £1.

http://uk.farnell.com/kodenshi/sg-2bc/opto-switch-reflective/dp/1253374

These are an infra-red LED and a matched phototransistor in the same package.  The LED emits IR light towards the target and whatever is reflected back causes the phototransistor to pass current.  The amount of current passed is proportional to the amount of reflected light.  When the big shiny reflective zero passes by the sensor, the phototransistor turns on fully and so can be made to generate an electrical pulse output.  All that is needed is a current limiting resistor for the LED - I used 470 ohms when working with a 5V supply, and a 100K "pull-up" resistor in the collector circuit of the phototransistor so as to turn the current variations into a varying voltage signal.

The circuit was built on a little scrap of veroboard about  25 x 30mm.  Two 4mm holes were drilled in the veroboard so that it locates conveniently on the two plastic pegs provided on the meter.  The opto-reflective sensor is mounted in such a way that it points directly through the clear plastic in the bottom of the register box and directly at the centre of the digit wheel.  It's so sensitive that if you get it slightly off centre, you can detect the white graduation lines that are down one edge of the digit wheel!

To make this circuit work with an Arduino, it's best to feed the voltage output into an ADC channel. You can then get the Arduino to apply a suitable threshold to the voltage output in software.

As well as counting pulses, the Arduino can also time the period that the reflective zero takes to pass the sensor.  The shorter the pulse width, the greater rate at which gas is being used.  With a little calibration you could express the mean gas consumption in kW and determine whether your boiler is full-on, modulating down, or if you have a cooker or oven on.  If you get a very long zero pulse - this suggest a gas leak somewhere.

The Arduino code to get the pulse counts up to the web is here courtesy of Richard Parker

http://blog.richard.parker.name/category/projects/

This opens up the discussion of useful web connected sensors that can send realtime data to a web site.  A £30 Arduino plus Ethernet shield could serve a whole bunch of live data up to the net, possibly using Pachube or another application that can draw a graphical representation of realtime data.

However - For those wanting to monitor locally with almost no effort, I devised a method of scungy-graphing the output of a pulse counter.

Use Hyperterminal or similar, to display the serial output of the Arduino.  Each time the Arduino sees a pulse it prints two square brackets (or whatever character you fancy) to the terminal.  Running in the background is a timer which cause the Arduino to output a carriage return/line feed at regular intervals - say 5 or 10 minutes for example.  So the Aruino will print a series of [] blocks along the line until it sends a CRLF - such as


[][][][][][][][]
[][][][][]
[][][][]
[][][]

etc - a nice easy horizontal bargraph of gas consumption - easy to write in C or assembly language and needing no other resources than file capture on hyperterminal. A quick and dirty method of producing a meaningful graphical output.

Those of you more accustomed to the "Processing" graphical package which is part of the Arduino offering, could probably to something a lot nicer.  I however like the minimalist ASCII graphics approach which allows a lot of graphical data to be stored in a relatively small text file.



Ken

[myozone]

Bit like mine

[myozone]

Messy but it works !

[pcmadman]

This job has got me inspired! 

I've got this baby laying around, ever since my Technical Informatics course: http://www.atmel.com/dyn/products/product_card.asp?PN=AT90USB1287

The Atmel AVR AT90USB1287,
it has 8 ADC's, a USB port, 16mb of storage and runs up to 8Mhz.

I should be able to make it store all our consumption data and then transfer it to my PC and/or send real-time consumption stats to my PC.

Our gas meter has a silver spot behing the zero and electricity meter gives a 1000 blimps per kWh, so should all be very readable.

Nice challenge I'd say....

[myozone]

I was thinking of using a 1-wire counter a DS2423 like this http://bwired.nl/How_stroom.asp on http://bwired.nl/ site

[KenB]

PCMadman,

You might want to try to utilise some of the wealth of code available for the Arduino (ATmega168,328 and 1280).  This includes a complete integrated design environment, bootloader and useful libraries for I/O, serial comms, ethernet/TCP/IP communications etc.

I'm not sure of your background, and forgive me for assuming that you are not a professional embedded programmer,  but starting from scratch to get a full USB datalogging running on your ATmega32U6 would be a substantial undertaking. I see from the datasheet that it has a USB bootloader already on-chip, and hopefully Atmel have complemented this with a nice user friendly bootloading application to run on the PC.

However, if you try to retain some compatability with the Arduino - you know that you have a huge wealth of code resources out there already,  plus most of the hardware drivers to I2C, dataflash, ethernet, TCP/IP stack etc.

Counting the pulses from the gasmeter is the trivial part.  Getting them into the PC, or direct up to the web, and then presenting the data in a useful manner is the bulk of this project  - and the part that most people are going to have to use and interract with.

Several people on this forum have written their own presentation applications, and I can assure you that there are a significant number of people, both as individuals or organisations who are doing similar.  Almost every utility now has on line viewing of historical consumption data.  Some of these packages are good,  some are so buggy and limited that I can't see why the utility has bothered.  My dealings with the British Gas online graphing were a very bad experience.  The package assumed that if you didn't have any data for the current quarter, then it would assume that you used 327670 kWh of gas - purely down to poor coding and a maths error.

Some of the electricity packages are not much better.  They will show you monthly, weekly and daily - but half hourly would be a lot better.  You might also want to compare Saturday 24th with Saturday 31st october - to see if your consumption had changed between particular days.  Very few graphing packages have these capabilities.

This said, you might want to look at the work by Dale Lane - one of the IBM hackers of the CurrentCost electricity monitor.  He decided to write his own graphing package

http://dalelane.co.uk/blog/?p=872

CurrentCost are now distributing digital input boards to work alongside their electricity monitor.  You can use these for pulse-counting and then feed the data through the CurrentCost, where it logs it and generates an XML formal serial output data.  For someone who already has a CurrentCost, this might be one of the quickest ways to get something up and running.

Finally a word about data storage.  Back in the late 1990s when I had to design a wireless gas meter pulse counter which communicated with a PSTN modem for data output, memory was still quite expensive.  The design could only afford a 128Kx8 static RAM - and so I was tasked with finding some way to package sufficiently fine grain gas data - for at least a years worth of daily consumption into the 128K available.

My solution was to allow 256 bytes per day - which consisted of 240 pulsecount readings taken at 6 minute accumulations - each reading was allowed one byte, limiting you to 255 pulses per 6 minutes - enough for even the largest of gas consumers.  The remaining 16 bytes was a header (or footer)  which said what day/date the data pertained to, and what the daily absolute start total was.

32 of these daily blocks would be packaged into a monthly block which was 8K bytes.  There would always be at least one spare daily block at the end of the "month" as no month, to my knowledge, exceeds 31 days.  This was a convenient way of being able to access a particular month's data. For example August being the 8th month - just index 8x 8K into the address range and read out whichever daily block you need.

So, using this simple scheme, it made data retrieval very easy.  You always new where to search in the address space for given dates - as these were tied to the calendar.  At midnight on the realtime clock, you just start accumulating your data in the next daily block - and you could store 16 months worth of data in a relatively small memory device - at 6 minute granularity which at 10 readings per hour is almost optimum to show the fine detail of gas or electricity consumption.   Whilst once per second data might be interesting - it really needs to be accumulated (smoothed) over a larger time window to give a presentable graph.

These days of huge, cheap data flash memories (8Mbit for about £2.50) allows vast quantities of data to be logged - but a thought should be given to how it is best organised for retrieval and more importantly, display.

MyOzone  - that would be the discontinued DS2423 - data sheet says not for new designs.

http://www.maxim-ic.com/quick_view2.cfm?qv_pk=2912

I think however Philips/NXP have a pulsecounter on an I2C bus - they certainly used to back in 1998



Ken

[myozone]

Oh well I think I have a couple of samples around somewhere. Using an Arduino, Freeduino in my case is a good way to go as Ken said lots of code examples.

Have fun

Dave.

[KenB]

Guys,

Dale Lane's CurrentCost electricity graphing package is available to download as a windows executable

The features are described here - quite comprehensive (Dale is a smart cookie):

http://code.google.com/p/currentcostgui/wiki/Features

Now if you got the Arduino to spit out a serial datastream which adhered to the CurrentCost XML type, then you could use Dale's package to graph your gas meter pulse counter readings.

It's interesting that CurrentCost Ltd chose to use an XML output as their format - but I suppose it makes sense - it is just about human-readable and quite easily parsed to extract the data into other applications, such as Pachube.  The problem is that it's quite verbose in terms of overall quantity of serial characters sent, to give even a small update in readings.

It would be relatively trivial to mimic the CurrentCost output format on an Arduino - and measure a whole host of other parameters as well as electricity and gas, such as water meter flow rates, room and pipe temperatures etc etc.  Possibly even use the Arduino (and it's variants) as a cheap and common platform for a whole host of energy monitoring and sensor applications.  At just shy of £17 from Nuelectronics, or make your own on a chunk of veroboard from a £4 ATmega328, this seems a very low cost route into making some smart logging applications. 

Whilst this could have been done years ago - say on a MIcrochip PIC, the difference is now that the Arduino has gained acceptance across a huge user base and there is a wealth of useful code out there. No longer do you have to struggle by yourself writing assembly language  - so the rate of progress is a lot quicker.

Perhaps Navitron could launch the Navitrino ( I'd be happy to design it - and add a few useful renewable energy hooks such as pulsecounter and thermistor interfaces and for once a sensible quantity of onboard memory such as a SD card).  Anyone else interested in a joint venture? 

I shall have to put my C-coding hat back on.



Ken

[StBarnabas]

Hi Ken

EricW and self have been looking at PIC based 1-wire slaves. These give a pseudo temperature reading and have inbuilt counters, ADCs etc. The advantages are two fold firstly cost: The  12F683 is easily obtainable for under £1.00, secondly as they can be hung on an existing one-wire network they would be easy to use for anyone with a 1-wire system.

Going into production would be difficult as there are licencing issues with Dallas/Maxim. This is a potential alternative route, but I can see that the Arduino route also has a lot of potential.

Sean

 

[pcmadman]

KenB: Thanks for the constructive comments!

You're right to asume that I'm not a full-time embedded software-guy, but I did half a year of it alongside my Software Engineering education, of which I'm in the second year atm.

The software I see as a nice challenge. I normally write in C# and lately a lot of Java, but I'd really like to learn more C.

The hardware is more of a problem. It shouldn't be very hard, but I've never done any proper soldering, so I was bit scared of soldering to the SMD-size holes in the board. Luckily as it seems to me now, the ADC is on the same port used for direct ROM programming and had a connector all ready soldered to it. Should be able to abuse a old floppy cable for that.

Atmel has generously supplied a programming enviroment called FLIP. It let's program in C and then upload through USB. Also there's are a lot of demo projects, including USB Mass Storage device and a HID device. We've all ready done some projects in school where we had to communicate between a C# application and the board. Also a scheduler is provided. If that still isn't enough my school mates, some of them who now actually study embedded programming, might be eager to help.

As for storing the measurements I was thinking about storing the timestamps of the pulses. I've got 16MB. That's 64 times the memory you used to have and I don't need to store a years worth of data. Maybe a month or two. The big issue with this is that I'll have to program a clock to even get a timestamp    Well storing locally will be something for the long run anyway, because the device will be <1m from my home server, so I can just start with directly sending them there and add the timestamp on the computer.

Anyway for now I have to concentrate on hardware side of it.
I've found this for a opto switch: http://www.conrad.nl/goto.php?artikel=184241 (>€20,- = free delivery and they should be able to provide pretty much any other component I need.)

But I don't have time ATM to look into it any further. I have to study now and will now stop hijacking your thread and open my own when I get to it! 

[KenB]

List,

as an update to the gas meter monitoring project, I have now written a pulse counter sketch for the Arduino which counts the pulses and times the time between them.  This allows me to calculate how long it takes the boiler or cooker to burn 10 litres of gas, and from this I can work out the instantaneous power of the gas appliance.  

This is handy because it shows me fairly convincingly whether the boiler is modulating down and what power its working at.

The photo-reflective sensor is quite sensitive and I can actually see the individual numbers 1-9 go past, as well as the silvered zero.  This would allow me to count individual litres, rather than 10 litre pulses - so as to get a more accurate flow rate.

Attached is a plot of what the photodiode "sees" as the numbered wheel rolls past.  Note each digit has its own characteristic peak in the photodiode output.


Ken

[KenB]

List,

I've now modified the pulse counter running on the Arduino, such that it accumulates the pulses counted over 6 minute intervals - so you get nice bargraphs of 10 columns per hour.

The boiler flat out uses 20 pulses (0.2m3) in 6 minutes.

Attached is a typical graph showing 1 hour's worth of consumption when the heating was on.   Also a "staircase plot"  which shows the individual pulses which make up the 6 minute totals.


Ken

[KenB]

List,

After a bit of code  hacking, I have now got my gas meter connected pulse counting Arduino to impersonate a Current Cost CC128 ENVI energy monitor.

The CC128 (I hate the name ENVI) outputs a stream of serial data every six seconds in an XML format at 57600 baud.  By getting the Arduino to fake this XML stream, I can then use third party graphing tools that are already written for the CC128 - such as Dale Lane's Current Cost GUI.

So the first exercise was to get gas pulse readings converted into meaningful power readings.  This is relatively easy if you know the calorific value of the gas (about 39MJ/m3) and the time between pulses in seconds.

Each pulse represents about 0.11kWh of gas,  so if you are getting pulses every 16 seconds (225 per hour) you are burning 225 x .11 kWh per hour - so your boiler is running at a power of 24.75kW.

The Arduino code to generate the XML data stream was fairly trivial - CurrentCost have made their format freely available on their website - and even a non-C-coder like me can hack a few print statements.

See http://www.currentcost.com/cc128/xml.htm  for their output format

The only downside to this approach is that you can only update the instantaneous power reading when you get the next pulse.  If your boiler turns off and there are no more pulses for a few hours - then the output will "flatline" at the last calculated power - which is clearly wrong if the boiler is using no gas.  Further improvenments to the code are needed here.

Finally to show that it works - attached is a screen shot from the "Live Data" screen of Dale Lane's GUI - showing what my boiler's doing - modulating down as any good condenser should.


Ken

[roscoe]

I recently had my gas meter upgraded to a basic metric one which is an Elster BK-G4.

There is a little blog here explaining it briefly
http://albacontrols.wordpress.com/2009/08/17/gas-metering-result/

However, many of these meters have rather convient reed switch clip-ons which for me was under £30 and saves the electronics breadboarding hassle.  The only trickly bit is being persistant enough to find where to buy the 'optional extra'.

As you can see in the blog it very slick.

As for monitoring I have a Brultech ECM1240 sitting right beside the gas meter, in which the 7th measuring channel can be configured to count pulses so again no pulse counting hassle.  As for data display, I have lovely dashboard trend graphs (but right now they don't work for ch7, boo)

In the meantime, I have an excel ODBC link to the Brultech SQLite database in the following excel chart

[MikeM]

For some time I have been 'fiddling' with a home brew Gas meter logger which involved a reflective infra-red sensor, a PIC , RF modules, a PicAxe based data logger and much indecision on my part as to how this was all going to work - usual debate about what goes where and how/where to save the data etc. ! So bouts of enthusiasm and then project gets put away for a while so I thought Xmas would be a good time to finish it !.

From another forum (automatedhome.co.uk) I then discovered that my Actaris G4 meter was actually fitted with a magnet and therefore was already  'pulse ready'. A reed switch taped to the bottom of the plastic case by the zero digit and a meter confirmed this. Encouraged by this and to simplify my regular manual meter reading which I submit to 'imeasure' I hooked up a dirt cheap remote display using a hacked pedometer that I happenned to find in the street.

I just opened and removed the pedometer 'pendulum' switch and soldered a couple of wires to the PCB where the switch contacts were. I ran these out to my reed switch and away I went ! Within a few minutes I had a remote display !

Of course, you need to note the actual Gas meter reading when you zero the counter. The reed switch seemed to work almost anywhere around the casing and I used double sided foam tape to stick it on.

Much better than poking around a dim cupboard so thought I would share it with forum members. Now to finish my logger.