Page History

...

Basically, the file is intended to include the necessary information (other than tables of effective area) for calculating exposures.  So it has the position and attitude of the LAT for regularly-spaced time intervals (nominally 30 seconds, although shorter intervals are used when the LAT enters and exits the South Atlantic Anomaly).  As currently planned, SAA entry and exit will correspond to the stop and start time for the data taking 'runs' in flight.  For orbits that miss the SAA, a run stop/start will be issued when the LAT crosses the orbital plane heading north. \[anders\] The reasons for the forced stop/starts can be found [here|https://confluence.slac.stanford.edu/download/attachments/17880/borgland_runLength_SciOps10272006.pdf?version=1]. For these stop/starts, the interval between the entries may also be less than 30 s.  For each of the intervals in an FT2 file the accumulated live time is also recorded.

...

This is kind of a minor point, but may need to be clarified:  During the time between the stop (LPASTOP) of a run and the LPASTART of the next (if a stop/start is issued outside an SAA passage - see above), the LAT will be dead as far as data taking is concerned.  If a time interval is not explicitly included in an FT2 file, i.e., if the time of a START entry is not the same as the time of the previous STOP entry, we can just assume that the missing interval was dead time, right? \[anders\] Any time between an LPASTOP and the subsequent LPASTART is deadtime i.e. we did not take any data.

...

(Ormes, from an e-mail message 4/14/07) The deadtime comes naturally from properties of the electronics and is normally easy to track, but as you have assumed in making the above decision, not what we want. We need live time to compute fluxes. Live time cannot reliably be obtained by subtracting dead time from clock time, no matter how much attention is paid to removing time in SAA, spacecraft anomalies, etc. I pushed for a requirement that the electronic electronics contain a clock that measure measures the livetime between events. One should be able, from this, to plot an "interval distribution" which should be exponential, with a mean that reflect reflects the inverse of the counting rate. If the live time distribution, for any given type of event is not exponential, there is trouble.

However, this said, if there is trouble, we should have the deadtime, too, for cross checks. It should be filled with the number of events times the deadtime per event, of or if the deadtime per event is not exactly constant but varies with the amount of readout or something else, the sum of the deadtimes over the events obtained during the accumulation time in question. I recommend not dropping the deadtime column but filling it with something useful.

...

(_Borgland_, from e-mail 4/16/07) There is no deadtime counter since by definition the instrument is dead. There is only a livetime counter which increments in 50 ns tickes all the time the instrument is alive i.e. not busy/dead reading out etc.  There is also an elapsed counter which is the total time. The livetime
fraction between events N and N+M is just
LiveTimeFraction = \[Livetime(N+M)-LiveTime(N)\]/\[ElapseTtime(N+M)-ElapsedTime(N)\]

and the deadtime (for whoever is interested in that) is just 1 - LivetimeFraction.

...

This is not possible because of the onboard filter. We do not know what trigger engine caused the readout of events that were rejected by the filter i.e. how they were read out (4-range, non zero-supp etc). Note that I actually currently do what Jonathan describes here in the current digi report. However, it's only valid for runs not running the filter (or running the filter in the passthru mode).

(Ormes, note added 4/20/07) - The implmentation meets my original intentions.  Having the elapsed total time and the live time are sufficient for the necessary cross checks.

3. McIlwain coordinates

(Digel) These are geomagnetic coordinates and presumably useful in some way for studying variations in residual background. The actual model we are using for the background depends on geomagnetic latitude, however, rather than the McIlwain L, B. I'm not entirely sure that we need (i.e., that anyone will use) L, B, but I won't propose removing them. I would like to propose including geomagnetic latitude, however, as an additional column.

(D. Band 4/6/07) I concur with adding this column (especially since I don't have to do the calculation...).

(Ormes 4/20/07) Thanks.  This will be helpful and avoid having any confusion that might be caused by the user having a separate lookup table to get it back.

4. IN_SAA column

(Digel) This is just a flag defined to be True if the LAT is in the SAA. Right now it is not entirely clear (to me) whether we will be getting spacecraft position and attitude information during SAA passages. This would have implications, e.g., for using the Low-Rate Science counters to monitor the boundaries of the SAA, and also would mean that an IN_SAA flag would be superfluous. I'll update (or remove) this entry when I find out the answer.

...