SharpCap Timestamp accuracy

Anything that doesn't fit into any of the other forums
Furgus
Posts: 24
Joined: Fri Mar 16, 2018 9:27 am

SharpCap Timestamp accuracy

#1

Post by Furgus »

Hi,
Firstly...get well soon Robin, and thanks as always for the program!

I use the SharpCap timestamp function a lot (occultations) and sync my laptop clock to UT from a GPS server I have. ('LeoNTP'). (no internet involved!)
'Meinberg' software controls this, and logs the difference between UT and the laptop clock....its always under 0.5ms.

To test accuracy, I have the 1PPS output from the GPS fed to an LED, which is recorded on-camera (ZWOASI174), along with any event I'm observing.
I can then see if the timestamp is in agreement with the LED as it comes on, every second.
This can show if there have been any 'Windows Interrupts' affecting the timing of an observation.
(BTW I run Sharpcap with 'RealTime' priority in W10 to minimise the chance of this occurring)
My tests reveal its very good...the timestamp is accurate over the range of usable shutter speeds.

But....I have it from an authority that there is usually a 20-25ms delay between UT (laptop time) and 'Sharpcap time' (the timestamp)....caused by the drivers and the programme itself. I cannot say I am seeing this at all. Does anyone else experience an 'offset' between the laptop time and the timestamp??
20-25ms seems an awfully long delay to me, considering whats going on; does anyone else have data or experience in this area??
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: SharpCap Timestamp accuracy

#2

Post by admin »

Hi,

unless you are using the QHY GPS cameras then there will be an unavoidable lag in the timestamp, since the timestamp used is the point in time where SharpCap becomes aware of the new frame being available. This occurs after the end of capture of the frame and after whatever delays introduced by transferring the frame data to the PC and any processing that occurs in their camera SDK before SharpCap is notified of the new frame. This delayed may vary between different brands of camera, different cameras of the same brand or even when various different camera settings are used.

Hope this is helpful, Robin
Furgus
Posts: 24
Joined: Fri Mar 16, 2018 9:27 am

Re: SharpCap Timestamp accuracy

#3

Post by Furgus »

Thankyou Robin,

That is indeed helpful. It would seem that using the fastest connections (ie USB 3) would minimise offset? Also the smallest ROI one can get away with?
I must say that the offset with my setup must be relatively small....using the timing method as below, very nearly all of the frames that first show the 1PPS LED coming on are stamped with the timestamp whose frame exposure time spans the 'xx.000s' point in time. Even at 100fps this holds true.
I suppose the error could be roughly the same for longer exposures, as the 'download' time should not be affected by exposure time?
(BTW I always taken the midpoint of the exposure to be the 'Frame time').

Many thanks!
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: SharpCap Timestamp accuracy

#4

Post by oopfan »

A couple years ago I worked briefly with an advanced amateur (adjunct prof of physics) whose life revolved around asteroid occultations. He was looking for a novel solution to an old problem: precise timing of events. Pros have long used optical systems that "inject" the timestamp directly onto the camera's sensor -- sort of like an off-axis guider in reverse. If that sounds complex, it is. An alternative is to find a camera that has built-in circuitry for timestamping an image saved as metadata in each image that is downloaded to your acquisition software. Perhaps ZWO's high-end cameras have this capability. I would not rely on there being a constant latency between your camera and SharpCap even if you use USB3.

Brian
Furgus
Posts: 24
Joined: Fri Mar 16, 2018 9:27 am

Re: SharpCap Timestamp accuracy

#5

Post by Furgus »

I think you are right Brian, there is very likely going to be a variation. Hopefully not too large.
However, one advantage of these cameras is they are generally more sensitive (when binned, anyway) than traditional video cameras (eg Watec), so can generally run at a higher frame rate, so making up for some loss of precision. Max on 'PAL video' anyway is 50i/25P of course.

QHY do have a 'stamping' camera such as you describe.....from things I've seen on the web, accuracy at higher framerates does not look good for some reason. (100ms in some cases?) Its also quite pricey. ZWO unfortunately have no plans to release a Global-shutter, GPS, timestamping camera. I asked them!

Robin....could you clarify one thing.....I thought that the SharpCap timestamp refers to the beginning of the exposure of each frame. Or have I got that wrong?....from what you say, the frame is only stamped when the exposure is finished and the camera notifies Sharpcap that the frame is available.
Many thanks.
User avatar
oopfan
Posts: 1321
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: SharpCap Timestamp accuracy

#6

Post by oopfan »

Yes, those too are factors: global shutter vs rolling shutter, plus high frame rates. Not all cameras meet these demanding requirements.

Brian
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: SharpCap Timestamp accuracy

#7

Post by admin »

Hi,

I can confirm that the timestamp is the time that SharpCap received the frame from the camera i.e. after the frame is finished.

Cheers, Robin
Furgus
Posts: 24
Joined: Fri Mar 16, 2018 9:27 am

Re: SharpCap Timestamp accuracy

#8

Post by Furgus »

Hi,

Sorry to come back on this again, but has the way in which this works changed from a previous build?
Early last year there was some advice that

'for videos the timestamp is the start of capture time, for single frames it is after the frame has been captured'

It does seem from my tests to be stamped at the start of frame capture for videos......either that or 'SharpCap time' is late (lower numbers) compared to Laptop time (UT) but is applied to a frame which has just previously been captured......thereby appearing correct!!

As I say, sorry to be so searching on this but getting my head round this would really help!
SharpCap seems to be the most stable capture program I have tried in this respect.

Once again, many thanks!
User avatar
admin
Site Admin
Posts: 13173
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: SharpCap Timestamp accuracy

#9

Post by admin »

Ah, right I understand now the cause of the confusion. The time used to name a video capture file is the time just before it starts capturing however if you capture a file in a format like SER where each frame is time stamped individually, timestamp for each individual frame is the time that this frame is delivered to SharpCap from the camera SDK. Similarly the timestamp that is written into the file when capturing individual frames to fits format is the time that the frame arrives at SharpCap from the SDK, i.e. after the frame capture is complete.

Hope that makes sense now, Robin
Furgus
Posts: 24
Joined: Fri Mar 16, 2018 9:27 am

Re: SharpCap Timestamp accuracy

#10

Post by Furgus »

Thankyou....it does makes sense.....but I wonder what exactly is happening because I think I'm seeing another effect.

Enclosed a very short animation from my ZWOASI174 . This has a modification to record the output, via fibre optic, of a 1PPS LED from GPS. This is accurate to 100 nanoseconds. (It is on the bottom right of the frame). A few consecutive frames are shown.
I have done hundreds of these tests with all sorts of frame rates and ROIs...SharpCap is very consistent. The light nearly always is first seen in the frame that covers 'xx.000' seconds......a perfect result within the limitations of the exposure time itself. SER or AVI formats....no difference.
(the LED comes on instantly....of course if it is 'dim', it has come on part way through the exposure).

Therefore It would appear that the timestamp is allocated at the start of the exposure....but from what you and others have said, that may not be the case, in which case some fortuitous effect makes the stamp appear 'accurate'!

Any comments or suggestions on this effect would be very welcome.
It seems such a good system to use for this sort of work.
Many thanks!
Attachments
Example two -25ms exposure.gif
Example two -25ms exposure.gif (135.75 KiB) Viewed 4143 times
Post Reply