About

This web site shows unprocessed/raw non-test IBAS alerts data only, together with very short classification of the object (if applicable) and/or description of any problems/errors (entered by the operator in the 'notes' column). While other web pages, i.e. GCN INTEGRAL page, also provide real time information about IBAS alerts, the pages presented here decode/show all the data contained in the alerts, including all comment fields and important attitude information. Scientific analysis of the data is not done here and is presented elsewhere (see pages in the Links section).

All data presented here is stored in MySQL database, and is updated in real time by ibas_client daemon program which listens on UDP socket for incoming IBAS alerts. Whenever new alert is received from IBAS alert daemon running at ISDC, it is decoded, then put into MySQL database. The WWW frontend to the database is provided by the PHP scripts. The scripts generate all the web pages including nice PNG graphics with antialiased fonts on the fly.

note: alert data for the period October.2002 - March.2003 is not available at the moment.

IBAS alerts are distributed in real time by ibas server running at ISDC to the list of registered clients. The delivery method is direct UDP socket connection over global internet with a typical transmision delay of about 100 millisec. The IBAS alerts sent over internet have the form of UDP packets and are 400 bytes long. There are 6 different types of IBAS alert packets : POINTDIR, SPIACS, WAKEUP, REFINED, OFFLINE and WEAK.

note: for delivery of alerts via UDP protocol to work, the clients must make sure that they do not block (on their firewalls) UDP packets originating from IP=129.194.67.222 PORT=1966

POINTDIR alerts give advance notice about the next scheduled INTEGRAL observation (pointing). The alert is usually sent out when S/C performs a manouver, some 1-2 minutes BEFORE the pointing begins. This gives the robotic telescopes, which follow the S/C, enough time to reposition themselves to new planned location during the S/C slew, so that observing time is as big as possible, while at the same time delays are the smallest possible. One should stress, that all the values in POINTDIR alerts (RA, DEC, START TIME, DURATION) are based on PAF (predicted attitude files), therefore they are wrong whenever S/C does not follow the timeline.

SPIACS alerts are generated whenever there is significant increase in SPI AntiCoincidence Shield countrate. Since one cannot determine position of GRB using SPIACS data alone, SPIACS alert gives only the time of the event and the URL to the lightcurve (LC) data file. The lightcurve data covers usually period from 5 seconds before the trigger time to 100 seconds after the trigger time (time bin size is 50millisec). Furthermore S/C ephemeris data are provided in EPH file, as well are some extra statistics about the event (i.e. max countrate during the event). Format of files is compatible with IPN requirements.

These files (LC and EPH) can be used to determine position of a GRB via triangulation method, provided other spacecrafts also have seen the burst. The absolute timing accuracy of the ligthcurves generated in real time is about 10 millisec. Note that historical data (before April 2004) may suffer from 125 millisec SPIACS time offset. See GCN 2568 notice for more info on the timing problem.

Due to the fact that lightcurve file must cover the period over 100 seconds, the LC datafile is available usually no sooner than 100 seconds after the SPIACS alert.

IBAS SPIACS monitor programs generate several time (approx 5x) more SPIACS triggers than alerts (triggers are detections with lower sigma value). These pages provide data only about SPIACS alerts. Furthermore, since it is very difficult to assess the reality of the event by looking at SPIACS data alone (one usually needs at least JEMX H/K to tell GRB from solar flare), it was decided to disable distribution of SPIACS alerts in real time to the outside users. Other web pages, in the Links section, provide information about low sigma SPIACS detections, as well as detailed description of the file formats.

WAKEUP, REFINED and OFFLINE alerts disseminate information about localized events (GRBs and other sources not blacklisted). Different types of alerts are marked with different colors.

 GREY COLOR  denotes WAKEUP alert generated automatically by the software, usually with a delay of 10-30 seconds from the real time. A WAKEUP alert is usually the first alert distributed for a given event (GRB or not).

 YELLOW COLOR  denotes REFINED alert generated automatically by the software usually with a delay of 30-200 seconds from the real time. Zero or more REFINED alerts are sent following the initial WAKEUP alert.

 RED COLOR  denotes OFFLINE alert which retracts (cancels) any former WAKEUP/REFINED alerts with the same alert_number. Technically speaking, an OFFLINE alert which retracts/cancels event has negative grb_pos_err field. This alert is IBAS team's final statement about the event and means : the event is definitely _NOT_ a GRB/XRF. It may be : known source not blacklisted due to incorrect attitude information available at the trigger time, trigger due to statistical noise, non-transient source which was not blacklisted since up to now it was quiet. This alert is generated manually by the operator. The delay with respect to real time is usually 1-2 hours. This alert is never generated if the position matches any source on the IBAS list of known sources.

 GREEN COLOR  denotes OFFLINE alert which confirms any former WAKEUP/REFINED alerts with the same alert_number. Technically speaking, an OFFLINE alert which confirms event has positive grb_pos_err field. This alert is IBAS team's final statement about the event and means : the event is definitely a GRB/XRF. For the very weak events, it is possible that only one OFFLINE alert is generated, without any preceeding WAKEUP/REFINED alerts. This alert is generated manually by the operator. The delay with respect to real time is usually 1-2 hours.

