I am creating a project that needs to save power - both battery and my house power.
I am creating a simple circuit using an ATMega328 + a few components to count the pulses from a power meter.
The device must run on batteries and about once per minute send a small payload via 2.4Ghz
My data packet I send is
TimeNowMS
TimePrevMS
PulseNow
PulsePrev
So based on this I can work out the power consumption in my house at the current time.
I have the basics working but I now want the device to sleep between updates over WIFI to save power.
I need to have the pulses being counted using interrupts even when sleeping.
Without any sleep the board is using 19ma - I want to reduce that by a huge amount - remember this is not an arduino board just the bare essentials to get it running with arduino code.
All of the arduino sleep modes of any value corrupt the value returned by Millis() since the timer is not running when the device is sleeping.
Normally I count the pulses between updates and also the duration in ms since the last update in ms.
I thought about a RTC but 1 second accuracy is not good enough - I need more accuracy !
Is there a way I can use a crystal to get ms? maybe using some sort of external circuit? but still readable by Arduino and all the while not using much power?
Why not sleep, use RTC's square wave output as an interrupt to wake up more often than once a second? Check the time, if not ready to send yet go back to sleep, check again.
You have these choices with a DS1307 for example:
1 Hz, 1000mS
4 KHz, 0.250mS
8KHz, 0.125mS
32kHZ, 0.03125mS
4 KHz seems like plenty, keep track of where you are within the second using that.
Wake up increment time interval counter, see of power pulse occurred yet.
Waking up every 250uS, or 4000 clocks, I guess you'd stll be sleeping most of the time.
CrossRoads:
Why not sleep, use RTC's square wave output as an interrupt to wake up more often than once a second? Check the time, if not ready to send yet go back to sleep, check again.
You have these choices with a DS1307 for example:
1 Hz, 1000mS
4 KHz, 0.250mS
8KHz, 0.125mS
32kHZ, 0.03125mS
4 KHz seems like plenty, keep track of where you are within the second using that.
Wake up increment time interval counter, see of power pulse occurred yet.
Waking up every 250uS, or 4000 clocks, I guess you'd stll be sleeping most of the time.
This sounds interesting - have you actually used the interrupt to count time?
It does not matter when I update the data - 60 seconds, 61 seconds etc.... But I need to know how long since the last update to get accurate data durations for the pulse count.
Are you saying with this interrupt I could increment a volatile variable and simulate my own millis function?
You could perhaps use some logic ics to count while you sleep, not sure how much they would draw tho
you can use a clock signal fed into a ripple counter(or multiple for more precision using a faster clock), then get that parallel output into a piso shifter and when the arduino wakes, clock the data in with spi or bitbang it to recieve how many clock cycles have passed since it was asleep
There are power management libraries which can perform the sleep and maintain the 'millis()' value correctly, which simplifies your sketch.
All you really need to send is the count, and the length of time over which that count was collected. I don't see any point sending the previous values since the absolute numbers don't mean anything - it is only the change that is significant.
I suggest that you accumulate the count and duration and only reset when a successful upload has been completed. That way, if there is any difficulty with the upload you will lose granularity in the logged data but the total values will still be correct.
[quote author=Coding Badly link=topic=116759.msg878880#msg878880 date=1343808292]Why not have the receiver timestamp the data? Why does the sender have to do it?
I guess this could work but if I lost a packet instead of a gap I would have corrupt data.[/quote]
A sequence number solves the problem. Including a few previous values will allow recovery from multiple dropped packets.