Go to the first, previous, next, last section, table of contents.
A simple prototype triggering algorithm (a classic gamma ray burst
trigger) has been implemented for some time in the transputer software.
It works in simple cases, but it is not flexible and requires a very
high threshold so as not to detect a lot of false triggers.
In this section I will ramble toward describing the design of the
complete triggering algorithm, designed by Ed Fenimore and Mark Galassi.
Triggering works on the WXM and FREGATE time history data. The time
histories from the two instruments are synchronized and treated as a
single data set with 8 energy bands. We expect to find most of the
triggers in the gamma ray data for two reasons: gamma ray bursts are
stronger in that regime, and there are fewer other variations in the
gamma ray background.
The triggering algorithm must satisfy the following requirements:
-
It runs on the transputer, looking at WXM and FREGATE time history data
that is stored in a queue (see section Time History).
-
It should be able to scan the time history with several different time
windows T0 ... T(n-1), which could be 40ms, 160ms, ..., 4000ms
(increasing exponentially up to about 4 seconds). Each window Ti would
look at the frame between the current moment tau and tau-Ti.
-
Some of the trigger algorithms would look for long bursts. These
are bursts that are still in progress. Others would look for
short bursts, i.e. bursts that have already happened and were
only a couple of seconds long.
-
Each time window should identify a foreground and a background region in
the time history data. For long bursts, the foreground would be
contiguous to the current time tau, and the background would be at the
beginning of the time window. For short bursts, the background would be
at the beginning and end of the time window, and the foreground in the
middle.
-
The triggering software should be able to choose one ore more energy
bands to use when looking for a trigger.
-
Once the triggering software has identified a trigger, it should send a
message to the imaging program, telling it to resolve the position. The
message should contain the following information:
-
The background and foreground specification (maybe expressed as
tb_start, tb_finish, tf_start, tf_finish).
-
A list of energy bands in the x-ray spectrum in which the signal is
strongest. This can be difficult if the trigger was detected in the
gamma ray spectrum, and might require tuning on orbit.
-
Once the triggering software has identified a trigger, it should send a
message to the photon tag archiving process, so that it can take all the
photon tag data in the queue and send it to ground (see section Photon tag data).
-
The triggering process should also maintain a list of recent triggers
and the time periods they cover, so that the telemetry processes can
intelligently determine when to send more data to ground.
-
For each of these types of "scan of the data", a different threshold
should be specified. The threshold is typically the number of standard
deviations above background.
To take a bottom-up view, what software infrastructure should be
available to allow these requirements to be satisfied? Here are some
random thoughts on things that would be useful:
-
The time history queue should have an easy way of associating real time
markers with the queue positions. The delta-t of time histories does
not usually change during ordinary operations, but some conversion is
still needed.
-
There should be a mechanism for doing a trigger blackout,
i.e. marking that a whole chunk of the time history is really not to be
used for triggering because mean and nasty things happened. These mean
and nasty things could include gaps in the data, powering up of the
instrument, changing instrument gains, changing other instrument
settings...
-
There should be some routines that flexibly pick out desired chunks of
the time history, allowing the user to specify t_start and t_stop, to
specify the energy band and maybe even the detector.
-
There should be an overall table which specifies configuration
parameters for the various passes through the time history data.
There are basically two different algorithms, and each one should be
invoked with several different parameters.
[I will assume that we are using a period of 20ms in sampling the time
histories. All specific time periods that follow need to be revised,
and especially need to be revised if we change this 20ms period.]
Long burst triggers
The long burst trigger algorithm is launched several times with
different time windows Tw, ranging from
Short burst triggers
The short burst ...
This section documents the format of the messages sent by the triggering
process to other processes that do things.
Go to the first, previous, next, last section, table of contents.