In this page we give specific information for the users of the IBAS, as well as a some more technical details on how IBAS works. We suggest to read first the IBAS Short Description Page
The updated IBAS results can be found in the Results Page
IBAS Alerts Distribution Systems
Alert Packets are sent by IBAS via internet, using the UDP transport protocol. Each packet is 400 bytes long, and consists of several fields, the format and content of which is explained below.
Different types of Alert Packets are distributed. Users can select which type(s) they want receive.
IBAS can send more than one packet for each GRB. After the first one (WAKEUP type) distributed with the shortest delay, one or more packets of type REFINED are sent automatically only if a more precise localization becomes available.
Finally, one or more packets of type OFFLINE are sent manually, after the interactive analysis of the data.
Robot telescopes can exploit the a priori knowledge of the INTEGRAL pointing direction (e.g. to reduce the slew time in case of a GRB alert, to obtain reference images of the pre-burst sky). For this purpose IBAS is also sending updated pointing information each time a slew to a new direction begins.
Test Alert Packets of each type are sent every 6 hours, to allow the IBAS users to check their software.
How to receive the IBAS Alerts
We distribute a Client Software which allows the users to receive the IBAS Alert Packets and to easily use their content in the software commanding their telescopes.
In order to receive IBAS Alert Packets you should :
The IBAS client software package contains one library and two simple programs (one to check the connection with the computer on which IBAS is running and one to print on the screen the content of the Alert Packets). The IBAS Client Software is written in standard C language and has been tested on Sun Solaris, Linux and MacOS X.
Types of Alert Packets:
Six Alert Types are used by IBAS:
Clients can subscribe only to alert packets of a given type(s). Each packet is 400 bytes long, and consists of several fields decribed below. (A more detailed explanation of the format and content of the Alert Packets is given in the User Manual distributed with the IBAS Client Software.)
Test packets of each of the 6 types are sent every 6 hours. They are recognized by the value of the field test_flag = 1
Many automated telescopes can exploit the a priori knowledge of the INTEGRAL pointing direction (e.g. to reduce the slew time in case of a GRB alert, to obtain reference images of the pre-GRB sky and to monitor the counterparts of INTEGRAL targets). For these reasons IBAS sends a new POINTDIR packet each time a slew to a new pointing direction begins. The POINTDIR packet contains the pointing direction expected at the end of the slew and the duration of the pointing.
SPIACS alert packets are sent after positive triggers detected with the SPI Anti-Coincidence Shield (ACS). No position information is available, unless the same GRB also triggers some of the imaging instruments and in such a case the position will come through other packet types.
WAKEUP packets are generated only once for each GRB and only if the GRB position information is available. They contain the preliminary position derived for the GRB. These are the alerts with the shortest time delay.
REFINED packets provide refined information on a GRB event. IBAS is designed to automatically generate a new REFINED packet only if the new information available has significantly smaller uncertainties and/or supersedes that sent with previous packets. Zero to several REFINED packets can be generated for a given GRB. They will have the same ALERT_NUMBER and incremental ALERT_SUBNUM.
OFFLINE packets are generated manually after interactive analysis of the data has been performed off -line by the IBAS Localization Team. The time delay might be from one to a few hours (or even longer in some cases). Typically only one OFFLINE packet is expected for each GRB, but the possibility of more than one is allowed for exceptional cases. The OFFLINE alert packet represents the final confirmation (or rejection) of a GRB and contains the most accurate GRB properties distributed by IBAS.
WEAK packets are generated automatically for 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)
Content of the Alert Packets:
Only the most important fields of the IBAS Alert Packets are described here. For a complete description and the format of the Packets see the User Manual of the IBAS Client Software.
PKT_TYPE = indicates the type of alert as described above (1,2,3,4,5)
TEST_FLAG = set to 1 for Test packets, otherwise set to 0
ALERT_NUMBER = incremental number assigned to each potential GRB
ALERT_SUBNUMBER = used to distinguish the different Alert Packets referring to
the same potential GRB (always set to 0 for the Packets of type WAKEUP,
then increases for the REFINED and OFFLINE Packets).
We refer to IBAS Alerts by their ALERT_NUMBER and _SUBNUMBER values (do not confuse these with the fields SEQNUM and PKT_NUMBER)
GRB_DEC = Coordinates (J2000) derived for the GRB position
GRB_POS_ERR = Radius (arcmin) of the circular error region. It corresponds approximately to the 90% c.l.
GRB_TIME = UTC time at which the trigger occurred. Its relation to the GRB start time depends on the GRB light curve and on the algorithm which triggered
PKT_TIME = UTC time at which the Alert Packet was generated. The difference wrt the GRB_TIME is due to the time required for trigger verification, derivation of satellite attitude, etc..
GRB_TIMESCALE = the value of the integration timescale over which the trigger occurred.
GRB_TIME_ERR = contains the value of the time delay between the first trigger and the time at which imaging is performed. Contrary to what the name suggests, it is not the error on GRB_TIME. However it gives some indication on the difference between GRB_TIME and the true start of the burst.
GRB_SIGMA = significance of the trigger. Note that this is NOT the GRB significance and it is not related to the intensity of the burst (see below for details on this important issue)
POINT_RA = satellite pointing direction. Can be compared with GRB_RA/DEC to
derive the GRB off-axis angle.
POINT_DEC = "
NX_POINT_TIME = coordinates and starting time of next pointing direction (used
only in packets of type POINTDIR)
NX_POINT_RA = "
NX_POINT_DEC = "
The accuracy of the localizations derived by the IBAS on-line programs and distributed in the automatic Alert Packets depends on (a) the imaging analysis results and (b) the knowledge of the satellite attitude.
(a) the error on the source location is a function of the source signal to noise ratio and is usually a small fraction of the intrinsic angular resolution (atan (mask element/mask distance) = 12 arcmin for ISGRI).
(b) the INTEGRAL attitude can be derived from one of the following three sources
The IBAS programs use the best source of information available at the time of the alert generation (in the order 3, 2, 1). In most cases this is the NEAR REAL TIME attitude (this is indicated by the value ATT_FLAGS = 2 in the Alert Packet). The PREDICTED attitude in nominal conditions, i.e. most of the time, is very close to the true one. Therefore IBAS localizations should be reliable also in the few cases in which the NEAR REAL TIME attitude is not yet available (ATT_FLAGS = 3 indicates that the PREDICTED attitude has been used). Significant differences between the PREDICTED and NEAR REAL TIME attitude are sometimes found at the boundaries between satellite slews and pointings. For this reason Alert Packets are not sent during the first ~10 s after the (predicted) end of a slew.
The accuracy of the IBAS locations, combining the effects of (a) and (b) has been estimated based on the IBAS triggers caused by known sources. This is discussed in Mereghetti et al. 2004. The main conclusion is that the 90\% c.l. error radius is smaller than 2.5 arcmin for sources detected at S/N > 10 (the current threshold for the automatic delivery of Alerts is S/N=8).
Note that the above discussion refers to
the on-line imaging analysis which is based on simplified
algorithms. In general, the GRB error regions can be further
reduced by the more sophisticated interactive analysis performed
Sensitivity and GRB Significance:
The expected sensitivity for IBAS GRB localization is about 0.1-0.2
photons/cm2/s on axis
(peak flux 20-200 keV on 1 s). The exact value is of course a function of
the spectral shape and light curve of the burst. It must also be considered
that the sensitivity worsens as the off-axis angle increases.
The two following figures shows how the sensitivity depends on the GRB spectral
(they refer to the 50-300 keV and 1-1000 keV ranges to allow comparison with
BATSE and with Band 2003, ApJ, 588, 945).
IBAS Sensitivity as a function of Epeak for different parameters of a Band spectrum in the 50-300 keV band.
IBAS Sensitivity as a function of Epeak for different parameters of a Band spectrum in the 1-1000 keV band.
Note that the Alert Packets do not contain information on the GRB intensity. The value of the field GRB_SIGMA can be misleading in this respect, for the following two reasons:
INTEGRAL Optical Monitoring Camera:
INTEGRAL also carries a 50 mm telescope (OMC) operating in the visible band, which unfortunately observes only the central 5x5 degrees of the IBIS field of view. Due to the limited telemetry rate allocated to the OMC, only the data from a number of small pre-selected windows around sources of interest are recorded and transmitted to the ground.
When a GRB is detected, IBAS checks if its position falls within the OMC field of view. In such a case, the appropriate telecommand with the definition of a new window centered on the interesting region is generated and sent to the MOC to be uploaded to the satellite.
This will allow to observe the GRB/afterglow emission in the optical band, with a sensitivity of the order of V=14 magnitudes (for an integration time of 60 s at high Galactic latitudes).
None of the INTEGRAL GRBs detected to date (Aug 2004) was inside the OMC field of view.
Last modified: 03-Sep-2004