There are cameras with GPS receiver for accurate timing.

QHY174M-GPS Time Domain Imager, With GPS PPS Synced High Precision Hardware Stamp:
www.qhyccd.com/index.php?m=content&c=ind...catid=94&id=46&cut=1

The FITS standard 4.0 specifies this:
[±C]CCYY-MM-DD[Thh:mm:ss[.s...]]

So four digits, accuracy 0.1ms.

But: ,,Keyword value was not re-stricted to mean the start time of an observation, and has historically also been used to indicate some form of mean observing date and time. "
I also assume you have to define then TIMESYS ='GPS'
GPS’(Global Positioning System): runs (approximately)synchronously with TAI; GPS≈TAI−19 s

For maximum accuracy you could use the float:

MJD-AVG– [floating point; default: none]. Modified Julian Date(JD−2,400,000.5) of the mid-point of the observation. (According Meeus this should be Julian day but that is an other discussion)

For accurate registration such as an occultation typically video is used. You will need some exposure time to register the event. So the 0.1 ms looks sufficient to me. If not keyword MJD-AVG looks for me the way to get more accuracy.


Han

The QHY174M-GPS test below indicates a maximum frame rate of 40 images /sec. So minimum exposure time is then 25 ms or less limiting the accuracy of an occultation event:

www.occultations.org/meetings/NA/2017Mee...HY174M-GPSFinal.pptx

Perhaps a different keyword would suffice?

Hi! Not trying to interrupt this topic, but...
Would it be possible to include the focus position in the header?

I'm working on a little Python script that uses images from a range of focal positions around the optimal. From this the image tilt is found so that it's easy(er) to shim the camera.

Cheers,
Bart

These keywords are in use by other programs:

FOCUSPOS= 36000 / Focuser position in steps
FOCUSTEM= 24.43 / Focuser temperature (Celsius)

Hi.

I was wondering about the focus position in the header as well. The modifications n the indiccd source files listed below (output from diff) appear to make it work for the CCD simulator. To my understanding this should be propagated to any CCD driver. I haven't done any further testing though, so I cannot tell whether this true and whether the mod could mess up other things.... but it at least suggests to me that it should be possible quite easily?

Cheers,

Joachim



indiccd.h:

505a506
> long FocusPos;
545c546
< IText ActiveDeviceT[4] {};
---
> IText ActiveDeviceT[5] {};
549a551
> SNOOP_FOCUSER,



indiccd.cpp:

