See this doc for more details.
Probably related to this issue.
The timestamps in file names are inaccurate and gradually lag further and further behind the real time. The differences between consecutive timestamps reflect the trigger interval we've set, but because the timestamps are lagging, the interval between photos is also greater than we intend.
Each file has three timestamps: 'triggertimestring' is identical to the time saved in the filename. The first file in a bout of recording has an accurate timestamp, but subsequent ones are slow. I'll investigate further if the trigger times are consistent but slower than intended, or if the trigger times are inconsistent.
I have not investigated 'triggertime', I assumed it was just a datetime translation of the trigger string, but the issue previously raised by Joe H suggests they are not the same.
Finally there is a 'camera_timestamp'. This is a count in nanoseconds, probably from when the cameras were last booted up, but I'm not certain. This does appear accurate, in the sense that the difference between the first and last camera timestamp in a set of photos reflects how long I was recording for. I haven't tested whether it is truly accurate at a sub-second resolution.
Assuming that the camera_timestamp is reliable, we can reconstruct accurate timestamps by calculating the time passed since the first file in a set and adding it to the timestamp from the first file which is accurate at least on the order of seconds. For 3D recordings, Mike has built an LED clock to hold up during alignment photos, so we can use that to get a more precise initial timestamp.
So, we can very probably get accurate information on when each photo was recorded, retrospectively. But this doesn't fix the fact that the triggers are occurring slower than we intend. We might be able to live with that and just learn to set the triggers a little faster. But maybe there's a better fix? I don't know what allows the cameras to make an accurate count, but if we can run something similar on the Pi we could use that to control the trigger timing?
See this doc for more details.
Probably related to this issue.
The timestamps in file names are inaccurate and gradually lag further and further behind the real time. The differences between consecutive timestamps reflect the trigger interval we've set, but because the timestamps are lagging, the interval between photos is also greater than we intend.
Each file has three timestamps: 'triggertimestring' is identical to the time saved in the filename. The first file in a bout of recording has an accurate timestamp, but subsequent ones are slow. I'll investigate further if the trigger times are consistent but slower than intended, or if the trigger times are inconsistent.
I have not investigated 'triggertime', I assumed it was just a datetime translation of the trigger string, but the issue previously raised by Joe H suggests they are not the same.
Finally there is a 'camera_timestamp'. This is a count in nanoseconds, probably from when the cameras were last booted up, but I'm not certain. This does appear accurate, in the sense that the difference between the first and last camera timestamp in a set of photos reflects how long I was recording for. I haven't tested whether it is truly accurate at a sub-second resolution.
Assuming that the camera_timestamp is reliable, we can reconstruct accurate timestamps by calculating the time passed since the first file in a set and adding it to the timestamp from the first file which is accurate at least on the order of seconds. For 3D recordings, Mike has built an LED clock to hold up during alignment photos, so we can use that to get a more precise initial timestamp.
So, we can very probably get accurate information on when each photo was recorded, retrospectively. But this doesn't fix the fact that the triggers are occurring slower than we intend. We might be able to live with that and just learn to set the triggers a little faster. But maybe there's a better fix? I don't know what allows the cameras to make an accurate count, but if we can run something similar on the Pi we could use that to control the trigger timing?