WEAK alerts disseminate information about low significance events (below the WAKEUP alert threshold). While it is quite likely that they are due to chance fluctuations in the reconstructed images, there is also a non negligible probability that they are generated by real astrophysical events. Packets of type WEAK were included in IBAS V.2.1.0 (Dec. 2010). A WEAK alert may be followed by any combination of WAKEUP, REFINED and OFFLINE alerts (OFFLINE only in the case of positive verification of the event).

SPACECRAFT Attitude

The att_flag field in IBAS alert specifies algorithm used to derive S/C sky coordinates at the time of trigger. This information may be used by IBAS clients to better assess information in WAKEUP/REFINED packets and to proceed (or not) with followup observations without the need to wait for an OFFLINE packet. Possible values are :

• UNDEF - unknown algorithm, this value is usually entered for OFFLINE alerts for GRBs discovered offline. Specifically if at the time of the burst IBAS was not running or was unable to localize the GRB, but later offline analysis showed that there was a GRB than this value is entered.
  
  
• SNAPSHOT - ASF (attitude snapshot files) are used to determine S/C sky coordinates. This value is only possible for the OFFLINE alerts, since for this algorithm to work, there must be 2 entries in the attitude file : one with attitude before the event, second with the attitude after the event - confirming attitude at the time of trigger, and this cannot happen in real time. The S/C sky coordinates derived using this method are always correct.
  
  
• MIXED SNA/PRE - ASF (attitude snapshot files) are used to determine S/C sky coordinates, however pointing duration is taken from PAF (predicted attitude files). This value is usually entered whenever the S/C is more than 10 minutes in the pointing and ISDC has received attitude snapshot file(s) for ongoing pointing. There is small chance, that the S/C attitude derived using this method is wrong, but this may happen only when S/C was manually commanded between time of last record in the attitude snapshot file and the GRB.
  
  
• PREDICTED - PAF (predicted attitude files) are used to determine S/C sky coordinates. This value is entered whenever alert is sent out during the initial 10 minutes of the ongoing pointing, for which only planned data is available. This means however, that whenever S/C does not follow the planned timeline, misses a slew, or there the startrackers related problems, the spacecraft's sky coordinates (thus GRB coordinates) derived using this algorithm are wrong. This usually results in 1 or more false alerts from known objects for which blacklisting does not work anymore. In general, the probability that GRB coordinates are wrong is higher than for MIXED SNA/PRE, but lower than for TM/AUX MISMATCH.
  Specifically, as INTEGRAL observes in so called dithering mode (frequent slews by 2 degrees), if the distance between GRB position in the alert and the nearest known object (i.e. Crab) is 120arcmin (+- 3-4arcmin) and GRB sigma is relatively high (above say 10), this is strong indication that the S/C has indeed missed a 2 deg slew, and what IBAS triggered on is simply well known object and not a GRB. This is what actually happened for alert_num=1991 where the reported position was 2 degrees from the Crab.
  On related note, IBAS version 2.0.0 operational since 20.Sept.2004, has more effective filtering of spurious alerts from active known sources not blacklisted due to S/C attitude problems. In the past (events on 2004-07-18, 2004-05-13, 2004-05-12, 2004-05-07, 2004-03-18, 2003-07-31, 2003-06-29) several WAKEUP alerts were generated per pointing. IBAS version 2.0.0 should issue only one WAKEUP alert possibly followed by one REFINED alert (as was the case for event on 2004-09-29).
  
  
• TM/AUX MISMATCH - information retrieved from either predicted or snapshot attitude files does not agree with orbit/pointing number retrieved from real time telemetry. S/C is likely not following the planned timeline, therefore WAKEUP/REFINED alerts are _not_ sent out in this situation. However, if after verification, operators are convinced that S/C attitude was indeed correct (or have computed the correct one using new data), an OFFLINE alert will be issued. This value may be found in historical records only (before year 2004).