SharpCap Timestamp accuracy

Anything that doesn't fit into any of the other forums
User avatar
oopfan
Posts: 387
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: SharpCap Timestamp accuracy

Post by oopfan » Fri Nov 30, 2018 2:20 pm

This is a remarkable coincidence. The SDK is "closer" to the camera than SharpCap so perhaps the SDK has got a clever way of working with the camera's firmware to make a very good estimation of the start of the frame. Perhaps the SDK is delivering the image data AND the metadata to SharpCap, and SharpCap is just reading the timestamp from the metadata.

Brian

User avatar
oopfan
Posts: 387
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: SharpCap Timestamp accuracy

Post by oopfan » Fri Nov 30, 2018 3:10 pm

I think it is a very good idea to continue using a fiber optic flash once per second as insurance. Versions of the SDK and SharpCap change frequently. I wouldn't want to be caught publishing data based on assumptions of accuracy.

If you haven't already done so, inject the flash while you are imaging the occultation. Engineer it like you're on a mission to Mars. There is a great need for high-precision astrometry but your data will be assigned a lower weight if your methodology makes assumptions.

Brian

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

Re: SharpCap Timestamp accuracy

Post by admin » Fri Nov 30, 2018 5:10 pm

With the ZWO cameras then the timestamp for the frame is definitely obtained by SharpCap after the frame has been delivered from the SDK – I just checked in the code! The only camera that gets a timestamp from the SDK is the qhy GPS model.

I'm afraid I really can't explain how the timings work out so well for you given the above information, sorry.

Cheers, Robin

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

Re: SharpCap Timestamp accuracy

Post by Furgus » Sat Dec 01, 2018 3:10 pm

Thanks Robin and Brian for your thoughts.

I wonder if a simple subtraction of the exposure duration is taken from the timestamp allocated at the end of the exposure? This would get you quite close. Certainly it fits in with my observation that the timestamp is virtually perfect when running the camera with many different exposure lengths.
I wonder if this is possible.

Yes, the fibre optic to the camera is now used on all my observations. There is a small box attached to the back of the camera that contains the LED and a device (non-electronic) to control the amount of light going down the fibre optic. The 'dot' of light on the chip is a little larger than I would have liked, but its actually not a problem. Sam at ZWO (always helpful) advised that the smallest ROI one can use for the job (especially in the vertical sense) makes the frame downloads faster. He said you can prove this by pushing the frame speed to its upper limit....its always true that the 'shortest' ROI's always are able to run faster (not that I need very high frame rates).

Concerning the 'in vision' LED light pulse.....what would be great would be a more rapid accurate pulse.....slaved to the 1PPS. One where whole second values were still identifiable somehow. I'm sure an electronics engineer could design one with little (or fixed) latency. Not me, unfortunately, but I'm sounding around!

Many thanks!

User avatar
oopfan
Posts: 387
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: SharpCap Timestamp accuracy

Post by oopfan » Sat Dec 01, 2018 4:42 pm

So, you would like a 10MHz clock that is synchronized to the 1PPS output of the GPS? I did a quick search at Digi-Key and Mouser but came up short. This project is way above my pay grade but I know someone who might be of assistance in one form or another.

In the meantime with your current setup you could associate a confidence level with your published data. For example if you are recording at 48fps, and you count 48 frames between 1PPS flashes, then you can be highly confident that the event happened at 1/48 sec times the number of frames past the previous flash. But if you count only 45 frames between flashes you can't be certain where those dropped frames occurred. The best you can do is linear interpolation and state a lower confidence level. Are you seeing a lot of dropped frames?

Brian

User avatar
oopfan
Posts: 387
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: SharpCap Timestamp accuracy

Post by oopfan » Sat Dec 01, 2018 9:01 pm

I just contacted him. Perhaps if there exists an integrated circuit that does it all then I would be able to help out.

Brian

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

Re: SharpCap Timestamp accuracy

Post by Furgus » Sat Dec 01, 2018 11:42 pm

