TABLE OF CONTENTS:
The GRB Coordinates Network (GCN, transitioning into TAN: Transient Astronomy Network) is composed of 2 parts.
1) The first part (Notices) distributes RA,Dec locations of GRBs and Transients detected
by various instruments (space-/ground-based) in real-time to ground-based
and space-based follow-up observers.
The Notices are simple email-based token-value style text messages and internet socket packets.
2) The second part (Circulars and Reports) consists of receiving from -- and automatically distributing to -- the GRB community
prose-style e-mail messages about follow-up observations on various GRBs.
The Notices cover GRBs and Transients; the Circulars/Reports cover just GRBs. Follow-up observations on Transients should be published in the ATELs.
1.1) Brief description of the GCN Notices portion:
The Notices are the result of information received by GCN/TAN in real-time, processed into a standard format and automatically distributed to the those people wishing to receive specific Notices (based on a variety of filtering conditions). No humans are involved in the GCN portion of the sequence, and for most missions there is no humans-in-the-loop at the mission-ops portion of the sequence. This automation minimizes the time delay between when the gamma-rays hit the instrument detectors and when the RA,Dec locaiton information is available to the follow-up observers telescope. (The GCN portion of the total time delay is less than 1 sec for socket-based recipients, and 1-30 sec, typical, for email-based reipients.) The token-value text style of the email form of the Notices is a compromise that allows both human reading and computer program parsing. The binary socket packet format and distribution method is the fastest way to get the information to robotic telescopes.
1.2a) Brief description of the GCN Circulars portion:
This part allows the GRB community to submit messages to a central queue where they are automatically distributed (e-mail) to the entire GRB community. These are prose-style messages (a) from follow-up observers reporting on their results (detections or upper limits) or (b) calls for coordinating with others. Click for the details of the GCN Circulars.
1.2b) Brief description of the GCN Reports portion (Reports discontinued 2014):
The Reports were active from 2006-2014; they are no longer being produced.
Reports were also prose-style write-ups on burst observation,
but they were issued at a later time after the burst (not quick like the Circulars),
allowing the observers to do the full analysis and corrections to the measurements.
They were distributed (e-mail) to the entire GRB community (the Circulars distribution list).
Click for the detail of the GCN Reports.
There are currently 13 different types of location information for GRBs/Transients in real- or near real-time. They span a range of delay times after the start of the event and they span a range of the sizes of the error boxes. Each type has its own separate dis/enable flag in the "sites.cfg" file controlling the distribution of that type to each site. If sites want different filtering (ALL, VIS, NIGHT, etc) for the different notice types, they can have multiple entries in the "sites.cfg" file. The comparison is shown in Tables 1.1-4, and they are described in more detail in the respective sections below.
| SOURCE | TIME DELAY | ERROR BOX SIZE | RATE | COMMENTS |
|---|---|---|---|---|
| IPN_POS | 0.5-1.5 days | 5-20' dia | 3/month | Small FOV telescopes. |
| INTEGRAL_WAKEUP | 60 sec | 10' | 1/month | Small FOV. |
| INTEGRAL_REFINED | 60-100 sec | 5' | 1/month | Small FOV. |
| INTEGRAL_OFFLINE | 60-200 sec | 3-5' | 1/month | Small FOV. |
| Swift-BAT_POS | 13-40 sec(1) | 1-5' dia | 2/week | Fast and Small. |
| Swift-XRT_POS | 30-80 sec(1) | 5" dia | 2/week | Fast and Small. |
| Swift-UVOT_POS | 0.2-9 hrs(1) | 2" dia | 1/week | Fast and Small. |
| SuperAGILE | 20-40 sec | 20' dia | 1/month | Small FOV. |
| Fermi-GBM | 20 sec | 4-10 deg dia | 15/month | Large FOV telescopes. |
| Fermi-LAT | 100 sec | 10-30' dia | 1/month | Small FOV telescopes. |
| MAXI_Unknown | 2-200 min | 1deg dia | 1/month | Small FOV. |
| MAXI_Known | 2-200 min | 0.5deg dia | 1/week | Small FOV. |
Note (1): The time_delays for the 3 Swift-based positions are the values
after the ~135-day Verification phase (when the mission is in the full automatic
distribution mode of operations. Prior to that (during the Verif phase),
the delays were in the 1-24 hr range because there will be humans-in-the-loop
to verify that the positions are accurate (and that the triggers are true GRBs).
| SOURCE | TIME DELAY | ERROR BOX SIZE | RATE | COMMENTS |
|---|---|---|---|---|
| SVOM | XX sec | ~X" dia | X/week | Small error-box GRB positions. |
| LVC | 3min;1hr;1day | ~1000 sq.deg | 2/mo | Large error-box positions. |
Click for the discontinued mission/notice_types.
| SOURCE | TIME DELAY | ERROR BOX SIZE | RATE | COMMENTS |
|---|---|---|---|---|
| MOA | most are before the peak | ~1" dia | 50/month | Photometry on grav-lensed events. |
| CALET-FLT/GND | 1-few min | n/a | 10/mo | The date/timestamp/lightcurve of a rate-trigger increase in the CALET-GBM instrument. |
| INTEGRAL_SPIACS | ~1 min | n/a | 5/mo | The date/timestamp/lightcurve of a rate-trigger increase in the SPI Anti-Coincidence Shield. |
| AMON_ICECUBE_HESE | 0.5-3 min | 2-9deg | 0.4/mo | Position of high energy netrino events. |
| AMON_ICECUBE_EHE | 0.5-3 min | 0.2-0.8deg | 0.5/mo | Position of high energy netrino events. |
| INTEGRAL_POINTDIR | n/a | n/a | n/a | The s/c pointing direction after the upcoming slew. |
| Swift-BAT hard x-ray TRANS | 20 sec | 1-4'' | 1-2/month | Small FOV telescopes. |
| Swift_POINTDIR | n/a | n/a | n/a | Two versions: (a) The s/c pointing direction after the upcoming slew. (b) Actual position after the slew. |
| AGILE_POINTDIR | n/a | n/a | n/a | The s/c pointing direction after the upcoming slew. |
| FERMI_POINTDIR | n/a | n/a | n/a | The s/c pointing direction for the next 2 hours. |
2.1) CURRENT GRB MISSIONS
2.1a) Swift GRB LOCATIONS, LIGHTCURVES, SPECTRA, and IMAGES
The Swift mission opens up a new era in GRB research. This is because of the combined (a) rapid availability, plus (b) small error boxes. The Swift mission also provides data products not previously available from prior missions: (a) spectra and (b) images, plus (c) lightcurves. See the Swift Notices page. And click to see the Table of Swift Locations.
2.1b) INTEGRAL GRB LOCATIONS
The IBIS instrument on INTEGRAL is a wide FOV CdTe coded-aperture instrument which has the ability to detect GRBs. Click for a description of the INTEGRAL location notices. And click to see the Table of INTEGRAL GRB Locations.
2.1c) AGILE GRB LOCATIONS
The SuperAGILE instrument on the AGILE spacecraft is a wide FOV CZT coded-aperture instrument which has the ability to detect GRBs. Click for a description of the AGILE location notices events. And click to see the Table of AGILE GRB Locations.
2.1d) FERMI-GBM/-LAT GRB LOCATIONS
The Fermi mission has two instruments: GBM which is a BATSE-like design (providing large error circles, but lots of them), and LAT which pushes the burst detection into the 100+ GeV regime. Click for a description of the Fermi GRB Notices events. And click to see the Table of Fermi GRB Locations.
2.1d) MAXI GRB and KNOWN-SOURCE TRANSIENT LOCATIONS
The MAXI instrument (on ISS) is able to locate transient sources (GRBs, other unknown transients, and flares from previously known sources). Click for a description of the MAXI_UNKNON/_KNOWN Notices events. And click to see the Table of MAXI GRB and other Transient Locations.
2.1f) IPN GRB INFORMATION
IPN_POSITION
The GCN system also include automated processing of the NEAR-XGRS instrument
telemetry data and the Wind-KONUS instrument telemetry data on a daily basis.
This processing looks for GRBs in the data stream, and when a burst is found
then the lightcurve is auotmatically sent to the K.Hurly's automated
processing at UC Berkeley for comparison with the Ulysses burst detections.
Using these 3 s/c (plus optional location information), small error box
locations can be obtained.
Click for a description of the
IPN POSITION GRB location notices.
And click to see the Table of IPN_POS Locations.
IPN_SEGMENT (no longer available)
The GCN system has greatly speeded up the process of producing IPN information
by (a) automatically sending the BATSE light curve data to Kevin Hurley (UCB)
where is it automatically combined with the Ulysses data. Given the current
situation of having only two spacrecraft with a long baseline, only annuli
are produced. However, these annuli are combined with the BATSE-Original
or BATSE-LOCBURST locations to provide "arc segments" which are
then distributed by GCN. Click for a description of the
IPN SEGMENT GRB location notices.
And click to see the Table of IPN_SEG Locations.
IPN_RAW
This third variation in the IPN category is a timestamp-only. It
results from a trigger on one or more of the following spacecraft:
Konus-Wind, Suzaku, or INTEGRAL SPI-ACS.
The purpose of these notices is to alert the community to a possible
GRB, so that they can save their data for future analysis. These
notices are sent out automatically, and
as a result, not all of them are valid bursts; furthermore, of those
that are, in some cases it may not be possible, for technical reasons,
to localize them. Multiple notices may
go out for a given event if it is observed by more than one
spacecraft. In these cases, the event is very likely to be real (i.e.
not a statistical fluctuation), but its nature could
still be solar or something other than a GRB (e.g. an SGR burst). The
rate of non-GRB triggers varies from mission to mission, and with
solar and SGR activity, but a rough false alarm estimate might
be around 20%. For details on any particular event, contact
khurley@ssl.berkeley.edu
2.1e) GRB COUNTERPART LOCATIONS
Follow-up observers can submit to GCN locations of GRB counterparts that they have detected. Once vetted (same as Circulars process), these are distributed to those sites enabled to receive this Notice type. These counterpart locations are useful to the automated sites because these Notices can be read by the automated sites whereas the Circulars (where counterparts are also published) can not be read by automated programs. See the COUNTERPART page.
2.1f) TEST LOCATIONS
While not strictly a source of GRB locations, the Test Notices are another "source" of information in that they can be enabled or disabled for each site just like the above sources of GRB locations. They can be used by sites for end-to-end testing of their communication link and their instrument. There are several mission-based types of test notices. Click for the details.
2.1g) LIGHT CURVES
Several missions produce lightcurves (countrate vs time) of the events they detect. Swift-BAT, swift-XRT, are Konus-Wind are the currently producing missions-instruments; and NEAR-XGRS is no longer active.
2.1h) POINTING DIRECTIONS
Various missions have pre-planned knowable pointing directions: INTEGRAL, Swift, AGILE, Fermi. This informations is captured within the GCN system and made available to the community so that their telescopes can follow along (ie be pointed at the location of the mission so that their slew time is minimized should a burst notice for that mission be issued. And further, they can be taking data so as to have data prior to and during the prompt phase of the burst. Click for the details.
2.1i) MOA The MOA Notices provide information about gravitation lensing events detected by the MOA project. In cotrast to the other GCN Notices, these MOA event are usually detected and distributed ebfore the main crossing occurs; you can be on target on the rising edge of the lensing event. See the MOA page.
2.2) FUTURE MISSIONS / SOURCES of TARGETS
2.2b) OGLE (not yet available) To be filled in.
2.2c) KAIT Supernova (not yet available) To be filled in.
2.3) Click for the discontinued mission/notice_types.
There are two basic media/methods by which the Notices are currently being distributed:
a) Internet sockets: binary packets (160 bytes) and XML text VOEvents,
b) E-mail based delivery (in 6 different formats/contents: full format email and several formats suitable for cellphones and pagers).
c) Phone/Modem-based: delivery: It comes in two variations: dedicated and dialed. These are no longer available.
They are listed in Table 2 and are discussed in more detail below.
The following Table 2 and paragraphs contain only a brief description
of the distribution methods/media.
For a very detailed description of the contents, formats, and meaning
of these various distribution media/methods, please see the
technical details section.
| TIME DELAY | METHOD/MEDIA | COMMENTS |
|---|---|---|
| 0.1-0.5 sec | Socket (160B binary) | Fast & suited for automated instruments. |
| 0.1-0.5 sec | Socket (VOEvent GCN-custom protocol) | Fast & suited for automated instruments. Both versions: 1.1 & 2.0. |
| 0.1-0.5 sec | Socket (VOEvent IVOA protocol) | Fast & suited for automated instruments. Both versions: 1.1 & 2.0. |
| 2-30 sec | L-mail (text) | To any network address (johndoe@machine.domain). |
| 5-100 sec | E-mail (text) | To any network address (johndoe@machine.domain). |
| 5-100 sec | E-mail (VOEvent XML) | To any network address (johndoe@machine.domain). Both versions: 1.1 & 2.0. |
| 5-180 sec | Pager | RA,Dec,UT,Intensity displayed on your cellphone/pager. |
| 5-180 sec | Short Pager | RA & Dec displayed on your cellphone/pager. |
| 5-180 sec | Subject-only | RA & Dec displayed in the Subject-line to your cell/pager. |
| 5-180 sec | SubjHHMM-only | RA, Dec, Time, & Intensity displayed in the Subject-line in RA=HH:MM:SS format. |
| 0.3 sec | Dedicated phone | Continuous phone/modem connection. (no longer available) |
| 30-90 sec | Dialed phone | Slower but much cheaper than Dedicated. (no longer available) |
Socket (160B binary pkt) (aka the "original" GCN socket method): The fastest method is the Internet socket connection. Sockets is a technique to connect two computers over a network. The socket connection is made at some initial time and is maintained for long periods of time. The GCN system runs 24/365 continuously allowing sites to connect and disconnect at their leisure. The time delay for the propagation of the packets varies due to the distance between the two computers, the number of routers and gateways in between, and the amount of other network traffic. However, we have routinely shown that for a connection between Maryland and California (coast to coast US) the (roundtrip) propagation time is typically less than 1.0 seconds and less than 0.1% of the packets take longer than 2.0 seconds ( a histogram of distribution times). For the details.
Socket (VOEvent XML message) (the GCN-custom socket protocol): This is just as fast as the original binary socket connection method. Instead of the 160B binary packets, the VOEvent XML messages (a packet of ascii text of 2-10 Kbytes) are sent to the customer. For the details. Other information about voevents within GCN.
Socket (VOEvent XML message) (the IVOA VOEvent socket protocol): This is just as fast as the the two socket methods above. The VOEvent XML messages (a packet of ascii text of 2-10 Kbytes) are sent to the customer using the protocol adopted by the IVOA. For the details. Other information about voevents within GCN.
Lmail (text): For those sites that do not have automated instruments,
the e-mail distribution method is suitable.
This format and content is exactly the same as the original "E-mail" method (see next);
only the distribtiuon/transport method at the GCN end is changed -- it is slightly faster than "E-mail".
At your (receiving) end of things, it looks and behaves exactly like E-mail (because it IS email).
(Examples of the L/E-mail Notices that are distributed.)
It is quite fast; typically delivery times range from a few seconds
to ~30 seconds, when the destination machine and local gateways are on-line.
This is the preferred method for people wanting the full-format email-based method.
Recipients must have a reason for specifying the old E-mail method instead of the L-mail method
(eg they need to have the To-line in the email header be their name
instead of the listfilename).
For the details.
E-mail (text): For those sites that do not have automated instruments, the e-mail notice distribution method is suitable. (Examples of the L/E-mail Notices that are distributed.) It is still quite fast; typically delivery times range from a few seconds to ~100 seconds, when the destination machine and local gateways are on-line. All the same information in the Internet socket packets for a burst notification is in the body of the e-mail. A "TOKEN: value" format was chosen as a reasonable compromise between human-readable and machine-readable formats. The later is useful for sites that have daemons waiting for incoming notices and take further action based on the contents (some sites have exploders and some sites parse the information). For the details.
E-mail (VOEvent XML): The XML format contains the same information as the "text" format email notices described above. However, the contents are in XML (instead of the TOKEN:value format above). The e-mail notice distribution method is suitable. (Examples of the E-mail XML Notices that are distributed.) The XML VOEvent message can be in either the body of the email or as an attachment (customer's choice). For the details.
Pager/Cellphone: The distribution of GCN GRB information is also available via alpha-numeric pagers and text-message-capable cellphones. (Examples of the Pager messages that are distributed.) Many pager and cellphone service-providors accept e-mail and automatically transmit it to the designated pager/cellphone -- you can get beeped by the Universe. This distribution method is perfect for those sites that do not have Internet access (for either e-mail or sockets). The pager units typically have a limit of 100-400 characters, but this is plenty to display the GRB's RA,Dec location, the UT time of the burst, and the initial intensity (the RA,Dec are current epoch). Current experience shows that the time between the GRB and the "beep" of the pager is 5 sec to 3 minutes depending on company, geography and time of day. The main limitation if geographic coverage. The companies tend to locate their transmitters in large metropolitan areas (cities with more than 50K people) and the range seems to be about 20-30 miles. This was the situation circa Late 1995. More companies have entered the market; and the coverage is a lot better now.
Short Pager: This is essentially identical to the above "Pager" capability with the exception that only the RA,Dec location (Epoch 1950) of the burst is transmitted to, and displayed on, the pager screen. (Examples of the Short-form Pager messages that are distributed.) This reduced information message is suitable for those people/sites with small-display alpha-numeric pagers.
Subject-only: This is a specialized version of distribution. It puts a short-form synopsis (RA,Dec position) in the Subject-line of an e-mail message. This is suitable for some pagers and cell-phones which only display the From-line and Subject-line of the e-mail (i.e. they do NOT have the ability to display the body of the e-mail). The RA,Dec coordinates are Current Epoch. (Examples of the Subject-only messages that are distributed.) This reduced information message is suitable for those people/sites with reduced-capability pagers and cell-phones (e.g.GSM Information Network in Europe).
SubjHHMM-only: This is a specialized version of distribution. It puts a medium-form synopsis (RA,Dec,Time,Intensity) in the Subject-line of an e-mail message. This is suitable for some pagers and cell-phones which only display the From-line and Subject-line of the e-mail (i.e. they do NOT have the ability to display the body of the e-mail). The RA,Dec coordinates are J2000 Epoch. (Examples of the SubjHHMM-only messages that are distributed.) This reduced information message is suitable for those people/sites with reduced-capability pagers and cell-phones (e.g.GSM Information Network in Europe).
Dedicated Phone (no longer available): This uses a dedicated phonecall to communicate the information to the customer (via computer modems on the phones). Around sunset at the instrument site (assuming it's an optical instrument), a phone/modem connection is made between the GCN computer and the computer at the instrument site. This connection is maintained throughout the night and should a burst occur during this time then the coordinates (RA, Dec, UT) are sent over the connection. At 9600 baud it takes 0.3 seconds. Due to a limitation of the US Government phone network here at GSFC, this method is only available within the US (overseas calls require a human operator in the loop to place the call and this is not possible with a computer-initiated call).
Dialed Phone (no longer available): GCN also has the capability to dial a predefined phone number at the time of the burst and make a modem transfer of the relevant information. The protocols are the same as for the "dedicated phone connection" method, it is just that the establishment of the link at the time of the burst adds a time delay to the receipt of the information, however, with a great savings in the telephone bill. Like the Dedicated Phone method described above, Dialed Phone calls are limited to the US (overseas calls require an operator).
Currently, there are 16 criteria applied to each GRB Location Notice
to determine if that notice should be sent to a particular site.
These distribution criteria are independent of the distribution method (socket-based and email-based).
The new system of filtering has 16 dimensions (the same 6 old dimensions plus 10 new dimensions): Notice Type (defaults is disabled), Error Size (default is 360 deg), Time Delay (default is infinity hours), Intensity (and now available for all types that have an "intensity" field; it is units specific), Significance (default is 0.0), Confidence (applicable to a small subset of types) (default is 0%), Trigger_ID (applicable to a small subset of types) (default is 0), Sun_distance (deg) (default is 0), Sun_hour_angle_dist (hours) (default is 0), Moon_distance (deg) (default is 0), Moon_Illumination (%) (default is 100), Celestial coords (RA,Dec ranges) (default is 0-360,-90-+90), Galactic coords (Lon,Lat ranges) (default is 0-360,-90-+90), Ecliptic coords (Lon,Lat ranges) (default is 0-360,-90-+90), Time-of-day window (default is 0.0-24.0), Observability (All, Visible, Night,Expanded explanations:) (default is All). The meaning of each filtering parameters are: Notice_type: The notice type has to be enabled to be received. Error_size: The location error has to be less than the specified value. Time_delay: The time delay has to be less than the specified value. Intensity: The intensity has to be greater than the specified value. Significance: The significance [sigma] has to be greater than the specified value. Confidence: The confidence level [%] has to be greater than the specified value. Trigger_ID: The trigger identity has to be what the TypeName indicates (ie no false positives). Observability: The observability has to satisfy your All, Visible, Night, filter. Sun_distance: The distance (in deg) to the Sun has to be greater than the specified value. Sun_hour_angle_dist: The delta_RA hour_angle (lead or lag) has to be greater than the specified value. Moon_distance: The distance (in deg) to the Moon has to be greater than the specified value. Moon_illumination: The Moon illumination has to be less than the specified value. Celestial_coords: The location has to be within the specified RA,Dec ranges. Galactic_coords: The location has to be within the specified Gal_Lon,Lat ranges. Ecliptic_coords: The location has to be within the specified Ecl_Lon,Lat ranges. Time-of-day_window: The notice time has to be within the specified time window (UT).
There are several motivations for applying one or more of these filtering functions to determine if a site is sent a particular notification. Obviously, the use of the VIS filter function is appropriate since it is not possible for sites to observe RA,Dec locations that are below their horizon. Optical instruments can elect to apply the NIGHT filter function, so as to not get "bothered" by notices during the day when they cannot observe. Even some radio sites elect to use this NIGHT filter because the ionosphere becomes noisy during the daylight hours in some radio bandpasses. The NIGHT filter has the VIS filter included. Sites not wishing to restrict their notices by either the VIS or NIGHT filters can elect to use the ALL filter (they get everything after any TRIGGER_ID or INTENSITY threshold is applied).
In addition to the basic service of distributing GRB coordinates, we also provide follow-up support activities for the groups doing the follow-up observations. Groups that have made follow-up observations can contact us for the more accurate locations that are available well after the burst. These locations come from: (1) the Huntsville BATSE team. Several days after the burst they have access to the full data set (the finer time sampling, the better spectroscopy data, etc) and have the luxury of having humans-in-the-loop for the analysis effort. They also have the full-blown location algorithm with the non-cos(theta) and scattering corrections. (2) The Interplanetary Network (IPN), also contributes to about 15% of the bursts seen by BATSE. The IPN annuli are important because they greatly reduce the amount of sky that must be analyzed looking for a transient. (3) COMPTEL and EGRET can provide error boxes that are much smaller than BATSE, and again this reduces the amount of analysis a site must perform. (4) And on rare occasions, the WATCH instruments provide locations. When more accurate locations become available, we provide these when asked.
Since the start of operations in June 1993, there have been many improvements to the system. Here is a chronology and description of these improvements.
Future sources of GRB locations:
To maximize the utility of the GCN system and to minimize the effort by the
various follow-up groups, GCN is always persuing an agressive campaign to include
any and all sources of GRB locations within the GCN system. As each new
spacecraft/instrument comes on-line, GCN will do whatever modifications
are necessary to incorporate those GRB locations and distribute them to
any and all who wish them.
Future sources of non-GRB locations:
And like the extreme-UV transients detected by the ALEXIS spacecraft, GCN will also expand its operations to include any astrophysical transient (GRB & non-GRB alike) information.
Asking for Inputs of New Targets:
If you have an operation which produces locations (and other information) about transient phenomenon, and you would like to provide them to the world follow-up community, then please contact me. I am always looking for more sources of transient events.
If you want all the gory details and specs on the various data formats and operations, then click here (about 8 pages).
ACTIVE:
IPN-format Lightcurves: GCN produces the IPN-lightcurve standard format files for the KONUS-Wind and Swift-BAT, and send thems to Kevin Hurley's IPN auto-processing system.
Swift S/C Ops warning Alert: GCN processes the warning and alert messages that the s/c bus and the 3 instruments produce and sends them to the designated people on the various teams.
Fermi Internal Messages: GCN processes several message types coming down the TDRSS link and sends them to the designated people on the various teams. These Team-only messages allow the Fermi-GBM and -LAT team members to enhance the quality of the notices types that are publically distributed.
DISCONTINUED:
There are 4 other discontinued services that GCN/TAN no longer provides (because the missions have terminated).
Currently, there are two parts of these GCN web pages that are updated automatically in real-time, so that the user community can have the latest information about what is happening with the GRBs and the operations of the GCN system. There is, at most, a 60-sec delay between when the Notices are distributed to the world community and when the web pages are updated. And since these web pages are updated automatically, people should remember to use the reload command on their web browsers, so that they see the current version of the various pages.
Real-time Coordinates Pages:
Currently Active
a) There is page which contains all the Notices from the RXTE spacecraft (even the ones not detected by CGRO-BATSE). It is called the RXTE GRB Locations page. This contains both the ALERT and POSITION notices
b) The IPN_Position Locations page.
from the Interplanetary Network of instruments.
c) The SWIFT Triggers and Locations page.
All of the latest information about the GRB locations from all 3 Swift instruments
is listed here.
d) The INTEGRAL Triggers and Locations page.
All of the latest information about the GRB locations from the INTEGRAL instruments
is listed here.
e) The INTEGRAL-SPIACS Triggers and Lightcurves page.
All of the latest information about the SPI-ACS triggers from INTEGRAL is listed here.
f) The AGILE Locations page.
All of the latest information about the GRB locations from the SuperAGILE instrument
is listed here.
g) The FERMI Triggers and Locations page.
All of the latest information about the GRB locations from GBM and LAT instruments
is listed here.
h) The MOA Events and Locations page.
Soon to be Active
a) None are soon; SVOM will be in ~2017.
No longer Active
Click for the discontinued mission/notice_types.
Partly Real-time Special_Burst Information Page:
The selected burst page contains links to all the information there is to-date on specially selected GRBs. This information includes: Identification (date, time, trigger number, etc), Locations (RA,Dec, radii, annuli, maps, etc), Lightcurves, and the archive of the GCN Circulars follow-up observation notices (optical, radio, etc). The main criteria that makes a burst "special" to be included in this page is that follow-up observations have been made. The 'partially' real-time designation means that some of the information in the pages is updated in real-time and some of it is done manually (usually within minutes to hours).
Semi-Real-time Sites.cfg File Page (updated every UT midnight):
The second is the CGN sites.cfg file. This is a copy of the currently used "sites.cfg" file. This allows sites to monitor their configuration entries and verify that they are as requested.
A list of GCN related acronyms and terms.
A list of Frequently Asked Questions.
The GCN/TAN contact is: Scott Barthelmy,
GCN Team.
This file was last modified on 17-Oct-17.