# Arduino pulse counting & storing

I'm using jeenodes from jeelabs for capturing data such as temperature, light, humidity and motion. Now I am looking to capture gas and water consumption using reed switches (the meters produce x number of pulses per kWh. How do you suggest I achieve this?

The main questions are:

How should I store the pulse count locally? (EEPROM? I can't simply transmit every time a pulse occurs because some packets might get lost- there might be network outages etc) How often should I transmit data? How should I store the pule count centrally? (just the cumulative figure? which I then have to compare to the value at any given time to determine the consumption between 2 dates/times?)

• If you write to the eeprom with every pulse you'll soon end up with a dead eeprom. Store it in ram. – Majenko Dec 28 '11 at 19:47
• If i only store in volatile memory- how do i handle resets? – Lee Tickett Dec 28 '11 at 19:50
• If you're transmitting periodically you only have to worry about the time between transmits. And why have resets? If you design it right you'll not have any resets. – Majenko Dec 28 '11 at 19:52
• If i was sure that 100% of transmits would be received and processed I would be happy with that but I know because of many variables some transmits will be lost I need something more. A reset could be as simple as me replacing the batteries. – Lee Tickett Dec 28 '11 at 20:01
• You don't implement backup systems then? Or overlapping battery systems? (add new batteries before remove old batteries). How about adding some battery-backed RAM - maybe a DS1306 RTC chip with a rechargeable battery? That has something like 96 bytes of RAM that is battery backed, and the battery lasts for months without external power. – Majenko Dec 28 '11 at 20:06

A 99% workable solution likely lies somewhere between the absolutes. For example:

You could transmit an incrementing count. The receiver can miss some transmissions as long as it gets a later one. If it gets a later transmission re-starting from (near) zero, it can assume the transmitter has been power cycled and can add the historically received count to the new one. You could measure the time duration of any gap and estimate the number of missed counts during the power loss based on either the rate before the loss or from a past period that might plausibly be similar (ie, same time of same day in preceding few weeks, or from a few weeks period a year ago, etc). This may work even better if you make the correction after the fact to equalize consumption over longer periods (ie, outage of a few hours, fix the total for the day to match similar days, rather than the hour to match similar hours). Also consider that the fact of a power outage may alter behavior and thus gas/water usage.

You could periodically store the count value to EEPROM, if you do it at nice round numbers you could do so using relatively few bits since you would only need the significant ones. Upon power cycle, you could restart the count at the last saved number. The receiver would see the count resume at a slightly lower number than before, and could add the difference back in to the received numbers.

As most power outages are short (some recent exceptions aside) you could use battery backup.

If the meters have a display, you could take an entirely different approach and point a camera at them and use optical character recognition on the images.

No system is perfect - in extreme cases, intelligent manual correction may be needed.

• Thanks- nice thorough answer. I may not write to the EEPROM as resetting from 0 actually provides quite a nice indicator that there has been an outage and potentially some usage has been missed. The transmitter/pulse counting device does run off batteries so it is safe in the event of a powercut but not safe when the batteries run out (it SHOULD notify me when the batteries are low). I now need to tackle the most effective mechanism for storing the time/pulse data for graphing/analysis. – Lee Tickett Dec 29 '11 at 15:05
• Be careful your voltage monitoring (divider?) circuit doesn't increase the current draw (not really significant if the processor is always running, but hugely important in comparison to sleep-mode micro-amps) – Chris Stratton Dec 29 '11 at 16:03

Water consumption in kWh???

The frequency for transmitting your data will depend on the pulse frequency and how up-to-date your information has to be. It doesn't make much sense to send an update every hour if you get on average only 1 pulse per hour. In that case once every day or so will do. You could send each time you've counted, say, 10 pulses, but then you won't send anything if you're away for a week, and the receiver may want more frequent updates. A better alternative is therefore to send at fixed time intervals, like every day at noon and at midnight.

For the reliability of the data transfer you have a number of options. The RFM12B radio modules are transceivers, so you can let the receiver send an acknowledge. Not exactly complicated, but it can even more simple, with one-way communication. The word is redundancy. Lots of it. That's often a bad word, but here our data volume is so low that some redundancy won't do any harm; it would hardly be worthwhile to switch on the transmitter to send two bytes, would it?

Now sending 5 copies of the same data in the same transmission is not a good idea. The redundancy is no use if the complete transmission gets jammed. Here's what you do: the N-th transmission sends the following:

• the counter value N (1 byte will do) • the N-4 th data
• the N-3 th data
• the N-2 nd data
• the N-1 st data
• the new data
• Hamming ECC

I would send cumulative data, for instance 16-bit numbers. If you have a pulse per 0.1 m$^3$ of water you'll have an overflow after a couple of years, but the receiver should have no problem with that.

That will give you a payload of still only a few dozen bytes, but ensure you that all data gets received even when 4 consecutive transmissions are lost. If it makes you sleep better you can still combine this with an acknowledge and a re-transmit if needed.

The microcontroller will have almost nothing to do: keep a timer to keep the time until the next transmission, and count incoming pulses. You can run it off a cheap 32.768 kHz crystal. Even without using the low-power modes an MSP430F1101A will only use a negligible couple of µA; your power supply will consume a multiple of that. Only switch on the transmitter twice a day to send your data.

Your microcontroller will have to run continuously for months, and then you have to take power-cuts into account. Where I live they are rare; the last one dates from 3 years back and lasted 15 minutes, but I've been told they're more frequent in rural areas in the US where there are many overhead powerlines. Anyway, you want a battery backup to keep the controller running during a power outage. A CR2032 cell and an MSP430 is enough for eternity. OR the battery's output with the mains power supply (3.3V) with a couple of diodes. Postpone transmissions when running on battery power.

There's no need to store the counters in EEPROM, just keep them in RAM.