Thanks Brian that sounds very interesting indeed!

My initial thoughts on the feasibility....the 'whole second ' pulse would need to be marked, or different in some way, to the others....not sure if thats possible.....?

Back to SharpCap.....I can say that since Robin's fix of the latest version...its extremely rare to get any dropped frames at all, at any normal speed; the intervals on the timestamped frames are not always perfectly even, but nearly always within a couple of milliseconds if 'wrong'.
I keep to USB 3 throughout, of course, and only use SSDs for capture.

Very interested in any info you can find out.

Many thanks!

User avatar
oopfan
Posts: 387
Joined: Sat Jul 08, 2017 2:37 pm
Location: New York
Contact:

Re: SharpCap Timestamp accuracy

Post by oopfan » Mon Dec 03, 2018 1:39 am

So, the specs of your camera suggest that the fastest frame rate is about 750fps (ASI174MM-Cool). If you have the mini then it is much less. 750Hz is an eternity in today's gigahertz world of communications which is where you find all of the clock synthesizers available as an integrated circuit however this is not to mean that you are out of luck -- you just need to program a microcontroller like an Arduino Uno that runs at 16MHz and costs $22. Essentially you would feed the 1PPS signal from the GPS into the Arduino. Each pulse will create an interrupt and run a bit of code that you write that pulses an output pin that drives the base of a transistor that creates a strong pulse of current through the LED that goes through the fiber optic to the camera. So it is different from what you are doing now. Right now I would guess that you have the 1PPS signal directly driving the LED. In the new scheme the 1PPS signal is wired into the Arduino which in turn drives the LED.

Now, in order to synthesize a faster clock rate, you enhance your interrupt service routine to start a 1MHz timer onboard the Arduino in order to measure the number of 1 microsecond ticks until the next interrupt fires. In an ideal world there are 1,000,000 ticks in 1 second but you will find that there are actually more or less depending on ambient temperature and other factors. The idea is to create a rolling average of say the last one minute of measurements. The current average will be the number of ticks that you expect to expire before the next 1PPS arrives. For arguments sake, let's say that number is 983,416. So you would program the Arduino to interrupt you every 491,708 ticks so that you can flash the LED at a 2Hz rate, or if you want a 10Hz rate then you interrupt every 98,341.6 ticks. Just to be clear the code constantly monitors itself against the 1PPS reference so that it responds to changes in the environment.

With regards to your question of how to differentiate the 1PPS event from the 10Hz or 100Hz pulse train using just a single LED, you can take advantage of the fortunate fact that the camera gives you 12 bits per pixel. The Arduino code will ensure that more electric current flows through the LED on 1PPS events. It does that with a thing called pulse-width-modulation.

99% of this project is software. It is best to find someone locally to work with. I suggest visiting your local university's engineering department and explain the project. The department head should know if he's got a sharp student that fits the bill.

Brian

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

Re: SharpCap Timestamp accuracy

Post by Furgus » Mon Dec 03, 2018 9:03 am

Many Thanks Brian,

Will digest all of this and ask around. I like the idea of 'PWM' indicating the second.

Thanks again!

User avatar
turfpit
Posts: 523
Joined: Mon Feb 13, 2017 8:13 pm
Location: UK
Contact:

Re: SharpCap Timestamp accuracy

Post by turfpit » Mon Dec 03, 2018 11:35 am

Furgus

For a time critical application it is possible that software running on the capture machine could be an issue. For that I would include:
  • Windows itself
  • Antivirus software
  • Wireless trying to connect to an out of range WAP
Watching Task Manager or Resource Monitor can be quite an eye-opener on what people think is a machine doing nothing. An AV file or process scan is an eternity with the time frames you are dealing with. Also Windows reporting (or trying to report) back to Microsoft with things like errors.

My Windows capture laptop is pretty stripped down software wise & I run with wireless/bluetooth off. It might be worth having a look at what is actually going on in your machine

Dave

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest