Howdy,
Im building the old motion controled timelapse photography setup.
Now, how do I messure the time between shots? It takes quite a long time to progress my code, so how do I know how long has passed while my code was processing? Is there an internal clock on the Arduino?
Cheers,
Nick Deboar
Hi Nick,
There is a function called millis() that returns the number of milliseconds since the Arduino was last reset. You can determine elapsed time between shots by saving the value returned from millis when you take your shoot, then wait until you get a value from millis that is greater than the previous value by the number of milliseconds desired between shots.
The millis value rolls over after around 9 hours so you need to take some precutions to handle this. A search in these forums for millis rollover should yield some suggestions for thing you can do.
If your delay will be in the order of seconds or more, you may want to look at the DateTime library in the playground. This has a function called now() that returns the number of seconds since the Arduino was started and for all practical uses this value doesn't roll over.
Also, depending on the accuracy you need you might consider a timekeeping chip to do the job.
There are external clock chips (called RTCs, or real time clocks) that also have alarms on them. You can wire one of them for an accurate time of day clock, or take it a step farther and configure the RTC to generate an alarm, which you use to trigger the camera and set the next alarm.
It all depends on your time interval and accuracy requirements.
-j
Nice!
I reckon the on board timmer will do the job, if it's out a couple miliseconds here or there it shouldn't ruin the shot.
Cheers!
Nick
The Arduino crystal should be accurate to a few seconds a day (around a millisecond or so per hour).
The Arduino crystal should be accurate to a few seconds a day (around a millisecond or so per hour).
a millisecond per hour is 24 miliseconds per day. 3 seconds per day is 125mS per hour. There's a couple of orders of magnitude difference in there.
Indeed, The crystals used by the Arduino are typically specified to 20 or 30 parts per million, which is between 2 and 3 seconds per day or around 1ms in a half minute, something around 120ms per hour.
The DS3231 is my favorite chip for this kind of application. With the IC and a lithium battery, you now have a battery-backed clock that drifts only a few seconds per year. It does this by using a precise internal crystal and compensating for temperature and aging effects.
It uses I2C and is pretty straightforward to get running. It's a 16-pin SOIC but 9 of the pins are just used for ground anyway.
Nice!
I reckon the on board timmer will do the job, if it's out a couple miliseconds here or there it shouldn't ruin the shot.
Cheers!
Nick
The millis() function works quite well for what you need, in fact, if you're going to be moving motors and such, you will have to use a millis() based timer to do shot interval timing. Given that you will most likely use delay()s in motor movements and it's much more accurate to use delay() for the shutter open time, (tried lots of solutions, for bulb-mode shooting, delay is more accurate for shutter-open timing than looping and checking conditions and then checking millis() - the math to count the difference in millis readings alone can take several more ms than one imagines).
However, be warned about both delay and millis, presently this response in a post is going to have some effect on your design: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1210889307/36#36
The millis/delay issues have had an impact on one in about 350 shots in my test setup. That is, sometimes delay won't delay as long as I expected, or sometimes it will delay longer - not very bad for shooting in M-mode w/ camera-set timing, but using a bulb-mode for timings of less than a second or two can cause exposure fluctuations. Not a big deal, as this can be compensated for in post.
If you're interested, I have fully rolled and working code to deal with 1 camera and 3 stepper motors (using easy driver, truck/dolly, pan, and tilt) I'd be happy to share with you. It's part of a multi-controller setup, where all variables are set elsewhere (via i2c), so I'd remove most of that i2c code that wouldn't make sense without the same UI (You can set variables by hand or some other means). It handles moving motors to preset amounts, skipping shot cycles when moving motors, stopping after x shots, manual motor control (single motor at a time), 49-days between shots (+/- millis errors and crystal accuracy =), and well, a bunch more stuff. Without the i2c code, it's less than 500 lines with about 100 lines of comments. Oh, and it's GPL grin (will release all the software later, as I work out system problems.)
If you like, I'd be happy to post it here, if for nothing else to help you get started.
!c
The DS3231 is my favorite chip for this kind of application. With the IC and a lithium battery, you now have a battery-backed clock that drifts only a few seconds per year.
I thought the DS3231 is specified as accurate to 2 parts per million, an order of magnitude better than the uncompensated arduino crystal, but that's a around a second a week, how do you get the figure of a few seconds per year?
I thought the DS3231 is specified as accurate to 2 parts per million, an order of magnitude better than the uncompensated arduino crystal, but that's a around a second a week, how do you get the figure of a few seconds per year?
Because that 2ppm is specified over a temperature variation of 0 to 40C. At normal temperatures, say 15C to 30C, the drift is much smaller. But even if your application was continuously running in freezing and desert temperatures, the quoted worst case drift is going to be about 60 seconds in one year.
Maxim even has a live demo on their website, a DS3231 is subjected to outdoor temperatures and was last synced with atomic time in 2005. Right now it's about 69 seconds off. If the device spends most of its time indoors, the accuracy will be even better. If you're using it for a timing application, it'll take a week for even one second of drift to appear at temperature extremes.
Indeed, The crystals used by the Arduino are typically specified to 20 or 30 parts per million, which is between 2 and 3 seconds per day or around 1ms in a half minute, something around 120ms per hour.
So you meant a couple of milliseconds per minute instead of one per hour. I'm not trying to be flippant, I just didn't understand what you meant in that paragraph; were you agreeing the earlier post was wrong?
Indeed, The crystals used by the Arduino are typically specified to 20 or 30 parts per million, which is between 2 and 3 seconds per day or around 1ms in a half minute, something around 120ms per hour.
So you meant a couple of milliseconds per minute instead of one per hour. I'm not trying to be flippant, I just didn't understand what you meant in that paragraph; were you agreeing the earlier post was wrong?
Indeed: adverb
Synonyms: absolutely, actually, admittedly, certainly, honestly, naturally, positively, really, surely, truly, undeniable, undoubtedly, yea
I think I was agreeing with your post 