FITS header Average midpoint time (UTC)
Stacking program, astrometric (plate) solver, fits file viewer
Brought to you by:
han59
Menu
▾
▴
In a recent lightcurve image batch processed with ASTAP, the Julian Date in the AAVSO report is clearly using the image FITS header DATA-AVG field (Average midpoint time (UTC).
However, this is not equal to the start time (DATE-OBS + EXPOSURE / 2).
For attached example with exposures of 60 seconds, I would expect the midpoint 30 seconds after the start time (DATE-OBS), but DATE-AVG shows 31.6 seconds, so systematically 1.6 seconds later.
The sequence was taken with NINA capture software, but is there any explanation for the 1.6 second time difference and why the DATA-AVG time is preferred by ASTAP ?
Regards,
Tom
It is assumed that the DATE-AVG is the best representation of the time of the measurement. Why it is not equal to DATE-OBS + EXPOSURE / 2) I do not know. I have seen the answer from dghent at Cloudnights.
As far I can see Ascom supports only these two in the API:
lastexposureduration Duration of the last exposure
lastexposurestarttime Start time of the last exposure in FITS standard format.
So how does Nina get DATE-AVG? From a camera native driver or by calculating from the values above?
Which camera model is this image from and which driver is used?
Cheers, Han
The camera is ZWO ASI6200MM Pro
NINA version was the most recent 3.1 HF2 version
The connection is ASCOM (platform 6.6)
(although I have seen this added discrepancy of 1.6 sec with other camera's in NINA too)
I'll check out Cloudy nights, and maybe NINA forum
Thanks,
Tom
Hi Han,
I also read the dgent reply on cloudy nights and meanwhile got a NINA discord forum reply which is not very clear how to make sure what the correct midpoint timestamp should be (see attachment). They claim some overhead time and fixes in NINA Nightly version 3.2, but don't explain how they calculate DATA-AVG, so I still distrust it for now.
Most other capture software like Sharpcap, MaximDL, ASI-studio, ... simply uses DATE-OBS + EXPOSURE/2.
So this remains a surprise for me, but if I look at a recent ASTAP AAVSO report, the timestamp is clearly the DATE-AVG value in the FITS file. If I reduce the same image set with for example AstroImageJ, I get the normally expected timestamp. 1.6 seconds is an unacceptable difference.
Very welcome if this 'midpoint time' confusion could be clarified.
What is the ASTAP logic on FITS files before NINA version 2.3 (because these simply don't contain the DATE-AVG field)
Best Regards,
Tom
Good you triggered this discussion. :) Feedback is important for all freeware programmers.
In ASTAP the logic is very simple. If DATE-AVG is available use it else calculate it by DATE-OBS + EXPOSURE/2.
I think it is tricky to use the end-time. How is the transmission delay compensated if the camera has no GPS clock? By definition If the calculation DATE-AVG= DATE-OBS+exposure/2 doesn't match there is something wrong. Either DATE-OBS or DATE-AVG is incorrect.
Han
Hi Han,
For your info : I did some additional testing today with different camera setups and connections.
That does show a trend which points to DATE-AVG being wrong:
Test 1) NINA 3.2 Nightly : tested on suggestion with ASI6200MM
-> much worse : difference between DATE-OBS + EXP/2 and DATE-AVG is now 4 seconds
-> in a sequence you can see the NINA exposing counter finish the exposure and then it wastes at least 5 seconds before starting the next exposure. If that gets added to DATE-AVG it is clearly wrong.
Test 2) back to NINA 3.1 HF2 (uninstalled the 3.2 Nightly, because much worse)
-> returned with the ASI6200MM in 2x2 binning mode to DATE-AVG difference of 1.6 seconds
-> without binning (1x1) difference = 1.7 seconds (slightly larger)
Test 3) Changed USB hub to direct connection
-> changed camera connection from powered 4 port ACT USB-c hub to direct laptop USB input
DATE-AVG difference now only 0.7 seconds !
Test 4) small ASI290MM camera:
-> changed camera to small ASI290MM with direct USB 3.0 input in laptop
-> DATE-AVG difference now dropped to 0.1 seconds !
My conclusion : DATE-AVG is wrong and adds unnecessary delays of USB communication and image size AFTER the image is taken.
Seems hard to believe that NINA shows a running progress bar for the ongoing exposure if it hasn't really started.
The smaller the image and download connections become, the closer you get to DATE-OBS+EXP/2
I will not use DATE-AVG anymore for now, I think it should have a warning for other users as long as it not 100% clear why some post-image delays seem added.
Let me know if it's useful to post this also on the NINA Discord forum, but I think it is better that you follow this up as developer specialist.
thanks for your follow-up
Tom.
Hi Tom,
Good you did some testing. I do not understand why the ignored the previous remark that the error was depending on the exposure duration. Now you have solid proof. I think you can drop it on Discord. Nothing to hide. Just report the observations and maybe replace the word "wrong" with erroneous . Maybe even ZWO is to blame. Everybody is volunteer and the discussion should stay friendly. If your unhappy with that, tell me and I will do it with pleasure.:)
Cheers, Han
You were very right: I appreciate all volunteer work a lot! I just got carried away a bit by discovering this issue and getting worried.
I have put a moderated version on NINA Discord.
I was now advised to try native driver connection instead of Ascom.
I'll first have to find out how to do that. NINA only shows a list of Ascom drivers.
Thanks for your advice as always,
Tom
Hi Tom,
Good and thanks for the feedback.
I do not own a ZWO camera at this moment but it would be nice to test the current accuracy of the reported DATE-OBS. That would require an ordinary camera lens mounted on a ZWO camera looking to a digital clock on an computer screen. An alternative would be using your telescope looking to a far away laptop in focus. That would require a big garden. Is this something you would be interested in and able to realize? It is not so important but I'm just curious how good the current ZWO drivers are.
Maybe I will do with my ToupTek camera. It would only require a little program to scroll the time across the screen
Success, Han
Excellent idea, I think I can do that, but it set me thinking about exposure time:
- on one hand you want to test millisecond accuracy: https://clock.zone/europe/antwerp
- on the other hand, you can not expose this longer to see the date-avg effect.
Would you just take very short exposures to verify only DATE-OBS (UTC) ?
I also need to find a way to get a the very large ZWO ASI6200MM camera in focus, because the large image size seems to have an effect. I think that is feasible with a smaller telescope on a tripod with some extra supporting.
Or would you say it doesn't matter which ASI camera if you only want to verify DATE-OBS (I have several small ones for planetary observing like the ASI290MM or ASI178MM) -> then you don't have the DATE-AVG delay effect
By the way: I was already using the ZWO native driver in my testing, by switching to ASCOM the DATE-AVG difference gets a little worse.
Tom
You could start with online clock something like this one:
https://clock.zone/
With an exposure time of 0.001 seconds or some more, the time recorded in the image should match with DATE-OBS.
For longer exposures it would require something moving. If the first test works, I could make a little program for use with longer exposures
If DATE-AVG<> DATE-OBS+exposure/2 then there is conflicting information. It would be better if there is no conflicting information and the offset is documented or tested.
Cheers, Han
I think the camera image size makes a difference.
Yesterday I experimented with a analog clock program. My idea was to duplicate the clock and let the second clock "hands" rotate in one second. But Window timing/latency doesn't allow that so easy. In one second it was maybe flickering 5 times at different positions. Writing the current time in a CMD window seems faster. But you should write it each time at a clean position because the camera is integrating. More experimenting required.
I have made a tiny program called scroll_time to test. See cloudynights forum.
Han
OK, I made a test setup with 2 laptops, one on my windowsill running https://clock.zone
The other one with the ASI6200MM camera in 2x2 binning mode with a small refractor on a tripod in my garden, viewing the other laptop screen. Made 0.001 second test images.
Found out it is not obvious to time sync 2 laptops. So right after the test I put the 2 laptops together and took a picture of both clock.zone running : you see a small difference remaining, but less than 0.050 seconds.
The result is unexpected : see attached FITS file.
To my surprise, the 'clock.zone' time almost matches DATE-AVG, and the exposure seems to have started 0.5 seconds earlier !!! I see no explanation for this
Tom
image 1 : test setup
image 2 : 0.001 second NINA 3.1 HF2 image (bin 2x2) of clock.zone screen
image 3 : imaging laptop left and target clock laptop right
Here is the FITS image
Good obeservation
The camera starts 0.6 seconds later then DATE-OBS indicates. It first has to do som preparations like clearing the sensor. So DATE-OBS is wrong and DATE-AVG is correct.
I found two days ago something similar in the ZWO forum. I have posted it on Discord. So it means Nina is reporting the correct value DATE-AVG. ZWO should correct this in their driver.I pity they have not fixed up to now but maybe the delay is unpredictable.
Han
I still think it is confusing : if I read this thread with comments from Tech@ZWO, it seems they changed DATE-OBS time reported as recent as september 2024 to match start of exposure time, where apparently someone found it was closer to end of exposure.
https://bbs.zwoastro.com/d/12736-what-time-is-held-in-the-date-obs-field-in-the-fits-header
That is worrying for current users: you have to keep track of what ZWO/NINA writes in your FITS headers and has changed underway. It makes using older observation FITS files inaccurate, even if you think as an observer that your PC was perfectly synchronized.
I still have not seen any reply on Discord why NINA introduced the DATE-AVG field in their FITS files as of version 2.3. (2.2 and earlier didn't have it). And on top of that apparently ZWO changed what they report as DATE-OBS.
Very disappointing this makes the combination of NINA + ZWO camera's inaccurate for good photometric timing and astrometry of fast asteroids. You almost need a camera with built-in GPS like a QHY174GPS if you want to be sure of the time signal.
I have to admit that NINA developers apparently did their best to correct something with DATE-AVG, but it remains very confusing if the DATE-OBS field is inaccurate for ZWO. In most other capture software SBIG, SharpCap, MaximDL, Astrometrica, you could trust DATE-OBS to be start of exposure. If weather permits I'll try a fast asteroid and check accuracy of astrometric positions obtained.
Hi Han,
One more info image: maybe we shouldn't look too specifically at ZWO only
Attached is an image taken with NINA 2.3.2.9001 taken with my much older ATIK 414EX mono camera. This is a small size CCD camera (only 1391 x 1039 pixels) no reason for big delays (though USB 2.0). It surprises me that DATE-AVG is also reported and shows 1.1 seconds later than DATE-OBS + EXP/2.
I read similar guesswork for determining start or end times (probably best effort) in this case for QHY camera's on the SGP forum: https://forum.sequencegeneratorpro.com/t/understanding-fits-time-record/17898
Seems like the clock.zone test is required for many camera brands to determine accurate start, mid or end times of exposure.
Thanks for the info. I'm very busy here but I will test my Touptek camera the next days. I would be good if you report your findings on Cloudynights.