118a119
> FocusPos = std::numeric_limits<long>::quiet_NaN();
411,414c412,416
< IUFillText(&ActiveDeviceT[1], "ACTIVE_FOCUSER", "Focuser", "Focuser Simulator");
< IUFillText(&ActiveDeviceT[2], "ACTIVE_FILTER", "Filter", "CCD Simulator");
< IUFillText(&ActiveDeviceT[3], "ACTIVE_SKYQUALITY", "Sky Quality", "SQM");
< IUFillTextVector(&ActiveDeviceTP, ActiveDeviceT, 4, getDeviceName(), "ACTIVE_DEVICES", "Snoop devices", OPTIONS_TAB,
---
> IUFillText(&ActiveDeviceT[1], "ACTIVE_ROTATOR", "Rotator", "Rotator Simulator");
> IUFillText(&ActiveDeviceT[2], "ACTIVE_FOCUSER", "Focuser", "Focuser Simulator");
> IUFillText(&ActiveDeviceT[3], "ACTIVE_FILTER", "Filter", "CCD Simulator");
> IUFillText(&ActiveDeviceT[4], "ACTIVE_SKYQUALITY", "Sky Quality", "SQM");
> IUFillTextVector(&ActiveDeviceTP, ActiveDeviceT, 5, getDeviceName(), "ACTIVE_DEVICES", "Snoop devices", OPTIONS_TAB,
431a434
> IDSnoopDevice(ActiveDeviceT[SNOOP_FOCUSER].text, "ABS_FOCUS_POSITION");
727a731,743
> else if (!strcmp(propName, "ABS_FOCUS_POSITION"))
> {
> for (ep = nextXMLEle(root, 1); ep != nullptr; ep = nextXMLEle(root, 0))
> {
> const char * name = findXMLAttValu(ep, "name");
>
> if (!strcmp(name, "FOCUS_ABSOLUTE_POSITION"))
> {
> FocusPos = atol(pcdataXMLEle(ep));
> break;
> }
> }
> }
786a803,807
> if (strlen(ActiveDeviceT[SNOOP_FOCUSER].text) > 0)
> IDSnoopDevice(ActiveDeviceT[SNOOP_FOCUSER].text, "FOCUS_ABSOLUTE_POSITION");
> else
> MPSAS = std::numeric_limits<double>::quiet_NaN();
>
---
> fits_update_key_dbl(fptr, "FOCUSPOS", FocusPos, 3, "Focus Position in steps", &status);
1722c1732,1734
<
---

Looking good! Can you please a PR for it on Github?

Focus temperature would also be useful because it would help with determining the focus temperature compensation. The temperature would need to be the temperature at which the autofocus run was done, not the current temperature. That may not fit with what others need though.

An alternative would be to log the focus position, temperature and filter at the end of each successful autofocus run. At present only position is logged sometimes. Maybe even logged to a separate autofocus result file.

The header has for me preference to store focus position and temperature. There you can relate the focus position with temperature, time, HFD/FWHM and altitude.

E.g. to analyse you can just add all fits files in the ASTAP stacker listview, press analyse , select all and copy and paste (all data) in your favorite spreadsheet for a thorough analyse. See the two screen shots:

www.hnsky.org/astap.htm#export_data

I created the github pull request for the absolute position.

The temperature information would be nice to have as well. It is slightly more complex, though:

- Thinking of determining temperature correction coefficients etc, I agree that it probably would be most useful to record the temperature at the time of the autofocus, not the current temperature. Well or actually, both should ideally be recorded in the FITS header.
- A temperature measurement could be provided by the driver of the focuser (in which temperature is not a standard property) or potentially by the driver of some weather device (in which case it might in principle be of interest to record also e.g. wind direction and speed).

I think someone with a better overview than me would need to code this.

Cheers,

Joachim

To me, the 4.0 standard doesn't read as if it was restricted to 3 or 4 decimal places. I'm aware of the fact that 6 decimal places might be far from reality, but for instance would a INumberProperty be sufficient to state the number of decimal places that are written to the FITS header?

Concerning the actual definition of the timestamp, whether it is the starting point or somewhere in the middle of the exposure, I guess you have to know what the program wrote when making the FITS. Am I right when assuming, that INDI generally states that to be the beginning?

Well, of course, generally the longer the exposure the less relevant is the accuracy of the timestamp, but I want to image satellites and measure their orbit. Thus using exposure times of approx. 0.1 seconds. Assuming an average speed of 7 km/sec, I'd like to have the uncertainty as low as possible.

As Han pointed out 0.1 ms would be already quite good, but is yet not implemented in INDI indiccd missing one decimal place. If this collides with other programs, would it be possible to use MJD-BEG, MJD-AVG or MJD-END? I'd be happy to do the implementation and make the PR.

Same goes for the altitude, might be not too interesting when imaging stars and planets, but for me, knowing I can later read all the information I need from the FITS header makes it somewhat simpler to lay out the over all schedule of measurering satellite orbits.

Cheers
Erik

I would avoid making this sort of change until it is neccesary.

Getting the time to microsecond precision is not available now, and may never be. Let us wait until there is a real, testable reqirement.
If this does become available it will only be so for a limited number of cameras. AIUI camera drivers export the data as a FITS file and the driver for those cameras can inplement the precision they require. If Ekos does nothing with the FITS data other than add data and save it then there may be nothing more to do.

If Ekos does update the data then this apparently simple requirement could balloon into something complex. It may need changing in multiple places. Everywhere that this is used may need to be checked to ensure that the data doesn't upset things - overflowing display boxes for example.

It would also need testing and at the momnet that's going to be tricky because there's no camera that provides data to that precision. Even using a simulator some module somewhere could silently truncate the data, maybe truncate it, then write it out with the same apparent precision.

There's more than just changing a format string.

Chris