Time of day

From edgertronic high speed video camera
Jump to navigation Jump to search

What time is it anyways?

Goal: document how to configure the camera so the trigger time is accurate to +/- 10 milliseconds.

Conclusion: figuring out what time it is, down to a +/- 10 milliseconds, is difficult to do and more difficult to verify it has been accomplished. At this point, we don't have enough data to know if the goal has been achieved. The initial measurements look good (+/- 8ms with camera CPU under heavy load and 7,000 measurement taken using a stratum 1 NTP time server). The source of the error is the drift of the DM368 Linux wall clock, which appears to be caused by the NTP algorithm.

Trigger timestamp

There are around 75 pieces of information in the metadata file relating to a captured video. One line contains the trigger time, in units of Epoch time, which is defined as seconds from midnight Jan 1, 1970 UTC. Up until software version v2.5.2rc37, the trigger time value was an integer, with around +/- one second of accuracy based on the camera's time being set using NTP. After v2.5.2rc37 the trigger time value is a float, as shown using an example below

Trigger time:   1671730962.816334       (sec since 1970)

How accurate is the trigger time value? Let's analyze the system to quantify the accuracy.

Trigger event

The camera triggers, and assoicates a trigger time when the trigger event occurs. The frame in the video, which we call the trigger frame, and is given the frame number 0, is the frame whose capture starts after the trigger event. The metadata file records the trigger delay, which is the time from the trigger event until the start of the trigger frame.

Camera time

The camera contains a general purpose CPU, running Linux, which keeps track of the camera time (also called wall clock or time of day) and when a trigger event occurs, Linux records the camera time.

Source of time error

From the above description, the sources of error when capturing the trigger time include:

  • Inaccurate setting of the camera time.
  • Drift in camera time.
  • Delay between the FPGA detecting the trigger event and the Linux camera application reading the time-of-day clock.

Improving time accuracy

Fixing Linux's variable interrupt handling delay

With v2.5.2rc37, clever programming on the part of Todd and Mike has compensated for variable interrupt latency in Linux.

During the development and testing of this feature, we captured around 9,000 videos and are confident that our solution works.

There is a known problem with the Linux VFAT file system, which slows system response times when there are more than 200 files in a directory. Our testing has shown our fix holds up even when there are thousands of files in a directory.

Setting camera time

There are two currently supported mechanisms to set the camera time: (1) web browser user interface and (2) Network Time Protocol (NTP).

webUI: Using the camera's web user interface to set the camera time is accomplished by clicking on the settings button, followed by selecting the About tab in the setting modal, followed by clicking on the Sync Camera Time (UTC) button. I estimate this will set the camera time +/- 1 second compared to the computer's time of day clock. This is likely sufficient unless you have multiple data acquisition systems where you want to associate data from another system with a specific frame in a captured video.

NTP: The camera NTP support provides a camera time with the accuracy limited by the NTP server accuracy, the NTP protocol itself, and Linux running on a 433 Mhz ARM9 processor. If the NTP server is on the same local area network, I would estimate the camera time to be +/- 1 ms to the time on the NTP server. A quick internet search turned up a $350 NTP GPS stratum 1 time server, which I haven't tried myself.

Drift in camera time

The NTP protocol compensates for drift, so keeping the camera for long periods of time doesn't effect the camera time's accuracy in these cases.

If you use the webUI to set the camera clock using the computer's current time, and you only do this once, the you will have drift when the camera is off caused by the battery operated Real Time Clock chip. You will also have camera time drift when the camera is on due to the tolerance of the CPU clock oscillator chip. Since the camera clock accuracy is in the +/- 1 second range of the computer's time, the best way to deal with this clock drift is to set the camera's time (via the webUI) each time you use the camera.

Synchronizing other sampled data with specific video frames

If you have multiple data acquisition systems recording the same event, it is possible to convert a timestamp from some acquired data to a section in capture video that corresponds to frames captured at approximately the same time as the timestamped event. If the camera time and camera accuracy are sufficiently precise and if the data acquisition system time and timestamp accuracy are sufficiently precise, you can calculate the frame of interest.

Let

  • [math]\displaystyle{ E_{ts} }[/math] be the timestamp from the data acquisition system that is identifying the event of interest,
  • [math]\displaystyle{ C_{ts} }[/math] be the captured video trigger timestamp, the time frame 0 was captured
  • [math]\displaystyle{ FrameRate }[/math] be the framerate of the captured video,
  • [math]\displaystyle{ FrameCount }[/math] be the total number of frames in the captured video, and
  • [math]\displaystyle{ PreTriggerFrames }[/math] be the number of frames before frame 0, the trigger frame.

[math]\displaystyle{ C_{ts} }[/math], [math]\displaystyle{ FrameRate }[/math], [math]\displaystyle{ FrameCount }[/math] and [math]\displaystyle{ PreTriggerFrames }[/math] are all values obtained from the metadata file.

Then the event frame number [math]\displaystyle{ E_{fn} }[/math], from the start of the video (being frame 1) can be calculated.

[math]\displaystyle{ E_{fn} = int( (C_{ts} -Ets) * FrameRate +PreTriggerFrames + 1.5) }[/math]

Where [math]\displaystyle{ Efn }[/math] will be an integer between 1 and [math]\displaystyle{ FrameCount }[/math] if the captured video contains the frame associated with the event of interest.