Hey,

would be awesome if the DATE-OBS seconds would be logged up to the 6th decimal place (minimum). I know, off-the-shelf cameras don't support this accuracy, once there is a camera that support this, that would be awesome. Precise timestamps could be possible using digital I/O. Have a look f. i. here Using Trigger and Digital I/Os .

Secondly, would be awesome if the altitude/height of the observer could be added to the keywords.

Thanks in advance.
Cheers
Erik

That would for sure violate the FITS definition and probably make a lot of programs reading fits data fail

KEYWORD: DATE-OBS
REFERENCE: FITS Standard
STATUS: reserved
HDU: any
VALUE: string
COMMENT: date of the observation
DEFINITION: The date of the observation, in the format specified in the
FITS Standard. The old date format was 'yy/mm/dd' and may be used only
for dates from 1900 through 1999. The new Y2K compliant date format is
'yyyy-mm-dd' or 'yyyy-mm-ddTHH:MM:SS[.sss]'.


And how accurate should you be on mid exposure of a long exposure?

Paul

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