In next-in-line mode the HRC serial-digital telemetry (rate, housekeeping, and events) is allocated 16 bytes every minor frame of the 128 minor frames that make-up a major frame (total of 2048 bytes). Major frames last 32.8 seconds. All but the first 72 bytes are used for events and each event take 16 bytes. This means that there are 123.5 events worth of bytes available to be filled. One might think that this would imply a next-in-line mode telemetry format maximum rate of ~3.76/s. However, this is not the case because the HRC cannot make use of the 0.5 event. In fact, if there is a partial event in the HRC primary science FIFO buffer at the end of the major frame the HRC has to re-sync to the start of an event when the time comes to get the next set of event data.
The maximum possible telemetered event rate in next-in-line format is
123 events/32.8 seconds = 3.75 events/s
However, it turns out that the "0.5 event" can mess things up a bit. If the last 8 bytes of the next-in-line data in a major frame contains event data, the second half does not appear in the next major frame. After the 72 bytes of "secondary science" are read, the HRC hardware sees that it is not synchronized with reading the event buffer. It fills the event slot in telemetry with zeros, moves one byte in the buffer, and waits until the next read to see if it has synchronized. As a result 8 of the potential 123 full event slots in the major frame can be lost so we would have:
115 events/32.8 seconds = 3.51 events/s
as we see in the top panel of Figure D1.
For a simulation study of dead time and telemetry saturation (for a normal operation case), please check a memo by Juda and Dobrzycki.
|R_obs:||Rate that we see|
|R_valid:||Valid input rate that we see|
|N_valid:||Valid input rate|
|ONTIME:||Time-interval of length|
|DTF:||Dead time correction|
The rate that we see (R_obs) must be related to the valid input rate (R_valid) by the dead time correction factor (DTF):
R_obs = R_valid * DTF
DTF = R_obs/R_valid
Or given an event list with N_evt events in a time-interval of length ONTIME, we should have seen N_valid = R_valid * ONTIME events; thus the LIVETIME are:
|LIVETIME||= ONTIME * DTF|
|= ONTIME * (N_evt / (R_valid * ONTIME))|
The Figure D1 shows the count rates obtained from event files, the valid count rates from secondary science file, and the dead time correction factor against time. Since the count rate is almost constant at 3.5, the dead time correction factor is the reverse of the valid count rates.
Last modified: Apr 13, 2016