Subject: Out-of-sequence HRC Time Tags

M. Juda
October 6, 1999

1 The Problem

When processing HRC data from flight, a problem appeared in the event time tags where the times of events as determined by a simple application of the time-tagging algorithm (see the time-tagging memo[1]) come out-of-sequence in the telemetry stream. There is nothing in the HRC hardware that can change the order of when events are telemetered. Time tags are based on the number of ``clicks'' of an internal HRC clock and the value of a sub-frame counter (the 3 LSBs of the ``science'' frame) when the event occurred and are measured relative to the start of the ``science'' frame.

A specific example occurred in the file:

/dsops/current/ap/sdp/cache/1999_08_31/hrc/hrcf052490522N001_evt0.fits.

Below is a snippet around the relevant point within the file; the out-of-sequence event is indicated.

   TIME                    MJF         MNF         SUB_MJF CLKTICKS
     5.249176299255712E+07       33017          71      0       129245
     5.249176300672899E+07       33017          71      0       130152
     5.249176301444774E+07       33017          71      0       130646
-->  5.249176507308844E+07       33017          72      1       131199
     5.249176303101022E+07       33017          72      1          506

The best clue to the origin of the problem is the value of the number of clock ticks. The largest value that the hardware will generate when functioning normally is given by T_sf/T_tick - 1, where T_sf is the duration of a science frame (2.05 s) and T_tick is the length of one clock tick (15.625 µs). After this, the science header pulse is received by the HRC and this resets the number of clock ticks to zero and increments the sub-frame counter. This largest value is 131199 and is the number telemetered for the event indicated above. The out-of-sequence time is caused by the details of the timing within the HRC. If the sub-frame counter is incremented before the number of clock ticks is reset and an event just happens to occur sometime during the brief interval between these events, the hardware will generate an incorrect combination of timing information. This sequence is shown schematically in figure 1. The timing information supplied is not ``invalid'' (the combination could occur for some event) but it is incorrect for this event. It is only because the time tag on the subsequent event is earlier than this event that we can recognize that something is wrong.

2 Recommendation

It is tempting to choose to ignore these events by labeling them as ``bad'' and discarding them from level 2 processing. However, given that the reason for the invalid time stamp is understood, we should modify the time-tagging software specification to correct the time tags on the events that are shown to be invalid since they occur out-of-sequence. Note that we cannot correct the time tag if the rates are so low that the time between the events is longer than 2.05 seconds; however, this is expected to be an extremely rare case in on-orbit operations where the mean valid event rate is ~ 50 counts/s.

The following algorithm can be used to correct the time tag of the CLKTICKS = 131199 events. If an event has a CLKTICKS value of 131199, compare the values of MJF, MNF, and SUB_MJF of the event to that of the next event. If the values are the same, set CLKTICKS of the first event to 0 and then calculate the time tag.

References

[1]: M. Juda memo, ``HRC Time Tagging'', February 28, 1996

Figure 1: Schematic view of the sequence of hardware events that lead to to out-of-sequence events.

File translated from T_EX by T_TH, version 2.01.
On 6 Oct 1999, 09:02.

Dr. Michael Juda
Harvard-Smithsonian Center for Astrophysics
60 Garden Street, Mail Stop 70
Cambridge, MA 02138, USA
Ph.: (617) 495-7062
Fax: (617) 495-7356
E-mail: mjuda@cfa.harvard.edu