I finally tested the accuracy of delay() for 24 hours.

I have a project that requires an alarm once a day. The accuracy is not critical, so I thought I'd test out my Arduino Duemilanove and see how close to 24 hours I could get with a long delay. I ran the following command, hoping to delay it for 24 hours:

delay(86400000);

That's 24 hours * 60 minutes * 60 seconds * 1000 milliseconds.

After 24 hours, the Arduino was less than 1 second off. That's amazing, considering there isn't a real time clock. For basic operations where high precision is not necessary, this length of delay works very well. Just thought I'd pass this along for anyone else considering long delays.

Thats great, but no one uses delays. An experienced programmer will tell you to never use delays throughout your code, but to instead use the millis() or micros() function to keep track of time.

Edit: Good find.

I don't think that was the ecstatic response the OP was hoping for .... XD

And possibly not the point either. By virtue of using the delay, OP is getting an event at 24 hour intervals, even though he is calling it an alarm. If that is what he wants, which apparently it is, the methodology seems entirely appropriate.

I don't claim to be an experienced programmer, but I use delays all the time. It seems to be a legitimate, and quite popular, way to do nothing.

Thanks for sharing. I don't like the way you did that for "setting the alarm" and I don't like the result. 1 second in 1 day, I believe is too mush inaccurate (at that rate there will be more than 6 minutes in an year and 1 hour in 10 years). But thanks for sharing anyway.

luisilva:
Thanks for sharing. I don't like the way you did that for "setting the alarm" and I don't like the result. 1 second in 1 day, I believe is too mush inaccurate (at that rate there will be more than 6 minutes in an year and 1 hour in 10 years). But thanks for sharing anyway.

6 minutes a year is accurate if all you need is an alarm once a day... I think drift of an hour is acceptable a year if all you need is a reminder to take your medication eg anytime after 6pm but ideally around the same time every day :slight_smile:

Cool thanks for the test good to know :slight_smile:

Hi, depending what you are using it for, if you have a clock using the delay, and you live in certain parts of the world, you will be resetting the clock , twice a year anyway.

Tom.... :slight_smile:

Duemilanove has a crystal for the system clock, so is more accurate than an Uno or other board that has a ceramic resonator.

TomGeorge:
Hi, depending what you are using it for, if you have a clock using the delay, and you live in certain parts of the world, you will be resetting the clock , twice a year anyway.

That can be avoided

HazardsMind:
That’s great, but no one uses delays. An experienced programmer will tell you to never use delays throughout your code, but to instead use the millis() or micros() function to keep track of time.

millis(), yes. No actual difficulty doing that, including in this situation.

Unless you also take into account the duration of the alarm (which if it is manually reset, you cannot do using “delay()”), then you will be “out” by the execution time of the alarm anyway.

Hi,

Neat, just stored URL in case I need it.

Tom...... :slight_smile:

beware, as millis() in arduino 168 and 368 chips does a 16-bit integer and won't wait for longer than 31.767seconds

ad2049q:
beware, as millis() in arduino 168 and 368 chips does a 16-bit integer and won't wait for longer than 31.767seconds

Yeah, right.
(You may want the software the US Secret Service is talking about buying to interpret that)

ad2049q:
beware, as millis() in arduino 168 and 368 chips does a 16-bit integer and won't wait for longer than 31.767seconds

Where did you read that? The function returns an unsigned long, which, last time I checked, is 32 bits and can hold a value up to 4,294,967,295. Which is 4,294,967.3 seconds. That's 71582+ minutes, or 1193.05 hours.

millis(), as I recall, rolls over after just shy of 50 days. And if the compare is done as a subtraction, roll-over would only be a problem if you tried to time something twice that long.

Or if you neglected to change the relevant variables to unsigned long, that are currently merely defined as long in the example sketch, Blink Without Delay.

Someone here gave the correct way to make sure that using millis() does not result in a cumulative error. Where was that? Anyone?

pretty normal for crystal around 115 ppm precision. so no surprise,

Here is what I was looking for regarding millis() and avoiding cumulative error:

I apologize for not responding to your earlier post. I misunderstood what you meant by "cumulative error".

anyone know how he did the timing ? I was thinking of using one UNO with an RTC and data logger to see how my units fair in the 24 hour test.

Well, Coding Badly, if you can't read my mind, what good are you? :stuck_out_tongue: