Incorrect Sleep Time

[Ardash Barsamian]

Hello Everyone,

I have started a project to extend my Vera network and add some sensors. At the moment I am at the testing part using the 1.4 version. I am going to use 3 gateways 1 at each Vera I have. Currently I have setup 1 sensor using a Pro Mini 3.3V powered by a C123a Battery because I want to test the life time of these batteries. I have done all the hacks needed to power with battery so everything is working fine. But I noticed one very strange problem. I have setup a 900000ms sleep time which is supposed to be 15min, but I measured it around 7.5min. I am pretty sure that I compiled the sketch using 3.3V version. It seams that the timing is calculated with 16Mhz instead of 8Mhz. Is this possible?

[hek]

What does the crystal say?

[Ardash Barsamian]

I had to use a microscope but is says S08

[Zeph]

I thought the sleep delay depended on an RC watchdog oscillator independent of the CPU clock.

Which is less accurate, and this is why at least one sleep library calibrates the watchdog clock against the CPU clock (which is usually a ceramic resonator or crystal).

[Zeph]

I think I've mentioned the calibrated sleep library before.

Not worthwhile for most people, but I wanted to provide a link somewhere here just in case.

https://github.com/n0m1/Sleep_n0m1

It has the normal power saving modes (like the rocketscream library currently used by MySensors), but also includes:

Function: setCalibrationInterval
Description: the WDT needs to be calibrated against timer 0 
periodically to keep the sleep time accurate. Default calibration
occurs every 100 wake/sleep cycles. recalibrate too often will
waste power and too rarely will make the sleep time inaccurate. 
Parameters: (int) set the # of wake/sleep cycles between calibrations

Since the WDT uses a less accurate (and independent) RC oscillator, while Timer 0 is based on a crystal (UNO) or ceramic resonator (Arduino Pro Micro).

Hopefully this will show up on a search if anybody's looking for it. Just in case.

It would be interesting to see how close one could come to maintaining a timestamp for sensor events, with occassional correction from the gateway.