Response to JIRA GRINF-38
https://jira.slac.stanford.edu/browse/GRINF-38 (by Denis D, Lucas G, David S)
The fundamental issue is: providing information on the quality of the event-by-event absolute time stamps to the users of the FT1, FT2, and/or Merit files, primarily for pulsar phase analyses.
The definition of "adequate quality" depends on the analysis in progress. Loose timing precision is perfectly acceptable for a slow pulsar with low photon statistics (the bins of the phase histogram will be wide).
Furthermore, absolute time drift is not a simple function of time since GPS lock-loss. Eric Siskind provided a way to estimate the typical drift. Actual drift could be a bit better or a bit worse.
We therefore believe that to handle data samples with GPS-lock loss users should simply be warned about lock loss, and methods to evaluate the timing quality should be recommended by the Pulsar group. Suggestions below.
In light of this, it seems less important that a cumulated time-since-lock-loss variable be included in the end-user data files, especially if it is technically challenging to implement.
EXECUTIVE SUMMARY:
1) Having 'sourceGPS()' in the FT1 and Merit is essential (see https://jira.slac.stanford.edu/browse/GRINF-44) ;
2) gtpphase and/or gtbary should emit warnings, such as "events without GPS lock in this data sample", possibly listing fraction of events, duration, start and stop time, etc. A separate warning could be issued if the data set or data run had no GPS lock at the first event.
3) Users may elect to remove some time intervals from the analysis. gtselect and gtexpcube already handle selection on time intervals.
4) If the cumulated time since GPS lock was lost can be included in FT1 and/or Merit and/or FT2 and/or the metadata information then that is good and useful but not essential.
SUGGESTIONS TO EVALUATE TIMING QUALITY
1) The user can calculate elapsed time since GPS lock-loss within their own data sample, and use E. Siskinds' typical or maximum drift rates to estimate the deviation from true absolute time.
2) "Vela pulsar peak position versus elapsed time", as in Marianne's IRF monitoring tasks , will, in many cases, provide a limit on the deviation from true absolute time.
[]https://confluence.slac.stanford.edu/display/DC2/2008/03/05/Absolute+timing+using+the+Vela+pulsar
COMMENTS ON THE JIRA COMMENTS
A) The choice of the technical discussions mentioned by Anders & Jim are beyond us. Andrea Tramacere's slides for the FT2 review (link here) suggest that he knows quite well how to accumulate information across run and file boundaries. So... if the digi L1Proc can generate a cumulated value to be stored with the metadata, then great! do it!
And if a cumulated quantity can be stored in the FT2 (and the user then imposes some condition for it to then affect the GTI !?!?) then also good.
B) Nota bene that Masa & James were thinking in December and January about how to add "ephemerides quality" messages to gtephem (link to his note, here). Perhaps if we start
adding "quality control quantities" to the files, we should do it consistently across ephemerides to timestamp space. In that case, space craft position precision might be thought about at the same time (although we expect it to always be right). See HERE for the "Five Easy Pieces of Good Phase Calculations".
C) Siskind reminds us in his comment that there is a 1 or 2 second lag in reporting GPS lock loss, and as much as a 20 second latency before reporting that GPS lock has returned. For most analyses, this is unnoticeable (see "slow, faint pulsars", above). For precision studies (high statistics on a millisecond pulsar?) the analyst will need to demonstrate adequate timing quality.