This forum has moved to forum.jeelabs.net - this read-only archive is for reference only!
Hi,
although the code in meter.pde is commented, would it be possible to explain it a bit further, or even blog about it? I don't understand everything in that sketch, but i would like to use it on a arduino.
I'm also logging my electricity/gas/water with an arduino, spitting out data on the serial/usb and storing it in a ms sql database, but i'm looking for ways to improve it.
Many thanks in advance,
EriSan500
Doh, forgot to ask, is it possible to take out the RF part and let it print the readings to the serial port?
Thanks in advance
The meter.pde sketch has been running almost a year now here, and is based on a fairly old setup - a predecessor of what is now the JeeNode. I have it on my (long) list of things to do and post about. It also needs to be modernized to take advantage of the current RF12 driver capabilities. I intend to build a new unit in the near future, several of them in fact, also some for family and friends around here who have expressed an interest in all this. Can't give you a date, but yes it's definitely on my radar.
The code basically has 4 identical interfaces, each one with a light sensor and a LED. The measurements are done in such a way that occasional loss of data does not affect the accuracy of the measurements. For each interface, two values are tracked: the total number of pulses (0..4095, then wrapping around to 0 again), and the number of milliseconds between each pulse. The former is a reliable indication of the total energy/gas/water/whatever consumption, while the latter is a good estimate of how fast the counter is currently incrementing, i.e. current rate of consumption.
There are some tricks in there, such as a shift register to reliably trigger on the leading edge of a pulse, even if the pulse "bounces" a bit. The other major trick is to pack the counts into a floating-point like value, so that big millisecond ranges can be sent (very slow moving counts) with low accuracy - as well as accurate low values (i.e. when the counter is moving very fast). This last trick is probably overdone - I'll probably just send a larger int value in the next revision of this code.
I hope this helps. It's fairly complicated C code, but there are several comments to help explain what's going on.