Accurate timelapse tied to system clock.

Use this forum to request new features or suggest modifications to existing features
Post Reply
Serge
Posts: 26
Joined: Sat Apr 23, 2016 6:23 pm

Accurate timelapse tied to system clock.

Post by Serge » Sat Apr 23, 2016 6:38 pm

I need the start of each frame of a long timelapse collect to occur at a reproducible time (+-0.05s) relative to the system clock, which I am regularly adjusting for drift using GPS/NTP.

At the moment timelapse collects do not appear to be tied to the system clock once started, so errors accumulate for long timelapse collects. (v2.0.17.0 beta)

My application is two cameras with separate instances of digiCamControl, driven by separate computers (not on a network but with accurate time) to take synchronized shots of moving objects for a stereo vision application.

With this addition/change the start of each frame should be reproducible and predictable to allow synchronization of long timelapse collects.
Last edited by Serge on Mon Apr 25, 2016 5:35 pm, edited 2 times in total.

Accurate timelapse tied to system clock.

Advertisment
 

Duka Istvan
Posts: 684
Joined: Sat Oct 03, 2015 7:57 pm

Re: Timelapse interval that is "start to start" of a frame.

Post by Duka Istvan » Sat Apr 23, 2016 8:46 pm

I made some improvement on time lapse capture precision in latest beta, but you can't capture with multiple camera synchronized this is a limitation of usb

Serge
Posts: 26
Joined: Sat Apr 23, 2016 6:23 pm

Re: Timelapse interval that is "start to start" of a frame.

Post by Serge » Mon Apr 25, 2016 5:18 pm

Hello,

I realize now that:
The latest beta that I am/was using is indeed "start to start". (i may need to remove/move/edit the post)
And the drift is constant with time, independent of exposure time.
And that the "Accuracy" tab in bottom right of the time lapse menu shows the drift in real time in milliseconds.
And that adjusting the "fine tune" can be used to offset the drift somewhat.

The problem is for very long time lapse collects where it will be very hard to keep the drift relative to system clock sufficiently small.

Question: is it not possible to tie each collect to the system clock? ie scheduling every shot just like the "start at" schedules the first shot. The program does have access to system clock because that is how the error is calculated?

(I thought of using an xml script to write my own trigger loop, but it seems that it is not possible to get the system time in milliseconds, and even an empty loop takes 0.2 sec to run, but I am hoping to get the timing to sub 0.1 sec accuracy, more or less repeatably, with fudge factors if needed.)

Wish I was smart enough to help program,
Serge

Post Reply