Question about Timestamp handling

[mcamilleri]

Hi Robin,

Thanks for implementing ADV format for non-GPS cameras. I have been using it for many months now for occultation observations and it has worked very well, with much smaller file sizes and less processing load and fewer dropped frames.

My question is about how timestamps are handled.
1. What rounding method is used to form the ms (3 d.p.) figure? Down, nearest or up or something else?
2. I think the timestamp is the time that SharpCap picks up the frame from the USB. Is that correct?
3. Is there any way with USB 3 to instead use the logged time that the frame hit the USB interface (assuming that it is logged)
4. Video vs Still mode. Video mode I think has the camera send a steady stream of images governed by the camera, so has a stable frame rate and exposure and minimal dead-time. What happens in Still mode? How is the next frame triggered? For example, is it before write to disk, or after write to disk is completed. I am trying to get an idea of how large and consistent a gap there may be in the frames.

Thanks
Michael

[admin]

Hi Michael,

Let's see on the ADV questions...

1. SharpCap doesn't round the timestamps itself, but it looks like the ADV library does when creating the milliseconds since epoch value - it just does integer division, so will always round down. By the look of things it may be storing a 'nanoseconds since epoch' value too - not sure if that actually gets to the file or not though.

2. & 3. The timestamp is set when SharpCap is delivered the frame from the camera SDK software. In general, timings before that point are unknown - nothing records how long the frame sat on the camera before beginning USB transmission, or how long the transmission took, or how long it was processed in the camera SDK before being handed to SharpCap.

4. You are correct, in video mode, the camera will start capturing a new frame by itself either immediately or soon after the previous frame finished. This will typically be close to immediate for longer exposures (where the exposure is longer than the USB download time for the image), but will be delayed for shorter exposures where the USB download time is limiting the frame rate to avoid having a second frame ready before the first has finished transferring to the PC.

In still mode, SharpCap requests each frame individually - this happens pretty quickly after the previous frame is handed to SharpCap (before any image processing, saving, etc), but there will still be some delay both in the SharpCap code and in the time for the 'new frame please' message to be passed to the camera and acted on.

From experiments done with GPS cameras, it seems that the frame rate and lag are pretty stable as long as the camera settings are kept the same, but when you start changing settings (particularly exposure, image/ROI size and 'turbo USB' settings), you can't count on the values that you measured/estimated at other settings.

Hope this helps,

Robin

[mcamilleri]

Thanks. That is very helpful.

So late or dropped frames are inevitable at fast rates using Video mode. In Still mode it seems like it will request the next frame as soon as the current frame is received then that will wait in the buffer until the SDK and Sharpcap can pick it up. Maybe that will give more consistent behaviour when the frame rate is too high.

I have done extensive testing using GPS flash timing and the delays are usually consistent to within 1-2 ms for the same camera settings. It varies depending on ROI, tilt, pan, binning, colour space and bit depth. It doesn't vary with gain. It does not vary with exposure as long as the exposure time is long enough to avoid dropped frames. I doesn't seem to vary with USB speed/mode unless the setting is very low, but I have not tested that much - I just run at full throttle or a high setting.

I have not done any testing of Still mode. I usually run in Video mode to ADV and I don't know if I can save to ADV using Still mode. Video mode seems to give a more consistent frame rate than Still mode, which is why I use Video. I'll do some testing to try to understand the behaviour.

Thanks again for your help and great customer support.

Michael

[admin]

Hi Michael,

you are correct that you cannot save to video file formats (ADV, SER, AVI) with the camera in still mode, so that rules out deliberately using the camera in still mode I think. On the other had, some cameras switch to still mode automatically above a threshold exposure length (about 2s) as it turns out to be easier to handle cancelling a frame in progress that way. Additionally, QHY cameras have an option to 'Force still mode' which makes them run internally in still mode when SharpCap is in video mode.

cheers,

Robin