|Info | Links | POINTDIR alerts | SPIACS alerts | WAKEUP/REFINED/OFFLINE alerts | WEAK alerts|
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
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=184.108.40.206 PORT=1966POINTDIR alerts
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
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/OFFLINE alerts
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
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).
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 :
|Last modified: 01-Jan-2019||Page/script maintained by : Jerzy Borkowski at CAMK Torun|