BATSE-Failed Notices



  1. Introduction and Background
  2. The Sequence of Activities
  3. Importance of this Failed Notice Type
  4. Formats
  5. E-mail Example

The BATSE-Original and -MAXBC calculations (a) may not have enough statistics to make valid location solution or (b) their brightest illuminated detectors may be in opposite directions on the spacecraft or (c) any of several other scenarios which prevent the Notice from being generated and distributed. When this happens a "failed" notice is issued; either a plain Failed Notice or a Failed MAXBC Notice.

These "failed" notices are not distributed to the GCN community, but they do appear in the BATSE Triggers table. This means there is an entry in the table for every BATSE trigger (independent of whether there was a valid location solution or not). This allows people to check the table and determine if there was a BATSE trigger at the specified timestamp. There are two types of "failed" notices: the Failed Trigger Notice (which is generated for each failed Original calculation, and the Failmaxbc entry (for the MAXBC notices).

The BATSE-Original Notice uses the first 1 or 2 1.024-sec rate samples after the BATSE trigger to calculate the burst location. The exact sequence of steps is:
a) The program continously scans the incoming telemetry stream from the CGRO spacecraft looking for the BATSE Trigger-flag to be set. During this, it is also calculating the background rates averaged over a 10-sec sliding window in all 8 LADs in all 4 DISCLA energy intervals (20-50-100-300-infinity keV).
b) When the trigger flag is set, the program checks to see in which of the two 1.024-sec samples the rate increase occurs. There is a 5.0-sigma increase above background requirement so that the GCN program has enough signal with which to calculate a useful location. It uses the previously accumulated background count rates to find the source-only rates. If there is no 5-sigma increase, then the program continues searching the incoming telemetry stream until there is or for up to 10 seconds (whichever comes first). This searching-for-enough allows for bursts which have slow risetimes. If there was not a significant enough rate increase in the first 10 sec after the trigger, then a Failed Notice is issued.
c) The program then finds the 3 brightest detectors in the middle two energy bins (50-300 keV). If the any two of the these three are opposite each other in the octohedron geometry of the LADs ont he spacecraft, then a Failed Notice is issued.

These "failed" notices are not distributed to the general GCN distribution list because there is no location information in them. They are used by the GCN system administrators to monitor the system and BATSE. The notices are also added to the BATSE_GRBs table so that GRB researchers can, after the fact, check to see if there was a BATSE trigger at a specific date/time (e.g. for correlative purposes in their own data sets, say).

An example of the e-mail format is shown below. It is based on a "TOKEN: value" scheme to allow for both the easy reading by humans and the easy parsing by computer daemons. There is only the e-mail and pager formats. The short_pager and subject-only formats are not needed, because these "failed" notices are distributed to only the GCN system adminstrators. There is also no socket packet format for these notice types.

......put in a real "failed original" notice and a "failed maxbc" notice....

Return to GCN homepage.
This file was last modified on 09-Nov-97.