GCN/TAN
INTERNET SOCKET PACKET DEFINITION DOC
Scott Barthelmy 05 Dec 1994 (revised 07 Dec 2021)
MODS: The material in this document on KONUS_Lightcurve notices
is not quite settled. 31jul04
The watchdog timeout flag bit in SWIFT_FOM_OBS
moved from 2^25 to 2^29 (to be like all the others). 06apr06
The MILAGRO notice has been finalized. 12may06
The material for GLAST is nearly stable at this time,
and should be used for guidance as to what things
will look like for launch/operations. 16oct06
Added the catnum to BAT_POS packet. 12apr07
Change the definition of the TRIG_ID 2^11 bit
in the Swift/BAT_POS (and LC, FOM, SLEW, TRANS packets
(from 0.0 to 6.5 sigma). 04may07
Added GLAST_LAT_GRB_POS_TEST. 12may07
Finished the GLAST OBS_REQUEST and REQUEST_REPONSE. 13may07
More stuff in the GLAST_LAT_INI/UPD/FIN. 15may07
Start the AGILE stuff. 16may07
Added 'misc' field to SWIFT_POINTDIR.
Added the near_brt_star flagbit to Swift, AGILE, and GLAST. 30may07
Tweaked the GLAST_LAT types. 02jun07
Added the Gnd-generated bit to the Swift_PointDir Misc. 13jun07
Added the Swift-BAT_SUBTHRESHOLD type. 21jun07
Added the galaxy coincidence flag bits to Swift-BAT_POS/_TRANS/_TEST
and XRT_POS/_IMAGE. 27jun07
Added the galaxy coincidence flag bits to Swift-BAT_LC and _SM
and FOM_OBS and SC_SLEW. 30jun07
Added the Swift-BAT_SLEW_GRB_POSITION type. 30sep07
Added the 2^14 bit to SolnStatus in SWIFT_BAT_GRB_POS and
SWIFT_XRT_POS. 11jan08
Move GLAST_GBM_LC from 112 to 113; added POS_UPD as 112. 19jan08
Added the 2^5, 2^14, 2^15 and 2^30 bit fields to PKT_MISC
in XRT_POS_CENTROID. 26jan05
Added the 2^29 bit field to the PKT_MISC in XRT_POS_CENTROID. 13feb08
Several changes to the GLAST_LAT_INI/UPD/FIN/TRANS/TEST. 18feb08
Added the 3 e_range bits to the MISC field in BAT_SLEW_POS. 24feb08
Added the 'far_away' bit to MISC in XRT_IMAGE and _POS. 03apr08
Added 'rmvd_catalog' bit to 'soln_status' in BAT_POS/LC/
SCALEDMAP/FOM/SLEW. 12apr08
Added XRT-BAT_position distance to XRT_POSITION.
Added UVOT-XRT_position distance to UVOT_POSITION. 14apr08
Added AGILE_POINTDIR. 20apr08
Added SIMBAD/NED Results. 11jun08
Added many flagbits to TRIG_ID and MISC for the AGILE and
GLAST packets. 06jul08
Added the IPN_RAW definition. 18jul08
About a dozen changes/additions to the GLAST-GBM pkts. 03aug08
Changed all GLAST to FERMI. 27aug08
Added internal/scratch field to slot 38 in IPN_RAW. 18sep08
Added hi-precission error to XRT_POS and UVOT_POS.
Fixed the defintion of "burst_error" in UVOT_POS. 19sep08
Added Trig_Signif and Lon,Lat to Fermi-GBM_ALERT. 04oct08
Added Trigger_Duration to Fermi-GBM_FLT_POS. 04oct08
Added missing definition for bit 22 in MISC in SWIFT_FOM. 27oct08
Added the TOO-initiated forms of SWIFT_FOM and _SLEW. 08nov08
Improved IPN_POS description. 11jan09
Changed XTE-PCA_Alert and XTE_ASM_TRANS to NLA. 21jan09
Added the spatial and temporal coincidence bits to the IPN_POS,
KONUS_LC, INTEGRAL_SPIACS/_WAKEUP/_REFINED/_OFFLINE, SWIFT_BAT_GRB_ALERT,
SWIFT_BAT_GRB_POS, SWIFT_XRT_POS, SWIFT_UVOT_POS, SWIFT_BAT_SUBTHRESHOLD,
SWIFT_BAT_TRANS, SWIFT_BAT_SLEW_GRB_POS, AGILE_GRB_WAKEUP/_GROUND/_REFINED,
FERMI_GBM_ALERT, FERMI_GBM_FLT_POS, FERMI_GBM_GND_POS,
FERMI_LAT_GRB_POS_INI/_UPD/_DIAG, FERMI_LAT_GND_REF/_TRIG. 24jan09
Improved the definition of the Fermi-LAT "temp_stat" and
"image_stat" fields. 18feb09
Added some fields to the FERMI_LAT_POS types. 08apr09
Added the 2^0 flagbit to the PKT_MISC fields in the BAT_LIGHTCURVE,
BAT_SCALEDMAP, FOM, SLEW, and XRT_POS types. 21apr09
Added the PIOTS_OT_POS definition. 03jul09
Added TGF to the Fermi classification table. 24aug09
Added Inten1/2/3 to FERMI_LAT_GND_REF. 19oct09
Added the spatial and temporal coincidence bits to the COUNTERPART.
Added the temporal coincidence bit to the IPN_RAW. 07nov09
Made the doc match reality that there is image_signif
in type=65 and 66 packets if the MISC 2^24 bit is set. 22nov09
Fixed the Misc field in SWIFT_BAT_QL. 31dec09
Added FERMI_GBM_FINAL_POS (type=115). 05jan10
Added SWIFT_BAT_MONITOR (type=133). 08feb10
Fixed the mistake in FERMI_GND_POS (=112): signif is in
deci-sigma (not the usual centi-sigma). 16feb10
Changed LAT_GND_REF to LAT_GND; LAT_GND_TRIG to LAT_OFFLINE. 11mar10
Added Nearby_Galaxy flag to BAT_POS_ACK. 09apr10
Fixed a mistake in the documentation for IPN_SEG slots 10-26. 09may10
Started the MAXI packet definitions. 19may10
Per request, Changed FERMI_GBM_FINAL_POS to FERMI_GBM_HITL_POS.27jun10
Added INTEGRAL_WEAK. 18jan11
Added LOCATION_QUALITY to 120 and 121. 26feb11
Changed (slightly) definition of 2^0 bit in slot[18] in pkt 112.
Added 2^1 bit in slot[18] of pkt 112. 03mar11
Finished the MAXI packet definitions; made public. 12mar11
Converted FERMI_OBS_REQ to FERMI_LAT_MONITOR. 21apr11
Replaced SNEWS with AAVSO. 06may11
Added neg flux value flag to MAXI TRIGGER_ID field. 08may11
Fixed definition of slot[15] in MAXI types. 09may11
Added Bright-star and Nearby-galaxy flags to BAT_MONITOR MISC. 28may11
Added DOW_TOD Test. 06jun11
Changed FERMI_GBM_HITL_POS back to FERMI_GBM_FINAL_POS. 06jun11
Started the MOA entry. 13jun11
Fixed up (finally) the GBM_TEST documentation. 15jun11
Started the OGLE entry. 03jul11
Updated/completed/change the FERMI_LAT_GND information. 04aug11
The MAXI_Unknown type was updated to reflect MAXI changes. 24sep11
Added BAT_SUB_SUB and KNOWN_SRC. 06nov11
Slightly improved the description of 'def_not_grb'. 15jan12
Added FERMI_GBM_ALERT_INTERNAL, FERMI_GBM_FLT_INTERNAL, and
FERMI_SC_SLEW_INTERNAL. 17mar12
Fixed up IPN_RAW (type=31) for the new timestamp-only era. 20jun12
Added In-Gnd-Catalog flagbit to BAT_QUICKLOOK. 31jul12
Moved the 2 'scratch' in IPN_RAW from 37-38 to 20-21.
Added the url string (starting at 22) to IPN_RAW. 06jan13
Corrected definition of 2^0 bit in TYPE_SWIFT_BAT_MONITOR,
and added unknown_src flag bit (2^1). 22jan13
Added the hi-precission form of the trigger_sod to KONUS_LC. 03feb13
Added two more bitflags to TYPE_SWIFT_BAT_MONITOR"flags" field. 23mar13
Added SNEWS back in (now at 149). 09jun13
Fixed a few of the SNEWS bitflag definitions. 14nov13
Added Fermi-GBM lightcurve url information. 13apr14
Added more Fermi-GBM lightcurve url information. 23apr14
Added Long-v-Short_GRB in FERMI_GBM_GND_POS(type=112). 03feb15
Changed the numbering of the 5 LVC-related types. 13feb15
Added the actual format/content information for the LVC-types. 04apr15
Started the AMON entry. 25apr15
Added 'internal' flag to LVC_* misc[]. 03jun15
Added the theta-less-than-10arcmin flagbit in BAT_POS PKT_MISC
at 2^12. 09jul15
Change the base-string portion of the skymap URL's in types 151-152.
Fixed the definitions of the "fluence" and "FAR" quantities
stored in slots 9 and 11 in packet types 150-153. 23jul15
Split AMON into AMON_ICECUBE_COINC and AMON_ICECUBE_HESE. 25jul15
Started CALET_GBM (2 types). 08aug15
Filled in some/all of the gaps in AMON and CALET. 09aug15
Added the spatial/temporal flagbits to the LVC, AMON, and CALET. 17aug15
Finally filled in 4 holes in the item descriptions fo
SWIFT_XRT_IMAGE and SWIFT_XRT_IMAGE_PROCESSED. 25aug15
Fixed the multiplicative values for 'eta' and 'chirpmass' in LVC.08sep15
Added Rank and DetWarn to LVC_COUNTERPART. 29dec15
Added already-looking-at-trigger-source to XRT_POS. 31dec15
Added FERMI_GBM_FIN_POS_INTERNAL. 08jan16
Added the long-missing description of 'iexpo' in COUNTERPART. 10jan16
In AMON_HESE remove hese_type, change signalness to signal_trackness.
27mar16
More adjustments/cleanup to the AMON_HESE packet. 10apr16
Added ST_LoL flag (bit10, [MISC]) to SPER notice. 26apr16
Added TYPE_COINCIDENCE. 03jul16
Converted Signalness in AMON_ICECUBE_EHE to log() usage. 06jul16
AMON_ICECUBE_EHE converted to public distribution. 15jul16
Added TYPE_GWHEN_COINC. 23aug16
Added subsec field to AMON_ICECUBE_{HESE,EHE,COINC} types 09sep16
Added TYPE_SWIFT_ACTUAL_POINTDIR. 03oct16
Added the long-missing long/latittude fields into the documentation
for the SWIFT_POINTDIR notice. 03oct16
Correct the packing order for the hi- and lo-energy boundaries
(in slot 17) for the two CALET notices. Remove the e_index
from the MISC slot. 08oct16
Added HardwareIng,Vetted,&OpenAlert flagbits to the LVC P/I/U/T. 20oct16
Added to this documentation the (long missing) 2^30 bit definition
in TRIGGER_ID slot for the FERMI_LAT_* notice types. 31oct16
Added 'charge' and 'energy' to AMON_ICECUBE_EHE. 02nov16
Added ProbHasNS and ProbHasRemnant to the LVC types. 23dec16
Removed Eta,ChirpMass,MaxDistance from LVC (as CBC no longer
supports these Params). 23dec16
Added the long-missing documentation on the "trig_id" slot
to FERMI_SLEW [*_INTERNAL). 28dec16
Added explanation that the URL is present for the 2nd issuance
of the LVC_PRELIMINARY notice. 19jan17
Started adding FERMI_GBM_SUBTHRESHOLD. 02apr17
Corrected the definitions (scaling factor) for the "significance" field
in the FERMI_GBM_ALERT[_INTERNAL], FERMI_GBM_FLT_POS[_INTERNAL],
FERMI_GBM_TRANS, and FERMI_GBM_POS_TEST notice types.
(The FERMI_GBM_GND_POS[_INTERNAL] was correct.) 25may17
Remove the 6th and 7th slots from COINCIDENCE. 28may17
Fermi corrected their correction: GBM_ALERT is back to deci-sigma
and GBM_FLT is back to centi-sigma. 02jun17
Added AMON_ICECUBE_TEST (type=159). 30jun17
Put back the 6th and 7th slots from COINCIDENCE. 15jul17
Added the long-missing letter-code (eg G-series, M-series, ...)
to the LVC_COUNTERPART section. 22jul17
Started adding 162-164 (the 3 Super LVC Events). 01jul18
Started adding 170-172 (the 3 new AMON Events). 05jul18
Removed 162-164 (the 3 Super LVC Events); LVC wants to reuse the
150-152 Types even though they have slightly different content. 12aug18
In LVC O3, Type=150 is now same format as 151-152.
Added the long missing definition of buf[21] in Typ=150-152.
Addeed buf[22] content and packing format to Types=150-152. 08dec18
Added AGILE_ALERT (MCAL) Type=105. 25jan19
Added LVC_RETRACTION Type=164. 26feb19
Added AMON_ICECUBE_GOLD and AMON_ICECUBE_BRONZE Type=173 and 174.30feb19
Added ProbNeutronStar and ProbRemnant to Type=150 (slot 20). 13mar19
Added MassGap Type=150-152 (slot 21). Added alpha2_let. 14mar19
Added trig_sod_usec to Type=164 documenation (it has alway been
in the packet (slot 13)). Added the url to Type=164. 31mar19
Filled in the missing parts of GOLD & BRONZE 173 and 174;
started HAWC 171. 14apr19
Finished GOLD & BRONZE 173 and 174, and HAWC 171. 10may19
Converted AGILE_MCAL_ALERT from IN-WORK to ACTIVE. 12may19
Changed GOLD/BRONZE to be ICECUBE_ASTROTRACK_GOLD/_BRONZE and
HAWC_BURST_MONITOR. 11jun19
Tweaked a few more things to make GOLD/BRONZE & HAWC public. 13jun19
Added the missing location specification of the two suffix letters
on the LVC_COUNTERPART TRIGGER_ID slot. 04jul19
Filled in the last of the places that needed explicit statements
about the AMON_ICECUBE_HESE & _EHE "not being available" and
bing "replaces by ICECUBE_GOLD & *_BRONZE. 01aug19
Added the Probabilities-Invalid indicators in the LVC P/I/U. 29aug19
Updated the skymap url definition in LVC P/I/Y types from O2 era
to the O3 era. 30aug19
Per AMON request, changed AMON_GAMMA_NU_COINC to AMON_NU_EM_COINC.01dec19
Finish the assignments and definations of AMON_NU_EM_COINC. 05jan20
Started adding Type 175 SK_Supernova notice type. 12jan20
Added "BBH" to the "Search" list in the LVC types. 16jan20
Added Type 176 LVC_PREMERGER notice type. 29feb20
Moved LVC_PREMERGER from 176 to 163 and renamed it LVC_EARLY_WARNING.
07mar20
Added event_date to AMON_NU_EM_COINC. 25may20
AMON_NU_EM_COINC went from "in work" to active. 28may20
LVC_EARLY_WARNING went from "in work" to active. 30may20
Started adding Type 176 AMON_ICECUBE_CASCADE notice type. 21jun20
Type 176 AMON_ICECUBE_CASCADE. announce available to the public. 31jul20
Corrected a typo in Type 48 DOW_TOD that said 23 slots available
when it should have been 32 slots. 03oct20
Finished adding SK_SN (175) to the public. 0?feb21
Added name[0-2] to slots 26-28 in Type 176 AMON_ICECUBE_CASCADE. 05apr21
Started adding the 188/189 GECAM_FLT/_GND types. 06aug21
Some more work on the GECAM. 07dec21
Finished work on the GECAM. 22sep22
TABLE OF CONTENTS:
INTRODUCTION:
Scope
Variations in Packeting Format
Integer vs Floating Point
Byte and Word Order
Obtaining an e-copy
PACKET NAME vs TYPE NUMBER
COMPARING THE TYPE=1-4,11,21,22,24-45,51-55,58-59,60-99,110-115,118-136,139-141,144,146,148,149,150-154,157-159,160-161,163-164,166,168,169,170-176,188-189 CONTENTS/FORMATS
PACKET ITEM MACROS
TYPE=1 PACKET CONTENTS (BATSE_ORIGINAL) [NO LONGER AVAILABLE, GRO de-orbit]
Packet Item Descriptions
TYPE=2 PACKET CONTENTS (Test coords)
Packet Item Descriptions
TYPE=3 PACKET CONTENTS (Imalive)
Packet Item Descriptions
TYPE=4 PACKET CONTENTS (Kill)
TYPE=11 PACKET CONTENTS (BATSE_MAXBC) [NO LONGER AVAILABLE, GRO de-orbit]
Packet Item Descriptions (only those unique to type=11)
TYPE=21 PACKET CONTENTS/DESCRIPTION (Bradford Test) [NO LONGER AVAILABLE, GRO de-orbit]
TYPE=22 PACKET CONTENTS/DESCRIPTION (BATSE_FINAL) [NO LONGER AVAILABLE, GRO de-orbit]
TYPE=24 PACKET CONTENTS/DESCRIPTION (BATSE_LOCBURST) [NO LONGER AVAILABLE, GRO de-orbit]
TYPE=25 PACKET CONTENTS (ALEXIS) [NO LONGER AVAILABLE, mission completed]
Packet Item Descriptions (only those unique to type=25)
TYPE=26 PACKET CONTENTS (XTE-PCA Alert) [NO LONGER AVAILABLE, project stopped producing]
Packet Item Descriptions (only those unique to type=26)
TYPE=27 PACKET CONTENTS (XTE-PCA Source) [NO LONGER AVAILABLE, project stopped producing]
Packet Item Descriptions (only those unique to type=27)
TYPE=28 PACKET CONTENTS (XTE-ASM Alert) [NOT YET AVAILABLE, project stopped producing]
TYPE=29 PACKET CONTENTS (XTE-ASM Source)
Packet Item Descriptions (only those unique to type=29)
TYPE=30 PACKET CONTENTS (COMPTEL) [NO LONGER AVAILABLE, GRO do-orbit]
TYPE=31 PACKET CONTENTS (IPN_Raw)
Packet Item Descriptions
TYPE=32 PACKET CONTENTS (IPN_Segment) [MAY BE RE-AVAILABLE]
Packet Item Descriptions (only those unique to type=32)
TYPE=33 PACKET CONTENTS (SAX-WFC Alert) [NEVER PRODUCED by project]
TYPE=34 PACKET CONTENTS (SAX-WFC Source) [NO LONGER AVAILABLE, mission completed]
Packet Item Descriptions (only those unique to type=34)
TYPE=35 PACKET CONTENTS (SAX-NFI Alert) [NEVER PRODUCED by project]
TYPE=36 PACKET CONTENTS (SAX-NFI Source) [NO LONGER AVAILABLE, mission completed]
Packet Item Descriptions (only those unique to type=36)
TYPE=37 PACKET CONTENTS (RXTE-ASM_XTRANS) [NO LONGER AVAILABLE, project stopped producing]
Packet Item Descriptions (only those unique to type=37)
TYPE=38 PACKET CONTENTS (spare for development testing)
TYPE=39 PACKET CONTENTS (IPN_Position)
Packet Item Descriptions (only those unique to type=39)
TYPE=40 PACKET CONTENTS (HETE_S/C_ALERT Source) [NO LONGER AVAILABLE, mission completed]
Packet Item Descriptions
TYPE=41 PACKET CONTENTS (HETE_S/C_UPDATE Source) [NO LONGER AVAILABLE, mission completed]
Packet Item Descriptions (only those unique to type=41)
TYPE=42 PACKET CONTENTS (HETE_S/C_LAST Source) [NO LONGER AVAILABLE, mission completed]
Packet Item Descriptions (only those unique to type=42)
TYPE=43 PACKET CONTENTS (HETE_GROUND_ANALYSIS Source) [NO LONGER AVAILABLE, mission completed]
Packet Item Descriptions (only those unique to type=43)
HETE FLAG BITS VS NOTICE TYPE
TYPE=44 PACKET CONTENTS (HETE_Test Source)
HETE-BASED PACKET ITEM MACROS
TYPE=45 PACKET CONTENTS (GRB_COUNTERPART Source)
Packet Item Descriptions
TYPE=46 PACKET CONTENTS (SWIFT_TOO_FOM_OBSERVE)
Packet Item Descriptions
TYPE=47 PACKET CONTENTS (SWIFT_TOO_SC_SLEW)
Packet Item Descriptions
TYPE=48 PACKET CONTENTS (DOW_TOD Test)
Packet Item Descriptions
TYPE=51 PACKET CONTENTS (INTEGRAL_POINTDIR)
Packet Item Descriptions
TYPE=52 PACKET CONTENTS (INTEGRAL_SPIACS)
Packet Item Descriptions
TYPE=53 PACKET CONTENTS (INTEGRAL_WAKEUP Source)
Packet Item Descriptions
TYPE=54 PACKET CONTENTS (INTEGRAL_REFINED Source)
Packet Item Descriptions
TYPE=55 PACKET CONTENTS (INTEGRAL_OFFLINE Source)
Packet Item Descriptions
TYPE=56 PACKET CONTENTS (INTEGRAL_WEAK Source)
Packet Item Descriptions
TYPE=57 PACKET CONTENTS (AAVSO Event) [NOT YET AVAILABLE]
Packet Item Descriptions
TYPE=58 PACKET CONTENTS (MILAGRO Source) [NO LONGER AVAILABLE, project completed]
Packet Item Descriptions
TYPE=59 PACKET CONTENTS (KONUS_Lightcurve) [SOON TO BE AVAILABLE]
Packet Item Descriptions
TYPE=60 PACKET CONTENTS (SWIFT_BAT_GRB_ALERT)
Packet Item Descriptions
TYPE=61 PACKET CONTENTS (SWIFT_BAT_GRB_POSITION Source)
Packet Item Descriptions
TYPE=62 PACKET CONTENTS (SWIFT_BAT_GRB_NACK_POSITION)
Packet Item Descriptions
TYPE=63 PACKET CONTENTS (SWIFT_BAT_GRB_LIGHTCURVE)
Packet Item Descriptions
TYPE=64 PACKET CONTENTS (SWIFT_BAT_SCALED_MAP) [NOT AVAILABLE TO THE PUBLIC]
Packet Item Descriptions
TYPE=65 PACKET CONTENTS (SWIFT_FOM_OBSERVE)
Packet Item Descriptions
TYPE=66 PACKET CONTENTS (SWIFT_SC_SLEW)
Packet Item Descriptions
TYPE=67 PACKET CONTENTS (SWIFT_XRT_POSITION Source)
Packet Item Descriptions
TYPE=68 PACKET CONTENTS (SWIFT_XRT_SPECTRUM) [NOT AVAILABLE TO THE PUBLIC]
Packet Item Descriptions
TYPE=69 PACKET CONTENTS (SWIFT_XRT_IMAGE)
Packet Item Descriptions
TYPE=70 PACKET CONTENTS (SWIFT_XRT_LIGHTCURVE) [NOT AVAILABLE TO THE PUBLIC]
Packet Item Descriptions
TYPE=71 PACKET CONTENTS (SWIFT_XRT_NACK_POSITION)
Packet Item Descriptions
TYPE=72 PACKET CONTENTS (SWIFT_UVOT_IMAGE)
Packet Item Descriptions
TYPE=73 PACKET CONTENTS (SWIFT_UVOT_SRC_LIST)
Packet Item Descriptions
TYPE=76 PACKET CONTENTS (SWIFT_BAT_GRB_LIGHTCURVE_PROC) [NOT YET AVAILABLE]
Packet Item Descriptions
TYPE=77 PACKET CONTENTS (SWIFT_XRT_SPECTRUM_PROC) [NOT AVAILABLE TO THE PUBLIC]
Packet Item Descriptions
TYPE=78 PACKET CONTENTS (SWIFT_XRT_IMAGE_PROC)
Packet Item Descriptions
TYPE=79 PACKET CONTENTS (SWIFT_UVOT_IMAGE_PROC)
Packet Item Descriptions
TYPE=80 PACKET CONTENTS (SWIFT_UVOT_SRC_LIST_PROC)
Packet Item Descriptions
TYPE=81 PACKET CONTENTS (SWIFT_UVOT_POSITION Source)
Packet Item Descriptions
TYPE=82 PACKET CONTENTS (SWIFT_BAT_GRB_POS_TEST Source)
Packet Item Descriptions
TYPE=83 PACKET CONTENTS (SWIFT_POINTDIR)
Packet Item Descriptions
TYPE=84 PACKET CONTENTS (SWIFT_BAT_TRANS Source)
Packet Item Descriptions
TYPE=85 PACKET CONTENTS (SWIFT_XRT_THRESHPIX) [NOT PUBLIC, SWIFT TEAM ONLY]
Packet Item Descriptions
TYPE=86 PACKET CONTENTS (SWIFT_XRT_THRESHPIX_PROC) [NOT PUBLIC, SWIFT TEAM ONLY]
Packet Item Descriptions
TYPE=87 PACKET CONTENTS (SWIFT_XRT_SPER) [NOT PUBLIC, SWIFT TEAM ONLY]
Packet Item Descriptions
TYPE=88 PACKET CONTENTS (SWIFT_XRT_SPER_PROC) [NOT PUBLIC, SWIFT TEAM ONLY]
Packet Item Descriptions
TYPE=89 PACKET CONTENTS (SWIFT_UVOT_NACK_POSITION)
Packet Item Descriptions
TYPE=97 PACKET CONTENTS (SWIFT_BAT_QUICKLOOK_POSITION Source)
Packet Item Descriptions
TYPE=98 PACKET CONTENTS (SWIFT_BAT_SUBTHRESHOLD_POSITION Source)
Packet Item Descriptions
TYPE=99 PACKET CONTENTS (SWIFT_BAT_SLEW_GRB_POSITION Source)
Packet Item Descriptions
TYPE=100 PACKET CONTENTS (SuperAGILE_GRB_POS_WAKEUP Source)
Packet Item Descriptions
TYPE=101 PACKET CONTENTS (SuperAGILE_GRB_POS_GROUND Source)
Packet Item Descriptions
TYPE=102 PACKET CONTENTS (SuperAGILE_GRB_POS_REFINED Source)
Packet Item Descriptions
TYPE=103 PACKET CONTENTS (SWIFT_ACTUAL_POINTDIR)
Packet Item Descriptions
TYPE=105 PACKET CONTENTS (AGILE_MCAL_ALERT)
Packet Item Descriptions
TYPE=107 PACKET CONTENTS (AGILE_POINTDIR)
Packet Item Descriptions
TYPE=109 PACKET CONTENTS (SuperAGILE_GRB_POS_TEST Source)
Packet Item Descriptions
TYPE=110 PACKET CONTENTS (FERMI_GBM_ALERT)
TYPE=116 PACKET CONTENTS (FERMI_GBM_ALERT_INT) [NOT PUBLIC, FERMI TEAM ONLY]
Packet Item Descriptions
TYPE=111 PACKET CONTENTS (FERMI_GBM_FLT_POS Source)
TYPE=117 PACKET CONTENTS (FERMI_GBM_FLT_INT Source) [NOT PUBLIC, FERMI TEAM ONLY]
Packet Item Descriptions
TYPE=112 PACKET CONTENTS (FERMI_GBM_GND_POS Source)
Packet Item Descriptions
TYPE=114 PACKET CONTENTS (FERMI_GBM_GND_INT Source) [NOT PUBLIC, FERMI TEAM ONLY]
Packet Item Descriptions
TYPE=115 PACKET CONTENTS (FERMI_GBM_FINAL_POS Source)
Packet Item Descriptions
TYPE=119 PACKET CONTENTS (FERMI_GBM_POS_TEST Source)
Packet Item Descriptions
TYPE=120 PACKET CONTENTS (FERMI_LAT_GRB_POS_INI Source) [NOT PUBLIC, FERMI TEAM ONLY]
Packet Item Descriptions
TYPE=121 PACKET CONTENTS (FERMI_LAT_GRB_POS_UPD Source)
Packet Item Descriptions
TYPE=122 PACKET CONTENTS (FERMI_LAT_GRB_POS_DIAG Source) [NOT PUBLIC, FERMI TEAM ONLY]
Packet Item Descriptions
TYPE=123 PACKET CONTENTS (FERMI_LAT_TRANS Source)
Packet Item Descriptions
TYPE=124 PACKET CONTENTS (FERMI_LAT_GRB_POS_TEST Source)
Packet Item Descriptions
TYPE=125 PACKET CONTENTS (FERMI_LAT_MONITOR)
Packet Item Descriptions
TYPE=126 PACKET CONTENTS (FERMI_SC_SLEW)
TYPE=144 PACKET CONTENTS (FERMI_SC_SLEW_INT) [NOT PUBLIC, FERMI TEAM ONLY]
Packet Item Descriptions
TYPE=127 PACKET CONTENTS (FERMI_LAT_GND Source)
Packet Item Descriptions
TYPE=128 PACKET CONTENTS (FERMI_LAT_OFFLINE Source)
Packet Item Descriptions
TYPE=129 PACKET CONTENTS (FERMI_POINTDIR)
Packet Item Descriptions
TYPE=130 PACKET CONTENTS (SIMBAD/NED Search Results)
Packet Item Descriptions
TYPE=131 PACKET CONTENTS (FERMI_GBM_SUBTHRESHOLD transient)
Packet Item Descriptions
TYPE=133 PACKET CONTENTS (SWIFT_BAT_MONITOR)
Packet Item Descriptions
TYPE=134 PACKET CONTENTS (MAXI_UNKNOWN_SOURCE)
Packet Item Descriptions
TYPE=135 PACKET CONTENTS (MAXI_KNOWN_SOURCE)
Packet Item Descriptions
TYPE=136 PACKET CONTENTS (MAXI_TEST)
Packet Item Descriptions
TYPE=137 PACKET CONTENTS (OGLE) [NOT YET AVAILABLE]
Packet Item Descriptions
TYPE=139 PACKET CONTENTS (MOA)
Packet Item Descriptions
TYPE=140 PACKET CONTENTS (SWIFT_BAT_SUB_SUB_THRESH_POS)
Packet Item Descriptions
TYPE=141 PACKET CONTENTS (SWIFT_BAT_KNOWN_SOURCE_POS)
Packet Item Descriptions
TYPE=145 PACKET CONTENTS (Coincidence)
Packet Item Descriptions
TYPE=146 PACKET CONTENTS (FERMI_GBM_FINAL_POS_INT Source)
Packet Item Descriptions
TYPE=148 PACKET CONTENTS (SUZAKU_Lightcurve)
Packet Item Descriptions
TYPE=149 PACKET CONTENTS (SNEWS)
Packet Item Descriptions
TYPE=150 PACKET CONTENTS (LVC_PRELIMIARY)
Packet Item Descriptions
TYPE=151 PACKET CONTENTS (LVC_INITIAL)
Packet Item Descriptions
TYPE=152 PACKET CONTENTS (LVC_UPDATE)
Packet Item Descriptions
TYPE=153 PACKET CONTENTS (LVC_TEST) [DISCONTINUED BY LVC]
Packet Item Descriptions
TYPE=154 PACKET CONTENTS (LVC_COUNTERPART)
Packet Item Descriptions
TYPE=157 PACKET CONTENTS (AMON_ICECUBE_COINC) [NOT YET PUBLIC, AMON TEAM ONLY]
Packet Item Descriptions
TYPE=158 PACKET CONTENTS (AMON_ICECUBE_HESE) [REPLACED BY 173/174]
Packet Item Descriptions
TYPE=159 PACKET CONTENTS (AMON_ICECUBE_TEST)
Packet Item Descriptions
TYPE=160 PACKET CONTENTS (CALET_GBM_FLT_LC)
Packet Item Descriptions
TYPE=161 PACKET CONTENTS (CALET_GBM_GND_LC)
Packet Item Descriptions
TYPE=163 PACKET CONTENTS (LVC_EARLY_WARNING)
Packet Item Descriptions
TYPE=164 PACKET CONTENTS (LVC_RETRACTION)
Packet Item Descriptions
TYPE=166 PACKET CONTENTS (AMON_ICECUBE_CLUSTER) [NOT YET PUBLIC, AMON TEAM ONLY]
Packet Item Descriptions
TYPE=168 PACKET CONTENTS (GWHEN_COINC) [NOT YET PUBLIC, GWHEN TEAM ONLY]
Packet Item Descriptions
TYPE=169 PACKET CONTENTS (AMON_ICECUBE_EHE) [REPLACED BY 173/174]
Packet Item Descriptions
TYPE=170 PACKET CONTENTS (AMON_ANTARES_FERMILAT_COINC) [TERMINATED BY AMON 08sep19]
Packet Item Descriptions
TYPE=171 PACKET CONTENTS (HAWC_BURST_MONITOR)
Packet Item Descriptions
TYPE=172 PACKET CONTENTS (AMON_NU_EM_COINC)
Packet Item Descriptions
TYPE=173 PACKET CONTENTS (ICECUBE_ASTROTRACK_GOLD)
Packet Item Descriptions
TYPE=174 PACKET CONTENTS (ICECUBE_ASTROTRACK_BRONZE)
Packet Item Descriptions
TYPE=175 PACKET CONTENTS (SK_SUPERNOVA)
Packet Item Descriptions
TYPE=176 PACKET CONTENTS (AMON_ICECUBE_CASCADE)
Packet Item Descriptions
*
*
*
*
TYPE=188 PACKET CONTENTS (GECAM_FLT)
Packet Item Descriptions
TYPE=189 PACKET CONTENTS (GECAM_GND)
Packet Item Descriptions
COORDINATES EPOCH and QUANTIZATION COMPARISON
INTRODUCTION:
Scope:
This is the Socket Packet Format Specification Document.
It contains the complete format and contents of each of the packets that are
sent to GCN/TAN Internet socket sites. This document lists only those packet types
available to the GCN/TAN Sites -- there are other packet types (not listed
in this doc) that are used for internal communication and processing
purposes within the GCN/TAN system (ie types 5-10, 12-20, and 23, and
90-96 are Swift_Tean internal messages).
Variations in Packeting Format:
Given the intrinsic variation of data types across all the missions,
it is not possible to have the same format for all packet types, nor is it
possible to have the same locations for those items that do appear
in more than one mission (packet type). Whenever possible, herculean effort
was made to put the same items in standard locations within the packet.
Integer vs Floating Point:
The basic packet is 160 bytes composed of 40 long_words (4-byte integers).
Integers are used even for the intrinsically floating point quantities
so as to make the transfer between platforms and operating systems easier.
All floating point quantities have been scaled up to preserve the decimal
fraction and then integerized. There are only two levels of scaling and
quantization for angles. For those coordinates source with relative large uncertainties,
the scaling is 100x [0.01 degrees]. And for those sources with better accuracy,
the scalling is 10,000x [0.0001 degrees]. For the few non-angle quantities
ther can be other scaling factors. [Fl.pt. were handdled this way because
in the early days of GCN, IEEE Fl.Pt. format were not at all common on computers.]
All that remains for inter-platform compatibility is possibly word and/or byte swapping.
Ranges:
For some quantities the dynamic range of the values is given. Sometimes
the upper limit of the range is given as "infinity". In practice,
"infinity" means the largest value that can be expressed the data type
being used (32K or 64K for signed/unsigned 4-byte integer).
Byte and Word Order:
These socket packets were originally created on a Sun Sparc platform
(which is a big-endian machine). But even though the packets are now
created on a small-endian machine, the byte order is adjusted back
to the big-endian order just prior to being written out the socket
connections. This rotation is done to maintain format continuity
over the years. If the GCN/TAN recipient site is small-endien machine,
you will have to perform byte and/or word swapping on the 40 long-word
fields to get them into a proper order for its computer. The location
of the '\n' character within the last 4-byte field in the packet
can be used to diagnose the byte and/or word swapping necessary.
Obtaining an e-copy:
Most of this document is preformatted, so the user can easily get a copy
of this document by using the get_document_source command within
their browser and removing the purposely very small number of html-ism's.
PACKET NAME vs TYPE NUMBER
This table lists all the currently valid notices (by their name) versus
the packet type number.
NUMBER NAME COMMENT
1 BATSE_ORIGINAL NO LONGER AVAILABLE
2 Test
3 Imalive
4 Kill
5-10 [internal use] n/a
11 BATSE_MAXBC NO LONGER AVAILABLE
12-20 [internal use] n/a
21 Bradford_TEST NO LONGER AVAILABLE
22 BATSE_FINAL NO LONGER AVAILABLE
24 BATSE_LOCBURST NO LONGER AVAILABLE
25 ALEXIS NO LONGER AVAILABLE
26 RXTE-PCA_ALERT NO LONGER AVAILABLE
27 RXTE-PCA NO LONGER AVAILABLE
28 RXTE-ASM_ALERT NO LONGER AVAILABLE
29 RXTE-ASM NO LONGER AVAILABLE
30 COMPTEL NO LONGER AVAILABLE
31 IPN_RAW
32 IPN_SEGMENT MAY BE RE-AVAILABLE
33 SAX-WFC_ALERT NOT AVAILABLE
34 SAX-WFC NO LONGER AVAILABLE
35 SAX-NFI_ALERT NOT AVAILABLE
36 SAX-NFI NO LONGER AVAILABLE
37 RXTE-ASM_XTRANS NO LONGER AVAILABLE
38 spare/testing
39 IPN_POSITION
40 HETE_S/C_ALERT NO LONGER AVAILABLE
41 HETE_S/C_UPDATE NO LONGER AVAILABLE
42 HETE_S/C_LAST NO LONGER AVAILABLE
43 HETE_GNDANA NO LONGER AVAILABLE
44 HETE_Test
45 GRB_COUNTERPART
46 SWIFT_TOO_FOM_OBSERVE
47 SWIFT_TOO_SC_SLEW
48 DOW_TOD_TEST
51 INTEGRAL_POINTDIR
52 INTEGRAL_SPIACS
53 INTEGRAL_WAKEUP
54 INTEGRAL_REFINED
55 INTEGRAL_OFFLINE
56 INTEGRAL_WEAK
57 AAVSO NOT YET AVAILABLE
58 MILAGRO NO LONGER AVAILABLE
59 KONUS_LIGHTCURVE SOON TO BE AVAILABLE
60 SWIFT_BAT_GRB_ALERT
61 SWIFT_BAT_GRB_POSITION
62 SWIFT_BAT_GRB_NACK_POSITION
63 SWIFT_BAT_GRB_LIGHTCURVE
64 SWIFT_BAT_SCALED_MAP NOT PUBLIC, SWIFT TEAM ONLY
65 SWIFT_FOM_OBSERVE
66 SWIFT_SC_SLEW
67 SWIFT_XRT_POSITION
68 SWIFT_XRT_SPECTRUM NOT PUBLIC, SWIFT TEAM ONLY
69 SWIFT_XRT_IMAGE
70 SWIFT_XRT_LIGHTCURVE NOT PUBLIC, SWIFT TEAM ONLY
71 SWIFT_XRT_NACK_POSITION
72 SWIFT_UVOT_IMAGE
73 SWIFT_UVOT_SRC_LIST
76 SWIFT_BAT_GRB_PROC_LIGHTCURVE NOT YET AVAILABLE
77 SWIFT_XRT_PROC_SPECTRUM NOT PUBLIC, SWIFT TEAM ONLY
78 SWIFT_XRT_PROC_IMAGE
79 SWIFT_UVOT_PROC_IMAGE
80 SWIFT_UVOT_PROC_SRC_LIST
81 SWIFT_UVOT_POSITION
82 SWIFT_BAT_GRB_POS_TEST
83 SWIFT_POINTDIR
84 SWIFT_BAT_TRANS
85 SWIFT_XRT_THRESHPIX NOT PUBLIC, SWIFT TEAM ONLY
86 SWIFT_XRT_THRESHPIX_PROC NOT PUBLIC, SWIFT TEAM ONLY
87 SWIFT_XRT_SPER NOT PUBLIC, SWIFT TEAM ONLY
88 SWIFT_XRT_SPER_PROC NOT PUBLIC, SWIFT TEAM ONLY
89 SWIFT_UVOT_NACK_POSITION
97 SWIFT_BAT_QUICKLOOK_POSITION
98 SWIFT_BAT_SUBTHRESHOLD_POSITION
99 SWIFT_BAT_SLEW_GRB_POSITION
100 SuperAGILE_GRB_POS_WAKEUP
101 SuperAGILE_GRB_POS_GROUND
102 SuperAGILE_GRB_POS_REFINED
103 SWIFT_ACTUAL_POINTDIR
105 AGILE_MCAL_ALERT
107 AGILE_POINTDIR
109 SuperAGILE_GRB_POS_TEST
110 FERMI_GBM_ALERT
111 FERMI_GBM_FLT_POS
112 FERMI_GBM_GND_POS
114 FERMI_GBM_GND_INTERNAL NOT PUBLIC, FERMI TEAM ONLY
115 FERMI_GBM_FIN_POS
116 FERMI_GBM_ALERT_INTERNAL NOT PUBLIC, FERMI TEAM ONLY
117 FERMI_GBM_FLT_INTERNAL NOT PUBLIC, FERMI TEAM ONLY
119 FERMI_GBM_POS_TEST
120 FERMI_LAT_GRB_POS_INI NOT PUBLIC, FERMI TEAM ONLY
121 FERMI_LAT_GRB_POS_UPD
122 FERMI_LAT_GRB_POS_DIAG NOT PUBLIC, FERMI TEAM ONLY
123 FERMI_LAT_TRANS
124 FERMI_LAT_GRB_POS_TEST
125 FERMI_LAT_MONITOR
126 FERMI_SC_SLEW
127 FERMI_LAT_GND
128 FERMI_LAT_OFFLINE
129 FERMI_POINTDIR
130 SIMBAD/NED_SEARCH_RESULTS
131 FERMI_GBM_SUBTHRESHOLD
133 SWIFT_BAT_MONITOR
134 MAXI_UNKNOWN_SOURCE
135 MAXI_KNOWN_SOURCE
136 MAXI_TEST
137 OGLE May become AVAILABLE
139 MOA
140 SWIFT_BAT_SUB_SUB_THRESH_POS
141 SWIFT_BAT_KNOWN_SRC_POS
144 FERMI_SC_SLEW_INTERNAL NOT PUBLIC, FERMI TEAM ONLY
145 COINCIDENCE
146 FERMI_GBM_FIN_POS_INTERNAL NOT PUBLIC, FERMI TEAM ONLY
148 SUZAKU_LIGHTCURVE
149 SNEWS
150 LVC_PRELIMINARY
151 LVC_INITIAL
152 LVC_UPDATE
153 LVC_TEST DISCONTINUED BY LVC
154 LVC_COUNTERPART
157 AMON_ICECUBE_COINC NOT YET PUBLIC, AMON TEAM ONLY
158 AMON_ICECUBE_HESE DISCONTINUED BY ICECUBE, REPLACED BY 173/174
159 AMON_ICECUBE_TEST
160 CALET_GBM_FLT_LC
161 CALET_GBM_GND_LC
163 LVC_EARLY_WARNING
164 LVC_RETRACTION
166 AMON_ICECUBE_CLUSTER NOT YET PUBLIC, AMON TEAM ONLY
168 GWHEN_COINC NOT YET PUBLIC, GWHEN TEAM ONLY
169 AMON_ICECUBE_EHE DISCONTINUED BY ICECUBE, REPLACED BY 173/174
170 AMON_ANTARES_FERMILAT_COINC TERMINATED BY AMON 08sep19
171 HAWC_BURST_MONITOR
172 AMON_NU_EM_COINC
173 ICECUBE_ASTROTRACK_GOLD
174 ICECUBE_ASTROTRACK_BRONZE
175 SK_SUPERNOVA
176 AMON_ICECUBE_CASCADE
***
188 GECAM_FLT
189 GECAM_GND
COMPARING THE TYPE=1,2,3,4,11,21,22,24-45,51-55,58-59,
60-89,98,99,100-102,105,107-109,110-113,115,118-137,139-141,144,145,146,148,149,
150-154,163,164,157,158,160-161,163-164,168-174,175-176,188-189 CONTENTS/FORMATS:
The contents and formats of all the valid packets for distribution are listed
below. The descriptions and definitions for each of the items within
the packets are given in the sections following each packet type.
Entries with a "-" or a "spare" in the table are undefined spare slots.
Type: 1 2 3 4 11
Loc: ORIGINAL TEST IMALIVE KILL MAXBC
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_num trig_num - - trig_num
5 burst_tjd burst_tjd burst_tjd burst_tjd burst_tjd
6 burst_sod burst_sod burst_sod burst_sod burst_sod
7 burst_ra burst_ra - - burst_ra
8 burst_dec burst_dec - - burst_dec
9 burst_inten burst_inten - - burst_inten
10 burst_peak burst_peak - - burst_peak
11 burst_error burst_error - - burst_error
12 sc_az sc_az=0 - - sc_az
13 sc_el sc_el=0 - - sc_el
14 sc_x_ra sc_x_ra=0 - - sc_x_ra
15 sc_x_dec sc_x_dec=0 - - sc_x_dec
16 sc_z_ra sc_z_ra=0 - - sc_z_ra
17 sc_z_dec sc_z_dec=0 - - sc_z_dec
18 trig_id trig_id - - trig_id
19 misc misc - - misc
20 earth_sc_az earth_sc_az - - earth_sc_az
21 earth_sc_el earth_sc_el - - earth_sc_el
22 sc_radius sc_radius - - sc_radius
23 t_peak spare - - maxc1[0]
24 sam_used spare - - maxc1[1]
25 spare spare - - maxc1[2]
26 spare spare - - maxc1[3]
27 spare spare - - maxc1[4]
28 spare spare - - maxc1[5]
29 spare spare - - maxc1[6]
30 spare spare - - maxc1[7]
31 spare spare - - maxbc[0]
32 spare spare - - maxbc[1]
33 spare spare - - maxbc[2]
34 spare spare - - maxbc[3]
35 spare spare - - maxbc[4]
36 spare spare - - maxbc[5]
37 spare spare - - maxbc[6]
38 spare spare - - maxbc[7]
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 21 22 24 25
Loc: BRAD_COORDS FINAL LOCBURST ALEXIS
0 pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_esrnum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_num trig_num trig_num src_num
5 burst_tjd burst_tjd burst_tjd trans_tjd
6 burst_sod burst_sod burst_sod trans_sod
7 burst_ra burst_ra burst_ra trans_ra
8 burst_dec burst_dec burst_dec trans_dec
9 burst_inten burst_inten burst_inten -
10 burst_peak burst_peak burst_peak -
11 burst_error burst_error burst_error trans_error
12 sc_az=0 sc_az sc_az -
13 sc_el=0 sc_el sc_el -
14 sc_x_ra=0 sc_x_ra sc_x_ra -
15 sc_x_dec=0 sc_x_dec sc_x_dec -
16 sc_z_ra=0 sc_z_ra sc_z_ra -
17 sc_z_dec=0 sc_z_dec sc_z_dec -
18 - trig_id trig_id -
19 misc misc misc -
20 - earth_sc_az - -
21 - earth_sc_el - -
22 - sc_radius - trans_alpha
23 - - - map_duration
24 - - - tele_id
25 - - - -
26 - - - -
27 - - - -
28 - - - -
29 - - - -
30 - - - -
31 - - - -
32 - - - -
33 - - - -
34 - - - -
35 - - - -
36 - - - -
37 - - - -
38 - - - -
39 pkt_term pkt_term pkt_term pkt_term
Type: 26 27 28 29 30
Loc: RXTE-PCA_ALERT RXTE-PCA XTE-ASM_ALERT XTE-ASM COMPTEL
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_num trig_num trig_num trig_num trig_num
5 burst_tjd burst_tjd burst_tjd burst_tjd burst_tjd
6 burst_sod burst_sod burst_sod burst_sod burst_sod
7 locburst_ra burst_ra burst_ra burst_ra burst_ra
8 locburst_dec burst_dec burst_dec burst_dec burst_dec
9 - burst_inten - burst_inten burst_inten
10 - burst_peak - burst_peak burst_peak
11 - burst_error - burst_error -
12 - - - burst_cont -
13 - - - - -
14 - - - - -
15 - - - - -
16 - - - - -
17 - - - - -
18 - - trig_id trig_id trig_id
19 misc misc misc misc misc
20 - - - - -
21 - - - - -
22 - - - - -
23 - - - - -
24 obs_tjd obs_tjd - err_ra1 err_ra1
25 obs_sod obs_sod - err_dec1 err_dec1
26 - - - err_ra2 err_ra2
27 - - - err_dec2 err_dec2
28 - - - err_ra3 err_ra3
29 - - - err_dec3 err_dec3
30 - - - err_ra4 err_ra4
31 - - - err_dec4 err_dec4
32 - - - length det_signif
33 - - - width -
34 - - - pos_angle -
35 - - - - -
36 - - - - -
37 - - - - -
38 - - - - -
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 31 32
Loc: IPN_RAW IPN_SEG
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 trig_id trig_num
5 burst_tjd burst_tjd
6 burst_sod burst_sod
7 ipn_center_ra ipn_center_ra
8 ipn_center_dec ipn_center_dec
9 ipn_radius ipn_radius
10 ipn_t_window -
11 ipn_width ipn_width
12 - 3sig_ra
13 - 3sig_dec
14 evt_duration 2sig_ra
15 - 2sig_dec
16 - 1sig_ra
17 - 1sig_dec
18 trig_id max_prob_ra
19 misc max_prob_dec
20 scratch 1sig_ra
21 scratch 1sig_dec
22 url_c0-3 2sig_ra
23 url_c4-7 2sig_dec
24 url_c8-11 3sig_ra
25 url_c12-15 3sig_dec
26 url_c16-19 -
27 url_... -
28 url_... -
29 url_... -
30 url_... -
31 url_... -
32 url_... -
33 url_... -
34 url_... -
35 url_... -
36 url_... -
37 url_... -
38 url_c64-67 -
39 pkt_term pkt_term
Type: 33 34 35 36
Loc: SAX-WFC_ALERT SAX-WFC SAX-NFI_ALERT SAX-NFI
0 pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod
4 - - - -
5 burst_tjd burst_tjd burst_tjd burst_tjd
6 burst_sod burst_sod burst_sod burst_sod
7 burst_ra burst_ra burst_ra burst_ra
8 burst_dec burst_dec burst_dec burst_dec
9 - burst_inten - burst_inten
10 - burst_peak - burst_peak
11 - burst_error - burst_error
12 - burst_cont - burst_cont
13 - - - -
14 - - - -
15 - - - -
16 - - - -
17 - - - -
18 trig_id trig_id trig_id trig_id
19 misc misc misc misc
20 - - - -
21 - - - -
22 - - - -
23 - - - -
24 - - - -
25 - - - -
26 - - - -
27 - - - -
28 - - - -
29 - - - -
30 - - - -
31 - - - -
32 - - - -
33 - - - -
34 - - - -
35 - - - -
36 - - - -
37 - - - -
38 - - - -
39 pkt_term pkt_term pkt_term pkt_term
Type: 37
Loc: XTE-ASM_XTRANS
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 ref_num
5 trans_tjd
6 trans_sod
7 trans_ra
8 trans_dec
9 trans_inten
10 -
11 trans_error
12 -
13 time_since
14 chi_sq_1
15 chi_sq_2
16 SigNoise1
17 SigNoise2
18 trig_id
19 misc
20 -
21 -
22 -
23 -
24 ra1
25 dec1
26 ra2
27 dec2
28 ra3
29 dec3
30 ra4
31 dec4
32 line_length
33 line_width
34 pos_angle
35 -
36 -
37 -
38 -
39 pkt_term
Type: 39
Loc: IPN_POS
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 ref_num
5 burst_tjd
6 burst_sod
7 burst_ra
8 burst_dec
9 burst_fluence
10 burst_flux
11 burst_error
12 sample_interval
13 -
14 -
15 -
16 burst2_ra
17 burst2_dec
18 sernum
19 misc
20 -
21 box_area
22 duration
23 ra1
24 dec1
25 ra2
26 dec2
27 ra3
28 dec3
29 ra4
30 dec4
31 ra21
32 dec21
33 ra22
34 dec22
35 ra23
36 dec23
37 ra24
38 dec24
39 pkt_term
Type: 40 41 42 43 44
Loc: HETE_S/C_ALERT HETE_S/C_UPDATE HETE_S/C_LAST HETE_GNDANA HETE_Test
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_seq_num trig_seq_num trig_seq_num trig_seq_num trig_seq_num
5 burst_tjd burst_tjd burst_tjd burst_tjd burst_jtd
6 burst_sod burst_sod burst_sod burst_sod burst_sod
7 [burst_ra] burst_ra burst_ra burst_ra burst_ra
8 [burst_dec] burst_dec burst_dec burst_dec burst_dec
9 trig_flags trig_flags trig_flags trig_flags trig_flags
10 gamma_cnts gamma_cnts gamma_cnts gamma_cnts gamma_cnts
11 wxm_s2n wxm_s2n wxm_s2n wxm_s2n wxm_s2n
12 sxc_cnts sxc_cnts sxc_cnts sxc_cnts sxc_cnts
13 gamma_time gamma_time gamma_time gamma_time gamma_time
14 wxm_time wxm_time wxm_time wxm_time wxm_time
15 sc_point sc_point sc_point sc_point sc_point
16 - wxra1 wxra1 wxra1 wxra1
17 - wxdec1 wxdec1 wxdec1 wxdec1
18 - wxra2 wxra2 wxra2 wxra1
19 - wxdec2 wxdec2 wxdec2 wxdec2
20 - wxra3 wxra3 wxra3 wxra1
21 - wxdec3 wxdec3 wxdec3 wxdec3
22 - wxra4 wxra4 wxra4 wxra1
23 - wxdec4 wxdec4 wxdec4 wxdec4
24 - wx_errors wx_errors wx_errors wx_errors
25 - wx_dimsig wx_dimsig wx_dimsig wx_dimsig
26 - sxra1 sxra1 sxra1 sxra1
27 - sxdec1 sxdec1 sxdec1 sxdec1
28 - sxra2 sxra2 sxra2 sxra1
29 - sxdec2 sxdec2 sxdec2 sxdec2
30 - sxra3 sxra3 sxra3 sxra1
31 - sxdec3 sxdec3 sxdec3 sxdec3
32 - sxra4 sxra4 sxra4 sxra1
33 - sxdec4 sxdec4 sxdec4 sxdec4
34 - sx_errors sx_errors sx_errors sx_errors
35 - sx_simsig sx_simsig sx_simsig sx_simsig
36 - pos_flags pos_flags pos_flags pos_flags
37 - validity validity validity validity
38 - lc_img_sn lc_img_sn lc_img_sn lc_img_sn
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 45
Loc: GRB_COUNTERPART
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 ref_num
5 burst_tjd
6 burst_sod
7 cp_ra
8 cp_dec
9 cp_inten
10 inten_uncert
11 pos_error
12 filter
13 seeing
14 obs_start_date
15 obs_start_time
16 obs_dur
17 id_conf_level
18 trig_id
19 misc
20 tele_name_c0-3
21 tele_name_c4-7
22 tele_name_c8-11
23 tele_name_c11-15
24 name_c0-3
25 name_c4-7
26 name_c8-11
27 name_c12-15
28 name_...
29 name_...
30 name_...
31 name_...
32 name_...
33 name_...
34 name_...
35 name_...
36 name_...
37 name_...
38 name_c56-59
39 pkt_term
Type: 48
Loc: DOW_TOD
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 -
5 pkt_tjd
6 pkt_sod
7 -
8 -
9 -
10 -
11 -
12 -
13 -
14 -
15 -
16 -
17 -
18 -
19 -
20 -
21 -
22 -
23 -
24 -
25 -
26 -
27 -
28 -
29 -
30 -
31 -
32 -
33 -
34 -
35 -
36 -
37 -
38 -
39 pkt_term
Type: 51 52 53 54 55 56
Loc: INTEGRAL_ INTEGRAL_ INTEGRAL_ INTEGRAL_ INTEGRAL_ INTEGAL_
POINTDIR SPIACS WAKEUP REFINED OFFLINE WEAK
0 pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_sub_num trig_sub_num trig_sub_num trig_sub_num trig_sub_num trig_sub_num
5 slew_tjd burst_tjd burst_tjd burst_tjd burst_tjd burst_tjd
6 slew_sod burst_sod burst_sod burst_sod burst_sod burst_sod
7 - - burst_ra burst_ra burst_ra burst_ra
8 - - burst_dec burst_dec burst_dec burst_dec
9 - det_flags det_flags det_flags det_flags det_flags
10 - inten_sigma inten_sigma inten_sigma inten_sigma inten_sigma
11 - - burst_error burst_error burst_error burst_error
12 test_mpos test_mpos test_mpos test_mpos test_mpos test_mpos
13 - time_scale time_scale time_scale time_scale time_scale
14 next_sc_ra - sc_ra sc_ra sc_ra sc_ra
15 next_sc_dec - sc_dec sc_dec sc_dec sc_dec
16 - time_error time_error time_error time_error time_error
17 - - - - - -
18 - - - - - -
19 misc_att misc_att misc_att misc_att misc_att misc_att
20 - - - - - -
21 - - - - - -
22 - - - - - -
23 - - - - - -
24 - - - - - -
25 - - - - - -
26 - - - - - -
27 - - - - - -
28 - - - - - -
29 - - - - - -
30 - - - - - -
31 - - - - - -
32 - - - - - -
33 - - - - - -
34 - - - - - -
35 - - - - - -
36 - - - - - -
37 - - - - - -
38 - - - - - -
39 pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 57 58
Loc: AAVSO MILAGRO
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 trig_num trig_num
5 event_tjd burst_tjd
6 event_sod burst_sod
7 event_ra burst_ra
8 event_dec burst_dec
9 - burst_signal
10 - background
11 event_error burst_error
12 - significance
13 - duration
14 - ann_rate
15 - zen_angle
16 - -
17 - -
18 trig_id trig_id
19 misc misc
20 - -
21 - -
22 - -
23 - -
24 - -
25 - -
26 - -
27 - -
28 - -
29 - -
30 - -
31 - -
32 - -
33 - -
34 - -
35 - -
36 - -
37 - -
38 - -
39 pkt_term pkt_term
Type: 59
Loc: KONUS_LC
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 -
5 trigger_tjd
6 trigger_sod
7 -
8 -
9 -
10 -
11 -
12 -
13 -
14 -
15 E_min
16 E_max
17 hi_prec_sod
18 trig_id
19 -
20 -
21 -
22 url_c0-3
23 url_c4-7
24 url_c8-11
25 url_...
26 url_...
27 url_...
28 url_...
29 url_...
30 url_...
31 url_...
32 url_...
33 url_...
34 url_...
35 url_...
36 url_...
37 url_...
38 url_c64-67
39 pkt_term
SWIFT PACKETS:
Type: 60 61 62 63 64
Loc: BAT_GRB_ALERT BAT_GRB_POS BAT_GRB_NACK BAT_GRB_LC BAT_SCALEDMAP
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_obs_num trig_obs_num trig_obs_num trig_obs_num trig_obs_num
5 trig_tjd burst_tjd trig_tjd burst_tjd burst_tjd
6 trig_sod burst_sod trig_sod burst_sod burst_sod
7 - burst_ra - burst_ra point_ra
8 - burst_dec - burst_dec point_dec
9 - burst_flue - - -
10 - burst_ipeak - - -
11 - burst_error - - -
12 - phi - phi -
13 - theta - theta -
14 - integ_time integ_time delta_time foregnd_dur
15 - - - integ_time integ_time
16 lon_lat lon_lat lon_lat lon_lat lon_lat
17 trig_index trig_index trig_index trig_index trig_index
18 soln_status soln_status soln_status soln_status soln_status
19 misc misc misc misc misc
20 - image_signif image_signif image_signif -
21 rate_signif rate_signif rate_signif rate_signif -
22 - bkg_flue bkg_flue url_c0-3 url_c0-3
23 - bkg_start bkg_start url_c4-7 url_c4-7
24 - bkg_dur bkg_dur url_c8-11 url_c8-1
25 - cat_num - url_... url_...
26 - - - url_... url_...
27 - - - url_... url_...
28 - - - url_... url_...
29 - - - url_... url_...
30 - - - url_... url_...
31 - - - url_... url_...
32 - - - url_... url_...
33 - - - url_... url_...
34 - - - url_... url_...
35 - - - url_... url_...
36 - merit_0-3 merit_0-3 url_... url_...
37 - merit_4-7 merit_4-7 url_... url_...
38 - merit_8-9 merit_8-9 url_c64-67 url_c64-67
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 65 (and 46) 66 (and 47)
Loc: FOM_OBS SC_SLEW
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 trig_obs_num trig_obs_num
5 burst_tjd burst_tjd
6 burst_sod burst_sod
7 burst_ra burst_ra
8 burst_dec burst_dec
9 roll roll
10 lon_lat lon_lat
11 - -
12 - -
13 - wait_time
14 - obs_time
15 integ_time integ_time
16 soln_status soln_status
17 trig_index trig_index
18 at_slew_flags slew_rtn
19 misc misc
20 image_signif image_signif
21 rate_signif rate_signif
22 - bat_mode
23 - xrt_mode
24 - uvot_mode
25 - -
26 - -
27 - -
28 - -
29 - -
30 - -
31 - -
32 - -
33 - -
34 - -
35 - -
36 - -
37 - -
38 merit_value merit_value
39 pkt_term pkt_term
Type: 67 68 69 70 71
Loc: XRT_POS XRT_SPEC XRT_IMAGE XRT_LC XRT_NACK_POS
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_obs_num trig_obs_num trig_obs_num trig_obs_num trig_obs_num
5 data_tjd spec_start_tjd image_start_tjd start_tjd data_tjd
6 data_sod spec_start_sod image_start_sod start_sod data_sod
7 burst_ra bore_ra burst_ra bore_ra point_ra
8 burst_dec bore_dec burst_dec bore_dec point_dec
9 burst_flue livetime centroid_cnt livetime centroid_cnts
10 - spec_stop_tjd - stop_tjd min_count
11 burst_error spec_stop_sod centroid_stddev stop_sod centroid_stddev
12 x_tam_i1 mode centroid_x - sig_max
13 y_tam_i1 waveform centroid_y - -
14 x_tam_i2 bias raw_x - -
15 y_tam_i2 - raw_y - -
16 hi_prec_err - roll - ph2_iter
17 amp_wave - gain/mode/wave - max_iter
18 soln_status - expo_time - err_flag
19 misc misc misc misc misc
20 xrt-bat - grb_in_xrt_y - -
21 det_signif term_cond grb_in_xrt_z term_cond -
22 - url_c0-3 url_c0-3 url_c0-3 -
23 - url_c4-7 url_c4-7 url_c4-7 -
24 - url_... url_... url_... -
25 - url_... url_... url_... -
26 - url_... url_... url_... -
27 - url_... url_... url_... -
28 - url_... url_... url_... -
29 - url_... url_... url_... -
30 - url_... url_... url_... -
31 - url_... url_... url_... -
32 - url_... url_... url_... -
33 - url_... url_... url_... -
34 - url_... url_... url_... -
35 - url_... url_... url_... -
36 - url_... url_... url_... -
37 - url_... url_... url_... -
38 - url_c64-67 url_c64-67 url_c64-67 -
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 72 73
Loc: UVOT_IMAGE UVOT_SRCLIST
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 trig_obs_num trig_obs_num
5 expo_start_tjd expo_start_tjd
6 expo_start_sod expo_start_sod
7 point_ra point_ra
8 point_dec point_dec
9 image_roll image_roll
10 filter filter
11 expo_id bkg_mean
12 x_offset x_max
13 y_offset y_max
14 width n_stars
15 height x_offset
16 xy_grb y_offset
17 n_frames det_thresh
18 swl_lwl photo_thresh
19 misc misc
20 - -
21 - -
22 url_c0-3 url_c0-3
23 url_c4 7 url_c4-7
24 url_... url_...
25 url_... url_...
26 url_... url_...
27 url_... url_...
28 url_... url_...
29 url_... url_...
30 url_... url_...
31 url_... url_...
32 url_... url_...
33 url_... url_...
34 url_... url_...
35 url_... url_...
36 url_... url_...
37 url_... url_...
38 url_c64-67 url_c64-67
39 pkt_term pkt_term
Type: 76 77 78 79 80
Loc: BAT_PROC_LC XRT_PROC_SPEC XRT_PROC_IMAGE UVOT_PROC_IM UVOT_PROC_SL
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_obs_num trig_obs_num trig_obs_num trig_obs_num trig_obs_num
5 burst_tjd spec_start_tjd image_start_tjd expo_start_tjd expo_start_tjd
6 burst_sod spec_start_sod image_start_sod expo_start_sod expo_start_sod
7 burst_ra bore_ra burst_ra point_ra point_ra
8 burst_dec bore_dec burst_dec point_dec point_dec
9 T90_time burst_flue Centroid_Cnts image_roll image_roll
10 - SpecStopTJD - filter filter
11 - SpecStopSOD CentStdDev expo_id bkg_mean
12 phi mode centroid_x x_offset x_max
13 theta waveform centroid_y y_offset y_max
14 delta_time - raw_x width n_stars
15 integ_time - raw_y height x_offset
16 lon_lat - roll xy_grb y_offset
17 trig_index - gain/mode/wave n_frames det_thresh
18 soln_status - expo_time swl_lwl photo_thresh
19 misc misc misc misc misc
20 - - - - -
21 - - - - -
22 url_c0-3 url_c0-3 url_c0-3 url_c0-3 url_c0-3
23 url_c4-7 url_c4-7 url_c4-7 url_c4-7 url_c4-7
24 url_c8-11 url_c8-11 url_c8-11 url_c8-11 url_c8-11
25 url_... url_... url_... url_... url_...
26 url_... url_... url_... url_... url_...
27 url_... url_... url_... url_... url_...
28 url_... url_... url_... url_... url_...
29 url_... url_... url_... url_... url_...
30 url_... url_... url_... url_... url_...
31 url_... url_... url_... url_... url_...
32 url_... url_... url_... url_... url_...
33 url_... url_... url_... url_... url_...
34 url_... url_... url_... url_... url_...
35 url_... url_... url_... url_... url_...
36 url_... url_... url_... url_... url_...
37 url_... url_... url_... url_... url_...
38 url_c64-67 url_c64-67 url_c64-67 url_c64-67 url_c64-67
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 81 82 83 84 103
Loc: UVOT_POS BAT_GRB_POS_TEST POINTDIR BAT_TRANS ACTUAL_POINTDIR
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_obs_num trig_obs_num trig_obs_num trig_obs_num trig_obs_num
5 burst_tjd burst_tdj point_tjd trans_tjd point_tjd
6 burst_sod burst_sod point_sod trans_sod point_sod
7 burst_ra burst_ra point_ra trans_ra point_ra
8 burst_dec burst_dec point_dec trans_dec point_dec
9 burst_mag burst_flue point_roll trans_flue point_roll
10 filter burst_ipeak - trans_ipeak -
11 burst_error burst_error bat_mode trans_error -
12 - phi xrt_mode phi -
13 - theta uvot_mode theta -
14 - integ_time obs_time integ_time -
15 - - merit_value - -
16 hi_prec_err lon_lat lon_lat lon_lat lon_lat
17 - trig_index - trig_index -
18 soln_status soln_status - soln_status -
19 misc misc misc misc misc
20 mag_error image_signif - image_signif -
21 - rate_signif - rate_signif -
22 - bkg_flue tgt_c0-3 bkg_flue -
23 - bkg_start tgt_c4-7 bkg_start -
24 - bkg_dur tgt_c8-11 bkg_dur -
25 - cat_num tgt_... cat_num -
26 - - tgt_... - -
27 - - tgt_... - -
28 - - tgt_... - -
29 - - tgt_... - -
30 - - tgt_... - -
31 - - tgt_... - -
32 - - tgt_... - -
33 - - tgt_... - -
34 - - tgt_... - -
35 - - tgt_... - -
36 - merit_0-3 tgt_... merit_0-3 -
37 - merit_4-7 tgt_... merit_4-7 -
38 - merit_8-9 tgt_c64-67 merit_8-9 -
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 85 86 87 88
Loc: XRT_THRESHPIX XRT_TP_PROC XRT_SPER XRT_SPER_PROC
0 pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_obs_num trig_obs_num trig_obs_num trig_obs_num
5 burst_tjd burst_tdj burst_tjd burst_tjd
6 burst_sod burst_sod burst_sod burst_sod
7 point_ra point_ra point_ra point_ra
8 point_dec point_dec point_dec point_dec
9 expo_time expo_time expo_time expo_time
10 stop_date stop_date stop_date stop_date
11 stop_time stop_time stop_time stop_time
12 seq_num seq_num num_pkt num_pkt
13 - - - -
14 - - - -
15 - - - -
16 - - - -
17 - - - -
18 - - - -
19 misc misc misc misc
20 - - num_evt num_evt
21 - - - -
22 url_c0-3 url_c0-3 url_c0-3 url_c0-3
23 url_c4-7 url_c4-7 url_c4-7 url_c4-7
24 url_c8-11 url_c8-11 url_c8-11 url_c8-11
25 url_... url_... url_... url_...
26 url_... url_... url_... url_...
27 url_... url_... url_... url_...
28 url_... url_... url_... url_...
29 url_... url_... url_... url_...
30 url_... url_... url_... url_...
31 url_... url_... url_... url_...
32 url_... url_... url_... url_...
33 url_... url_... url_... url_...
34 url_... url_... url_... url_...
35 url_... url_... url_... url_...
36 url_... url_... url_... url_...
37 url_... url_... url_... url_...
38 url_c64-67 url_c64-67 url_c64-67 url_c64-67
39 pkt_term pkt_term pkt_term pkt_term
Type: 89
Loc: UVOT_POS_NACK
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 trig_obs_num
5 trig_tjd
6 trig_sod
7 src_ra
8 src_dec
9 mag_lim
10 filter
11 src_error
12 src
13 -
14 -
15 -
16 -
17 -
18 soln_status
19 misc
20 lim_sigma
21 -
22 -
23 -
24 -
25 -
26 -
27 -
28 -
29 -
30 -
31 -
32 -
33 -
34 -
35 -
36 -
37 -
38 -
39 pkt_term
Type: 97 98 99
Loc: BAT_QUICKLOOK_POS BAT_SUBTHRESHOLD_POS BAT_SLEW_GRB_POS
0 pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod
4 trig_obs_num trig_obs_num id_num
5 burst_tjd burst_tjd burst_tjd
6 burst_sod burst_sod burst_sod
7 burst_ra burst_ra burst_ra
8 burst_dec burst_dec burst_dec
9 roll burst_flue burst_flue
10 lon_lat burst_ipeak burst_ipeak
11 burst_error burst_error burst_error
12 - phi -
13 - theta -
14 - integ_time integ_time
15 - - -
16 - lon_lat -
17 trig_index trig_index trig_index
18 at_slew_flags soln_status soln_status
19 misc misc misc
20 - image_signif image_signif
21 rate_signif rate_signif -
22 - bkg_flue -
23 - bkg_start -
24 - bkg_dur -
25 - cat_num -
26 - - -
27 - - -
28 - - -
29 - - -
30 - - -
31 - - -
32 - - -
33 - - -
34 - - -
35 - - -
36 - merit_0-3 -
37 - merit_4-7 -
38 merit_value merit_8-9 -
39 pkt_term pkt_term pkt_term
SuperAGILE PACKETS:
Type: 100-102 105 107 108 109
Loc: SuperAGILE_POS AGILE_MCAL_ALERT AGILE_POINTDIR SuperAGILE_TRANS SuperAGILE_POS_TEST
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_num trig_num - trig_num trig_num
5 burst_tjd burst_tjd curr_tjd trans_tjd burst_tjd
6 burst_sod burst_sod curr_sod trans_sod burst_sod
7 burst_ra - curr_ra trans_ra burst_ra
8 burst_dec - curr_dec trans_dec burst_dec
9 burst_intenX burst_tot_cnt - trans_intenX burst_intenX
10 burst_intenY burst_peak_cnt - trans_intenY burst_intenY
11 burst_error - - trans_error burst_error
12 - bin_size next_tjd - -
13 - bkg_cnt_rate next_sod - -
14 - integ_time - - -
15 - - - - -
16 - lon_lat - - -
17 - peak_signif - - -
18 trig_id trig_id - trig_id trig_id
19 misc misc misc misc misc
20 burst_signif burst_signif - trans_signif burst_signif
21 - e_low - - -
22 - e_high - - -
23 - - - - -
24 - - - - -
25 - - - - -
26 - - - - -
27 - - - - -
28 - - - - -
29 - url_c0-3 - - -
30 - url_c4-7 - - -
31 - url_c8-11 - - -
32 - url_c12-15 - - -
33 - url_c16-l9 - - -
34 - url_c20-23 - - -
35 - url_c24-27 - - -
36 - url_c28-31 - - -
37 - url_c32-35 - - -
38 - url_c36-39 - - -
39 pkt_term pkt_term pkt_term pkt_term pkt_term
FERMI PACKETS:
Type: 110&116 111&117 112 113 114 115&146 118 119 131
Loc: GBM_ALERT GBM_FLT_POS GBM_GND_POS GBM_LC GBM_GND_INTERNAL GBM_FINAL GBM_TRANS GBM_POS_TEST GBM_SUBTHRESH
0 pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_num trig_num trig_num trig_num trig_num trig_num trig_num trig_num trans_num
5 burst_tjd burst_tjd burst_tjd burst_tjd burst_tjd burst_tjd trans_tjd burst_tjd event_tjd
6 burst_sod burst_sod burst_sod burst_sod burst_sod burst_sod trans_sod burst_sod event_sod
7 - burst_ra burst_ra burst_ra burst_ra burst_ra trans_ra burst_ra event_ra
8 - burst_dec burst_dec burst_dec burst_dec burst_dec trans_dec burst_dec event_dec
9 algorithm burst_flue - ??? burst_flue - trans_flue burst_flue -
10 - - - ??? burst_inten - trans_inten burst_inten -
11 - burst_error burst_error ??? burst_error burst_error trans_error burst_error event_error
12 - phi phi - - - - - evt_sod_subsec
13 - theta theta - - - - - earth_angle
14 trig_dur integ_time data_interval ??? integ_time - integ_time integ_time duration
15 lo_chan - - - - - - - -
16 hi_chan - lon_lat ??? - - - - -
17 ADC_LoChan trig_dur - ??? trig_dur - trig_dur trig_dur -
18 ADC_HiChan soln_status ?soln_status? ??? soln_status soln_status soln_status soln_status soln_status
19 misc misc misc ??? misc misc misc misc misc
20 rec_seq_num rec_seq_num rec_seq_num ??? rec_seq_num - rec_seq_num rec_seq_num -
21 trig_signif rate_signif signif ??? signif - rate_signif rate_signif -
22 lon loc_algor loc_algor ??? loc_algor loc_algor loc_algor loc_algor -
23 lat most_likely - ??? - - most_likely most_likely reliability
24 - 2most_likely - ??? - - 2most_likely 2most_likely -
25 - hard_ratio - - - - hard_ratio hard_ratio -
26 dets dets lo_e - lo_e lo_e dets detd -
27 - - hi_e - hi_e hi_e - - url_c0-3
28 - - sc_x - sc_x - - - url_c4-7
29 - - sc_y - sc_y - - - url_c8-11
30 - - sc_z - sc_z - - - url_c12-15
31 lc_yymmdd lc_yymmdd lc_yymmdd - lc_yymmdd lc_yymmdd - lc_yymmdd url_c16-19
32 lc_fff lc_fff lc_fff - lc_fff lc_fff - lc_fff url_c20-23
33 - - - - - - - - url_c24-27
34 - - - - - - - - url_c28-31
35 - - - - - - - - url_c32-35
36 - - - - - - - - url_c36-39
37 - lon - - - - - - url_c40-43
38 - lat - - - - - - url_c44-47
39 pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 120 121 122 123 124 125
Loc: LAT_POS_INI LAT_POS_UPD LAT_POS_DIAG LAT_TRANS LAT_POS_TEST LAT_MONITOR
0 pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 trig_num trig_num trig_num ref_num trig_num ref_num
5 burst_tjd burst_tjd burst_tjd trans_tjd burst_tjd trans_tjd
6 burst_sod burst_sod burst_sod trans_sod burst_sod trans_sod
7 burst_ra burst_ra burst_ra trans_ra burst_ra trans_ra
8 burst_dec burst_dec burst_dec trans_dec burst_dec trans_dec
9 tot_loc_inten tot_loc_inten tot_loc_inten curr_flux tot_loc_inten curr_flux
10 inten_4 inten_4 inten_4 base_flux inten_4 base_flux
11 burst_error burst_error burst_error trans_error burst_error trans_error
12 phi phi phi cur_flx_err phi cur_flx_err
13 theta theta theta bas_flx_err theta bas_flx_err
14 int_time int_time int_time time_scale int_time time_scale
15 - - - e_band - e_band
16 - - - - - -
17 trig_index trig_index trig_index - trig_index -
18 trig_id trig_id trig_id trig_id trig_id trig_id
19 misc misc misc misc misc misc
20 rec_seq_num rec_seq_num rec_seq_num - rec_seq_num -
21 - - - - - -
22 - - - - - -
23 - - - - - -
24 - - - - - -
25 temp_signif temp_signif temp_signif signif temp_signif signif
26 image_signif image_signif image_signif - image_signif -
27 - - - - - -
28 - - - - - -
29 - - - - - -
30 - - - - - -
31 1st_phot_tjd 1st_phot_tjd 1st_phot_tjd - - -
32 1st_phot_sod 1st_phot_sod 1st_phot_sod src_c0-3 - src_c0-3
33 last_ph_tjd last_ph_tjd last_ph_tjd src_c4-7 - src_c4-7
34 last_ph_sod last_ph_sod last_ph_sod src_c8-11 - src_c8-11
35 - - - src_c12-15 - src_...
36 - - - src_c16-19 - src_...
37 burst_id burst_id burst_id src_c20-23 - src_...
38 loc_qual loc_qual - src_c24-27 - src_c24-27
39 pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 126&144
Loc: FERMI_SC_SLEW
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 trig_num
5 point_tjd
6 point_sod
7 point_ra
8 point_dec
9 -
10 -
11 -
12 -
13 -
14 dwell_time
15 -
16 -
17 -
18 -
19 misc
20 -
21 -
22 -
23 -
24 -
25 -
26 -
27 -
28 -
29 -
30 -
31 -
32 -
33 -
34 -
35 -
36 -
37 -
38 -
39 pkt_term
Type: 127 128
Loc: LAT_GND LAT_OFFLINE
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 trig_num trig_num
5 burst_tjd burst_tjd
6 burst_sod burst_sod
7 burst_ra burst_ra
8 burst_dec burst_dec
9 tot_inten -
10 - -
11 burst_error burst_error
12 burst_phi -
13 burst_theta -
14 - -
15 - -
16 - -
17 - -
18 trig_id trig_id
19 misc misc
20 - -
21 - -
22 - -
23 - -
24 - -
25 - -
26 signif -
27 inten2 -
28 inten3 -
29 inten4 -
30 - -
31 - -
32 - -
33 - -
34 - -
35 - -
36 - -
37 - -
38 - -
39 pkt_term pkt_term
Type: 129
Loc: FERMI_POINTDIR
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 -
5 start_tjd
6 start_sod
7 start_ra
8 start_dec
9 delta_t
10 ra_dec_1t
11 ra_dec_2t
12 ra_dec_3t
13 ra_dec_4t
14 ra_dec_5t
15 ra_dec_6t
16 ra_dec_7t
17 ra_dec_8t
18 ra_dec_9t
19 ra_dec_10t
20 ra_dec_11t
21 ra_dec_12t
22 ra_dec_13t
23 ra_dec_14t
24 ra_dec_15t
25 ra_dec_16t
26 ra_dec_17t
27 ra_dec_18t
28 ra_dec_19t
29 ra_dec_20t
30 ra_dec_21t
31 ra_dec_22t
32 ra_dec_23t
33 ra_dec_24t
34 ra_dec_25t
35 ra_dec_26t
36 ra_dec_27t
37 ra_dec_28t
38 ra_dec_29t
39 pkt_term
Type: 130
Loc: SIMBAD/NED
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 trig_obs_num
5 trig_tjd
6 trig_sod
7 ra
8 dec
9 -
10 -
11 error
12 orig_type
13 -
14 -
15 -
16 -
17 -
18 -
19 -
20 -
21 -
22 fname_c0-3
23 fname_c4-7
24 fname_c8-11
25 fname_c12-15
26 fname_...
27 fname_...
28 fname_...
29 fname_...
30 fname_...
31 fname_...
32 fname_...
33 fname_...
34 fname_...
35 fname_...
36 fname_...
37 fname_c60-63
38 fname_c64-67
39 pkt_term
Type: 133
Loc: SWIFT_BAT_MONITOR
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 ref_num
5 tjd
6 sod
7 ra
8 dec
9 crab_flux
10 curr_flux
11 base_flux
12 signif
13 sname_c0-3
14 sname_c4-7
15 sname_c8-11
16 sname_c12-15
17 sname_c16-19
18 soln_status
19 misc
20 -
21 -
22 url_c0-3
23 url_c4-7
24 url_c8-11
25 url_c12-15
26 url_...
27 url_...
28 url_...
29 url_...
30 url_...
31 url_...
32 url_...
33 url_...
34 url_...
35 url_...
36 url_...
37 url_...
38 url_c64-67
39 pkt_term
Type: 134 135 136
Loc: MAXI_UNKNOWN_SOURCE MAXI_KNOWN_SOURCE MAXI_TEST
0 pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod
4 id_num id_num id_num
5 event_tjd src_tjd event_tjd
6 event_sod src_sod event_sod
7 event_ra src_ra event_ra
8 event_dec src_dec event_dec
9 event_flux src_flux event_flux
10 event_flux_err - -
11 event_error src_error event_error
12 - src_bkg_lo src_bkg_lo
13 - src_bkg_med src_bkg_med
14 - src_bkg_lo src_bkg_hi
15 tscale_eband tscale_eband tscale_eband
16 - lon_lat lon_lat
17 - - -
18 evt_flags evt_flags evt_flags
19 misc misc misc
20 - - -
21 - - -
22 - srcname_c0-3 -
23 - srcname_c4-7 -
24 - srcname_c8-11 -
25 - srcname_c12-15 -
26 - srcname_c16-19 -
27 - srcname_c20-23 -
28 - srcname_c24-27 -
29 - srcname_c28-31 -
30 - - -
31 - - -
32 - - -
33 - - -
34 - - -
35 - - -
36 - - -
37 - - -
38 - - -
39 pkt_term pkt_term pkt_term
Type: 137 139
Loc: OGLE MOA
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 id_num id_num
5 det_tjd det_tjd
6 det_sod det_sod
7 ra ra
8 dec dec
9 max_mag max_mag
10 curr_mag curr_mag
11 base_mag I0 base_mag
12 base_m_err base_m_err
13 max_tjd max_tjd
14 max_sod Tmax max_sod
15 max_t_err max_t_err
16 umin u0
17 umin_err u0_error
18 flags flags
19 misc misc
20 ampl_n_err ampl_n_err
21 tau tE_width
22 tau_err tE_err
23 fbl -
24 Ibl -
25 LeadTime LeadTime
26 - -
27 - -
28 - -
29 - -
30 url_c0-3 url_c0-3
31 url_c4-7 url_c4-7
32 url_c8-11 url_c8-11
33 url_... url_...
34 url_... url_...
35 url_... url_...
36 url_... url_...
37 url_... url_...
38 url_c32-35 url_c32-35
39 pkt_term pkt_term
Type: 140 141
Loc: BAT_SUB_SUB_THRESH_POS BAT_KNOWN_SRC
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 ref_num ref_num
5 evt_tjd evt_tjd
6 evt_sod evt_sod
7 evt_ra evt_ra
8 evt_dec evt_dec
9 evt_inten evt_inten
10 - -
11 evt_error evt_error
12 phi phi
13 theta theta
14 int_time int_time
15 - -
16 - -
17 - -
18 soln_status soln_status
19 misc misc
20 image_signif image_signif
21 - -
22 - -
23 - -
24 - -
25 - cat_num
26 apid apid
27 - -
28 - -
29 - -
30 - -
31 - -
32 - -
33 - -
34 - -
35 - -
36 - -
37 - -
38 - -
39 pkt_term pkt_term
Type: 145
Loc: COINCIDENCE
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 contrib1_fields
5 contrib1_trignum
6 contrib1_tjd
7 contrib1_sod
8 contrib1_ra
9 contrib1_dec
10 contrib2_fields
11 contrib2_trignum
12 contrib2_tjd
13 contrib2_sod
14 contrib2_ra
15 contrib2_dec
16 contrib3_fields
17 contrib3_trignum
18 contrib3_tjd
19 contrib3_sod
20 contrib3_ra
21 contrib3_dec
22 contrib4_fields
23 contrib4_trignum
24 contrib4_tjd
25 contrib4_sod
26 contrib4_ra
27 contrib4_dec
28 contrib5_fields
29 contrib5_trignum
30 contrib5_tjd
31 contrib5_sod
32 contrib5_ra
33 contrib5_dec
34 contrib6_fields
35 contrib7_fields
36 total_contribute
37 trigger_id
38 misc
39 pkt_term
Type: 148
Loc: SUZAKU_LC
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 -
5 trigger_tjd
6 trigger_sod
7 -
8 -
9 -
10 -
11 -
12 -
13 -
14 -
15 E_min
16 E_max
17 -
18 trig_id
19 -
20 -
21 -
22 url_c0-3
23 url_c4-7
24 url_c8-11
25 url_...
26 url_...
27 url_...
28 url_...
29 url_...
30 url_...
31 url_...
32 url_...
33 url_...
34 url_...
35 url_...
36 url_...
37 url_...
38 url_c64-67
39 pkt_term
Type: 149
Loc: SNEWS
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 trig_num
5 event_tjd
6 event_sod
7 event_ra
8 event_dec
9 event_fluence
10 -
11 event_error
12 containment
13 duration
14 -
15 -
16 -
17 -
18 trig_id
19 misc
20 -
21 -
22 -
23 -
24 -
25 -
26 -
27 -
28 -
29 -
30 -
31 -
32 -
33 -
34 -
35 -
36 -
37 -
38 -
39 pkt_term
Type: 150 151 152 153[discontinued] 154 163 164
Loc: LVC_PRELIMINARY LVC_INITIAL LVC_UPDATE LVC_TEST LVC_COUNTERPART LVC_EARLY_WARNING LVC_RETRACTION
0 pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod pkt_sod
4 id_num id_num id_num id_num id_num id_num id_num
5 trigger_tjd trigger_tjd trigger_tjd trigger_tjd trigger_tjd trigger_tjd trigger_tjd
6 trigger_sod trigger_sod trigger_sod trigger_sod trigger_sod trigger_sod trigger_sod
7 - - - - cp_ra - -
8 - - - - cp_dec - -
9 fluence fluence fluence fluence cp_inten fluence -
10 peak_freq peak_freq peak_freq peak_freq inten_uncert peak_freq -
11 far far far far pos_error far -
12 event_type event_type event_type event_type filter event_type -
13 trig_sod_usec trig_sod_usec trig_sod_usec trig_sod_usec seeing trig_sod_usec trig_sod_usec
14 duration duration duration duration obs_start_date duration -
15 - - - - obs_start_time - -
16 - - - - obs_dur - -
17 - - - - id_conf_level - -
18 trigger_ID trigger_ID trigger_ID trigger_ID trigger_ID trigger_ID trigger_ID
19 misc misc misc misc misc misc misc
20 ProbNS,Remnt ProbNS,Remnt ProbNS,Remnt ProbNS,Remnt tele_name_c0-3 ?? -
21 MassGap,Let MassGap,Let MassGap,Let Let,MassGap tele_name_c4-7 ?? -
22 ClassProb ClassProb ClassProb ClassProb tele_name_c8-11 ?? -
23 ProbInvalid ProbInvalid ProbInvalid - tele_name_c12-15 ?? -
24 - - - - name_c0-3 - -
25 - - - - name_c4-7 - -
26 - - - - name_c8-11 - -
27 - - - - name_c12-15 - -
28 - - - - name_... - -
29 url_c0-3 url_c0-3 url_c0-3 url_c0-3 name_... url_c0-3 url_c0-3
30 url_c4-7 url_c4-7 url_c4-7 url_c4-7 name_... url_c4-7 url_c4-7
31 url_c8-11 url_c8-11 url_c8-11 url_c8-11 name_... url_c8-11 url_c8-11
32 url_c12-15 url_c12-15 url_c12-15 url_c12-15 name_... urlc12-15 urlc12-15
33 url_... url_... url_... url_... name_... url... url...
34 url_... url_... url_... url_... name_... url... url...
35 url_... url_... url_... url_... name_... url... url...
36 url_... url_... url_... url_... name_... url... url...
37 url_... url_... url_... url_... name_... url... url...
38 url_c36-39 url_c36-39 url_c36-39 url_c36-39 name_c56-59 url_c36-39 url_c36-39
39 pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 157 158 159 166 169
Loc: AMON_ICECUBE_COINC AMON_ICECUBE_HESE AMON_ICECUBE_TEST AMON_ICECUBE_CLUSTER AMON_ICECUBE_EHE
0 pkt_type pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_type pkt_sod pkt_sod
4 event_num event_num event_num event_num event_num
5 trigger_tjd trigger_tjd trigger_tjd trigger_tjd trigger_tjd
6 trigger_sod trigger_sod trigger_sod trigger_sod trigger_sod
7 ra ra ra ra ra
8 dec dec dec dec dec
9 n_events n_events n_events n_events n_events
10 false_pos false_pos false_pos - -
11 pos_error90 pos_error90 pos_error_90 pos_error_50 pos_error50
12 - - - - -
13 deltaT deltaT deltaT - deltaT
14 sigmaT sigmaT sigmaT - sigmaT
15 observation - - - energy
16 stream stream stream [stream???] stream
17 rev rev rev - rev
18 trigger_ID trigger_ID trigger_ID trigger_ID trigger_ID
19 misc misc misc misc misc
20 pvalue pvalue pvalue - -
21 substream charge charge - charge
22 - signal_trackness signal_trackness signalness
23 - run_num run_num - run_num
24 pos_error50 pos_error50 pos_error50 - pos_error90(tbc)
25 - - - - -
26 - - - - -
27 - - - - -
28 - - - - -
29 - - - - -
30 - - - - -
31 - - - - -
32 - - - - -
33 - - - - -
34 - - - - -
35 - - - - -
36 - - - - -
37 - - - - -
38 - - - - -
39 pkt_term pkt_term pkt_term pkt_term pkt_term
Type: 160 161
Loc: CALET_GBM_FLT_LC CALET_GBM_GND_LC
0 pkt_type pkt_type
1 pkt_sernum pkt_ernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 id_num id_num
5 trigger_tjd trigger_tjd
6 trigger_sod trigger_sod
7 sc_boresight_ra sc_boresight_ra
8 sc_boresight_dec sc_boresight_dec
9 lc_signif lc_signif
10 fore_dur fore_dur
11 bkg_dur1 bkg_dur1
12 bkg_dur2 bkg_dur2
13 - -
14 - -
15 - -
16 lon_lat lon_lat
17 lo_e_hi_e lo_e_hi_e
18 trigger_ID trigger_ID
19 misc misc
20 - -
21 - -
22 - -
23 - -
24 - -
25 - -
26 - -
27 - -
28 - -
29 url_c0-3 url_c0-3
30 url_c4-7 url_c4-7
31 url_c8-11 url_c8-11
32 url_... url_...
33 url_... url_...
34 url_... url_...
35 url_... url_...
36 url_... url_...
37 url_... url_...
38 url_c36-39 url_c36-39
39 pkt_term pkt_term
Type: 168
Loc: GWHEN
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 id_num
5 trigger_tjd
6 trigger_sod
7 coinc_ra
8 coinc_dec
9 fluence
10 peak_freq
11 lvc_far
12 event_type
13 trig_sod_usec
14 duration
15 eta
16 chirpMass
17 MaxDistance
18 trigger_ID
19 misc
20 hen_ra
21 hen_dec
22 hen_error
23 ????_far
24 -
25 -
26 -
27 -
28 -
29 url_c0-3
30 url_c4-7
31 url_c8-11
32 url_...
33 url_...
34 url_...
35 url_...
36 url_...
37 url_...
38 url_c36-39
39 pkt_term
Type: 170 [terminatd 08sep19] 171 172 176
Loc: AMON_ANTARES_FERMILAT_COINC HAWC_BURST_MONITOR AMON_NU_EM_COINC AMON_ICECUBE_CASCADE
0 pkt_type pkt_type pkt_type pkt_type
1 pkt_sernum pkt_sernum pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod pkt_type pkt_type
4 event_num event_num event_num event_num
5 trigger_tjd trigger_tjd trigger_tjd trigger_tjd
6 trigger_sod trigger_sod trigger_sod trigger_sod
7 ra ra ra ra
8 dec dec dec dec
9 n_events - - energy
10 false_pos - - pos_error_50
11 pos_error90 pos_error68 pos_error_90 pos_error_90
12 - far far far
13 deltaT deltaT deltaT -
14 sigmaT - - -
15 observation event_id - event_id
16 stream stream stream stream
17 rev rev rev rev
18 trigger_ID trigger_ID trigger_ID trigger_ID
19 misc misc misc misc
20 pvalue pvalue pvalue -
21 substream - - -
22 - - - signalness
23 - run_num run_num run_num
24 pos_error50 - pos_error50 -
25 - - trig_sod_sub_sec -
26 - - - name[0]
27 - - - name[1]
28 - - - name[2]
29 - url_c0-3 - url_c0-3
30 - url_c4-3 - url_c4-7
31 - url_c8-11 - url_c8-11
32 - url_c12-15 - url_c12-15
33 - url_c16-19 - url_c16-19
34 - url_c20-23 - url_c20-23
35 - url_c24-27 - url_c24-27
36 - url_c28-31 event_date_c0-3 url_c28-31
37 - url_c32-35 event_date_c4-7 url_c32-35
38 - url_c36-39 event_date_c8-11 url_c36-39
39 pkt_term pkt_term pkt_term pkt_term
Type: 173 174
Loc: ICECUBE_ASTROTRACK_GOLD ICECUBE_ASTROTRACK_BRONZE
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 event_num event_num
5 trigger_tjd trigger_tjd
6 trigger_sod trigger_sod
7 ra ra
8 dec dec
9 - -
10 - -
11 pos_error90 pos_error90
12 event_id event_id
13 - -
14 - -
15 energy energy
16 stream stream
17 rev rev
18 trigger_ID trigger_ID
19 misc misc
20 far far
21 - -
22 signalness signalness
23 run_num run_num
24 pos_error50 pos_error50
25 - -
26 - -
27 - -
28 - -
29 - -
30 - -
31 - -
32 - -
33 - -
34 - -
35 - -
36 - -
37 - -
38 - -
39 pkt_term pkt_term
Type: 175
Loc: SK_SN
0 pkt_type
1 pkt_sernum
2 pkt_hopcnt
3 pkt_sod
4 event_num
5 event_tjd
6 event_sod
7 event_ra
8 event_dec
9 n_events
10 -
11 event_error68
12 -
13 distance_lo
14 distance_hi
15 event_error90
16 event_error95
17 -
18 trig_id
19 misc
20 -
21 -
22 -
23 -
24 -
25 -
26 -
27 -
28 -
29 -
30 -
31 -
32 -
33 -
34 -
35 -
36 -
37 -
38 -
39 pkt_term
Type: 188 189
Loc: GECAM_FLT GECAM_GND
0 pkt_type pkt_type
1 pkt_sernum pkt_sernum
2 pkt_hopcnt pkt_hopcnt
3 pkt_sod pkt_sod
4 event_num event_num
5 trigger_tjd trigger_tjd
6 trigger_sod trigger_sod
7 ra ra
8 dec dec
9 burst_inten burst_inten
10 error error
11 class_type class_type
12 phi phi
13 theta theta
14 burst_dur burst_dur
15 spare spare
16 sc_lat sc_lat
17 sc_lon sc_lon
18 soln_stat soln_stat (possible test_flag)
19 misc misc only 1 thing so far; mission A or B
20 trig_signif -
21 trig_dur -
22 chan_lo -
23 chan_hi -
24 energy_lo -
25 energy_hi -
26 trig_dets -
27 - -
28 - -
29 - -
30 - -
31 - -
32 - -
33 - -
34 - -
35 - -
36 - -
37 - -
38 - -
39 pkt_term pkt_term
PACKET ITEM MACROS:
Below are the C-language define's for picking out the various elements
of the array of longs that make up the packet. They have names which
reflect the contents of packet types 1, 2, and 3 (for historical reasons).
For the other types, these macros are reusable and for others their names
conote the wrong concept, so straight numerical indices are used in accessing
the packet buffer array. [For the HETE-based packets, a new set of 40 macros
was define'd (see a section towards the end of this document).]
// Indices into the socket packet array of 40 longs:
#define PKT_TYPE 0 // Packet type number
#define PKT_SERNUM 1 // Packet serial number
#define PKT_HOP_CNT 2 // Packet hop counter
#define PKT_SOD 3 // Packet Sec-Of-Day [centi-sec] (sssss.sss*100)
#define BURST_TRIG 4 // BATSE Trigger number
#define BURST_TJD 5 // Truncated Julian Day
#define BURST_SOD 6 // Sec-of-Day [centi-secs] (sssss.sss*100)
#define BURST_RA 7 // RA [centi-deg] (0.0 to 359.999 *100)
#define BURST_DEC 8 // Dec [centi-deg] (-90.0 to +90.0 *100)
#define BURST_INTEN 9 // Intensity [cnts]
#define BURST_PEAK 10 // Peak Intensity [cnts/1.024sec]
#define BURST_ERROR 11 // Location uncertainty [centi-deg]
#define SC_AZ 12 // Burst SC Az [centi-deg] (0.0 to 359.999 *100)
#define SC_EL 13 // Burst SC El [centi-deg] (-90.0 to +90.0 *100)
#define SC_X_RA 14 // SC X-axis RA [centi-deg] (0.0 to 359.999 *100)
#define SC_X_DEC 15 // SC X-axis Dec [centi-deg] (-90.0 to +90.0 *100)
#define SC_Z_RA 16 // SC Z-axis RA [centi-deg] (0.0 to 359.999 *100)
#define SC_Z_DEC 17 // SC Z-axis Dec [centi-deg] (-90.0 to +90.0 *100)
#define TRIGGER_ID 18 // Flag bits that identify the trigger type
#define MISC 19 // Misc indicator flag bits
#define E_SC_AZ 20 // Earth's center in SC Az
#define E_SC_EL 21 // Earth's center in SC El
#define SC_RADIUS 22 // Orbital radius of the GRO SC [km]
#define BURST_T_PEAK 23 // Time of Peak intensity [centi-sec] (sssss.ss*100)
#define PKT_SPARE24 24 // Beginning of spare section
#define PKT_SPARE38 38 // End of the spare section
#define PKT_TERM 39 // Packet termination character
#define SIZLBUF 40 // Number of longwords in socket packet
TYPE=1 PACKET CONTENTS:
NOTE: Type=1 packets (BATSE_Original) are NO LONGER AVAILABLE (June 2000). (since CGRO was de-orbitted).
The packet consists of 40 four-byte quantities. The order and contents
are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=1)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 burst_trig integer BATSE trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 8 burst_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 9 burst_inten [cnts] Intensity, 0 to infinity
long 10 burst_peak [cnts/1.024s] Peak Intensity, 0 to infinity
long 11 burst_error [centi-deg] (int)(0.0 to 180.0 *100)
long 12 sc_az [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 sc_el [centi-deg] (int)(-90.0 to +90.0 *100)
long 14 sc_x_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 15 sc_x_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 16 sc_z_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 17 sc_z_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 18 trigger_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 e_sc_az [centi-deg] (int)(0.0 to 359.999 *100)
long 21 e_sc_el [centi-deg] (int)(-90.0 to +90.0 *100)
long 22 sc_radius [km] SC orbital radius
long 23 t_peak [centi-sec] (int)(sssss.sss *100)
long 24 sam_used integer Num samples integrated
long 25-38 spare[14] integer 56 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS for type=1:
[0] The "pkt_type" is an integer with a value of 1, 2 or 3 that tells
which type of packet this is and therefore what the contents are (they change
between the various types). The types are: 1) Real BATSE trigger
initiated notices (GRBs, SFs, PEs, etc), 2) Test trigger notices,
3) Imalive packets. The other types (4, 11, 22, and 24-34) are discussed
in other sections below. And packet types (4-10, 12-21 and 23) never make it
to the outside world -- they are for internal GCN-use only.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet
type has its own sequential serial numbering. They all start from 1 when
the GCN programs start up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the machine of origin. Do not confuse this with the burst_sod (see below).
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[4] The "burst_trig" is the uniquely identifying serial number assigned by the
on-board BATSE flight software to each trigger. It started with SN=1 just
after launch and is currently (Jun97) in the 6000's.
[5] The "burst_tjd" is the Truncated Julian Day of the BATSE trigger,
eg. TJD=10281 is 17 Jul 96.
[6]`The "burst_sod" is the UT seconds-of-day of the BATSE trigger. This is the
spacecraft system clock UT time when the on-board software found a large
enough increase in the countrate (the 5.5-sigma threshold) in two or more
detectors in the selected energy band in any of the 3 sampling time scales
(64, 256, or 1024 msec). It is derived from the spacecraft clock which has
more accuracy, but then is truncated to 10msec level, multiplied by 100,
and converted to a 32-bit integer for the packet.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
as determined by the GCN program (current epoch). These intrinsically
floating point quantities have been multiplied by 100 and then integerized
to make an integer quantity with units of centi-degrees.
[9] The "burst_inten" is actually the integrated fluence of the trigger (burst).
For Original notices, it is just the counts in the first 1.024 or 2.048 sec
of the burst after the time when there was enough counts for GCN to
calculate a direction solution.
[10] The "burst_peak" is the maximum count rate intensity seen in the
trigger (burst). Since there are several time domains in which
the notices are sent, the peak intensity is that so far encountered
in the light curve. For type=1 it is the brightest 1-sec sample
of the 1or2 rate samples used from that Major Frame of telemetry data.
[11] The "burst_error" is the radius of the circle that will contain on average
68% of the bursts. This number is generated from an emperical comparison
to the Huntsville locations from an ensemble of past bursts.
[12-13] The "sc_az" and "sc_el" are the spacecraft coordinates of the trigger (burst)
as determined by the GCN program. The location in this coordinate system
is useful for the other 3 instruments on the GRO spacecraft (especially
the elevation angle allows the two z-axis instruments to determine if it is
in their FOVs).
[14-17] The "sc_x_ra", "sc_x_dec", "sc_z_ra", and "sc_z_dec" are the RA,Dec (J2000)
coordinates to which the spacecraft x- and z-axes point. These are the four
quantities needed to turn the spacecraft az,el directions into celestial
coordinates.
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of transient event that triggered the BATSE instrument.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 suspected_grb 0=No or 1=Yes, it is a suspected GRB
1 definite_grb 0=No or 1=Yes, it is definitely a GRB
2 near_sun 0=No or 1=Yes, the direction is near the Sun
3 soft_sf 0=No or 1=Yes, the spectrum is SF soft
4 suspected_pe 0=No or 1=Yes, it is a suspected Particle evt
5 definite_pe 0=No or 1=Yes, it is definitely a Particle evt
6 x_x_x_x_xxx spare
7 definite_unk 0=No or 1=Yes, it is definitely an Unknown
8 earthward 0=No or 1=Yes, the direction is in the Earth cone
9 soft_flag 0=No or 1=Yes, the spectrum is a little soft
10 near_saa 0=No or 1=Yes, the spacecraft location is in SAA
11 definite_saa 0=No or 1=Yes, trigger is definitely SAA related
12 suspected_sf 0=No or 1=Yes, it is a suspected Solar Flare
13 definite_sf 0=No or 1=Yes, it is definitely a Solar Flare
14 op_flag 0=No or 1=Yes, the 2 brightest dets are opposites
15 def_not_grb 0=No or 1=Yes, it is definitely not a GRB
16 iso_pe 0=No or 1=Yes, Datlowe isotropic param is low
17 iso_grb 0=No or 1=Yes, Datlowe isotropic param is high
18 neg_h_ratio 0=No or 1=Yes, the hardness ratio is negative
19 neg_iso_bc 0=No or 1=Yes, Datlowe isotropic param is negative
20 not_soft 0=No or 1=Yes, the hardness ratio is not soft
21 hi_iso_ratio 0=No or 1=Yes, Datlowe iso C3/C2 ratio is high
22 low_inten 0=No or 1=Yes, intensity too small to be a GRB
23-30 spare spare
31 bow 0=No or 1=Yes, it is a Burst OverWrite
These define's are in C-language programs for masking to get the various items
out of "trigger_id":
#define SUSP_GRB 0x00000001 // Suspected GRB
#define DEF_GRB 0x00000002 // Definitely a GRB
#define NEAR_SUN 0x00000004 // Coords are near the Sun (<15deg)
#define SOFT_SF 0x00000008 // Spectrum is soft, h_ratio > 2.0
#define SUSP_PE 0x00000010 // Suspected Particle Event
#define DEF_PE 0x00000020 // Definitely a Particle Event
#define X_X_X_X_XXX 0x00000040 // spare
#define DEF_UNK 0x00000080 // Definitely an Unknown
#define EARTHWARD 0x00000100 // Location towards Earth center
#define SOFT_FLAG 0x00000200 // Small hardness ratio (>1.5)
#define NEAR_SAA 0x00000400 // It is near/in the SAA region
#define DEF_SAA 0x00000800 // Definitely an SAA region
#define SUSP_SF 0x00001000 // Suspected Solar Flare
#define DEF_SF 0x00002000 // Definitely a Solar Flare
#define OP_FLAG 0x00004000 // Op-dets flag set
#define DEF_NOT_GRB 0x00008000 // Definitely not a GRB event
#define ISO_PE 0x00010000 // Datelowe Iso param is small (PE)
#define ISO_GRB 0x00020000 // D-Iso param is large (GRB/SF)
#define NEG_H_RATIO 0x00040000 // Negative h_ratio
#define NEG_ISO_BC 0x00080000 // Negative iso_part[1] or iso_part[2]
#define NOT_SOFT 0x00100000 // Not soft flag, GRB or PE
#define HI_ISO_RATIO 0x00200000 // Hi C3/C2 D-Iso ratio
#define LOW_INTEN 0x00400000 // Inten too small to be a real GRB
#define X_X_X_X_XX2 0x7F800000 // spare
#define BOW_FLAG 0x80000000 // Burst OverWrite trigger
[19] The "misc" field contains various bit_flags, the algorithm level, the
notice type, and the program source-code version numbers.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 tm_indicator 0=No_TM, 1=TM_present
1 bad_calc Singular matrix (bad calculation)
2 comptel_fov Position is in COMPTEL FOV
3 egret_fov Position is in EGRET FOV
4 osse_fov Position is in OSSE FOV
5-7 level Program coords calc level [1-4]
8-9 notice_type 0=Original coords notice,
1=Updates coords notice,
2=Delay coords notice,
3=Final coords notice.
10 alex_anti_sun Position is in the Anti-Solar hemisphere (ALEXIS)
11 ipn_peak Passed the IPN Peak Inten Threshold criteria
12 ipn_flue Passed the IPN Fluence Threshold criteria
13 xte_crit Passed the RXTE follow-up criteria
14 xte_type RXTE-PCA_ALERT and RXTE-PCA packet sub-types:
0=RXTE_ALERT_WILL_NOT_OBSERVE
1=RXTE_ALERT_WILL_OBSERVE
0=RXTE_OBS_SAW_NOTHING
1=RXTE_OBS_SAW_SOMETHING
15 no_trig_ind BATSE is not in a triggerable mode
16-27 ver_minor Program version, Minor number [0-2047]
28-31 ver_major Program version, Major number [1-15]
The define's for masking to get the various items out of "misc":
#define TM_IND_MASK 0x00000001 // TM Indicator mask
#define BAD_CALC_MASK 0x00000002 // Singular matrix (bad calculation)
#define C_FOV_MASK 0x00000004 // COMPTEL FOV indicator mask
#define E_FOV_MASK 0x00000008 // EGRET FOV indicator mask
#define O_FOV_MASK 0x00000010 // OSSE FOV indicator mask
#define PROG_LEV_MASK 0x000000E0 // Program Algorithm Level mask
#define NOTICE_TYPE_MASK 0x00000300 // Notification Type mask
#define A_ASD_MASK 0x00000400 // ALEXIS Anti-Solar Dir ind mask
#define IPN_PEAK_MASK 0x00000800 // Passed the IPN Peak Inten thresh
#define IPN_FLUE_MASK 0x00001000 // Passed the IPN Fluence thresh
#define XTE_CRITERIA 0x00002000 // Meets RXTE follow-up criteria
#define XTE_STATUS 0x00004000 // Won't/will obs and Didn't/did see
#define NO_TRIG_MASK 0x00008000 // BATSE is not in a triggerable mode
#define VER_MINOR_MASK 0x0FFF0000 // Program Minor Version Number mask
#define VER_MAJOR_MASK 0xF0000000 // Program Major Version Number mask
[20-21] The "e_sc_az" and "e_sc_el" are the spacecraft az,el coordinates of the
center of the Earth.
[22] The "sc_radius" is the distance of the spacecraft from the center of the Earth.
[23] The "t_peak" item is the UT seconds-of-day of the time of the peak/maximum
count rate [cnts/1.024sec] seen so far (remember there are a series of notices)
in the trigger/burst light curve. This count rate has been normalized back
to be the true planewave intensity of the burst -- not for any given detector.
[24] The "sam_used" item is the number of 1.024-sec samples of rate data
that went into the accumulation (integration). For type=1 packets it must
be either a 1 or a 2. For type=22 packets it can be a value of 1 to 32.
There are 14 "spare" items in the packet for future growth.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=2 PACKET CONTENTS:
The TEST packet consist of 40 four-byte quantities. The order and contents
are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=2)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 burst_trig integer BATSE trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 8 burst_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 9 burst_inten [cnts] Intensity, 0 to infinity
long 10 burst_peak [cnts/1.024s] Peak Intensity, 0 to infinity
long 11 burst_error [centi-deg] (int)(0.0 to 180.0 *100)
long 12 sc_az [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 sc_el [centi-deg] (int)(-90.0 to +90.0 *100)
long 14 sc_x_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 15 sc_x_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 16 sc_z_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 17 sc_z_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 18 trigger_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 e_sc_az [centi-deg] (int)(0.0 to 359.999 *100)
long 21 e_sc_el [centi-deg] (int)(-90.0 to +90.0 *100)
long 22 sc_radius [km] SC orbital radius
long 23-38 spare[16] integer 64 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS for type=2:
[0] The "pkt_type" is an integer with a value of 1, 2 or 3 that tells
which type of packet this is and therefore what the contents are (they change
between the various types). The types are: 1) Real BATSE trigger
initiated notices (GRBs, SFs, PEs, etc), 2) Test trigger notices,
3) Imalive packets. The other types (4, 11, 22, and 24-34) are discussed
in other sections below. And packet types (4-10, 12-21 and 23) never make it
to the outside world -- they are for internal GCN-use only.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet
type has its own sequential serial numbering. They all start from 1 when
the GCN programs start up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent.
Do not confuse this with the burst_sod (see below).
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[4] The "burst_trig" is the uniquely identifying serial number assigned by the
on-board BATSE flight software to each trigger. It started with SN=1 just
after launch and is currently (Jun97) in the 6000's. This is always -1
for type=2 packets.
[5] The "burst_tjd" is the Truncated Julian Day of the BATSE trigger,
eg. TJD=10281 is 17 Jul 96.
[6] The "burst_sod" is the UT seconds-of-day of the BATSE trigger. This is the
spacecraft system clock UT time when the on-board software found a large
enough increase in the countrate (the 5.5-sigma threshold) in two or more
detectors in the selected energy band in any of the 3 sampling time scales
(64, 256, or 1024 msec). It is derived from the spacecraft clock which has
more accuracy, but then is truncated to 10msec level, multiplied by 100,
and converted to a 32-bit integer for the packet.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
as determined by the GCN program (current epoch). These intrinsically
floating point quantities have been multiplied by 100 and then integerized
to make an integer quantity with units of centi-degrees.
[9] The "burst_inten" is set to 1000 cnts/sec for Test Notices.
[10] The "burst_peak" is set to 1000 cnts/sec for Test Notices.
[11] The "burst_error" is the radius of the circle that will contain on average
68% of the bursts. This number is generated from an emperical comparison
to the Huntsville locations from an ensemble of past bursts.
[12-13] The "sc_az" and "sc_el" are the spacecraft coordinates of the trigger (burst)
as determined by the GCN program. The location in this coordinate system
is useful for the other 3 instruments on the GRO spacecraft (especially
the elevation angle allows the two z-axis instruments to determine if it is
in their FOVs).
[14-17] The "sc_x_ra", "sc_x_dec", "sc_z_ra", and "sc_z_dec" are the RA,Dec (J2000)
coordinates to which the spacecraft x- and z-axes point. These are the four
quantities needed to turn the spacecraft az,el directions into celestial
coordinates.
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of transient event that triggered the BATSE instrument.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 suspected_grb 0=No or 1=Yes, it is a suspected GRB
1 definite_grb 0=No or 1=Yes, it is definitely a GRB
2 near_sun 0=No or 1=Yes, the direction is near the Sun
3 soft_sf 0=No or 1=Yes, the spectrum is SF soft
4 suspected_pe 0=No or 1=Yes, it is a suspected Particle evt
5 definite_pe 0=No or 1=Yes, it is definitely a Particle evt
6 x_x_x_x_xxx spare
7 definite_unk 0=No or 1=Yes, it is definitely an Unknown
8 earthward 0=No or 1=Yes, the direction is in the Earth cone
9 soft_flag 0=No or 1=Yes, the spectrum is a little soft
10 near_saa 0=No or 1=Yes, the spacecraft location is in SAA
11 definite_saa 0=No or 1=Yes, trigger is definitely SAA related
12 suspected_sf 0=No or 1=Yes, it is a suspected Solar Flare
13 definite_sf 0=No or 1=Yes, it is definitely a Solar Flare
14 op_flag 0=No or 1=Yes, the 2 brightest dets are opposites
15 def_not_grb 0=No or 1=Yes, it is definitely not a GRB
16 iso_pe 0=No or 1=Yes, Datlowe isotropic param is low
17 iso_grb 0=No or 1=Yes, Datlowe isotropic param is high
18 neg_h_ratio 0=No or 1=Yes, the hardness ratio is negative
19 neg_iso_bc 0=No or 1=Yes, Datlowe isotropic param is negative
20 not_soft 0=No or 1=Yes, the hardness ratio is not soft
21 hi_iso_ratio 0=No or 1=Yes, Datlowe iso C3/C2 ratio is high
22 low_inten 0=No or 1=Yes, intensity too small to be a GRB
23-30 spare spare
31 bow 0=No or 1=Yes, it is a Burst OverWrite
These define's are in C-language programs for masking to get the various items
out of "trigger_id":
#define SUSP_GRB 0x00000001 // Suspected GRB
#define DEF_GRB 0x00000002 // Definitely a GRB
#define NEAR_SUN 0x00000004 // Coords are near the Sun (<15deg)
#define SOFT_SF 0x00000008 // Spectrum is soft, h_ratio > 2.0
#define SUSP_PE 0x00000010 // Suspected Particle Event
#define DEF_PE 0x00000020 // Definitely a Particle Event
#define X_X_X_X_XXX 0x00000040 // spare
#define DEF_UNK 0x00000080 // Definitely an Unknown
#define EARTHWARD 0x00000100 // Location towards Earth center
#define SOFT_FLAG 0x00000200 // Small hardness ratio (>1.5)
#define NEAR_SAA 0x00000400 // It is near/in the SAA region
#define DEF_SAA 0x00000800 // Definitely an SAA region
#define SUSP_SF 0x00001000 // Suspected Solar Flare
#define DEF_SF 0x00002000 // Definitely a Solar Flare
#define OP_FLAG 0x00004000 // Op-dets flag set
#define DEF_NOT_GRB 0x00008000 // Definitely not a GRB event
#define ISO_PE 0x00010000 // Datelowe Iso param is small (PE)
#define ISO_GRB 0x00020000 // D-Iso param is large (GRB/SF)
#define NEG_H_RATIO 0x00040000 // Negative h_ratio
#define NEG_ISO_BC 0x00080000 // Negative iso_part[1] or iso_part[2]
#define NOT_SOFT 0x00100000 // Not soft flag, GRB or PE
#define HI_ISO_RATIO 0x00200000 // Hi C3/C2 D-Iso ratio
#define LOW_INTEN 0x00400000 // Inten too small to be a real GRB
#define X_X_X_X_XX2 0x7F800000 // spare
#define BOW_FLAG 0x80000000 // Burst OverWrite trigger
[19] The "misc" field contains various bit_flags, the algorithm level, the
notice type, and the program source-code version numbers.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 tm_indicator 0=No_TM, 1=TM_present
1 bad_calc Singular matrix (bad calculation)
2 comptel_fov Position is in COMPTEL FOV
3 egret_fov Position is in EGRET FOV
4 osse_fov Position is in OSSE FOV
5-7 level Program coords calc level [1-4]
8-9 notice_type 0=Original coords notice,
1=Updates coords notice,
2=Delay coords notice,
3=Final coords notice.
10 alex_anti_sun Position is in the Anti-Solar hemisphere (ALEXIS)
11 ipn_peak Passed the IPN Peak Inten Threshold criteria
12 ipn_flue Passed the IPN Fluence Threshold criteria
13 xte_crit Passed the RXTE follow-up criteria
14 xte_type RXTE-PCA_ALERT and RXTE-PCA packet sub-types:
0=RXTE_ALERT_WILL_NOT_OBSERVE
1=RXTE_ALERT_WILL_OBSERVE
0=RXTE_OBS_SAW_NOTHING
1=RXTE_OBS_SAW_SOMETHING
15 no_trig_ind BATSE is not in a triggerable mode
16-27 ver_minor Program version, Minor number [0-2047]
28-31 ver_major Program version, Major number [1-15]
The define's for masking to get the various items out of "misc":
#define TM_IND_MASK 0x00000001 // TM Indicator mask
#define BAD_CALC_MASK 0x00000002 // Singular matrix (bad calculation)
#define C_FOV_MASK 0x00000004 // COMPTEL FOV indicator mask
#define E_FOV_MASK 0x00000008 // EGRET FOV indicator mask
#define O_FOV_MASK 0x00000010 // OSSE FOV indicator mask
#define PROG_LEV_MASK 0x000000E0 // Program Algorithm Level mask
#define NOTICE_TYPE_MASK 0x00000300 // Notification Type mask
#define A_ASD_MASK 0x00000400 // ALEXIS Anti-Solar Dir ind mask
#define IPN_PEAK_MASK 0x00000800 // Passed the IPN Peak Inten thresh
#define IPN_FLUE_MASK 0x00001000 // Passed the IPN Fluence thresh
#define XTE_CRITERIA 0x00002000 // Meets RXTE follow-up criteria
#define XTE_STATUS 0x00004000 // Won't/will obs and Didn't/did see
#define NO_TRIG_MASK 0x00008000 // BATSE is not in a triggerable mode
#define VER_MINOR_MASK 0x0FFF0000 // Program Minor Version Number mask
#define VER_MAJOR_MASK 0xF0000000 // Program Major Version Number mask
[20-21] The "e_sc_az" and "e_sc_el" are the spacecraft az,el coordinates of the
center of the Earth.
[22] The "sc_radius" is the distance of the spacecraft from the center of the Earth.
There are 16 "spare" items in the packet for future growth.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=3 PACKET CONTENTS:
The IMALIVE packet consists of 40 four-byte quantities. The order and contents
are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=3)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for the future
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7-38 spare[32] integer 128 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS for type=3:
[0] The "pkt_type" is an integer with a value of 1, 2 or 3 that tells
which type of packet this is and therefore what the contents are (they change
between the various types). The types are: 1) Real BATSE trigger
initiated notices (GRBs, SFs, PEs, etc), 2) Test trigger notices,
3) Imalive packets. The other types (4, 11, 22, and 24-34) are discussed
in other sections below. And packet types (4-10, 12-21 and 23) never make it
to the outside world -- they are for internal GCN-use only.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet
type has its own sequential serial numbering. They all start from 1 when
the GCN programs start up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[5] The "burst_tjd" is the Truncated Julian Day when this packet was formed.
eg. TJD=10281 is 17 Jul 96. Since this is an "imalive" packet, the "burst"
aspect of this is meaningless. It is filled because the filtering code
needs to have this field to work for all packet types.
[6] The "burst_sod" is the UT seconds-of-day when this packet was formed.
It is identical in value to the "pkt_sod" field.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). Since this is an "imalive" packet, the "burst" aspect
of this is meaningless. It is filled because the filtering code needs to have
this field to work for all packet types.
There are 32 "spare" items in the packet for future growth.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=4 PACKET CONTENTS:
The KILL packet consists of 40 four-byte quantities. It is used to send a
signal the site-end of the socket connection that GCN is going to close
the connection immediately (within milliseconds). This is the only socket
packet that is never echo-ed back to the GCN system. The order and contents
are listed in the table below. They have the same function, meaning, and
content as the items of the same name in the previous packet types (1-3).
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=4)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for the future
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7-38 spare[32] integer 128 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
The "burst_tjd" and "burst"sod" are in this "KILL" packet
because there are one or two places within the GCN codes
that like to have TJD, so this was a convenient place to put it.
They are not for a "burst" but rather are for the "pkt" formation date/time.
TYPE=11 PACKET CONTENTS:
NOTE: This Type=11 (BATSE_MAXBC) is NO LONGER AVAILABLE (June 2000).
The MAXBC packet consists of 40 four-byte quantities. The order and contents
are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=11)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 burst_trig integer BATSE trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 8 burst_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 9 burst_inten [cnts] Linear scale, 0 to infinity
long 10 burst_peak [cnts/1.024s] Linear scale, 0 to infinity
long 11 burst_error [centi-deg] (int)(0.0 to 180.0 *100)
long 12 sc_az [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 sc_el [centi-deg] (int)(-90.0 to +90.0 *100)
long 14 sc_x_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 15 sc_x_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 16 sc_z_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 17 sc_z_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 18 trigger_id integer Trigger identification flags
long 19 misc integer Misc stuff packed in here
long 20 e_sc_az [centi-deg] (int)(0.0 to 359.999 *100)
long 21 e_sc_el [centi-deg] (int)(-90.0 to +90.0 *100)
long 22 sc_radius [km] SC orbital radius
long 23 maxc1[0] [cnts/64mSec] Linear scale, 0 to infinity
long 24 maxc1[1] [cnts/64mSec] Linear scale, 0 to infinity
long 25 maxc1[2] [cnts/64mSec] Linear scale, 0 to infinity
long 26 maxc1[3] [cnts/64mSec] Linear scale, 0 to infinity
long 27 maxc1[4] [cnts/64mSec] Linear scale, 0 to infinity
long 28 maxc1[5] [cnts/64mSec] Linear scale, 0 to infinity
long 29 maxc1[6] [cnts/64mSec] Linear scale, 0 to infinity
long 30 maxc1[7] [cnts/64mSec] Linear scale, 0 to infinity
long 31 maxbc[0] [cnts/64mSec] Linear scale, 0 to infinity
long 32 maxbc[1] [cnts/64mSec] Linear scale, 0 to infinity
long 33 maxbc[2] [cnts/64mSec] Linear scale, 0 to infinity
long 34 maxbc[3] [cnts/64mSec] Linear scale, 0 to infinity
long 35 maxbc[4] [cnts/64mSec] Linear scale, 0 to infinity
long 36 maxbc[5] [cnts/64mSec] Linear scale, 0 to infinity
long 37 maxbc[6] [cnts/64mSec] Linear scale, 0 to infinity
long 38 maxbc[7] [cnts/64mSec] Linear scale, 0 to infinity
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=11):
The 8 "maxc1[i]" and the 8 "maxbc[i]" are the 16 maximum (bkg subtracted) rates
[cnts/64mSec] as determined by the BATSE flight software during the 0-10
minutes after the initial trigger. The index "i" runs from 0 to 7 for the 8
LADs. The "c1" refers to the C1 DISCLA channel (~20-50 keV). The "bc" refers
to the "burst channels" which is most of the time set to the two middle
DISCLA channels (50-100-300 keV).
TYPE=21 PACKET CONTENTS/DESCRIPTION:
NOTE: This Type=11 (Bradford) is NO LONGER AVAILABLE (June 2000)
The format and content of this BRAD_COORDS packet is identical to the
Test Coords packet (type=2). The only difference is that the values
for the test RA,Dec locations are different than the set used for type=2.
The Bradford telescope system needed a different set of locations than
the generic set, so a separate packet type was defined and this different type
allowed the necessary filtering differences between the Bradford site
and the rest of the GCN sites.
TYPE=22 PACKET CONTENTS/DESCRIPTION:
NOTE: This Type=22 (BATSE_Final) is NO LONGER AVAILABLE (June 2000)
The format and content of this FINAL packet is identical to the ORIGINAL
(type=1) with the one exception: that the "inten" is now a fluence value
for the number of "sam_used" values that went into the integration
of the burst light curve.
TYPE=24 PACKET CONTENTS/DESCRIPTION:
NOTE: This Type=24 (BATSE_LOCBURST) is NO LONGER AVAILABLE (June 2000).
The format and content of this LOCBURST packet is identical to the
GRB Coords packet (type=1). The major difference is that the values
of the RA,Dec location are calculated using the LOCBURST algorithm
instead of the ideal-physics and are, therefore, more accurate.
The "t_peak" value at location index=23 is undefined for this packet type.
TYPE=25 PACKET CONTENTS:
NOTE: This Type=25 (ALEXIS) is NO LONGER AVAILABLE (December 1999).
The ALEXIS packet consists of 40 four-byte quantities. The order and contents
are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=25)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 src_num integer ALEXIS source number
long 5 trans_tjd [days] Truncated Julian Day
long 6 trans_sod [centi-sec] (int)(sssss.sss *100)
long 7 trans_ra [centi-deg] (int)(0.0 to 359.9999 *100)
long 8 trans_dec [centi-deg] (int)(-90.0 to +90.0 *100)
long 9-10 spare[2] integer Unused at this point
long 11 trans_error [centi-deg] (int)(0.0 to 180.0 *100)
long 12-22 spare[11] integer Unused at this point
long 22 trans_alpha integer (int)(alpha *100)
long 23 map_dur integer Always 12, 24, or 48
long 24 tele_id integer Always 1, 2, 3, 4, 5, or 6
long 25-38 spare[14] integer 56 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=25):
Only the packet items that are different than the type=1,2,3 packet contents
are listed below. The standard packet items are described and defined
in the above sections.
[4] The "src_num" is the uniquely identifying number assigned by the ground
ALEXIS data processing software to each identified source. It starts with 1
for each processing run and progresses upwards (typically 0-20 sources
are identified each 12-hr run).
[5] The "trans_tjd" is the Truncated Julian Day of the ALEXIS source,
eg. TJD=10281 is 17 Jul 96. It is the TJD of the ending date/time stamp
of the map accumulation in which the transient was found.
[6] The "trans_sod" is the UT seconds-of-day of the ALEXIS source. It is the
SOD of the ending date/time stamp of the map accumulation in which the
transient was found. While the units are centi-seconds, the value is always
a whole second. The use of centi-seconds maintains the format/precission
that is used throughout all the packets.
[7-8] The "trans_ra" and "trans_dec" are the RA,Dec coordinates of the transient
as determined by the ALEXIS batch processing analysis program (current epoch).
The units are centi-degrees.
[11] The "trans_error" is the 3-sigma radius of the error circle. It contains
the sum of the statistical and systematic errors. This number is derived
from a comparison of the known location of the HZ 43 object and the
instrument's determination.
[22] The "trans_alpha" is the -log10(probability_of_false_detection). The alpha
parameter is only the statistical significance of the detection, or put another
way, -log10 of the probability that the source could be a natural fluctuation
above a Poisson background.
[23] The "map_duration" is the amount of data (the last 12, 24, or 48 hours)
that went into the accumulation that the transient was found. The ALEXIS
processing uses three different time scales as a tradeoff between transient
duration and sensitivity. This integer has only the 12, 24, or 48 numeric
values -- all other values are invalid.
[24] The "tele_id" is the telescope that the transient was detected in. This is
an integer with only 1 through 6 as the valid values for the six detectors.
The telescope names and energy bandpasses are: 1="1A 93eV", 2="1B 70eV",
3="2A 93eV", 4="2B 66eV", 5="3A 70eV", 6="3B 66eV". (Telescopes 1 and 2
are co-aligned on ALEXIS, as are telescopes 3 and 4, and telescopes 5 and 6.)
TYPE=26 PACKET CONTENTS:
NOTE: Type=26 packets (RXTE_PCA_ALERT) are NO LONGER AVAILABLE.
The RXTE-PCA_ALERT packet consist of 40 four-byte quantities. The order and
contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=26)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 burst_trig integer BATSE trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 locburst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 locburst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9-18 spare[10] integer 40 bytes for the future
long 19 misc integer Misc stuff packed in here
long 20-23 spare[4] integer 16 bytes for the future
long 24 obs_tjd integer Observation start TJD
long 25 obs_sod integer (int)(sssss.ss *100)
long 26-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=26):
For the type=26 (PCA ALERT) packets, the normal burst_ra/_dec locations
contain the LOCBURST RA/Dec location. This allows the potential follow-up
observer to make tentative observing plans based approximate LOCBURST location
on the sky.
The "misc" field contains various bit_flags (see the section for types=1,2,3
for the definition of all the normal bits), and for the specialty bits
for type=26 (see the partial table below):
Bit_Number Item_name Description
---------- --------- -----------
13 xte_crit Passed the RXTE-PCA follow-up criteria
14 xte_type RXTE-PCA_ALERT packet sub-types:
0=RXTE_ALERT_WILL_NOT_OBSERVE
1=RXTE_ALERT_WILL_OBSERVE
The define's for masking to get the various items out of "misc":
#define XTE_CRITERIA 0x00002000 // Meets RXTE-PCA follow-up criteria
#define XTE_STATUS 0x00004000 // Won't/will observe
The "obs_tjd" and "obs_sod" fields are the Truncated Julian Day and
Seconds-of_day for the start of the RXTE-PCA observation. Putting this
timestamp in the ALERT notice allows the follow-up observer to know
when the RXTE-PCA observation is planned and about when the RXTE-PCA coordinates
will become available.
TYPE=27 PACKET CONTENTS:
The RXTE-PCA GRB coordinates packet consist of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=27)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 burst_trig integer BATSE trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [mCrab] Linear scale, 0 to infinity
long 10 spare integer spare
long 11 burst_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12-18 spare[7] integer 28 bytes for the future
long 19 misc integer Misc stuff packed in here
long 20-23 spare[4] integer 16 bytes for the future
long 24 obs_tjd integer Observation start TJD
long 25 obs_sod integer (int)(sssss.ss *100)
long 26-28 spare[13] integer 42 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=27):
The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst
(current epoch). These intrinsically floating point quantities have been
multiplied by 10000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
The "burst_inten" is slightly different than the burst_inten used in type=1.
It is units of mCrab (instead of the counts/sec).
The "misc" field contains various bit_flags (see the section for types=1,2,3
for the definition of all the normal bits), and for the specialty bits
for type=27 (see the partial table below):
Bit_Number Item_name Description
---------- --------- -----------
13 xte_crit Passed the RXTE-PCA follow-up criteria
14 xte_type RXTE-PCA packet sub-types:
0=RXTE_OBS_SAW_NOTHING
1=RXTE_OBS_SAW_SOMETHING
The define's for masking to get the various items out of "misc":
#define XTE_CRITERIA 0x00002000 // Meets RXTE-PCA follow-up criteria
#define XTE_STATUS 0x00004000 // Didn't/did see a source
The "obs_tjd" and "obs_sod" fields are the Truncated Julian Day and
Seconds-of_day when the observation started.
TYPE=28 PACKET CONTENTS:
The packet for the RXTE-ASM ALERT notice has not been finalized yet.
TYPE=29 PACKET CONTENTS:
The RXTE-ASM GRB coordinates packet consist of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=29)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 burst_trig integer BATSE trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [mCrab] Linear scale, 0 to infinity
long 10 spare integer spare
long 11 burst_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12 burst_cont [10^-2] (int)(0.0 to 100.0 *100)
long 13-18 spare[6] integer 24 bytes for the future
long 19 misc integer Misc stuff packed in here
long 20-23 spare[4] integer 16 bytes for the future
long 24 err_ra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 25 err_dec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 26 err_ra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 27 err_dec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 28 err_ra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 29 err_dec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 30 err_ra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 31 err_dec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 32 length [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 33 width [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 34 pos_angle [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 35-38 spare[4] integer 16 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=29):
The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst
(current epoch). These intrinsically floating point quantities have been
multiplied by 10000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
The "burst_inten" is slightly different than the burst_inten used in type=1.
It is units of mCrab (instead of the counts/sec).
The "misc" field contains various bit_flags (see the section for type=1,2,3
for the definition of all the normal bits), and for the specialty bits
for type=32 (see the partial table below):
Bit_Number Item_name Description
---------- --------- -----------
8-9 notice_type 0=Initial coords notice,
1=Updates coords notice,
3=Final coords notice.
14 box_v_line RXTE-ASM error box sub-types:
0=line
1=box
The define's for masking to get the various items out of "misc":
#define NOTICE_TYPE_MASK 0x00000300 // Notification Type mask
The "burst_error" is the radius of a circle which circumscribes the error
box (diamond-shaped). It is decimal degrees and is for the "burst_cont"
containment (statistical + systematic).
The "burst_cont" is the confidence containment percentage for the quoted
burst_error value. It is stored in the packet in centi-percentage
(e.g. 98.5% would be an integer value of 9850).
The "err_ra1" and "err_dec1" are the RA,Dec coordinates for the 1st corner
of the error box. Ditto for "2", "3", and "4" for the second, third, and
fourth corners, respectively. (These fields are valid when the error box
is type "box".) Note that these RA,Dec values are J2000 epoch, whereas the
RA,Dec of the center of the box is in Current epoch. The use of different
epochs is, admittedly, ugly, but is due to historical/evolutionary aspects
that are way too lengthy and of little practical importance to explain here.
The "length" is the length of the error box when the error box is type "line".
The "width" is the width of the error box when the error box is type "line".
The "pos_angle" is the position angle of the error box when the error box
is type "line". It is measured eastward from north.
================================================================================
TYPE=30 PACKET CONTENTS:
NOTE: Type=30 (COMPTEL) is NO LONGER AVAILABLE (June 2000). (since CGRO was de-orbitted).
{Note that the RA,Dec of the center are in J2000 epoch, and not
in the rest-of-the-program standard Current epoch. The corners
of the error box are in the J2000 epoch.}
================================================================================
TYPE=31 PACKET CONTENTS:
The IPN_RAW packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=31)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Mission-specific ID number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 ipn_cntr_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 ipn_cntr_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 ipn_radius [0.0001-deg] Radius of the annulus
long 10 ipn_t_win [centi-sec] Earth-center time range (*100)
long 11 ipn_width [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-13 spare[2] integers 8 bytes for the future
long 14 event_dur [centi-sec] Duration of the event (*100)
long 15-17 spare[3] integers 12 bytes for the future
long 18 trig_id bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 scratch integer Scratch/internal use
long 21 scratch integer Scratch/internal use
quad_char 22-38 url[17] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 31
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num is some mission-specific identification number. It is optional;
not all misions-instruments have an identification number.
[5] The "burst_tjd" is the Truncated Julian Day of the burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "ipn_center_ra" and "ipn_center_dec" are the RA,Dec coordinates of the center
of the IPN annulus (J2000). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make an integer quantity
with units of 0.0001-degrees. This field is valid only if the "trigger_id"
2^0 bit is a 0 (ie the 'annulus' form of this notice type).
[9] The "ipn_radius" is the radius to the center of the IPN annulus.
The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). This field is valid only if the "trigger_id"
2^0 bit is a 0 (ie the 'annulus' form of this notice type).
[10] The "ipn_t_window" is the amount of time slop that the Timestamp could vary
depending on the direction of the burst wavefront (eg for a LEO s/c, this
would be +-0.022 sec, and for Mars Observer, it would range from +/-250 sec
to +/-1250 sec depending on the relative positions of Mars and Earth).
The units are 0.01-sec (ie the fl.pt. time duration was multiplied
by 100 and then integerized).
[11] The "ipn_width" is the 3-sigma width of the IPN annulus.
The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). This field is valid only if the "trigger_id"
2^0 bit is a 0 (ie the 'annulus' form of this notice type).
[14] The "event_duration" is the duration of the event in the specified instrument
(see Misc flag bits). (Note that the different mission-instruments have
different sensitivities and energy windows, so for a given GRB, there will be
variations in this value from one instrument to the next.)
The units are 0.01-sec (ie the fl.pt. time duration was multiplied
by 100 and then integerized).
[18] The "trig_id" field contains flag bits on the content and expectation
of this event being a burst or not.
The bit packing of the "trig_id" entry in the packet is:
BitNum Item_name Description
------ --------- -----------
0 times_only 0=No or 1=Yes, this packet contains only the times (trig,window,duration; no ra,dec,err)
//1 not_operational Instrument not able to take data at that time (PwrOff, Cal_mode, SAA)
//2 grb 0=No or 1=Yes, it is definitely a GRB
//3 prob_grb 0=No or 1=Yes, it is probably a GRB
//4 poss_grb 0=No or 1=Yes, it is possibly a GRB
//5 def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
//6 nothing_found if 1, it indicates no "blip" was found in the corresponding time_window
//7-8 ecliptic 0=Unknown, 1=North hemisphere, 2=South hemisphere, 3=Middle_band (less than X deg)
9 trig_time_only 0=No or 1=Yes, this packet contains only the trigger_time (no t_window, t_duration))
10-28 spare spare for future use
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 spare spare for future use
//Bits with a "//" prefix are no longer available (post Sep 2009).
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
//2^0 When this bit is a 1, it indicates that no further information will be available on this event.
//2^1 When this bit is a 1, it indicates that further information will probably be available on this event.
//2^2 When this bit is a 1, it indicates that further information will definitely be available on this event.
//2^3 This is an updated notice. This is a notice that changes/improves
// the information specified in the original Notice.
2^4-9 Not assigned.
2^10 The Ulysses mission contributed to this Notice.
2^11 The Mars Odyssey-HEND instrument contributed to this Notice.
2^12 The Mars Odyssey-GRS instrument contributed to this Notice.
2^13 The RHESSI mission contributed to this Notice.
2^14 The KONUS-Wind instrument contributed to this Notice.
2^15 The Swift-BAT instrument contributed to this Notice.
2^16 The Messenger-GRNS instrument contributed to this Notice.
2^17 The Suzaku-WAM instrument contributed to this Notice.
2^18 The INTEGRAL-SPIACS instrument contributed to this Notice.
2^19 The SuperAGILE instrument contributed to this Notice.
2^20 The AGILE-GRID instrument contributed to this Notice.
2^21 The AGILE-MCAL instrument contributed to this Notice.
2^22 The FERMI-GBM instrument contributed to this Notice.
2^23 The FERMI-LAT instrument contributed to this Notice.
2^24-31 Not assigned.
[20-21] The "scratch" fields are for use internal to GCN (to communicate
the name of the temporary comments files during importation)
and the mission/instrument ID.
It has no value to the outside world and should be ignored.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/XXXXXXX". //DECIDE ON THIS !!!!
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 5 "spare" items in the packet (usually filled
with zeros). They are located at items 12-13 and 15-17.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=32 PACKET CONTENTS:
NOTE: Type=32 (IPN_SEGMENT) is no longer available (since it part of the
input to this type was the BATSE position).
NOTE: It might become available again now that FERMI-GBM error circles are available.
The IPN_SEGMENT packet consists of 40 four-byte quantities. The order and
contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=32)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 burst_trig integer BATSE trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 ipn_c_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 ipn_c_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 ipn_radius [10^-4-deg] (int)(0.0 to +90.0 *10000)
long 10 spare integer 4 bytes for the future
long 11 ipn_width [10^-4-deg] (int)(0.0 to +90.0 *10000)
long 12 3sig_ra [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 13 3sig_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 14 2sig_ra [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 15 2sig_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 16 1sig_ra [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 17 1sig_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 18 max_prob_ra [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 19 max_prob_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 10 1sig_ra [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 21 1sig_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 22 2sig_ra [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 23 2sig_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 24 3sig_ra [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 25 3sig_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 26-38 spare[13] integer 52 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=32):
[7-8] The "ipn_c_ra" and "ipn_c_dec" are the RA,Dec coordinates of the center of
the IPN annulus. They are in J2000 epoch. The units are 0.0001-degrees.
It was necessary to use a scaling factor (1000x) bigger than the normal 100x
(ie centi-degrees) because the intrinsic accuracy and precision of the
IPN coordinates is much better.
[9] The "ipn_radius" and "ipn_width" are the radius and the width of the IPN
annulus. Full width which contains all the known statistical and
systematic errors (ie greater than 90% confidence). The units are
0.0001-degrees.
[12-13] The "3sig_ra" and "3sig__dec" are the RA,Dec coordinates of the point along
the annulus at which the 3-sigma probability is located. There are
two such locations (one on each side of the maximum probability location.
They are in J2000 epoch. The units are 0.0001-degrees.
[14-17] Similarly for the "2sig_ra", "2sig_dec", "1sig_ra", and "1sig_dec".
[18-19] The "max_prob_ra" and "max_prob_dec" are the RA,Dec coordinates of the
location on the IPN annulus which the has the maximum probability of being
the location of the GRB. They are in J2000 epoch. The units are
0.0001-degrees.
================================================================================
TYPE=33 PACKET CONTENTS:
The packet for the SAX-WFC ALERT notice has not been finalized yet.
[03feb01: It probably never will be finalized. There seems to be
no interest from the community to have/use this Notice type, and
there seems to be no interest amongst the SAX team to generate it.]
TYPE=34 PACKET CONTENTS:
NOTE: Type=34 (SAX_WFC) is no longer available (since BeppoSAX mission was terminated).
The SAX-WFC GRB Position packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=34)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for the future
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [mCrab] Linear scale, 0 to infinity
long 10 spare integer 4 bytes for the future
long 11 burst_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12 burst_cont [centi-%] (int)(0.0 to 100.0 *100)
long 13-17 spare[5] integer 20 bytes for the future
long 18 trigger_id integer Trigger identification flags
long 19 misc integer Misc stuff packed in here
long 20-38 spare[19] integer 56 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=34):
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst
(current epoch). These intrinsically floating point quantities have been
multiplied by 10000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
[9] The "burst_inten" is slightly different than the burst_inten used in type=1.
It is units of mCrab (instead of the counts/sec).
[12] The "burst_cont" is the confidence containment percentage for the quoted
burst_error value. It is stored in the packet in centi-percentage
(e.g. 98.5% would be an integer value of 9850).
TYPE=35 PACKET CONTENTS:
The packet for the SAX-NFI ALERT notice has not been finalized yet.
[03feb01: It probably never will be finalized. There seems to be
no interest from the community to have/use this Notice type, and
there seems to be no interest amongst the SAX team to generate it.]
TYPE=36 PACKET CONTENTS:
NOTE: Type=36 (SAX_NFI) is no longer available (since BeppoSAX mission was terminated).
The SAX-NFI GRB Position packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=36)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for the future
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [mCrab] Linear scale, 0 to infinity
long 10 spare integer 4 bytes for the future
long 11 burst_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12 burst_cont [centi-%] (int)(0.0 to 100.0 *100)
long 13-17 spare[5] integer 20 bytes for the future
long 18 trigger_id integer Trigger identification flags
long 19 misc integer Misc stuff packed in here
long 20-38 spare[19] integer 56 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=36):
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst
(current epoch). These intrinsically floating point quantities have been
multiplied by 10000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
[9] The "burst_inten" is slightly different than the burst_inten used in type=1.
It is units of mCrab (instead of the counts/sec).
[12] The "burst_cont" is the confidence containment percentage for the quoted
burst_error value. It is stored in the packet in centi-percentage
(e.g. 98.5% would be an integer value of 9850).
================================================================================
TYPE=37 PACKET CONTENTS:
NOTE: Type=37 packets (RXTE_ASM_XTRANS) are NO LONGER AVAILABLE.
The RXTE-ASM_XTRANS Position packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=37)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer The serial number of trans
long 5 trans_tjd [days] Truncated Julian Day
long 6 trans_sod [centi-sec] (int)(sssss.sss *100)
long 7 trans_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 trans_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 trans_inten [mCrab] Linear scale, 0 to infinity
long 10 spare integer 4 bytes for the future
long 11 trans_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12 spare integer 4 bytes for the future
long 13 time_since [centi-sec] (int)(sssss.sss *100)
long 14-17 spare[4] integer 16 bytes for the future
long 18 trigger_id integer Trigger identification flags
long 19 misc integer Misc stuff packed in here
long 24 ra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 25 dec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 26 ra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 27 dec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 28 ra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 29 dec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 30 ra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 31 dec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 32 line_length [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 33 line_width [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 34 pos_angle [10^-4-deg] (int)(0.0 to 360.0 *10000)
long 35-38 spare[4] integer 16 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=37):
[7-8] The "trans_ra" and "trans_dec" are the RA,Dec coordinates of the transient
(current epoch). These intrinsically floating point quantities have been
multiplied by 10000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
[9] The "trans_inten" is slightly different than the burst_inten used in type=1.
It is units of mCrab (instead of the counts/sec).
[11] The "trans_error" is the radius of a circle which circumscribes the error
box (diamond-shaped).
[19] The "misc" field contains various bit_flags (see the section for type=1,2,3
for the definition of all the normal bits), and for the specialty bits
for type=37 (see the partial table below):
Bit_Number Item_name Description
---------- --------- -----------
8-9 notice_type 0=Initial coords notice,
1=Updates coords notice,
3=Final coords notice.
14 box_v_line RXTE-ASM error box sub-types:
0=line
1=box
The define's for masking to get the various items out of "misc":
#define NOTICE_TYPE_MASK 0x00000300 // Notification Type mask
[24-31] The "ra1" and "dec1" are the RA,Dec coordinates for the 1st corner of the
error box. Ditto for "2", "3", and "4" for the second, third, and
fourth corners, respectively. (These fields are valid when the error box
is type "box".) Note that these RA,Dec values are J2000 epoch, whereas the
RA,Dec of the center of the box is in Current epoch. The use of different
epochs is, admittedly, ugly, but is due to historical/evolutionary aspects
that are way too lengthy and of little practical importance to explain here.
[32] The "line_length" is the length of the error box when the error box
is type "line" (this and the next two fields are ONLY assigned when
the type is "line").
[33] The "line_width" is the width of the error box when the error box
is type "line".
[34] The "pos_angle" is the position angle of the error box when the error box
is type "line". It is measured eastward from north.
================================================================================
TYPE=38 PACKET CONTENTS:
This type=38 is a "spare" packet. It is used for development testing
within the GCN as each new "source" packet is brought online. It's contents
and format change with each new source. (The epoch is Current; not J2000.)
This packet type should never be distributed to the GCN sites.
================================================================================
TYPE=39 PACKET CONTENTS:
The IPN_POSITION packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=39)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer The serial number of trans
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flue [10^-9erg/cm2] Linear scale, 0 to infinity
long 10 burst_flux [10^-9erg/cm2/s]Linear scale, 0 to infinity
long 11 burst_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12 samp_interval[10^-4-sec] (int)(0.0 to infinity)
long 13-15 spare[3] integer 16 bytes for the future
long 16 burst2_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 17 burst2_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 18 trig_id bits Trigger identification flags
long 19 misc integer Misc stuff packed in here
long 20 spare integer 4 bytes for the future
long 21 box_area [10^-4-sq.arcmin](int)(0.0 to X.X *10000)
long 22 duration [centi-sec] (int)(sssss.sss *100)
long 23 ra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 24 dec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 25 ra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 26 dec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 27 ra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 28 dec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 29 ra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 30 dec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 31 ra21 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 32 dec21 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 33 ra22 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 34 dec22 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 35 ra22 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 36 dec23 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 37 ra23 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 38 dec24 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 39, which tells that this packet
is of type IPN_POSITION and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "refnum" is a serial number assigned by K.Hurley (UCBerkeley, IPN).
It is used for referencing/citation purposes. It is sequential for the
Notices -- not the GRBs -- hence two Notices on a single GRB will have
different serial numbers (eg an initial notice and a refined-calculation notice
would have different refnum's).
[5] The "burst_tjd" is the Truncated Julian Day of the burst,
eg. TJD=12275 is 01 Jan 2002.
[6] The "burst_sod" is the time of earth-crossing for the burst
as determined by the Interplanetary Network of spacecraft.
The SOD is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689568 = 46895.68 sec-of-day =
13:01:35.68 UT.
[7-8] The "burst_ra" and "burst_dec" fields specify the RA,Dec location of the calculated
burst position (in Current epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "burst_flue" is the burst fluence in units of 10^-9 erg/cm2.
This is not always known for the burst at the time of the issuance
of the Notice, in which case it will have a value of -1.
[10] The "burst_flux" is the burst fluence in units of 10^-9 erg/cm2/sec.
This is not always known for the burst at the time of the issuance
of the Notice, in which case it will have a value of -1.
[11] The "burst_error" is the radius of a circle which circumscribes
the error box (rectangular-or-diamond-shaped). The units are decimal degrees
times 10,000.0. This radius represents the worst case error distance
(ie the distance from the center to the farthest corner).
[12] The "sampling_interval" is the interval of time during which the peak flux
was observed (ie the integration interval while scanning for the maximum
flux value).
[16-17] The "burst2_ra" and "burst2_dec" values (Current epoch!) is the center of the 2nd IPN box
(if the Notice is a 2-box subtype).
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of burst event.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 x_x_x_x spare
1 definite_grb 0=No or 1=Yes, it is definitely a GRB
2-27 x_x_x_x spare
28 spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 x_x_x_x spare
[19] In the "misc" word, the 2^5-6 bits are used to indicate the Notice subtype:
a 00 is a 1-box subtype, and a 01 is a 2-box subtype. For subtype=0 (1-box),
the various 2nd-box items in the packet format are filled with zeros (ie the
center and the 4 corners).
[21] The "box_area" is the area of the error box in units of 0.0001 sq.arcminutes.
If the Notice is a 2-box notice, then the area of the 2nd box is always
the same as the first box.
[22] The "duration" is the T90 duration of the burst in units of centi-seconds.
This is not always known for the burst at the time of the issuance
of the Notice, in which case it will have a value of -1.
[23-38] The "ra1" and "dec1" are the RA,Dec coordinates (J2000!) for the 1st corner of the
error box. Ditto for "2", "3", and "4" for the second, third, and
fourth corners, respectively.
The "ra21" and "dec21" are the RA,Dec coordinates (J2000!) for the 1st corner of the
second box (if the Notice is a 2-box subtype). Ditto for the 2nd, 3rd, and 4th corners.
There are a total of tbd "spare" items in the packet (usually filled
with zeros). They are located at items 13-15, and 20.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=40 PACKET CONTENTS:
NOTE: Type=40 packets (HETE_S/C_ALERT) are NO LONGER AVAILABLE.
The HETE_S/C_ALERT packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=40)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_seq_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7-8 spare[2] integer Mostly empty in Alert packets
long 9 trig_flags bits Trigger type ID flag bits
long 10 gamma_cnts [cnts/sec] GammaDet count rate
long 11 wxm_signoise [centi-sig/nois]WXM rate trigger signal/noise
long 12 sxc_cnts [cnts/sec] SXC count rate
long 13 gamma_time [milli-sec] GammaDet timescale
long 14 wxm_time [milli-sec] WXM det timescale
long 15 sc_point integers S/c RA,Dec pointing dir
long 16-38 spare[23] integer 92 bytes not filled (zeros)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 40, 41, 42, 43, or 44
that tells which type of packet this is and therefore what the contents are
(they change slightly between the various types). The types are:
40 = HETE_S/C_ALERT, 41 = HETE_S/C_UPDATE, 42 = HETE_S/C_LAST,
43 = HETE_GNDANA, and 44 = HETE_Test.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_seq_num" contains two separate items: a) the "trigger number"
and b) the "message sequence number". The trigger number is assigned
by the HETE flight software for each new triggering event. The message
sequence number is a serial number across all 4 message subtypes (S/C_Alert,
S/C_Update, S/C_Last, and GndAna). The S/C_Alert always has a sequence number of 1,
then there can be one or more S/C_Update messages for a given trigger (2,3,...,N),
then one S/C_Last (seq_num=N+1), and then one GndAnalysis message (seq_num=N+2).
The two parts of the trig_seq_num word can be extracted using these masks:
#define TRIGNUM_MASK 0x0000FFFF // Trigger number
#define SEQNUM_MASK 0xFFFF0000 // Mesg Seq Num, then downshift 16 bits
[5] The "burst_tjd" is the Truncated Julian Day of the HETE trigger,
eg. TJD=11910 is 01 Jan 2001.
[6] The "burst_sod" is the UT seconds-of-day of the HETE trigger. This is the
spacecraft system clock UT time when the on-board software found a large
enough increase in the countrate. The sod is multiplied by 100,
and converted to a 32-bit integer for the packet (ie the units are centi-sec; 10 msec).
There are 2 "spare" items next in the packet that are not filled in
for the S/C_Alert packet. These are the locations of the "burst_ra" and "burst_dec"
which will be assigned values in the later packets when the position information
becomes available. Please note that on some occasions (~10% of the time),
these two fields can, in fact, be filled with the burst_ra and burst_dec
position values for the burst. This happens when the s/c can not transmit
the Alert when it first becomes available on the s/c (ie when there is a
gap in the downlinks), if this gap islong enough (about 10-30 sec), then enough
time will have gone by for the "Update" to come along. The Update has position
information so it fills in those "slots" in the outgoing packet. But the outgoing
packet keeps the Alert type indentity instead of the Update indentity even though
it has position information. The TBD flag is also set in this scenario
(indicating that there are values to be had in the burst_ra/_dec slots).
[9] The "trig_flags" is a collection of bit flags. The content, bit position,
and meaning is contained in the following list of macros:
#define GAMMA_TRIG 0x00000001 // Did FREGATE trigger? 1=yes, 0=no
#define WXM_TRIG 0x00000002 // Did WXM trigger?
#define SXC_TRIG 0x00000004 // Did SXC trigger?
#define ART_TRIG 0x00000008 // Artificial trigger?
#define POSS_GRB 0x00000010 // Possible GRB
#define DEF_GRB 0x00000020 // Definite GRB
#define DEF_NOT_GRB 0x00000040 // Definitely NOT GRB
#define HETE_NEAR_SAA 0x00000080 // S/c is in or near the SAA
#define POSS_SGR 0x00000100 // Possible SGR
#define DEF_SGR 0x00000200 // Definite SGR
#define POSS_XRB 0x00000400 // Possible XRB
#define DEF_XRB 0x00000800 // Definite XRB
#define GAMMA_DATA 0x00001000 // Gamma data in this message
#define WXM_DATA 0x00002000 // WXM data in this message
#define SXC_DATA 0x00004000 // SXC data in this message
#define OPT_DATA 0x00008000 // Optical (s/c ACS) data in this message
#define WXM_POS 0x00010000 // WXM position in this message
#define SXC_POS 0x00020000 // SXC position in this message
#define H_TRIG_spare1 0x000C0000 // spare1
#define H_USE_TRIG_SN 0x00400000 // Use H_WXM_S_N
#define H_TRIG_spare2 0x00800000 // spare2
#define H_SXC_EN_TRIG 0x01000000 // Triggered on the 1.5-12 keV band
#define H_LOW_EN_TRIG 0x02000000 // Triggered on the 2-30 keV band
#define H_MID_EN_TRIG 0x04000000 // Triggered on the 6-120 keV band
#define H_HI_EN_TRIG 0x08000000 // Triggered on the 25-400 keV band
#define H_PROB_XRB 0x10000000 // Probable XRB
#define H_PROB_SGR 0x20000000 // Probable SGR
#define H_PROB_GRB 0x40000000 // Probable GRB
#define H_TRIG_spare3 0x80000000 // spare3
The 9 "*_POSS_*", "*_PROB_*", and "*_DEF_*" flag bits indicate
if the flight s/w thought the trigger was "possibly", "probably" or "definitely"
due to a GRB, SGR, or an X-Ray Burster. Given the complexity of the problem and
the limitations of flight s/w algorithms, more than one of these 9 bits
can be set at the same time.
The "WXM_DATA" and "SXC_DATA" flag bits indicate whether or not this packet
contains data describing the brightness of the SXC or WXM data.
The "WXM_POS" and "SXC_POS" flag bits indicate whether or not this packet
contains valid WSM and SXC position information (ie the 4 corners).
These 2 flag bits are only valid for the S/C_UPDATE, S/C_LAST, and GNDANA (41-43)
packets (ie not valid for the S/C_ALERT (40) packet).
[10] The "gamma_counts" field contains the count rate as detected
by the FREGATE detector. The units are (approximately) counts per sec.
[11] The "wxm_signoise" field contains the rate-trigger detection signal-to-noise
ratio of the WXC detector. It is the increase in the countrate
that caused the trigger -- the units are an integer ratio [centi-sigma].
[12] The "sxc_counts" field contains the count rate as detected by the SXC detector.
The units are counts per sec.
[13] The "gamma_time" is the trigger_criteria timescale used in the FREGATE
detection -- this is related to the risetime of the burst.
[14] The "wxm_time" is the trigger timescale, which is more like a burst duration,
but not exactly: it's the "foreground" interval duration which gives
the best S/N in the trigger algorithm.
[15] The "sc_point" field contains the RA,Dec coordinates of the s/c pointing
direction. The RA is stored in the upper word, and Dec is stored
in the lower word. The units are degrees.
There are 23 "spare" items in the packet that are not used (usually filled
with zeros).
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=41 PACKET CONTENTS:
NOTE: Type=41 packets (HETE_S/C_UPDATE) are NO LONGER AVAILABLE.
The HETE_S/C_UPDATE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=41)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_seq_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 trig_flags bits Trigger type ID flag bits
long 10 gamma_cnts [cnts/sec] GammaDet count rate
long 11 wxm_signoise [centi-sig/nois]WXM rate trigger signal/noise
long 12 sxc_cnts [cnts/sec] SXC det count rate
long 13 gamma_time [milli-sec] GammaDet timescale
long 14 wxm_time [milli-sec] WXM det timescale
long 15 sc_point integers S/c RA,Dec pointing dir
long 16 wxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 17 wxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 18 wxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 19 wxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 20 wxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 21 wxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 22 wxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 23 wxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 24 wx_errors bit fields Packed with Sys & Stat errors
long 25 wx_dimsig bit fields Packed numbers
long 26 sxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 27 sxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 28 sxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 29 sxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 30 sxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 31 sxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 32 sxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 33 sxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 34 sx_errors bit fields Packed with Sys & Stat errors
long 35 sx_dimsig bit fields Packed numbers
long 36 pos_flags bits Mixed bits: pos, signif, data
long 37 validity bits Trigger source ID type
long 38 lc_img_sn 4 bytes WXM X&Y LightCurve & Image SN
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=41):
The following items are unique to packet type=41. Items 0-13 and 39
are the same as defined in packet type=40.
[7-8] The "burst_ra" and "burst_dec" items are the RA,Dec (Current epoch) location
of the burst. Since there are two instruments that can produce
position information, these two locations are filled with the best position
of the 1 or 2 possibilities. If both the SXC and WXM positions are available,
then these two fields are filled with the SXC location. If only the WXM
position is available, the WXM position is contained in these two items.
If neither position is available, then that very rare (but technically
possible) situation is indicated by filling the items with the values
-999.9999 and -999.9999 (illegal values for RA,Dec).
Note that the 3 countrate fields (gamma_cnt, wxm_cnt, and sxc_cnt) may change
their values from from one Notice to the next.
[9] The "trig_flags" field may also change from one Notice to the next.
[16-23] The "wxraN", "wxdecN", sxraN", and "sxdecN" fields are the RA,Dec corners
of the WXC and SXC instrument source position error boxes (in J2000 epoch),
respectively. The value "N" runs from 1 to 4 for the four corners of the box.
Coordinates of corners are given in degrees * 10000 (0.36" precision!).
If all 4 corners are the same RA,Dec location, then the error box is circular
and not rectangular. And the RA,Dec given is the center of the circle (and
is the same as the "burst_ra","burst_dec" fields.
[24] The"wx_errors" contains the statistical error (upper word) and
the systematic error (lower word) for the WXC position determination.
These should be added in quadrature to get the total uncertainty (radius).
To decode the wx_errors word:
#define STATERR_MASK 0xFFFF0000 // Statistical error [arcsec], radius
#define SYSERR_MASK 0x0000FFFF // Systematic error [arcsec], radius
[25] The "wx_dimsig" contains two things:
a) the maximum dimension of the WXM error box (the distance between the two
corners of the error box that are the farthest apart [units arcsec]), and
b) the significance of the detection of the point source in the image plane
(in Sig/Noise units) [note that this is different than the wxm_signoise field
which is based on the rate-trigger detection significance].
To decode the ws_dimsig word:
#define MAXDIM_MASK 0xFFFF0000 // Max dimension of location box
#define NSIGMA_MASK 0x0000FFFF // Detection significance [Sig/Noise]
Note that the "maximum dimension" of the 'error box' is effectively a diameter
for a circumscribing 'error circle'.
[34] The"sx_errors" contains the statistical error (upper word) and
the systematic error (lower word) for the SXC position determination.
The same decoding listed in wx_errors also applies for sx_errors.
[35] The "sx_dimsig" contains two things:
a) the maximum dimension of the SXC error box (the distance between the two
corners of the error box that are farthest apart [units arcsec], and
b) the significance of the detection (in Sig/Noise units).
The same decoding macros listed in wx_dimsig also apply for sx_dimsig.
[36] The "pos_flags" is a slight misnomer. It contains a mixture of flag bits.
There are bits about the status of the various detected positions;
bits about the significance of the detections; and bits about if things
have changed/improved during the ground analysis (GNDANA packets only).
Except the "sc_long" field which is present in all 4 types (Alerts through
GNDANA). It is contains the longitude of the s/c in its orbit, and is measured
eastward from the prime meridian (ie it goes 0-359deg, however because of
bit-packing constraints, it is prescaled by 2).
The pos_flags bits:
#define WXM_SXC_SAME 0x00000001 // Positions are consistent, 1=yes
// WXM and SXC have overlapping boxes
#define WXM_SXC_DIFF 0x00000002 // Positions are inconsistent
// WXM and SXC do not have overlapping boxes
#define WXM_LOW_SIG 0x00000004 // NSIGMA below a threshold
// The S/N is below a "good" value
#define SXC_LOW_SIG 0x00000008 // NSIGMA below a threshold
// The S/N is below a "good" value
// The following bits are assigned (and therefore valid) only
// in the GNDANA packets:
#define GAMMA_REFINED 0x00000010 // Gamma refined since FINAL
// Gamma data changed as a result
// of ground analysis
#define WXM_REFINED 0x00000020 // WXM refined since FINAL
// WXM data changed as a result
// of ground analysis
#define SXC_REFINED 0x00000040 // SXC refined since FINAL
// SXC data changed as a result
// of ground analysis
#define POS_spare 0x00FFFFB0 // spare
#define SC_LONG 0xFF000000 // S/C Longitude East [units of 2-degrees]
[37] The "validity" is set of bit flags specifying the identity of the type
of trigger (i.e. GRB, x-ray src, etc).
Validity is determined after the trigger has been detected.
Fregate looks at background trends before and after the burst:
it can say "hey, this was due to a rising background" and the burst is invalid.
The on-board code can see that a burst came from a known source,
but only after a position has been detected: the burst is invalid
because it's a known source.
The on-board code can protect against emersion triggers if it's
been properly configured. If the ground analysis shows
"oops, it was an emersion trigger", then that bit is set.
If there's no position, it's a useless burst. This bit is defined,
but it is not currently set by the on-board or the ground processing s/w.
The following macros can be used to extract the various flag bits from validity:
#define BURST_VALID 0x00000001 // Burst declared valid
#define BURST_INVALID 0x00000002 // Burst declared invalid
#define H_VAL0x4_spare 0x00000004 // spare; not used
#define H_VAL0x8_spare 0x00000008 // spare; not used
#define EMERGE_TRIG 0x00000010 // Emersion trigger
#define KNOWN_XRS 0x00000020 // Known X-ray source
#define NO_POSITION 0x00000040 // No WXM or SXC position
#define H_VAL0x80_spare 0x00000080 // spare; not used
#define OPS_ERROR 0x00000100 // Bad burst: s/c and inst ops error
#define PARTICLES 0x00000200 // Bad burst: particles
#define BAD_FLT_LOC 0x00000400 // Bad burst: bad flight location
#define BAD_GND_LOC 0x00000800 // Bad burst: bad ground location
#define RISING_BACK 0x00001000 // Bad burst: rising background
#define POISSON_TRIG 0x00002000 // Bad burst: poisson fluctuation trigger
#define H_VALID_spare 0x1FFFC000 // spare
#define H_EMAIL_METHOD 0x20000000 // email import method(=1, socket=0)
#define H_INTERNAL_TEST 0x40000000 // HETE_OPS GndAna test/debug loop
#define H_NOT_A_BURST 0x80000000 // GndAna shows this trigger to be non-GRB
[38] The "lc_img_sn" contains 4 values (the WXM X and Y LightCurve SN and
Image SN values).
WXM_X_LC_SN in the most significant byte,
WXM_Y_LC_SN in the next most significant byte,
WXM_X_IMAGE_SN in the third most significant byte, and
WXM_Y_IMAGE_SN in the least significant byte.
WXM_X_LC_SN and WXM_Y_LC_SN describe the signal-to-noise of the excess
over background in the WXM light curve (LC) in each of the two modules (X and Y).
The WXM light curve is obtained by summing the data over all position bins
at 320ms time resolution. The flight software chooses background and
burst time intervals, and performs a standard background subtraction
in each detector. The resulting net signals are divided by their respective
root-variances, to yield the quantities reported here.
Note that WXM_*_LC_SN are not directly related to trigger SNR,
since the trigger operates on 80ms resolution data, and may in fact
come from FREGATE data rather than from WXM data. The light-curve SNR
is designed measure the overall signal-to-noise in the actual data used
to obtain the location, so as to complement WXM_*_IMAGE_SN.
The two values stored in the packet are in units of deci-sigma (ie they
have been multiplied by 10.0 and integerized prior to storing, and thus
have a dynamic range of 0.0 to 25.5).
WXM_X_IMAGE_SN and WXM_Y_IMAGE_SN describe the peak signal-to-noise
in the cross-correlation of the background-subtracted image with the mask
in each of the two modules (X and Y).
The background-subtracted signal across each WXM detector is cross-correlated
with the mask. The resulting cross-correlation functions are mean-subtracted
and divided by their respective root-variances, yielding SNR as a function
of source projection angle in each detector. The quantities reported here
are the peak values of those functions.
The two values stored in the packet are in units of deci-sigma (ie they
have been multiplied by 10.0 and integerized prior to storing, and thus
have a dynamic range of 0.0 to 25.5).
TYPE=42 PACKET CONTENTS:
NOTE: Type=42 packets (HETE_S/C_LAST) are NO LONGER AVAILABLE.
The HETE_S/C_LAST packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=42)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_seq_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 trig_flags bits Trigger type ID flag bits
long 10 gamma_cnts [cnts/sec] GammaDet count rate
long 11 wxm_signoise [centi-sig/nois]WXM rate trigger signal/noise
long 12 sxc_cnts [cnts/sec] SXC det count rate
long 13 gamma_time [milli-sec] GammaDet timescale
long 14 wxm_time [milli-sec] WXM det timescale
long 15 sc_point integers S/c RA,Dec pointing dir
long 16 wxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 17 wxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 18 wxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 19 wxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 20 wxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 21 wxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 22 wxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 23 wxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 24 wx_errors bit fields Packed with Sys & Stat errors
long 25 wx_dimsig bit fields Packed numbers
long 26 sxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 27 sxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 28 sxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 29 sxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 30 sxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 31 sxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 32 sxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 33 sxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 34 sx_errors bit fields Packed with Sys & Stat errors
long 35 sx_simsig bit fields Packed numbers
long 36 pos_flags bits Mixed bits: pos, signif, data
long 37 validity bits Trigger source ID type
long 38 lc_img_sn 4 bytes WXM X&Y LightCurve & Image SN
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=42):
The following items are unique to packet type=42. Items 0-33 and 39
are the same as defined in packet type=41. The only two new
bit fields in "validity".
The following macros can be used to extract the new flag bits from validity:
#define BURST_VALID 0x00000001 // Is this a real GRB? 1=yes
#define BURST_INVALID 0x00000002 // It is not a real GRB. 1=not_real
TYPE=43 PACKET CONTENTS:
NOTE: Type=43 packets (HETE_GNDANA) are NO LONGER AVAILABLE.
The HETE_GNDANA packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=43)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_seq_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 trig_flags bits Trigger type ID flag bits
long 10 gamma_cnts [cnts/sec] GammaDet count rate
long 11 wxm_signoise [centi-sig/nois]WXM rate trigger signal/noise
long 12 sxc_cnts [cnts/sec] SXC det count rate
long 13 gamma_time [milli-sec] GammaDet timescale
long 14 wxm_time [milli-sec] WXM det timescale
long 15 sc_point integers S/c RA,Dec pointing dir
long 16 wxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 17 wxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 18 wxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 19 wxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 20 wxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 21 wxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 22 wxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 23 wxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 24 wx_errors bit fields Packed with Sys & Stat errors
long 25 wx_dimsig bit fields Packed numbers
long 26 sxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 27 sxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 28 sxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 29 sxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 30 sxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 31 sxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 32 sxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 33 sxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 34 sx_errors bit fields Packed with Sys & Stat errors
long 35 sx_simsig bit fields Packed numbers
long 36 pos_flags bits Mixed bits: pos, signif, data
long 37 validity bits Trigger source ID type
long 38 lc_img_sn 4 bytes WXM X&Y LightCurve & Image SN
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=43):
There are no unique (new) fields in packet type=43. All the fields defined
in type=42 are also present in type=43. However, there are a few new bits
defined in the "pos_flags" and "validity" fields. Also, the values contained
in the following fields may have changed from what was distributed
in the last type=42 Notice.
HETE FLAG BITS VS NOTICE TYPE:
The table below contains the 3 fields that have flag bits in the 4 types
of HETE Notices (S/C_Alert, S/C_Update, S/C_Last, and GroundAnalysis). It shows
which bits are assigned (set to 1 or 0) in each Notice type.
An "X" means that bit is tested and set (1or0) in that Notice type.
A blank (" ") means that bit is not determined/controlled in that Notice type.
Table of HETE Packet Flag Bits vs Notice Type
WORD:
BIT Bit_Mask S/C_Alert S/C_Update S/C_Last GndAna
TRIG_FLAGS:
H_GAMMA_TRIG 0x00000001 X X X X
H_WXM_TRIG 0x00000002 X X X X
H_SXC_TRIG 0x00000004 X X X X
H_ART_TRIG 0x00000008 X X X X
H_POSS_GRB 0x00000010 X X X X
H_DEF_GRB 0x00000020 X X X X
H_DEF_NOT_GRB 0x00000040 X X X X
H_NEAR_SAA 0x00000080 X X X X
H_POSS_SGR 0x00000100 X X X X
H_DEF_SGR 0x00000200 X X X X
H_POSS_XRB 0x00000400 X X X X
H_DEF_XRB 0x00000800 X X X X
H_GAMMA_DATA 0x00001000 X X X X
H_WXM_DATA 0x00002000 X X X X
H_SXC_DATA 0x00004000 X X X X
H_OPT_DATA 0x00008000 X X X X
H_WXM_POS 0x00010000 X X X X
H_SXC_POS 0x00020000 X X X X
H_TRIG_spare 0xFFFD0000
POS_FLAGS:
H_WXM_SXC_SAME 0x00000001 X X X
H_WXM_SXC_DIFF 0x00000002 X X X
H_WXM_LOW_SIG 0x00000004 ???
H_SXC_LOW_SIG 0x00000008 ???
H_GAMMA_REFINED 0x00000010 X
H_WXM_REFINED 0x00000020 X
H_SXC_REFINED 0x00000040 X
H_POS_spare 0x00FFFFB0
H_SC_LONG 0xFF000000 X X X X
VALIDITY:
H_BURST_VALID 0x00000001 X X
H_BURST_INVALID 0x00000002 X X
H_VAL0x4_spare 0x00000004
H_VAL0x8_spare 0x00000008
H_EMERGE_TRIG 0x00000010 X X X
H_KNOWN_XRS 0x00000020 X X X
H_NO_POSITION 0x00000040 X X X
H_VAL0x80_spare 0x00000080
H_OPS_ERROR 0x00000100 X
H_PARTICLES 0x00000200 X
H_BAD_FLT_LOC 0x00000400 X
H_BAD_GND_LOC 0x00000800 X
H_RISING_BACK 0x00001000 X
H_POISSON_TRIG 0x00002000 X
H_VALID_spare 0x1FFFC000
H_EMAIL_METHOD 0x20000000 X
H_INTERNAL_TEST 0x40000000 X
H_NOT_A_BURST 0x80000000 X
SLOT 38:
H_X_LC 0xff000000 X X X
H_Y_LC 0x00ff0000 X X X
H_X_IMAGE 0x0000ff00 X X X
H_Y_IMAGE 0x000000ff X X X
TYPE=44 PACKET CONTENTS:
The HETE_Test packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=44)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_seq_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 trig_flags bits Trigger type ID flag bits
long 10 gamma_cnts [cnts/sec] GammaDet count rate
long 11 wxm_signoise [centi-sig/nois]WXM rate trigger signal/noise
long 12 sxc_cnts [cnts/sec] SXC det count rate
long 13 gamma_time [milli-sec] GammaDet timescale
long 14 wxm_time [milli-sec] WXM det timescale
long 15 sc_point integers S/c RA,Dec pointing dir
long 16 wxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 17 wxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 18 wxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 19 wxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 20 wxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 21 wxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 22 wxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 23 wxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 24 wx_errors bit fields Packed with Sys & Stat errors
long 25 wx_dimsig bit fields Packed numbers
long 26 sxra1 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 27 sxdec1 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 28 sxra2 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 29 sxdec2 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 30 sxra3 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 31 sxdec3 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 32 sxra4 [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 33 sxdec4 [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 34 sx_errors bit fields Packed with Sys & Stat errors
long 35 sx_simsig bit fields Packed numbers
long 36 pos_flags bits Mixed bits: pos, signif, data
long 37 validity bits Trigger source ID type
long 38 lc_img_sn 4 bytes WXM X&Y LightCurve & Image SN
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (only those unique to type=44):
There are no unique (new) fields in packet type=44. All the fields defined
in type=43 are also present in type=44.
HETE-BASED PACKET ITEM MACROS:
Below are the C-language define's for picking out the various elements
of the array of longs that make up the HETE-based packets. They have names
which reflect the contents of packet types 40, 41, 42, 43, & 44. A few of the
items have the same names as the original BATSE-based packets, because
they are common to all type-bases. For the other (non-HETE-based) types,
these macros should not be used because these macro names would conote
the wrong information content.
// Indices into the socket packet array of 40 longs:
#define PKT_TYPE 0 // Packet type
#define PKT_SERNUM 1 // Packet serial number
#define PKT_HOP_CNT 2 // Packet hop count
#define PKT_SOD 3 // Packet Sec-of-Day [centi-sec] (sssss.sss*100)
#define BURST_TRIG 4 // HETE trigger number plus message sequence num
#define BURST_TJD 5 // Truncated Julian Day
#define BURST_SOD 6 // Sec-Of-Day [centi-sec] (sssss.sss*100)
#define BURST_RA 7 // RA [10^-4-deg] (0.0 to 359.9999 *100)
#define BURST_DEC 8 // Dec [10^-4-deg] (-90.0 to +90.0 *100)
#define TRIG_FLAGS 9 // See flags below
#define GAMMA_CTS_S 10 // cts/s defined by gamma, can be 0
#define WXM_CTS_S 11 // cts/s defined by WXM, can be 0
#define SXC_CTS_S 12 // cts/s defined by SXC, can be 0
#define GAMMA_TIMESCALE 13 // in milliseconds
#define WXM_TIMESCALE 14 // in milliseconds
#define SC_POINTING 15 // S/c pointing direction in degrees
#define WXM_CNR1_RA 16 // First corner of WXM error box
#define WXM_CNR1_DEC 17 // First corner of WXM error box
#define WXM_CNR2_RA 18 // Second corner of WXM error box
#define WXM_CNR2_DEC 19 // Second corner of WXM error box
#define WXM_CNR3_RA 20 // Third corner of WXM error box
#define WXM_CNR3_DEC 21 // Third corner of WXM error box
#define WXM_CNR4_RA 22 // Fourth corner of WXM error box
#define WXM_CNR4_DEC 23 // Fourth corner of WXM error box
#define WXM_ERRORS 24 // Arcsec, stat high, sys low
#define WXM_DIM_NSIGMA 25 // Max box size (arcsec), significance of loc'n
#define SXC_CNR1_RA 26 // First corner of SXC error box
#define SXC_CNR1_DEC 27 // First corner of SXC error box
#define SXC_CNR2_RA 28 // Second corner of SXC error box
#define SXC_CNR2_DEC 29 // Second corner of SXC error box
#define SXC_CNR3_RA 30 // Third corner of SXC error box
#define SXC_CNR3_DEC 31 // Third corner of SXC error box
#define SXC_CNR4_RA 32 // Fourth corner of SXC error box
#define SXC_CNR4_DEC 33 // Fourth corner of SXC error box
#define SXC_ERRORS 34 // Arcsec, stat high, sys low
#define SXC_DIM_NSIGMA 35 // Max box size (arcsec), significance of loc'n
#define POS_FLAGS 36 // Collection of various info bits
#define VALIDITY 37 // Trigger identity, source type, etc
#define H_LC_IMG_SN 38 // LightCurve and Image Sig/Noise ratios
#define PKT_TERM 39 // Packet termination character
================================================================================
TYPE=45 PACKET CONTENTS:
The GRB_COUNTERPART packet contains detections of the burst counterpart
in both the optical, radio, and other (x-ray, TeV, neutrinos, etc ...) bandpasses.
However, to make the field_names shorter, they were given names
with an optical bias. Only the name has this bias, the contents
cover the optical, the radio, the x-ray, particles, etc.
The GRB_COUNTERPART packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=45)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer Some reference number (eg trig_num)
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 cp_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 cp_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 cp_inten [centi-mag] (int)(mm.mm *100)
long 10 inten_err [centi-mag] (int)(mm.mm *100)
long 11 cp_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12 filter integer Opt_fltr, Radio_freq, Oth_??
long 13 seeing [centi-arcsec] (int)(ss.ss *100)
long 14 obs_tjd [days] Truncated Julian Day
long 15 obs_time [centi-sec] (int)(sssss.sss *100)
long 16 obs_dur [centi-sec] (int)(sssss.sss *100)
long 17 id_conf [centi-%] (int)(0.0 to 100.00 *100)
long 18 flags bits Flag bits on source-type
long 19 misc bits Misc flag bits and fields
quad_char 20-23 telescope[4] chars The name of the telescope
quad_char 24-38 name[15] chars The name of the submittor
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=45):
[0] The "pkt_type" is an integer with a value of 45, which tells that this packet
is of type GRB_COUNTERPART and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "ref_num" is a reference number for that burst. Typically it is a trigger_number
of the burst for that mission that made the original detection of the burst.
[5] The "burst_tjd" is the Truncated Julian Day of the burst,
eg. TJD=12275 is 01 Jan 2002.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the burst. The SOD
is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689568 = 46895.68 sec-of-day =
13:01:35.68 UT.
[7-8] The "cp_ra" and "cp_dec" fields specify the RA,Dec location of the detected
GRB counterpart (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "cp_inten" field contains the magnitude of the detected optical transient.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
then integerized). If the packet is for a counterpart detection
in the radio band (see the misc flag bits field), then the "cp_mag" field
contains the flux in centi-uJy (ie 10^-8 Janskies). If the counterpart
detection in the "other" (x-/g-ray) category, then the units type are specified
by the 'expo' subfield in the 'filter' field and then multiplied by 100 and integerized.
[10] The "inten_error" field contains the uncertainty (statistical plus systematic)
of the cp_inten value. The units are also centi-magnitudes or centi-uJy or
centi-units for 'other' (eg centi-kHz, centi-MHz, centi-GHz, centi-keV,...,centi-TeV).
(See the 'expo' subfield in the 'filter' value.)
[11] The "cp_error" is the radius of the circle that will contain on average
68% of the counterpart locations. The units are 10^-4-degrees.
[12] The "filter" field specifies the filter that was used for the observation.
The filter_index comes from a predefined list [see below].
0 n/a
1 U
2 B
3 V
4 R
5 I
6 J
7 K
8 L
9 M
10 r
The upper 8 bits (of this 32-bit field) contain the 'exponent' of the 'band'
if this is a 'radio' or 'other' counterpart observation:
RADIO:
3 kHz
6 MHz
9 GHz
OTHER:
3 keV
6 MeV
9 GeV
12 TeV
15 PeV
[13] The "seeing" field contains the seeing during the observation. The units
are centi-arcsec.
[14] The "obs_tjd" is the Truncated Julian Day of the start of the observation.
[15] The "obs_sod" is the Seconds-of-Day of the start of the observation.
[16] The "obs_dur" is the duration in centi-seconds of the observation. The seconds
is multiplied by 100 and then integerized (i.e. the units are centi-sec, ie 10 msec).
[17] The "id_conf" is the confidence level of the identification of the counterpart to the GRB.
The percentage_value is multiplied by 100 and then integerized (i.e. the units are centi-%).
[18] The "trig_id" field contains flag bit bits relating to the source-type identity.
Bit_Number Item_name Description
---------- --------- -----------
0 n/a n/a
1 GRB_DEF This is definitely related to a GRB
2-27 n/a spare
28 spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 n/a spare
[19] The "misc" field contains various miscellaneous flags and fields.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0-4 n/a spare
5-6 type optical=1/radio=2/other=3
7-23 n/a spare
24-31 iexpo Intensity exponent value
[20-23] The "telescope" is the name of the telescope that made the detection.
This item in the packet spans 4 longwords (ie 16 bytes) and contains
the ASCII string of the name of the telescope. This string can be
up to 15 characters long, and will always be null-terminated.
[24-38] The "name" is the name of the person submitting this counterpart detection notice.
This item in the packet spans 15 longwords (ie 60 bytes) and contains
the ASCII string of the name of the submittor. This string can be
up to 59 characters long, and will always be null-terminated.
There are no "spare" items in this packet.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as multiple sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
TYPE=46 PACKET CONTENTS:
TYPE=47 PACKET CONTENTS:
See packet types 65 and 67 respectively.
================================================================================
TYPE=48 PACKET CONTENTS:
The DOW_TOD Test packet contain timestamp information about the
day-of-week and time-of-day you requested this notice.
The DOW_TOD Test packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=45)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for future use
long 5 pkt_tjd [days] Truncated Julian Day
long 6 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 7-38 spare[32] integer 128 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=48):
[0] The "pkt_type" is an integer with a value of 48, which tells that this packet
is of type DOW_TOD and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[5] The "notice_tjd" is the Truncated Julian Day when the notice was created,
eg. TJD=12275 is 01 Jan 2002.
[6] The "notice_sod" is the UT seconds-of-day (SOD) when the notice was created.
The SOD is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689568 = 46895.68 sec-of-day =
13:01:35.68 UT.
There are 32 "spare" items in this packet.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as multiple sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
PACKET ITEM DESCRIPTIONS for type=51:
The INTEGRAL_POINTDIR packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=51)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_sub_num integers Trigger num & mesg sernum
long 5 slew_tjd [days] Truncated Julian Day
long 6 slew_sod [centi-sec] (int)(sssss.sss *100)
long 7-11 spare[5] integer 20 bytes for the future
long 12 test_mpos flag_bits Test and Multi-Position flags
long 13 spare[1] integer 4 bytes for the future
long 14 next_sc_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 15 next_sc_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 16-18 spare[3] integer 12 bytes for the future
long 19 misc_att integer S/c status & attitude
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 51, 52, 53 , 54, or 55
that tells which type of packet this is and therefore what the contents are
(the contents change slightly between the various types). The types are:
51 = INTEGRAL_POINTDIR, 52 = INTEGRAL_SPIACS, 53 = INTEGRAL_WAKEUP,
54 = INTEGRAL_REFINED, and 55 = INTEGRAL_OFFLINE.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created and sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_sub_num" are the uniquely identifying serial numbers (main and sub)
assigned by the on-board INTEGRAL flight software to each trigger.
The lower 16 bits contain the trigger ("Alert") number, and the upper 16 bits
contain the Alert sub-number. The sub-number is always 0 for type=53;
goes from 1 to N for type=54; and N+1, N+2, ... for type=55.
[5] The "slew_tjd" is the TJD when the next s/c slew happens.
[6] The "slew_sod" is the seconds-of-day (SOD) when the next s/c slew happens.
[12] The "test_mpos" field contains the Test_Notice flag bit (2^31) and
the multiple_position flag bit (2^0). The multi-position flag is meaningless
for the POINTDIR Notice.
[14] The "next_sc_ra" and "next_sc_dec" are the RA,Dec (J2000) coordinates
to which the spacecraft will point after this slew. This is the pointing
direction of the s/c. The units are 10^04 deg, ie the values
where multiplied by 10000 and integerized.
[19] The "misc_att" field contains status and attitude information on the s/c.
The exact contents and format are still TBD at the INTEGRAL MOC.
There are a total of 28 "spare" items in the packet (usually filled with zeros).
They are located at items 7-11,13, 16-18, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=52 PACKET CONTENTS:
The INTEGRAL_SPIACS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=52)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_sub_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7-8 spare[2] integer 8 bytes for the future
long 9 det_flags flag_bits Detector flag bits
long 10 inten_sigma [centi-sigma] Burst_intensity_sigma*100
long 11 spare[1] integer 4 bytes for the future
long 12 test_mpos flag_bits Test and Multi-Position flags
long 13 time_scale [10^-4 sec] Time sampling or trigger time
long 14-15 spare[2] integer 8 bytes for the future
long 16 time_error [10^-4 sec] Accuracy of GRB time
long 17-18 spare[2] integer 8 bytes for the future
long 19 misc_att integer S/c status & attitude
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 51, 52, 53 , 54, or 55
that tells which type of packet this is and therefore what the contents are
(the contents change slightly between the various types). The types are:
51 = INTEGRAL_POINTDIR, 52 = INTEGRAL_SPIACS, 53 = INTEGRAL_WAKEUP,
54 = INTEGRAL_REFINED, and 55 = INTEGRAL_OFFLINE.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_sub_num" are the uniquely identifying serial numbers (main and sub)
assigned by the on-board INTEGRAL flight software to each trigger.
The lower 16 bits contain the trigger ("Alert") number, and the upper 16 bits
contain the Alert sub-number. The sub-number is always 0 for type=53;
goes from 1 to N for type=54; and N+1, N+2, ... for type=55.
The Alert number started with s/n=??? just after launch (Oct 02) and
is currently (???03) in the ???'s.
[5] The "burst_tjd" is the Truncated Julian Day of the INTEGRAL burst trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the INTEGRAL burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[9] The "det_flags" ("trig_id") field contains bit_flags specifing
the trigger process. The bit packing of the "det_flags" entry in the packet
is unknown as yet (TBD at the INTEGRAL MOC).
[10] The "intensity_sigma" field contains the intensity of the burst in sigma units,
essentially a signal/noise metric. The units are 'centi-sigma', ie the fl.pt.
sigma was multiplied by 100 and then integerized and put into the packet.
[12] The "test_mpos" field contains the Test_Notice flag bit (2^31) and
the multiple_position flag bit (2^0). The multi-position flag is meaningless
for the SPIACS Notice.
The "test_mpos" field contains the following bit_flags:
Bit_Number Item_name Description
---------- --------- -----------
0 multi_position 0=No or 1=Yes, the INTEGRAL Gnd s/w there was more
than one likely position for this burst.
In that case, the RA,Dec fields
????contain/do_not_contain????
the most likely position (I'm waiting
for info from the Ops team).
1-28 x_x_x_x spare
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 def_not_grb 0=No or 1=Yes, it is definitely not a GRB.
31 test 0=No or 1=Yes, it is a Test_Notice.
[13] The "time_scale" field has the sampling interval used. For type=52 (SPIACS)
it is the lightcurve binning; for type=53 and 54 (WAKEUP and REFINED) it is
the SIT and IMITS that triggered; and for type=55 (OFFLINE) it is the TBD
duration of the burst.
[16] The "time_error" field contains the accuracy of the GRB timing information
(units are 10^-4 seconds). This is usually the sum of the time bin size
used for the image reconstruction and the propogation delay. It is expected
(by the INTEGRAL MOC) that type=55 packets (OFFLINE) will be corrected
for propogation delays.
[19] The "misc_att" field contains status and attitude information on the s/c.
The exact contents and format are still TBD at the INTEGRAL MOC.
There are a total of 26 "spare" items in the packet (usually filled
with zeros). They are located at items 7-8, 11, 14-15, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=53 PACKET CONTENTS:
The INTEGRAL_WAKEUP packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=53)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_sub_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 det_flags bits Detector flag bits
long 10 inten_sigma [centi-sigma] Burst_intensity_sigma*100
long 11 burst_error [arcsec] Burst location uncertainty
long 12 test_mpos flag_bits Test and Multi-Position flags
long 13 time_scale [10^-4 sec] Time sampling or trigger time
long 14 sc_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 15 sc_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 16 time_error [10^-4 sec] Accuracy of GRB time
long 17-18 spare[2] integer 8 bytes for the future
long 19 misc_att integer S/c status & attitude
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 51, 52, 53 , 54, or 55
that tells which type of packet this is and therefore what the contents are
(the contents change slightly between the various types). The types are:
51 = INTEGRAL_POINTDIR, 52 = INTEGRAL_SPIACS, 53 = INTEGRAL_WAKEUP,
54 = INTEGRAL_REFINED, and 55 = INTEGRAL_OFFLINE.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_sub_num" are the uniquely identifying serial numbers (main and sub)
assigned by the on-board INTEGRAL flight software to each trigger.
The lower 16 bits contain the trigger ("Alert") number, and the upper 16 bits
contain the Alert sub-number. The sub-number is always 0 for type=53;
goes from 1 to N for type=54; and N+1, N+2, ... for type=55.
The Alert number started with s/n=~1 just after launch (Oct 02) and
is currently (Oct2006) in the 3500s.
[5] The "burst_tjd" is the Truncated Julian Day of the INTEGRAL burst trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the INTEGRAL burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
(current epoch). These intrinsically floating point quantities
have been multiplied by 10000 and then integerized to make an integer quantity
with units of 10^-4-degrees.
[9] The "det_flags" ("trig_id") field contains bit_flags specifing
the trigger process. The bit packing of the "det_flags" entry in the packet
is unknown as yet (TBD at INTEGRAL MOC).
[10] The "intensity_sigma" field contains the intensity of the burst in sigma units,
essentially a signal/noise metric. The units are 'centi-sigma', ie the fl.pt.
sigma was multiplied by 100 and then integerized and put into the packet.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% c.l. of the bursts. The units are arcseconds.
[12] The "test_mpos" field contains the following bit_flags:
Bit_Number Item_name Description
---------- --------- -----------
0 multi_position 0=No or 1=Yes, the INTEGRAL Gnd s/w there was more
than one likely position for this burst.
In that case, the RA,Dec fields
????contain/do_not_contain????
the most likely position (I'm waiting
for info from the Ops team).
1-27 x_x_x_x spare
28 spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 def_not_grb 0=No or 1=Yes, it is definitely not a GRB.
31 test 0=No or 1=Yes, it is a Test_Notice.
[13] The "time_scale" field has the sampling interval used. For type=52 (SPIACS)
it is the lightcurve binning; for type=53 and 54 (WAKEUP and REFINED) it is
the SIT and IMITS that triggered; and for type=55 (OFFLINE) it is the TBD
duration of the burst.
[14-15] The "sc_ra" and "sc_dec" are the RA,Dec (J2000) coordinates
to which the spacecraft points. This is the pointing direction of the s/c.
The units are 10^04 deg, ie the values where multiplied by 10000 and
integerized.
[16] The "time_error" field contains the accuracy of the GRB timing information
(units are 10^-4 seconds). This is usually the sum of the time bin size
used for the image reconstruction and the propogation delay. It is expected
(by the INTEGRAL MOC) that type=55 packets (OFFLINE) will be corrected
for propogation delays.
[19] The "misc_att" field contains status and attitude information on the s/c.
The exact contents and format are still TBD at the INTEGRAL MOC.
There are a total of 23 "spare" items in the packet (usually filled
with zeros). They are located at items 11-12, 17-18, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=54 PACKET CONTENTS:
The INTEGRAL_REFINED packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=54)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_sub_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 det_flags bits Detector flag bits
long 10 inten_sigma [centi-sigma] Burst_intensity_sigma*100
long 11 burst_error [arcsec] Burst location uncertainty
long 12 test_mpos flag_bits Test and Multi-Position flags
long 13 time_scale [10^-4 sec] Time sampling or trigger time
long 14 sc_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 15 sc_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 16 time_error [10^-4 sec] Accuracy of GRB time
long 17-18 spare[2] integer 8 bytes for the future
long 19 misc_att integer S/c status & attitude
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 51, 52, 53 , 54, or 55
that tells which type of packet this is and therefore what the contents are
(the contents change slightly between the various types). The types are:
51 = INTEGRAL_POINTDIR, 52 = INTEGRAL_SPIACS, 53 = INTEGRAL_WAKEUP,
54 = INTEGRAL_REFINED, and 55 = INTEGRAL_OFFLINE.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_sub_num" are the uniquely identifying serial numbers (main and sub)
assigned by the on-board INTEGRAL flight software to each trigger.
The lower 16 bits contain the trigger ("Alert") number, and the upper 16 bits
contain the Alert sub-number. The sub-number is always 0 for type=53;
goes from 1 to N for type=54; and N+1, N+2, ... for type=55.
The Alert number started with s/n=~1 just after launch (Oct 02) and
is currently (Oct2006) in the 3500s.
[5] The "burst_tjd" is the Truncated Julian Day of the INTEGRAL burst trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the INTEGRAL burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
(current epoch). These intrinsically floating point quantities
have been multiplied by 10000 and then integerized to make an integer quantity
with units of 10^-4-degrees.
[9] The "det_flags" ("trig_id") field contains bit_flags specifing
the trigger process. The bit packing of the "det_flags entry in the packet
is unknown as yet (TBD at INTEGRAL MOC).
[10] The "intensity_sigma" field contains the intensity of the burst in sigma units,
essentially a signal/noise metric. The units are 'centi-sigma', ie the fl.pt.
sigma was multiplied by 100 and then integerized and put into the packet.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% c.l. of the bursts. The units are arcseconds.
[12] The "test_mpos" field contains the following bit_flags:
Bit_Number Item_name Description
---------- --------- -----------
0 multi_position 0=No or 1=Yes, the INTEGRAL Gnd s/w there was more
than one likely position for this burst.
In that case, the RA,Dec fields
????contain/do_not_contain????
the most likely position (I'm waiting
for info from the Ops team).
1-27 x_x_x_x spare
28 spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 def_not_grb 0=No or 1=Yes, it is definitely not a GRB.
31 test 0=No or 1=Yes, it is a Test_Notice.
[13] The "time_scale" field has the sampling interval used. For type=52 (SPIACS)
it is the lightcurve binning; for type=53 and 54 (WAKEUP and REFINED) it is
the SIT and IMITS that triggered; and for type=55 (OFFLINE) it is the TBD
duration of the burst.
[14-15] The "sc_ra" and "sc_dec" are the RA,Dec (J2000) coordinates
to which the spacecraft points. This is the pointing direction of the s/c.
The units are 10^04 deg, ie the values where multiplied by 10000 and
integerized.
[16] The "time_error" field contains the accuracy of the GRB timing information
(units are 10^-4 seconds). This is usually the sum of the time bin size
used for the image reconstruction and the propogation delay. It is expected
(by the INTEGRAL MOC) that type=55 packets (OFFLINE) will be corrected
for propogation delays.
[19] The "misc_att" field contains status and attitude information on the s/c.
The exact contents and format are still TBD at the INTEGRAL MOC.
There are a total of 23 "spare" items in the packet (usually filled
with zeros). They are located at items 11-12, 17-18, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=55 PACKET CONTENTS:
The INTEGRAL_OFFLINE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=55)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_sub_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 det_flags bits Detector flag bits
long 10 inten_sigma [centi-sigma] Burst_intensity_sigma*100
long 11 burst_error [arcsec] Burst location uncertainty
long 12 test_mpos flag_bits Test and Multi-Position flags
long 13 time_scale [10^-4 sec] Time sampling or trigger time
long 14 sc_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 15 sc_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 16 time_error [10^-4 sec] Accuracy of GRB time
long 17-18 spare[2] integer 8 bytes for the future
long 19 misc_att integer S/c status & attitude
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 51, 52, 53 , 54, or 55
that tells which type of packet this is and therefore what the contents are
(the contents change slightly between the various types). The types are:
51 = INTEGRAL_POINTDIR, 52 = INTEGRAL_SPIACS, 53 = INTEGRAL_WAKEUP,
54 = INTEGRAL_REFINED, and 55 = INTEGRAL_OFFLINE.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_sub_num" are the uniquely identifying serial numbers (main and sub)
assigned by the on-board INTEGRAL flight software to each trigger.
The lower 16 bits contain the trigger ("Alert") number, and the upper 16 bits
contain the Alert sub-number. The sub-number is always 0 for type=53;
goes from 1 to N for type=54; and N+1, N+2, ... for type=55.
The Alert number started with s/n=~1 just after launch (Oct 02) and
is currently (Oct2006) in the 3500s.
[5] The "burst_tjd" is the Truncated Julian Day of the INTEGRAL burst trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the INTEGRAL burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
(current epoch). These intrinsically floating point quantities
have been multiplied by 10000 and then integerized to make an integer quantity
with units of 10^-4-degrees.
[9] The "det_flags" ("trig_id") field contains bit_flags specifing
the trigger process. The bit packing of the "det_flags" entry in the packet
is unknown as yet (TBD at INTEGRAL MOC).
[10] The "intensity_sigma" field contains the intensity of the burst in sigma units,
essentially a signal/noise metric. The units are 'centi-sigma', ie the fl.pt.
sigma was multiplied by 100 and then integerized and put into the packet.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% c.l. of the bursts. The units are arcseconds.
[12] The "test_mpos" field contains the following bit_flags:
Bit_Number Item_name Description
---------- --------- -----------
0 multi_position 0=No or 1=Yes, the INTEGRAL Gnd s/w there was more
than one likely position for this burst.
In that case, the RA,Dec fields
????contain/do_not_contain????
the most likely position (I'm waiting
for info from the Ops team).
1-27 x_x_x_x spare
28 spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 def_not_grb 0=No or 1=Yes, it is definitely not a GRB.
31 test 0=No or 1=Yes, it is a Test_Notice.
[13] The "time_scale" field has the sampling interval used. For type=52 (SPIACS)
it is the lightcurve binning; for type=53 and 54 (WAKEUP and REFINED) it is
the SIT and IMITS that triggered; and for type=55 (OFFLINE) it is the TBD
duration of the burst.
[14-15] The "sc_ra" and "sc_dec" are the RA,Dec (J2000) coordinates
to which the spacecraft points. This is the pointing direction of the s/c.
The units are 10^04 deg, ie the values where multiplied by 10000 and
integerized.
[16] The "time_error" field contains the accuracy of the GRB timing information
(units are 10^-4 seconds). This is usually the sum of the time bin size
used for the image reconstruction and the propogation delay. It is expected
(by the INTEGRAL MOC) that type=55 packets (OFFLINE) will be corrected
for propogation delays.
[19] The "misc_att" field contains status and attitude information on the s/c.
The exact contents and format are still TBD at the INTEGRAL MOC.
There are a total of 23 "spare" items in the packet (usually filled
with zeros). They are located at items 11-12, 17-18, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=56 PACKET CONTENTS:
The INTEGRAL_WEAK packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=54)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_sub_num integers Trigger num & mesg sernum
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 det_flags bits Detector flag bits
long 10 inten_sigma [centi-sigma] Burst_intensity_sigma*100
long 11 burst_error [arcsec] Burst location uncertainty
long 12 test_mpos flag_bits Test and Multi-Position flags
long 13 time_scale [10^-4 sec] Time sampling or trigger time
long 14 sc_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 15 sc_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 16 time_error [10^-4 sec] Accuracy of GRB time
long 17-18 spare[2] integer 8 bytes for the future
long 19 misc_att integer S/c status & attitude
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 51, 52, 53 , 54, or 55
that tells which type of packet this is and therefore what the contents are
(the contents change slightly between the various types). The types are:
51 = INTEGRAL_POINTDIR, 52 = INTEGRAL_SPIACS, 53 = INTEGRAL_WAKEUP,
54 = INTEGRAL_REFINED, 55 = INTEGRAL_OFFLINE, and 56 = INTEGRAL_WEAK.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_sub_num" are the uniquely identifying serial numbers (main and sub)
assigned by the on-board INTEGRAL flight software to each trigger.
The lower 16 bits contain the trigger ("Alert") number, and the upper 16 bits
contain the Alert sub-number. The sub-number is always 0 for type=53;
goes from 1 to N for type=54; and N+1, N+2, ... for type=55.
The Alert number started with s/n=~1 just after launch (Oct 02) and
is currently (Oct2006) in the 3500s.
[5] The "burst_tjd" is the Truncated Julian Day of the INTEGRAL burst trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the INTEGRAL burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
(current epoch). These intrinsically floating point quantities
have been multiplied by 10000 and then integerized to make an integer quantity
with units of 10^-4-degrees.
[9] The "det_flags" ("trig_id") field contains bit_flags specifing
the trigger process. The bit packing of the "det_flags" entry in the packet
is unknown as yet (TBD at INTEGRAL MOC).
[10] The "intensity_sigma" field contains the intensity of the burst in sigma units,
essentially a signal/noise metric. The units are 'centi-sigma', ie the fl.pt.
sigma was multiplied by 100 and then integerized and put into the packet.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% c.l. of the bursts. The units are arcseconds.
[12] The "test_mpos" field contains the following bit_flags:
Bit_Number Item_name Description
---------- --------- -----------
0 multi_position 0=No or 1=Yes, the INTEGRAL Gnd s/w there was more
than one likely position for this burst.
In that case, the RA,Dec fields
????contain/do_not_contain????
the most likely position (I'm waiting
for info from the Ops team).
1-27 x_x_x_x spare
28 spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 def_not_grb 0=No or 1=Yes, it is definitely not a GRB.
31 test 0=No or 1=Yes, it is a Test_Notice.
[13] The "time_scale" field has the sampling interval used. For type=52 (SPIACS)
it is the lightcurve binning; for type=53 and 54 (WAKEUP and REFINED) it is
the SIT and IMITS that triggered; and for type=55 (OFFLINE) it is the TBD
duration of the burst.
[14-15] The "sc_ra" and "sc_dec" are the RA,Dec (J2000) coordinates
to which the spacecraft points. This is the pointing direction of the s/c.
The units are 10^04 deg, ie the values where multiplied by 10000 and
integerized.
[16] The "time_error" field contains the accuracy of the GRB timing information
(units are 10^-4 seconds). This is usually the sum of the time bin size
used for the image reconstruction and the propogation delay. It is expected
(by the INTEGRAL MOC) that type=55 packets (OFFLINE) will be corrected
for propogation delays.
[19] The "misc_att" field contains status and attitude information on the s/c.
The exact contents and format are still TBD at the INTEGRAL MOC.
There are a total of 23 "spare" items in the packet (usually filled
with zeros). They are located at items 11-12, 17-18, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=57 PACKET CONTENTS:
NOTE: This Type=57 (AAVSO) is NOT YET AVAILABLE.
The AAVSO packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=57)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integer 8 bytes for the future
long 11 event_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-17 spare[6] integer 24 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 57, which tells that this packet
is of type AAVSO and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the event_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is the uniquely identifying serial number for each event.
[5] The "event_tjd" is the Truncated Julian Day of the trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "event_sod" is the UT seconds-of-day (SOD) of the trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). This is the beginning of the 'duration' search window
of the successful trigger.
[7-8] The "event_ra" and "event_dec" are the RA,Dec coordinates of the event (J2000).
These intrinsically floating point quantities have been multiplied by 10,000
and then integerized to make an integer quantity with units of 0.0001-degrees.
[11] The "event_error" is the radius of the circle that will contain on average
TBD% of the event locations. The units are 0.0001-deg (ie the error was multiplied
by 10000 and then integerized).
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of transient event.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
//0 Subtype Notice sub-type: 0=Individual, 1=Coincidence
//1 test_flag Test-type: 0=Real, 1=Test
//2 radec_undef RA,Dec knowledge: 0=defined, 1=Undefined (no position known)
3-4 [not yet defined]
//5 retract 0=No or 1=Yes, it is definitely not a GRB (a Retraction)
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
//?
There are a total of 24 "spare" items in the packet (usually filled
with zeros). They are located at items 10, 14-17, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=58 PACKET CONTENTS:
The MILAGRO packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=58)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_sig [evts] Events [counts] (0 to infinity *10000)
long 10 bkg [0.0001-evts] Background events (0 to infinity *10000)
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 signif - (int)(-log10(signif) *100)
long 13 duration [centi-sec] (int)(0.0 to inf *100)
long 14 ann_rate [0.01*N/yr] (int)(0.0 to inf *100)
long 15 zenith [centi-deg] (int)(0.0 to +90.0 *100)
long 16-17 spare[2] integer 8 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 58, which tells that this packet
is of type MILAGRO and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is the uniquely identifying serial number
assigned by the MILAGRO software to each trigger.
[5] The "burst_tjd" is the Truncated Julian Day of the trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). This is the beginning of the 'duration' search window
of the successful trigger.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
as determined by the MILAGRO software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "signal" is actually the integrated fluence of the burst
over the duration of the trigger. The units are 'events' (ie counts).
Background events have NOT been subtracted.
[10] The "background" is the counts seen in a 2-hr interval prior to the trigger.
This intrinsically floating point quantity have been multiplied by 10,000 and
then integerized to make an integer quantity with units of 0.0001-events.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-deg (ie the error was multiplied
by 10000 and then integerized).
[12] The "signif" is the -100*log10(probability_of_false_detection).
It is only the statistical significance of the detection, or put another way,
-log10 of the probability that the source could be a natural fluctuation
within the Poisson background. It is typically a small number (10^-12),
but since there are a large number of trials, this by itself is not an indication
of whether this is real GRB or just a chance fluctuation. The annual_rate (see below)
will give a better handle on this aspect. The number stored in this location is actually
the negative base_ten log of the significance multiplied by 100 and then integerized.
[13] The "duration" is the time interval of the search window of the event_times stream
looking for an increase. The units are centi-seconds, ie fl.pt. seconds time 100,
then integerized.
[14] The "ann_rate" is the number of times per year that a fluctuation of this significance
at this duration interval is expected to be seen. The units are 0.01/year
(ie the annual rate has been multiplied by 100, then integerized, and poked
into the packet).
[15] The "zenith" is the MILAGRO instrument zenith angle of the trigger (burst)
as determined by the MILAGRO software. The units are centi-degrees.
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of transient event that triggered the MILAGRO instrument.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 possible_grb 0=No or 1=Yes, it is a possible GRB
1 definite_grb 0=No or 1=Yes, it is definitely a GRB
2-14 x_x_x_x spare
15 def_not_grb 0=No or 1=Yes, it is definitely not a GRB
16-31 x_x_x_x spare
[19] The "misc" field contains various bit_flags and the message sequence number.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0-3 short Subtype: 1=Short,2=medium(TBD),3=long(TBD)
4-23 x_x_x_x spare
24-31 seq_num The sequence number of this message
The first 4 bits are the Notice subtype. Currently, only the 'short' subtype
is defined, but there is provisions for other subtypes, tentatively identified
as 'medium' and 'long' timescales of trigger durations/methods.
The 'seq_num' is a sequentially assigned number for each trigger.
As ground-processing (automated and humans-in-the-loop) progresses,
successive messages may be issued. This sequence number keeps track
of those updates.
There are a total of 21 "spare" items in the packet (usually filled
with zeros). They are located at items 16-17, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=59 PACKET CONTENTS:
The KONUS_LIGHTCURVE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=59)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for the future
long 5 trigger_tjd [days] Truncated Julian Day
long 6 trigger_sod [centi-sec] (int)(sssss.sss *100)
long 7-14 spare[8] integer 32 bytes for the future
long 15 E_min integer Low end of the energy range
long 16 E_max integer Upper end of the energy range
long 17 hi_prec_sod [milli-sec] (int)(sssss.sss *1000)
long 18 trigger_id bits Trigger identification flags
long 19-21 spare[3] integer 12 bytes for the future
quad_char 22-38 url[17] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 59, which tells that this packet
is of type KONUS_LC and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[There is no "trig_num" for KONUS_LC at the time the notice is sent to GCN for distribution.
It is assigned later (1-7 days later) by the KONUS Team. It eventually appears on the Table page.]
[5] The "trigger_tjd" is the Truncated Julian Day of the trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "trigger_sod" is the UT seconds-of-day (SOD) of the trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[15-16] The "E_min" and "E_max" have the lower and upper ends of the energy range
used in making the countrate lightcurve.
[17] The "hi_prec_sod" is a hi-precission form of the seconds-of-day (SOD) of the trigger.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized). (ie it the same value as "trigger_sod", just one more decimal place)
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of event that triggered the KONUS instrument.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
//0 possible_grb 0=No or 1=Yes, it is a possible GRB
//1 definite_grb 0=No or 1=Yes, it is definitely a GRB
2-14 x_x_x_x spare
//15 def_not_grb 0=No or 1=Yes, it is definitely not a GRB
16-28 x_x_x_x spare
29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 x_x_x_x spare
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_k".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 15 "spare" items in the packet (usually filled
with zeros). They are located at items 7-21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=60 PACKET CONTENTS:
The SWIFT_BAT_GRB_ALERT packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=60)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7-15 spare[9] integer 40 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 spare integer 4 bytes for the future
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22-38 spare[17] integer 68 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
60 = SWIFT_BAT_GRB_ALERT, 61 = SWIFT_BAT_GRB_POSITION, 62 = SWIFT_BAT_GRB_NACK_POSITION,
63 = SWIFT_BAT_GRB_LIGHTCURVE. (Only the raw BAT Notices are listed here;
see later for the other Swift-XRT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 2004).
[5] The "trig_tjd" is the Truncated Julian Day of the Swift-BAT trigger,
eg. TJD=13370 is 01 Jan 2005. (Note that at the time when this Alert Notice
is issued, it is not yet known if this trigger is due to a real GRB,
or some non-GRB cause (eg. failed or false trigger).)
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the Swift-BAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). (Since this is the Alert Notice, it is not known yet
if this trigger is a real GRB or just a false trigger.)
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
There are a total of 28 "spare" items in the packet (usually filled
with zeros). They are located at items 7-16, 20, and 22-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=61 PACKET CONTENTS:
The SWIFT_BAT_GRB_POS_ACK packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=61)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flue [counts] Num events during trig window, 0 to inf
long 10 burst_ipeak [cnts*ff] Counts in image-plane peak, 0 to infinity
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +70.0 *100)
long 14 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22 bkg_flue [counts] Num events during the bkg interval, 0 to inf
long 23 bkg_start [centi-sec] (int)(sssss.sss *100)
long 24 bkg_dur [centi-sec] (int)(0-80,000 *100)
long 25 cat_num integer On-board cat match ID number
long 26-35 spare[10] integer 40 bytes for the future
long 36 merit_0-3 integers Merit params 0,1,2,3 (-127 to +127)
long 37 merit_4-7 integers Merit params 4,5,6,7 (-127 to +127)
long 38 merit_8-9 integers Merit params 8,9 (-127 to +127)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
60 = SWIFT_BAT_GRB_ALERT, 61 = SWIFT_BAT_GRB_POSITION, 62 = SWIFT_BAT_GRB_NACK_POSITION,
63 = SWIFT_BAT_GRB_LIGHTCURVE. (Only the raw BAT Notices are listed here;
see later for the other Swift-XRT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by +/- 320 msec
for events that have a trigger duration less than 64 msec. This has to do with the way
that the flight software is optimized for execution speed for evaluating trigger criteria.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_flue" is the number of events (burst+background events)
during the 'integ_time' time interval of the successful trigger criterion.
[10] The "burst_ipeak" is the height of the peak in the sky-image plane (ie the result
of the FFT,MaskConvolution,InvFFT calculation). The units are counts
after a multiplicative factor of about 0.5-0.7.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). [Initially, this value was hardwired
at a constant value of 4arcmin (0.067deg) radius. As the mission progressed,
this changed to 3 arcmin. Eventually, it might become intensity-dependant.]
[12-13] The "phi" and "theta" are the BAT instrument coordinates of the trigger (burst)
as determined by the BAT flight software program. Phi is measured phi=0
along the +Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the BAT instrument (it would have
been better to call this the 'zenith' angle).
[14] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14 G was_subthresh 0=No or 1=Yes, this was originally a SubThresh, but it is now converted to a real BAT_POS
15 G onboard_rmvd 0=No or 1=Yes, this is a source that has purposefully been removed from on-board catalog
16 G nearby_gal 0=No or 1=Yes, this matched a Nearby_Galaxy in the on-board catalog
17-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-11 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it indicated the theta value was less than 10arcmin (ie Swift was already pointed at this source).
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real BAT_POS.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 When this bit is a 1, it means the Trig_Time was zero and so the s/c system clock
in the TDRSS Message SecondaryHeader was used to fill the Burst_TJD and Burst_SOD fields.
(This 0-Trig_Time scenario occurs during a ground-commanded GRB_TOO.)
2^24 When this bit is a 1, it indicates that the TDRSS Message was received on the ground
more than 60 sec after the BAT Trigger time. The most likely scenario for this kind of transmission delay
is that the BAT Trigger occured during a Malindi downlink pass (when TDRSS messages are blocked
from immediate transmission; they are buffered onboard until the end of the Malindi Pass).
2^25 This is an updated position. This is a position notice that changes/improves
the position specified in the original BAT_Position Notice.
2^26 Not assigned.
2^27 Not assigned.
2^28 When this bit is a 1, then this Notice was derived from a SERS message; else flight-generated.
If none of the regular position-containing messages are received via the real-time
TDRSS comm channel (eg BAT_Pos_Ack, BAT_LC, etc), then the SERS messages
(which come from pipe-line processing of the Malindi playback downlinked data)
will be used to generate a reconstituted BAT_Pos_Ack Notice. But since
the SERS message only contains a subset of the information is a regular TDRSS
messages, these SERS-reconstituted Notices will have (tbd) fields undefined.
These undefined fields are: tbd, tbd, tbd....
2^29 When this bit is a 1, then this Notice was reconstituted; else flight-generated.
If a BAT_LC is received from the s/c before a BAT_Pos is received,
then bits and pieces from other Notices will be used to generate a reconstituted
BAT_Pos Notice and it will be issued (with this flag bit set to 1).
But since the LC message only contains a subset of the information in a regular
TDRSS BAT_POS messages, these LC-reconstituted Notices will have (tbd) fields undefined.
These undefined fields are: tbd, tbd, tbd....
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a BAT_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there may be rare occaisions when a BAT_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[22] The "bkg_flue" is the total number of events in the time interval used
for the background subtraction of the detector_rate_map (used for the image calc).
The units are counts.
[23] The "bkg_start" is the starting time of the background interval.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). Note that not all trigger criteria have a background interval
specified, so this "bkg_start" value may be zero for some bursts.
[24] The "bkg_dur" is the duration of the background interval.
The units are in centi-seconds.
[25] The "cat_num" is the catalog number in the on-board catalog for sources
that match a known source in the on-board catalog. (Typically it is a number
in the low 10,000s, 12,000s, or 15,000s.)
[36-38] The "merit_0-3", "merit_4-7", and "merit_8-9" are the 10 merit parameters
for this burst. Their values range from -127 to +127. These 'merit params'
are different than the 'merit_value' that is in the SWIFT_FOM_OBS and SWIFT_SC_SLEW
messages. There are 4, 4, & 2 values packed into these 3 longs. The packing order
is "0" in the lowest_address byte in the long, "1" is in the next_lowest, etc.
The definition of the 10 parameters is:
Param Description
0 Flag bit indicating GRB or not (1 or 0, resp).
1 Flag bit indicating Transient or not (1 or 0, resp); unknown src with T_trig>64sec.
2 Flag bit indicating Known_src or not (1 or 0, resp); Known_src matches something in on-board catalog.
3 Trigger duration (log2(t_trig/1024msec)).
4 Trigger energy range (0=15-25,1=15-50,2=25-100,3=50-350).
5 Image significance
6 Is it observable (-1 if w/in 30deg of Moon; -5, 20deg Moon; -100, 45deg Sun).
7 Flag bit indicating in a confused or obscurred region (ie Gal Center or Plane).
8 Sun distance (-100*cos(sun_angular_dist)).
9 An offset param to bias for/against PPTs and TOOs wrt ATs (norm param).
There are a total of 13 "spare" items in the packet (usually filled
with zeros). They are located at items 15-16 and 25-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=62 PACKET CONTENTS:
The SWIFT_BAT_GRB_POS_NACK packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=62)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7-13 spare[7] integer 28 bytes for the future
long 14 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22 bkg_flue [counts] Num events during the bkg interval, 0 to inf
long 23 bkg_start [centi-sec] (int)(sssss.sss *100)
long 24 bkg_dur [centi-sec] (int)(0-80,000 *100)
long 25-35 spare[11] integer 44 bytes for the future
long 36 merit_0-3 integers Merit params 0,1,2,3 (-127 to +127)
long 37 merit_4-7 integers Merit params 4,5,6,7 (-127 to +127)
long 38 merit_8-9 integers Merit params 8,9 (-127 to +127)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
60 = SWIFT_BAT_GRB_ALERT, 61 = SWIFT_BAT_GRB_POSITION, 62 = SWIFT_BAT_GRB_NACK_POSITION,
63 = SWIFT_BAT_GRB_LIGHTCURVE. (Only the raw BAT Notices are listed here;
see later for the other Swift-XRT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "trig_tjd" is the Truncated Julian Day of the Swift-BAT trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the Swift-BAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[14] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" field contains flag bits on the type of solution that would
found in the FFT sky image and about whether it matches anything in the
on-board source catalog.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12-21 Not assigned.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 When this bit is a 1, then this Notice was derived from a SERS message; else flight-generated.
If the regular BAT_POS_NACK is not received via the real-time TDRSS comm channel,
then the SERS message (which comes from pipe-line processing of the Malindi
playback downlinked data) will be used to generate a reconstituted BAT_Pos_Nack Notice.
But since the SERS message only contains a subset of the information is a regular TDRSS
message, these SERS-reconstituted Notices will have (tbd) fields undefined.
These undefined fields are: tbd, tbd, tbd....
2^29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if the Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the trigger has been determined to be non-GRB by humans,
a BAT_Pos_Nack Notice will be issued (with this flag bit set to 1).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field is always zero for BAT_Pos_Nack packets.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field is always zero for BAT_Pos_Nack packets.
[22] The "bkg_flue" is the total number of events in the time interval used
for the background subtraction of the detector_rate_map (used for the image calc).
The units are counts.
This field is always zero for BAT_Pos_Nack packets.
[23] The "bkg_start" is the starting time of the background interval.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
This field is always zero for BAT_Pos_Nack packets.
[24] The "bkg_dur" is the duration of the background interval.
The units are in centi-seconds.
This field is always zero for BAT_Pos_Nack packets.
[36-38] The "merit_0-3", "merit_4-7", and "merit_8-9" are the 10 merit parameters
for this burst. Their values range from -127 to +127. These 'merit params'
are different than the 'merit_value' that is in the SWIFT_FOM_OBS and SWIFT_SC_SLEW
messages. There are 4, 4, & 2 values packed into these 3 longs. The packing order
is "0" in the lowest_address byte in the long, "1" is in the next_lowest, etc.
These fields are always zero for BAT_Pos_Nack packets.
There are a total of 20 "spare" items in the packet (usually filled
with zeros). They are located at items 7-13, 15-16, and 25-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=63 PACKET CONTENTS:
The SWIFT_BAT_GRB_LC packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=63)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-11 spare[3] integer 12 bytes for the future
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +70.0 *100)
long 14 delta_time [centi-sec] (int)(ssss.sss *100)
long 15 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
quad_char 22-38 url[17] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
60 = SWIFT_BAT_GRB_ALERT, 61 = SWIFT_BAT_GRB_POSITION, 62 = SWIFT_BAT_GRB_NACK_POSITION,
63 = SWIFT_BAT_GRB_LIGHTCURVE. (Only the raw BAT Notices are listed here;
see later for the other Swift-XRT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These will always be
the same values as in the SWIFT_BAT_POS_ACK packet. These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[12-13] The "phi" and "theta" are the BAT instrument coordinates of the trigger (burst)
as determined by the BAT flight software program. Phi is measured phi=0
along the +Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the BAT instrument.
[14] The "delta_time" is the difference between the first sample in the lightcurve
and the Trigger_time. The units are centi-seconds (although they will always be whole sec).
This will almost always be -37.00 sec; only when packets are lost will this be some
other value.
[15] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. This particular field is copied from the BAT_POS
notice. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
(This 16-th 4-byte field is only defined/valid for packets if the 2^24 bit is set
in the 'misc' field.)
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" (aka trigger_id) field contains flag bits copied from the BAT_POS_ACK
ie (a) flag bits on the type of solution that was found in the on-board image and
about whether it matches anything in the on-board source catalog, and
(b) flag bits that are assigned in the GCN ground-processing.
(This 18-th 4-byte field is only defined/valid for packets (a) if the 2^24 bit is set
in the 'misc' field, and (b) if it was generated after 03 May 05 (the time
when the distribution order of the BAT_POS and FOM_OBS packets was changed
to allow for the filling of this field and to allow for the filtering of FOM_OBS
based on these trigger_id bits).)
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14 - spare spare for future use
15 G onboard_rmvd 0=No or 1=Yes, this is a source that has purposefully been removed from on-board catalog
16 G nearby_gal 0=No or 1=Yes, this matched a Nearby_Galaxy in the on-board catalog
17-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0 When this bit is a 1, it indicates that the BAT_Pos TDRSS message was not received for this TrigNum.
2^1-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real BAT_LC.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 This includes "extended" data packets.
2^24 This bit is set if the 'soln_status' field was copied to here from BAT_POS_ACK.
2^25 When this bit is a 1, then this Notice was generated with the 3rd of 3 pkts missing.
2^26 When this bit is a 1, then this Notice was generated with the 2nd of 3 pkts missing.
2^27 When this bit is a 1, then this Notice was generated with the 1st of 3 pkts missing.
2^28 Not assigned.
2^29 This bit is set if this LightCurve Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always 0 for the 'raw' form of this Notice (type=63) and
1 for the ground-processed form (type=76) or the imported-form of type=63.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field was copied from the BAT_POS notice.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field was copied from the BAT_POS notice.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 6 "spare" items in the packet (usually filled
with zeros). They are located at items 9-11, 15-16 and 18.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=64 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_BAT_SCALED_MAP packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=64)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 map_tjd [days] Truncated Julian Day
long 6 map_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-13 spare[5] integer 20 bytes for the future
long 14 foregnd_dur [mSec] Duration of the foreground interval, 1 to inf
long 15 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index [not assigned]
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
quad_char 22-38 url[17] chars The URL for the ScaledMap
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "map_tjd" is the Truncated Julian Day when the map was generated.
eg. TJD=13370 is 01 Jan 2005.
[6] The "map_sod" is the UT seconds-of-day (SOD) when the map was generated.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates of the pointing direction
of the s/c at the start/stop? of the integration interval for this map (J2000).
These intrinsically floating point quantities have been multiplied
by 10,000 and then integerized to make an integer quantity with units of 0.0001-degrees.
[14] The "foregnd_dur" is the duration of the sampling interval
of the successful trigger criteria. This field is native to the ScaledMap notice
(unlike the next field which is copied from BAT_POS).
The units are milliseconds.
[15] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. This particular field is copied from the BAT_POS
notice. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
(This 16-th 4-byte field is only defined/valid if the 2^24 bit is set
in the 'misc' field.)
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
This field is not yet (if ever) assigned.
[18] The "soln_status" (aka trigger_id) field contains flag bits copied from the BAT_POS_ACK
ie (a) flag bits on the type of solution that was found in the on-board image and
about whether it matches anything in the on-board source catalog, and
(b) flag bits that are assigned in the GCN ground-processing.
(This 18-th 4-byte field is only defined/valid for packets (a) if the 2^24 bit is set
in the 'misc' field, and (b) if it was generated after 03 May 05 (the time
when the distribution order of the BAT_POS and FOM_OBS packets was changed
to allow for the filling of this field and to allow for the filtering of FOM_OBS
based on these trigger_id bits).)
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (mag less than 6.5).
14 - spare spare for future use
15 G onboard_rmvd 0=No or 1=Yes, this is a source that has purposefully been removed from on-board catalog
16 G nearby_gal 0=No or 1=Yes, this matched a Nearby_Galaxy in the on-board catalog
17-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0 When this bit is a 1, it indicates that the BAT_Pos TDRSS message was not received for this TrigNum.
2^1-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the BAT_Pos position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the BAT_Pos position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real BAT_SM.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 This bit is set if the 'soln_status' field was copied to here from BAT_POS_ACK.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this Scaled_Map Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field is copied from the BAT_Position Notice.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field is copied from the BAT_Position Notice.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 6 "spare" items in the packet (usually filled
with zeros). They are located at items 9-13 and 16.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=65 (and 46) PACKET CONTENTS:
The SWIFT_FOM_OBS (and SWIFT_TOO_FOM) packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=65 or =46)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 roll [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 10 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 11-14 spare[4] integer 16 bytes for the future
long 15 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 16 soln_status bits Type of source found
long 17 trig_index integer Rate_Trigger index
long 18 AT_slewFlags bits Two flag bits packed here
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22-37 spare[16] integer 64 bytes for the future
long 38 merit [centi-merit] (int)(Merit_value *100)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "roll" of the spacecraft (after this requested slew). This intrinsically
floating point quantity have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[10] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
This slot is empty for type=46.
[15] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. This particular field is copied from the BAT_POS
notice. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
(This 16-th 4-byte field is only defined/valid for type=65 packets and
if the 2^24 bit is set in the 'misc' field.)
[16] The "soln_status" (aka trigger_id) field contains flag bits copied from the BAT_POS_ACK
ie (a) flag bits on the type of solution that was found in the on-board image and
about whether it matches anything in the on-board source catalog, and
(b) flag bits that are assigned in the GCN ground-processing.
(This 16-th 4-byte field is only defined/valid for packets (a) if the 2^24 bit is set
in the 'misc' field, and (b) if it was generated after 03 May 05 (the time
when the distribution order of the BAT_POS and FOM_OBS packets was changed
to allow for the filling of this field and to allow for the filtering of FOM_OBS
based on these trigger_id bits). Note that this is a non-standard location
for the "soln_status" field in the Swift series of notices.)
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14 - spare spare for future use
15 G onboard_rmvd 0=No or 1=Yes, this is a source that has purposefully been removed from on-board catalog
16 G nearby_gal 0=No or 1=Yes, this matched a Nearby_Galaxy in the on-board catalog
17-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "at_slew_flags" field contains two flag bits related to the status
of the given burst wrt the Automated Target (AT) and Slewing.
The bits are:
2^0 Is this burst worthy of becoming the new Automated Target: 1=yes
2^1 Is this burst of sufficient merit to request a s/c slew: 1=yes
The AT is a special target that the Swift Observatory will keep coming back to
orbit after orbit without any ground commanding intervention. It is distinct
from the PrePlanned Targets (PPTs) that are in the uploaded stored observing table.
Whenever the AT is observable (ie no observing constraint is in effect),
then the AT will override any previous PPT. The override lasts for up to
a commandable amount of time -- typically 60,000 observed-seconds.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0 When this bit is a 1, it indicates that the BAT_Pos TDRSS message was not received for this TrigNum.
2^1-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real FOM.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 This bit is set if the FOM_OBS packet was delayed (to come after
the BAT_POS_ACK packet) so that the 'soln_status' field
could be added to this packet (copied from BAT_POS_ACK).
2^24 This bit is set if the 'soln_status' field was copied to here from BAT_POS_ACK.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this FOM_OBS Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a BAT_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there may be rare occaisions when a FOM_OBS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
(This 20-th 4-byte field is only defined/valid for type=65 packets and
if the 2^24 bit is set in the 'misc' field.)
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[38] The "merit_value" is the total calculated value for the given burst.
It is a fl.pt. quantity which can theoretically range from -infinity to
+infinity, but given normal operations, we expect it to range from about
-100 to +300. And for the first 6-12 months of flight-ops, it will be
forced to be a constant value of 100 for all bursts.
There are a total of 23 "spare" items in the packet (usually filled
with zeros). They are located at items 9-14, 20, and 22-37.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=66 (and 47) PACKET CONTENTS:
The SWIFT_SC_SLEW (and SWIFT_TOO_SC_SLEW) packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=66 or =47)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 roll [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 10 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 11-12 spare[2] integer 8 bytes for the future
long 13 wait_time [centi-sec] (int)(sssss.sss *100)
long 14 obs_time [centi-sec] (int)(sssss.sss *100)
long 15 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 16 soln_status bits Type of source/trigger found
long 17 trig_index integer Rate_Trigger index
long 18 slew_rtn integer 0=will_slew, non-0=wont
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22 bat_mode bits BAT configuration
long 23 xrt_mode bits XRT configuration
long 24 uvot_mode bits UVOT configuration
long 25-37 spare[13] integer 52 bytes for the future
long 38 merit [centi-merit] Merit_value *100
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "roll" of the spacecraft (after this requested slew). This intrinsically
floating point quantity have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[10] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[13] The "wait_time" is the number of seconds until the target becomes viewable.
A value of zero means that the spacecraft will slew immediately -- ie no waiting.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[14] The "obs_time" is the number of seconds the target is observable. (This value
does not reflect any time spent inside the SAA.)
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[15] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. This particular field is copied from the BAT_POS
notice. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
(This 16-th 4-byte field is only defined/valid for type=66 packets and
if the 2^24 bit is set in the 'misc' field.)
[16] The "soln_status" (aka trigger_id) field contains flag bits copied from the BAT_POS_ACK
ie (a) flag bits on the type of solution that was found in the on-board image and
about whether it matches anything in the on-board source catalog, and
(b) flag bits that are assigned in the GCN ground-processing.
(This 16-th 4-byte field is only defined/valid for packets (a) if the 2^24 bit is set
in the 'misc' field, and (b) if it was generated after 03 May 05 (the time
when the distribution order of the BAT_POS and FOM_OBS packets was changed
to allow for the filling of this field and to allow for the filtering of FOM_OBS
based on these trigger_id bits). Note that this is a non-standard location
for the "soln_status" field in the Swift series of notices.)
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14 - spare spare for future use
15 G onboard_rmvd 0=No or 1=Yes, this is a source that has purposefully been removed from on-board catalog
16 G nearby_gal 0=No or 1=Yes, this matched a Nearby_Galaxy in the on-board catalog
17-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "slew_rtn" is the return_code from the s/c for the given slew_request.
If value is zero, then the slew will be executed by the s/c;
if non-zero, then slew will not be executed. The non-zero values are:
1 Sun constraint,
2 Earth_limb constraint,
3 Moon constraint,
4 Ram_vector constraint,
5 invalid slew_request parameter.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0 When this bit is a 1, it indicates that the BAT_Pos TDRSS message was not received for this TrigNum.
2^1-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real SC_SLEW.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 This bit is set if the 'soln_status' field was copied to here from BAT_POS_ACK.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a BAT_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there may be rare occaisions when a SC_SLEW notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
(This 20-th 4-byte field is only defined/valid for type=65 packets.)
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[22-24] The 3 "modes" are configuration fields for each instrument.
[38] The "merit_value" is the total calculated value for the given burst.
It is a fl.pt. quantity which can theoretically range from -infinity to
+infinity, but given normal operations, we expect it to range from about
-100 to +500. And for the first 6-12 months of flight-ops, it will be
forced to be a constant value of 100 for all bursts.
The units are in centi-merit (ie the fl.pt. merit is multiplied by 100
and then integerized).
There are a total of 19 "spare" items in the packet (usually filled
with zeros). They are located at items 10-12, 15-16, 20, and 25-37.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=67 PACKET CONTENTS:
The SWIFT_XRT_POS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=67)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 data_tjd [days] Truncated Julian Day
long 6 data_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flux [flux] (int)(xrt_flux *100)
long 10 spare integer 4 bytes for the future
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 X_TAM_I1 [centi-pixel] (int)(tam[0]*100)
long 13 Y_TAM_I1 [centi-pixel] (int)(tam[1]*100)
long 14 X_TAM_I2 [centi-pixel] (int)(tam[2]*100)
long 15 Y_TAM_I2 [centi-pixel] (int)(tam[3]*100)
long 16 hi_prec_err [centi-arcsec] Hi-precission burst_error
long 17 Amp_Wave dual_int AmpNum*256 + WaveformNum
long 18 soln_status bits The type of event
long 19 misc bits Misc stuff packed in here
long 20 xrt-bat [0.0001-deg] Distance between XRT & BAT positions
long 21 det_signif [centi-sigma] (int)(det_signif *100)
long 22-38 spare[17] integer 68 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
67 = SWIFT_XRT_POS, 68 = SWIFT_XRT_SPEC, 69 = SWIFT_XRT_IMAGE,
70 = SWIFT_XRT_LC, and 71 = SWIFT_XRT_NACK_POS. (Only the raw XRT Notices are listed here;
see before and later for the other Swift-BAT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the data_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "data_tjd" is the Truncated Julian Day of the start of the CCD image
from which this position was extracted, eg. TJD=13370 is 01 Jan 2005.
[6] The "data_sod" is the UT seconds-of-day (SOD) of the start of the CCD image
from which this position was extracted, which will be very close
to the Swift-BAT burst_sod. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst/afterglow
as determined by the XRT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_flux" is the sum of pixel intensities that are between the low-level threshold
and an upper-level threshold divided by the exposure time and a fudge factor.
Note that the pixels intensities have NOT had the bias subtraction made,
so there is an offset to these flux estimates. [For now, the fudge factor is set to 1.]
This gives a crude relative brightness estimate of the afterglow source;
and is only intended for comparison of previous XRT detections.
After 14nov05 this field contains the approximate flux in CGS units [erg/cm2/sec]
multiplied by 10^14 and then integerized (eg if the field contains a value of 1230,
then the flux is 1.23x10^-11 erg/cm2/sec).
[11] The "burst_error" is the radius of the circle that will contain on average
90% of the bursts afterglow positions. It contains statistical plus
systematic contributions. [The value was hardcoded to be 6arcsec
for all Notices at the beginning of the mission -- as experience built,
this was replaced with a value that is dependant on the flux and/or significance
of the detection.] (See also the hi_prec_err below.)
[12-15] The "tam_x/y_1/2 are the positions of the TAM (Telescope Alignment Monitor)
in the 1st and 2nd images. The units are centi-tam_pixels; the values typically
range from 200.00 to 400.00. [These values should remain roughly constant
from Notice to Notice, ie the XRT tube is not flexing over time or temperature.]
[16] The "hi_prec_err" is the radius of the circle that will contain on average
90% of the bursts afterglow positions. It contains statistical plus
systematic contributions. This is different than the regular "burst_error"
in that the units are 'centi-arcsec' to remove quantization error of 0.36arcsec
introduced by the regular "burst_error" value.
[17] The "amp_wave" field has two values contained in the 32 bits.
The lower 8 bits (2^0-7) are the 'waveform number' of the readout.
And the next higher 8 bits (2^8-15) is the amplifier used during the readout.
The waveform number is typically 134. The amplifier number is typically 2.
[18] The "soln_status" (aka "trigger_id")field contains flag bits on the type of solution that was found.
The bit packing of the "soln_status" entry in the packet is:
The bit packing is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G cosmic_ray 0=No or 1=Yes, this is probably a cosmic ray.
1 - undef Not yet defined.
2 - undef Not yet defined.
3 - undef Not yet defined.
4 - undef Not yet defined.
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-7 - undef Not yet defined.
8 G gnd_cat_src 0=No or 1=Yes, BAT_loc is in the BAT ground catalog
9-13 - undef Not yet defined.
14 G was_subthresh 0=No or 1=Yes, this was originally a SubThresh, but it is now converted to a real XRT_POS
15-27 - undef Not yet defined.
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - undef Not yet defined.
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0 When this bit is a 1, it indicates that the BAT_Pos TDRSS message was not received for this TrigNum.
2^1-9 Not assigned.
2^10 When this bit is a 1, it indicates that the centroided position was more than 100 rows or columns
from the center of the FOV (ie likely not a real astrophysical peak).
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16 When this bit is a 1, it indicated the theta value was less than 10arcmin (ie Swift was already pointed at this source).
2^17-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_POS.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 This bit is set if the XRT_POS packet was momentarily (few sec) delayed
so that the XRT_IMAGE message could be interrogated to determine
the 'gain' of the image that generated the xrt_position.
2^24 Not assigned.
2^25 This is an updated position. This is a position notice that changes/improves
the position specified in the original XRT_Position Notice.
2^26 Not assigned.
2^27 Not assigned.
2^28 When this bit is a 1, then this Notice was derived from a SERS message; else flight-generated.
If the regular xrt_position message was not received via the real-time
TDRSS comm channel, then the SERS message (which come from pipe-line processing
of the Malindi playback downlinked data) will be used to generate a reconstituted
XRT_Pos_Ack Notice. But since the SERS message only contains a subset of the
information is a regular TDRSS messages, these SERS-reconstituted Notices
will have (tbd) fields undefined. These undefined fields are: tbd, tbd, tbd....
2^29 When this bit is a 1, then this Notice was reconstituted from information
from the XRT_IMAGE notice. It was generated on the ground because the XRT_POS notice
was not received on the ground after a fixed amount of time (~200 sec). Presumably
the original XRT_POS was lost due to a TDRSS telemetry gap. We have reconstituted
most of the contents of an XRT_POS notice from information from the XRT_IMAGE notice.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "xrt-bat" is the angular distance between the XRT position and the BAT position.
This intrinsically floating point quantity have been multiplied by 10,000 and
then integerized to make an integer quantity with units of 0.0001-degrees.
[21] The "det_signif" is a measure of the significance of the afterglow detection.
It is the square root of the number of pixels above threshold. Because of the
limited dynamic range of the pixel intensities in the CCD in this initial image,
the "det_signif" suffers from saturation problems. Example: a det_signif of 5
means there were 25 pixels above threshold, but if there were 1000 pixels,
then the photon pile-up in those pixels will be significant and the "det_signif"
of 32 will not be an accurate measure of the significance (ie it will be under-valued).
There are a total of 10 "spare" items in the packet (usually filled
with zeros). They are located at items 10, 18, 20, and 22-28.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=68 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_XRT_SPEC packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=68)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 SpecStart_tjd[days] Truncated Julian Day
long 6 SpecStart_sod[centi-sec] (int)(sssss.sss *100)
long 7 bore_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 bore_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 LiveTime [centi-sec] (int)(sssss.sss *100)
long 10 SpecStopTJD [days] Truncated Julian Day
long 11 SpecStopSOD [centi-sec] (int)(sssss.sss *100)
long 12 mode integer XRT operational mode
long 13 waveform integer Waveform number (50 or 60)
long 14 bias [ADU] Bias value
long 15-18 spare[4] integer 16 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20 spare integer 4 bytes for the future
long 21 term_code integer Termination condition code
quad_char 22-38 url[17] chars The URL for the spectrum
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
67 = SWIFT_XRT_POS, 68 = SWIFT_XRT_SPEC, 69 = SWIFT_XRT_IMAGE,
70 = SWIFT_XRT_LC, and 71 = SWIFT_XRT_NACK_POS. (Only the raw XRT Notices are listed here;
see before and later for the other Swift-BAT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "SpecStart_tjd" is the Truncated Julian Day of the start of the first
CCD integration in the spectrum accumulation, eg. TJD=13370 is 01 Jan 2005.
[6] The "SpecStart_sod" is the UT seconds-of-day (SOD) of the start of the first
CCD integration in the spectrum accumulation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[7-8] The "bore_ra/dec" is the RA,dec of the XRT bore sight (J2000 epoch).
This is the center of the FOV of the XRT image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "live_time" is the exposure time duration of the spectrum integration.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[10] The "SpecStop_tjd" is the Truncated Julian Day of the last CCD integration
in the spectrum accumulation, eg. TJD=13370 is 01 Jan 2005.
[11] The "SpecStop_sod" is the UT seconds-of-day (SOD) of the last CCD integration
in the spectrum accumulation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[12] The "mode" is the CCD Readout mode. The values are:
1 Null
2 Short image
3 Long image
4 Piled-up Photodiode
5 Low Rate Photodiode
6 Windowed Timing
7 Photo-counting
8 Raw data
9 Bias map
10 Stop
[13] The "waveform" is the CCD waveform ID. The values are either 50 or 60.
[14] The "bias" is the bias value of the last LRPD frame (ignore this for WT spectrum).
The units are ADU.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, it indicates that there is nearby bright star (mag less than 6.5).
2^14-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_SPEC.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 When this bit is a 1, then this Notice was generated with the 3rd of 3 pkts missing.
2^26 When this bit is a 1, then this Notice was generated with the 2nd of 3 pkts missing.
2^27 When this bit is a 1, then this Notice was generated with the 1st of 3 pkts missing.
2^28 Not assigned.
2^29 This bit is set if this XRT_SPECTRUM Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always 0 for the 'raw' form of this Notice (type=68) and
1 for the ground-processed form (type=77).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[21] The "term_cond" is the termination condition of the lightcurve collection process.
The values are:
0 Normal,
1 Terminated by time,
2 Terminated by snapshot,
3 Terminated by entering SAA,
4 Spectrum generated at the LRPD-to-WT transition,
5 Spectrum generated at the WT-to-LRorPC transition.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 5 "spare" items in the packet (usually filled
with zeros). They are located at items 15-18, and 20.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=69 PACKET CONTENTS:
The SWIFT_XRT_IMAGE packet (aka postage-stamp image) consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=69)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 ImgStartTJD [days] Image Start Truncated Julian Day
long 6 ImgStartSOD [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_bright [pixels] Num of bright pixels in the image
long 10 spare integer 4 bytes for the future
long 11 cent_sdev [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 12 cent_x [centi-pixels] (int)(xxx.xx *100)
long 13 cent_y [centi-pixels] (int)(yyy.yy *100)
long 14 iraw_x [pixels] Center of the 51x51 pixel postage stamp image
long 15 iraw_y [pixels] Center of the 51x51 pixel postage stamp image
long 16 roll [0.0001-deg] (int)(-180.0 to +180.0 *10000)
long 17 gain/mod/wav mixed gain, mode, & waveform; ints
long 18 expo_time [centi-sec] (int)(sssss.sss *100)
long 19 misc bits Misc stuff packed in here
long 20 grb_in_xrt_y [centi-pixels] Position of GRB afterglow in XRT pixels*100
long 21 grb_in_xrt_z [centi-pixels] Position of GRB afterglow in XRT pixels*100
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
67 = SWIFT_XRT_POS, 68 = SWIFT_XRT_SPEC, 69 = SWIFT_XRT_IMAGE,
70 = SWIFT_XRT_LC, and 71 = SWIFT_XRT_NACK_POS. (Only the raw XRT Notices are listed here;
see before and later for the other Swift-BAT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "ImgStart_tjd" is the Truncated Julian Day of the start of the CCD image integration.
eg. TJD=13370 is 01 Jan 2005.
[6] The "ImgStart_sod" is the UT seconds-of-day (SOD) start of the CCD image integration.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra/dec" is the RA,dec of the centroid of the source found
in the image (J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "n_bright" is the number of bright pixels in the 51x51 postage-stamp image,
where bright means the pixel intensity is above the LLD and below the ULD thresholds.
[11] The "cent_sdev" is the standard deviation of the centroid peak in the image.
The units are 0.0001-degrees (ie the fl.pt. std_dev was multiplied by 10000
and then integerized).
[12-13] The "cent_x/y" is the centroid position in raw units.
The units are centi-pixels (ie the fl.pt. position was multiplied by 100
and then integerized).
[14-15] The "iraw_x/y" are the row/column numbers (in units of CCD pixels) of the center
of the 51x51 pixel image that is this 'postage-stamp' subarray of the whole CCD.
[16] The "roll" angle of the spacecraft. This intrinsically floating point quantity
has been multiplied by 10,000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
[17] The "gain/mod/wav" is a triplet of 1-byte values in a single 4-byte quantity.
The "gain" is the gain of the amplifier used during the readout of the CCD.
It is packed in bits 2^16-23. The value will be 1, 2, 4, 8, or 16. If the gain
is greater than 1, then the "object" in the image is likely due to a cosmic ray,
and not due to a GRB afterglow.
The "mode" is the CCD Readout mode. It is packed in bits 2^8-15. The values are:
1 Null
2 Short image
3 Long image
4 Piled-up Photodiode
5 Low Rate Photodiode
6 Windowed Timing
7 Photo-counting
8 Raw data
9 Bias map
10 Stop
The "waveform" is the CCD waveform ID. It is packed in bits 2^0-7.
[18] The "expo_time" is the nominal exposure time for this image.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-9 Not assigned.
2^10 When this bit is a 1, it indicates that the centroided position was more than 100 rows or columns
from the center of the FOV (ie likely not a real astrophysical peak).
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_IMAGE.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 When this bit is a 1, then this Notice was generated with the 3rd of 3 pkts missing.
2^26 When this bit is a 1, then this Notice was generated with the 2nd of 3 pkts missing.
2^27 When this bit is a 1, then this Notice was generated with the 1st of 3 pkts missing.
2^28 Not assigned.
2^29 This bit is set if this XRT_IMAGE Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always 0 for the 'raw' form of this Notice (type=69) and
1 for the ground-processed form (type=78).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20-21] The "grb_in_xrt_y/z" is the GRB x-ray afterglow position in XRT coordinates.
The units are centi-pixels (but this was overkill because the intrinsic numbers
are in XRT CCD row,col pixels, so there is no non-zero fractional portion).
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There is a total of 1 "spare" items in the packet (usually filled
with zeros). It is located at item 10.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=70 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_XRT_LC packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=70)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 start_tjd [days] Truncated Julian Day
long 6 start_sod [centi-sec] (int)(sssss.sss *100)
long 7 bore_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 bore_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 live_time [centi-sec] (int)(sssss.sss *100)
long 10 stop_tjd [days] Truncated Julian Day
long 11 stop_sod [centi-sec] (int)(sssss.sss *100)
long 12-18 spare[7] integer 28 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20 n_bins integer Number of valid bins in lightcurve
long 21 term_cond integer Termination condition
long 20-21 spare[2] integer 8 bytes for the future
quad_char 22-38 url[17] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
67 = SWIFT_XRT_POS, 68 = SWIFT_XRT_SPEC, 69 = SWIFT_XRT_IMAGE,
70 = SWIFT_XRT_LC, and 71 = SWIFT_XRT_NACK_POS. (Only the raw XRT Notices are listed here;
see before and later for the other Swift-BAT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "start_tjd" is the Truncated Julian Day of the start of the first
CCD integration in the lightcurve accumulation, eg. TJD=13370 is 01 Jan 2005.
[6] The "start_sod" is the UT seconds-of-day (SOD) of the start of the first
CCD integration in the lightcurve accumulation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[7-8] The "bore_ra/dec" is the RA,dec of the XRT bore sight (J2000 epoch).
This is the center of the FOV of the XRT. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "live_time" is the exposure time duration of the lightcurve integration.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[10] The "SpecStop_tjd" is the Truncated Julian Day of the last CCD integration
in the lightcurve accumulation, eg. TJD=13370 is 01 Jan 2005.
[11] The "SpecStop_sod" is the UT seconds-of-day (SOD) of the last CCD integration
in the lightcurve accumulation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, there is a nearby bright star (mag less than 6.5).
2^14-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_LC.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 Not assigned.
2^30 Not assigned.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "n_bins" is the number of valid bins in the collected lightcurve (0-100).
[21] The "term_cond" is the termination condition of the lightcurve collection process.
The values are:
0 Normal (100 bins),
1 Terminated by time (1-99 bins),
2 Terminated by snapshot (1-99 bins),
3 Terminated by entering SAA (1-99 bins).
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 9 "spare" items in the packet (usually filled
with zeros). They are located at items 12-18 and 20-21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=71 PACKET CONTENTS:
The SWIFT_XRT_NACK_POS packet (aka centroid error) consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=71)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 data_tjd [days] Truncated Julian Day
long 6 data_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 centroid_cnt [cnts] Integer counts in centroid
long 10 min_cnt integer Minimum num cnts needed in centroid
long 11 centroid_std [0.0001-deg] StdDev of centroid
long 12 sig_max [0.0001-deg] Mx_Allowed_StdDev to be good
long 13-15 spare integer 12 bytes for the future
long 16 ph2_iter integer Number of iteration attempts
long 17 max_iter integer Max allowed number of attempts
long 18 err_flag integer Centroid rtn code: 1,2,3
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
67 = SWIFT_XRT_POS, 68 = SWIFT_XRT_SPEC, 69 = SWIFT_XRT_IMAGE,
70 = SWIFT_XRT_LC, and 71 = SWIFT_XRT_NACK_POS. (Only the raw XRT Notices are listed here;
see before and later for the other Swift-BAT/UVOT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "data_tjd" is the Truncated Julian Day when this data packet was generated on-board.
eg. TJD=13370 is 01 Jan 2005.
[6] The "data_sod" is the UT seconds-of-day (SOD) when this data packet was generated on-board,
which will be very close to the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "centroid_cnt" is the "calculated number of events" in the centroid.
The units are counts.
[10] The "min_count" is the minimum number of events needed to calculate
a proper centroid (ie a proper position).
The units are counts.
[11] The "centroid_std" is the standard deviation of any centroid found in the image.
The units are 0.0001-deg (ie the fl.pt. value multiplied by 10000 and
then integerized).
[12] The "sig_max" is the maximum allowable std-deviation for a valid centroid.
The units are 0.0001-deg (ie the fl.pt. value multiplied by 10000 and
then integerized).
[16] The "ph2_iter" is the number of iterations used in Phase 2 of the search
algorithm.
[17] The "max_iter" is the maximum number of iterations allowed in Phase 2
of the search algorithm.
[18] The "err_flag" is the error_code value for why a position was not found.
The values are: 1= no source found in image, 2= algorithm did not converge,
3= standard deviation too large, and 0xFFF= general error.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-4 Not assigned.
2^5 It is definitely not a GRB (bad label; its really a Retraction). Note that for this flagbit
is in a nonstandard field (MISC instead of the usual TRIGGER_ID) for this one pkt type.
2^6-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, there is a nearby bright star (mag less than 6.5).
2^14 SPER date was used (by the UL processing) to determine this trigger is a non-burst trigger.
2^15 No SPER date was used (by the UL processing) but it is still determined that this is a non-burst trigger.
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_POS_NACK.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 test_submit 0=No or 1=Yes, this is a test submission (internal use only). Non-std location!
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
There are a total of 22 "spare" items in the packet (usually filled
with zeros). They are located at items 13-15 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=72 PACKET CONTENTS:
The SWIFT_UVOT_IMAGE packet (aka DarkBurst, aka Genie) consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=72)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 ExpStart_tjd [days] Truncated Julian Day
long 6 ExpStart_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 image_roll [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 10 filter integer Which filter was used
long 11 expo_id [sec] Exposure_ID expressed in s/c_sec
long 12 X0 [det_coords] 0-2095
long 13 Y0 [det_coords] 0-2095
long 14 width [det_coords] 0-2095
long 15 height [det_coords] 0-2095
long 16 xy_grb [det_coords] 0-2095; two packed
long 17 n_frames integer 1-inf
long 18 swl_lwl integers 2 4-bit integers
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
72 = SWIFT_UVOT_IMAGE, and 73 = SWIFT_UVOT_SRCLIST (Only the raw UVOT Notices are listed here;
see before and later for the other Swift-BAT/XRT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "ExpStart_tjd" is the Truncated Julian Day of the start of the CCD integration,
eg. TJD=13370 is 01 Jan 2005.
[6] The "ExpStart_sod" is the UT seconds-of-day (SOD) of the start of the CCD integration.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100 and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "image_roll" is the Roll of the target.
This intrinsically floating point quantity has been multiplied by 10,000
and then integerized to make an integer quantity with units of 0.0001-degrees.
[10] The "filter" is the filter used for the image. The values are:
0 Blocked
1 UV_Grism
2 UVW2
3 V
4 UVM2
5 Vis_Grism
6 UVW1
7 U
8 Magnifier
9 B
10 White
11 unknown
[11] The "expo_id" is the exposure_ID expressed in spacecraft seconds.
(???what is range? ambiguity????)
[12-13] The "X/Y_offset" are the coordinates of pixel_zero in the Image subarray.
The units are detector coordinates: 0-2095.
[14-15] The "width" and "height" are the sizes of the Image subarray.
The units are detector coordinates: 0-2095.
[16] The "xy_grb" is the position of the GRB in unbinned detector units. The source
of this position is determined by the 2^28 bit in the "misc" field.
[17] The "n_frames" is the total number of read-out frames that went into
compiling this Image.
[18] The "swl_lwl" is the 'short word length' and the 'long word length' used
in the compress of the as-transmitted image packet. There is no compression
in the GCN-version of this Notice (so they are pretty much useless by the time
it gets to GCN distribution).
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-3 Four bits encoding the pixel binning, eg =0 means 1x1 binning (ie none), =1 mean 2x2 binning,
=2 means 4x4 binning, up to =6 mean 64x64 binning.
2^4-10 The height of the Detector Window used in the "Blue" Processing Electronics.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, there is a nearby bright star (mag less than 6.5).
2^14-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real UVOT_IMAGE.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 When this bit is a 1, then the source of the GRB Position came from an XRT Position command,
else it came from the Window Position in the Mode command.
2^29 This bit is set if this UVOT_IMAGE Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always 0 for the 'raw' form of this Notice (type=72) and
1 for the ground-processed form (type=79).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 2 "spare" items in the packet (usually filled
with zeros). They are located at items 20-21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=73 PACKET CONTENTS:
The SWIFT_UVOT_SRCLIST packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=73)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 start_tjd [days] Truncated Julian Day
long 6 start_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 image_roll [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 10 filter integer Which filter was used
long 11 bkg_mean [0.001-dn] Mean of the background
long 12 x_max [det_coords] 0-2095
long 13 y_max [det_coords] 0-2095
long 14 n_stars integer 1-infinity
long 15 x_offset [det_coords] 0-2095
long 16 y_offset [det_coords] 0-2095
long 17 det_thresh integer 0-????
long 18 photo_thresh integer 0-????
long 19 misc bits Misc stuff packed in here
long 20-22 spare[2] integer 8 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
72 = SWIFT_UVOT_IMAGE, and 73 = SWIFT_UVOT_SRCLIST (Only the raw UVOT Notices are listed here;
see before and later for the other Swift-BAT/XRT Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "Start_tjd" is the Truncated Julian Day of the start of the Finding Chart
CCD integration, eg. TJD=13370 is 01 Jan 2005.
[6] The "Start_sod" is the UT seconds-of-day (SOD) of the start of the Finding Chart
CCD integration. The units are in centi-seconds (ie the fl.pt. seconds were multiplied
by 100 and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "image_roll" is the Roll of the target.
This intrinsically floating point quantity has been multiplied by 10,000
and then integerized to make an integer quantity with units of 0.0001-degrees.
[10] The "filter" is the filter used for the image. The values are:
0 Blocked
1 UV_Grism
2 UVW2
3 V
4 UVM2
5 Vis_Grism
6 UVW1
7 U
8 Magnifier
9 B
10 White
11 unknown
[11] The "bkg_mean" is the mean value of the background level in the exposure.
This intrinsically floating point quantity has been multiplied by 1000
and then integerized to make an integer quantity with units of 0.001-degrees.
[12-13] The "x/y_max" are the maximum extent of the image window expressed
in detector coordinates (0-2095).
[14] The "n_stars" is the total number of stars in the source list.
[15-16] The "x/y_offset0" are the X and Y offsets of the image window expressed
in detector coordinates (0-2095).
[17] The "det_thresh" is the detection threshold used in this exposure.
The units are "dn" (digital number), and the range is 0 to ????.
[18] The "photo_thresh" is the photometry threshold used in this exposure.
The units are "dn" (digital number), and the range is 0 to ????.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, there is a nearby bright star (mag less than 6.5).
2^14-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real UVOT_SL.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this UVOT_SrcList Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always 0 for the 'raw' form of this Notice (type=73) and
1 for the ground-processed form (type=80).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 3 "spare" items in the packet (usually filled
with zeros). They are located at items 20-22.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=76 PACKET CONTENTS:
The SWIFT_BAT_GRB_LC_PROCESSED packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=76)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-11 spare[3] integer 12 bytes for the future
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +70.0 *100)
long 14 delta_time [centi-sec] (int)(ssss.sss *100)
long 15 spare integer 4 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
quad_char 22-38 url[17] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
76 = SWIFT_BAT_GRB_LIGHTCURVE_PROC, 77 = SWIFT_XRT_SPECTRUM_PROC,
78 = SWIFT_XRT_IMAGE_PROC, 79 = SWIFT_UVOT_IMAGE_PROC, and
80 = SWIFT_UVOT_SRCLIST_PROC. (Only the ground-processed Notices are listed here;
see before for all the other Swift Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These will always be
the same values as in the SWIFT_BAT_POS_ACK packet. These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[12-13] The "phi" and "theta" are the BAT instrument coordinates of the trigger (burst)
as determined by the BAT flight software program. Phi is measured phi=0
along the +Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the BAT instrument.
[14] The "delta_time" is the difference between the first sample in the lightcurve
and the Trigger_time. The units are centi-seconds (although they will always be whole sec).
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" (aka trigger_id) field contains flag bits copied from the BAT_POS_ACK
ie (a) flag bits on the type of solution that was found in the on-board image and
about whether it matches anything in the on-board source catalog, and
(b) flag bits that are assigned in the GCN ground-processing.
(This 18-th 4-byte field is only defined/valid for packets (a) if the 2^24 bit is set
in the 'misc' field, and (b) if it was generated after 03 May 05 (the time
when the distribution order of the BAT_POS and FOM_OBS packets was changed
to allow for the filling of this field and to allow for the filtering of FOM_OBS
based on these trigger_id bits).)
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
//2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
//2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
// is less than the sum of the position error radius and the galaxy radius AND that the position error radius
// is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
//2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
// is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
// is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real BAT_PROC_LC.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 This includes "extended" data packets.
2^24 This bit is set if the 'soln_status' field was copied to here from BAT_POS_ACK.
2^25 When this bit is a 1, then this Notice was generated with the 3rd of 3 pkts missing.
2^26 When this bit is a 1, then this Notice was generated with the 2nd of 3 pkts missing.
2^27 When this bit is a 1, then this Notice was generated with the 1st of 3 pkts missing.
2^28 When this bit is a 1, then this lightcurve contains GT 50 illegal values.
This is probably an empty lightcurve for a long image trigger.
2^29 This bit is set if this original 'raw' LightCurve Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always be 0 for the 'raw' form of this Notice (type=63) and
1 for this ground-processed form (type=76).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field was copied from the BAT_POS notice.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
This field was copied from the BAT_POS notice.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 4 "spare" items in the packet (usually filled
with zeros). They are located at items 9-11 and 15.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=77 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_XRT_SPEC_PROCESSED packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=77)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 SpecStart_tjd[days] Truncated Julian Day
long 6 SpecStart_sod[centi-sec] (int)(sssss.sss *100)
long 7 bore_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 bore_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 LiveTime [centi-sec] (int)(sssss.sss *100)
long 10 SpecStopTJD [days] Truncated Julian Day
long 11 SpecStopSOD [centi-sec] (int)(sssss.sss *100)
long 12 mode integer XRT operational mode
long 13 waveform integer Waveform number (50 or 60)
long 14 bias [ADU] Bias value
long 15-18 spare[4] integer 16 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20 spare integer 4 bytes for the future
long 21 term_code integer Termination condition code
quad_char 22-38 url[17] chars The URL for the spectrum
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
76 = SWIFT_BAT_GRB_LIGHTCURVE_PROC, 77 = SWIFT_XRT_SPECTRUM_PROC,
78 = SWIFT_XRT_IMAGE_PROC, 79 = SWIFT_UVOT_IMAGE_PROC, and
80 = SWIFT_UVOT_SRCLIST_PROC. (Only the ground-processed Notices are listed here;
see before for all the other Swift Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "SpecStart_tjd" is the Truncated Julian Day of the start of the first
CCD integration in the spectrum accumulation, eg. TJD=13370 is 01 Jan 2005.
[6] The "SpecStart_sod" is the UT seconds-of-day (SOD) of the start of the first
CCD integration in the spectrum accumulation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[7-8] The "bore_ra/dec" is the RA,dec of the XRT bore sight (J2000 epoch).
This is the center of the FOV of the XRT image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "live_time" is the exposure time duration of the spectrum integration.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[10] The "SpecStop_tjd" is the Truncated Julian Day of the last CCD integration
in the spectrum accumulation, eg. TJD=13370 is 01 Jan 2005.
[11] The "SpecStop_sod" is the UT seconds-of-day (SOD) of the last CCD integration
in the spectrum accumulation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[12] The "mode" is the CCD Readout mode. The values are:
1 Null
2 Short image
3 Long image
4 Piled-up Photodiode
5 Low Rate Photodiode
6 Windowed Timing
7 Photo-counting
8 Raw data
9 Bias map
10 Stop
[13] The "waveform" is the CCD waveform ID. The values are either 50 or 60.
[14] The "bias" is the bias value of the last LRPD frame (ignore this for WT spectrum).
The units are ADU.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, there is a nearby bright star (mag less than 6.5).
2^14-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_PROC_SPEC.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 When this bit is a 1, the xrt_proc_sp{1,2}.fits file had an error in processing and does not exist.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this original 'raw' Spectrum Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always be 0 for the 'raw' form of this Notice (type=68) and
1 for the ground-processed form (type=77).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[21] The "term_cond" is the termination condition of the lightcurve collection process.
The values are:
0 Normal,
1 Terminated by time,
2 Terminated by snapshot,
3 Terminated by entering SAA,
4 Spectrum generated at the LRPD-to-WT transition,
5 Spectrum generated at the WT-to-LRorPC transition.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 5 "spare" items in the packet (usually filled
with zeros). They are located at items 15-18, and 20.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=78 PACKET CONTENTS:
The SWIFT_XRT_IMAGE_PROCESSED packet (aka poststamp image) consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=78)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 ImgStartTJD [days] Image Start Truncated Julian Day
long 6 ImgStartSOD [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_bright [pixels] Num of bright pixels in the image
long 10 spare integer 4 bytes for the future
long 11 cent_sdev [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 12 cent_x [centi-pixels] (int)(xxx.xx *100)
long 13 cent_y [centi-pixels] (int)(yyy.yy *100)
long 14 iraw_x [pixels] Center of the 51x51 pixel postage stamp image
long 15 iraw_y [pixels] Center of the 51x51 pixel postage stamp image
long 16 roll [0.0001-deg] (int)(-180.0 to +180.0 *10000)
long 17 gain/mod/wav mixed gain, mode, & waveform; ints
long 18 expo_time [centi-sec] (int)(sssss.sss *100)
long 19 misc bits Misc stuff packed in here
long 20 grb_in_xrt_y [centi-pixels] Position of GRB afterglow in XRT pixels*100
long 21 grb_in_xrt_z [centi-pixels] Position of GRB afterglow in XRT pixels*100
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
76 = SWIFT_BAT_GRB_LIGHTCURVE_PROC, 77 = SWIFT_XRT_SPECTRUM_PROC,
78 = SWIFT_XRT_IMAGE_PROC, 79 = SWIFT_UVOT_IMAGE_PROC, and
80 = SWIFT_UVOT_SRCLIST_PROC. (Only the ground-processed Notices are listed here;
see before for all the other Swift Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "ImgStart_tjd" is the Truncated Julian Day of the start of the image integration.
eg. TJD=13370 is 01 Jan 2005.
[6] The "ImgStart_sod" is the UT seconds-of-day (SOD) start of the image integration.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra/dec" is the RA,dec of the centroid of the source found
in the image (J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "n_bright" is the number of bright pixels in the 51x51 postage-stamp image,
where bright means the pixel intensity is above the LLD and below the ULD thresholds.
[11] The "cent_sdev" is the standard deviation of the centroid peak in the image.
The units are 0.0001-degrees (ie the fl.pt. std_dev was multiplied by 10000
and then integerized).
[12-13] The "cent_x/y" is the centroid position in raw units.
The units are centi-pixels (ie the fl.pt. position was multiplied by 100
and then integerized).
[14-15] The "iraw_x/y" are the row/column numbers (in units of CCD pixels) of the center
of the 51x51 pixel image that is this 'postage-stamp' subarray of the whole CCD.
[16] The "roll" angle of the spacecraft. This intrinsically floating point quantity
has been multiplied by 10,000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
[17] The "gain/mod/wav" is a triplet of 1-byte values in a single 4-byte quantity.
The "gain" is the gain of the amplifier used during the readout of the CCD.
It is packed in bits 2^16-23. The value will be 1, 2, 4, 8, or 16.
The "mode" is the CCD Readout mode. It is packed in bits 2^8-15. The values are:
1 Null
2 Short image
3 Long image
4 Piled-up Photodiode
5 Low Rate Photodiode
6 Windowed Timing
7 Photo-counting
8 Raw data
9 Bias map
10 Stop
The "waveform" is the CCD waveform ID. It is packed in bits 2^0-7.
[18] The "expo_time" is the nominal exposure time for this image.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_PROC_IMAGE.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 When this bit is a 1, the xrt_proc_image.fits file had an error in processing and does not exist.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this original 'raw' Image Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always be 0 for the 'raw' form of this Notice (type=69) and
1 for the ground-processed form (type=78).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20-21] The "grb_in_xrt_y/z" is the GRB x-ray afterglow position in XRT coordinates.
The units are centi-pixels (but this was overkill because the intrinsic numbers
are in XRT CCD row,col pixels, so there is no non-zero fractional portion).
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There is a total of 1 "spare" items in the packet (usually filled
with zeros). It is located at item 10.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=79 PACKET CONTENTS:
The SWIFT_UVOT_IMAGE_PROCESSED packet (aka DarkBurst, aka Genie) consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=79)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 ExpStart_tjd [days] Truncated Julian Day
long 6 ExpStart_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 image_roll [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 10 filter integer Which filter was used
long 11 expo_id [sec] Exposure_ID expressed in s/c_sec
long 12 X0 [det_coords] 0-2095
long 13 Y0 [det_coords] 0-2095
long 14 width [det_coords] 0-2095
long 15 height [det_coords] 0-2095
long 16 xy_grb [det_coords] 0-2095; two packed
long 17 n_frames integer 1-inf
long 18 swl_lwl integers 2 4-bit integers
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
76 = SWIFT_BAT_GRB_LIGHTCURVE_PROC, 77 = SWIFT_XRT_SPECTRUM_PROC,
78 = SWIFT_XRT_IMAGE_PROC, 79 = SWIFT_UVOT_IMAGE_PROC, and
80 = SWIFT_UVOT_SRCLIST_PROC. (Only the ground-processed Notices are listed here;
see before for all the other Swift Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "ExpStart_tjd" is the Truncated Julian Day of the start of the CCD integration,
eg. TJD=13370 is 01 Jan 2005.
[6] The "ExpStart_sod" is the UT seconds-of-day (SOD) of the start of the CCD integration.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100 and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "image_roll" is the Roll of the target.
This intrinsically floating point quantity has been multiplied by 10,000
and then integerized to make an integer quantity with units of 0.0001-degrees.
[10] The "filter" is the filter used for the image. The values are:
0 Blocked
1 UV_Grism
2 UVW2
3 V
4 UVM2
5 Vis_Grism
6 UVW1
7 U
8 Magnifier
9 B
10 White
11 unknown
[11] The "expo_id" is the exposure_ID expressed in spacecraft seconds.
(???what is range? ambiguity????)
[12-13] The "X/Y_offset" are the coordinates of pixel_zero in the Image subarray.
The units are detector coordinates: 0-2095.
[14-15] The "width" and "height" are the sizes of the Image subarray.
The units are detector coordinates: 0-2095.
[16] The "xy_grb" is the position of the GRB in unbinned detector units. The source
of this position is determined by the 2^28 bit in the "misc" field.
[17] The "n_frames" is the total number of read-out frames that went into
compiling this Image.
[18] The "swl_lwl" is the 'short word length' and the 'long word length' used
in the compress of the as-transmitted image packet. There is no compression
in the GCN-version of this Notice (so they are pretty much useless by the time
it gets to GCN distribution).
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-3 Four bits encoding the pixel binning, eg =0 means 1x1 binning (ie none), =1 mean 2x2 binning,
=2 means 4x4 binning, up to =6 mean 64x64 binning.
2^4-10 The height of the Detector Window used in the "Blue" Processing Electronics.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, there is a nearby bright star (mag less than 6.5).
2^14-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real UVOT_PROC_IMAGE.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 When this bit is a 1, the uvot_sky_image.ps file had an error in processing and does not exist.
2^25 When this bit is a 1, the uvot_sources_image.fits file had an error in processing and does not exist.
2^26 When this bit is a 1, the uvot_catalog_image.fits file had an error in processing and does not exist.
2^27 When this bit is a 1, the uvot_field_image.ps file had an error in processing and does not exist.
2^28 When this bit is a 1, then the source of the GRB Position came from an XRT Position command,
else it came from the Window Position in the Mode command.
2^29 This bit is set if this original 'raw' Image Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always be 0 for the 'raw' form of this Notice (type=72) and
1 for the ground-processed form (type=79).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 2 "spare" items in the packet (usually filled
with zeros). They are located at items 20-21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=80 PACKET CONTENTS:
The SWIFT_UVOT_SRCLIST_PROCESSED packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=80)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 start_tjd [days] Truncated Julian Day
long 6 start_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 image_roll [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 10 filter integer Which filter was used
long 11 spare integer 4 bytes for the future
long 12 x_max [det_coords] 0-2095
long 13 y_max [det_coords] 0-2095
long 14 n_stars integer 1-infinity
long 15 x_offset [det_coords] 0-2095
long 16 y_offset [det_coords] 0-2095
long 17-18 spare[2] integer 8 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20-22 spare[2] integer 8 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
76 = SWIFT_BAT_GRB_LIGHTCURVE_PROC, 77 = SWIFT_XRT_SPECTRUM_PROC,
78 = SWIFT_XRT_IMAGE_PROC, 79 = SWIFT_UVOT_IMAGE_PROC, and
80 = SWIFT_UVOT_SRCLIST_PROC. (Only the ground-processed Notices are listed here;
see before for all the other Swift Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "Start_tjd" is the Truncated Julian Day of the start of the Finding Chart
CCD integration, eg. TJD=13370 is 01 Jan 2005.
[6] The "Start_sod" is the UT seconds-of-day (SOD) of the start of the Finding Chart
CCD integration. The units are in centi-seconds (ie the fl.pt. seconds were multiplied
by 100 and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9] The "image_roll" is the Roll of the target.
This intrinsically floating point quantity has been multiplied by 10,000
and then integerized to make an integer quantity with units of 0.0001-degrees.
[10] The "filter" is the filter used for the image. The values are:
0 Blocked
1 UV_Grism
2 UVW2
3 V
4 UVM2
5 Vis_Grism
6 UVW1
7 U
8 Magnifier
9 B
10 White
11 unknown
//The "bkg_mean" is the mean value of the background level in the exposure.
[12-13] The "x/y_max" are the maximum extent of the image window expressed
in detector coordinates (0-2095).
[14] The "n_stars" is the total number of stars in the source list.
[15-16] The "x/y_offset0" are the X and Y offsets of the image window expressed
in detector coordinates (0-2095).
//The "det_thresh" is the detection threshold used in this exposure.
//The units are "dn" (digital number), and the range is 0 to ????.
//The "photo_thresh" is the photometry threshold used in this exposure.
//The units are "dn" (digital number), and the range is 0 to ????.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, there is a nearby bright star (mag less than 6.5).
2^14-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real UVOT_PROC_SL.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 When this bit is a 1, the uvot_sky_srclist.ps file had an error in processing and does not exist.
2^25 When this bit is a 1, the uvot_sources_srclist.fits file had an error in processing and does not exist.
2^26 When this bit is a 1, the uvot_catalog_srclist.fits file had an error in processing and does not exist.
2^27 When this bit is a 1, the uvot_field_srclist.ps file had an error in processing and does not exist.
2^28 Not assigned.
2^29 This bit is set if this original 'raw' SrcList Noticed was forced-out via the watchdog timeout.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always be 0 for the 'raw' form of this Notice (type=73) and
1 for the ground-processed form (type=80).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 3 "spare" items in the packet (usually filled
with zeros). They are located at items 20-22.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=81 PACKET CONTENTS:
The SWIFT_UVOT_POS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=81)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_mag [arb] (int)(uvot_mag *100)
long 10 filter integer Filter_value: x-yy
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-15 spare[4] integer 16 bytes for the future
long 16 hi_prec_err [centi-arcsec] hi precission error
long 17 spare integer 24 bytes for the future
long 18 soln_status bits Type of source found
long 19 misc bits Misc stuff packed in here
long 20 mag_error [arb] (int)(mag_error *100)
long 21 uvot-xrt [0.0001-deg] Distance between XRT & UVOT pos
long 22-38 spare[17] integer 68 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
76 = SWIFT_BAT_GRB_LIGHTCURVE_PROC, 77 = SWIFT_XRT_SPECTRUM_PROC,
78 = SWIFT_XRT_IMAGE_PROC, 79 = SWIFT_UVOT_IMAGE_PROC, and
80 = SWIFT_UVOT_SRCLIST_PROC. (Only the ground-processed Notices are listed here;
see before for all the other Swift Notices type values.)
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-UVOT data,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-UVOT data.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the trigger/burst
as determined by the UVOT ground software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_mag" is the magnitude (in the specified filter) of the burst/afterglow.
The units are in centi-mag (ie the fl.pt. magnitude is multiplied by 100
and then integerized).
[10] The "filter" is the filter used for the image. The values are:
0 Blocked
1 UV_Grism
2 UVW2
3 V
4 UVM2
5 Vis_Grism
6 UVW1
7 U
8 Magnifier
9 B
10 White
11 unknown
[11] The "burst_error" is the radius of the circle that will contain on average
90% of the bursts afterglow positions. (See the "hi_prec_err" below.)
[16] The "hi_prec_err" is the radius of the circle that will contain on average
90% of the bursts afterglow positions. It contains statistical plus
systematic contributions. This is different than the regular "burst_error"
in that the units are 'centi-arcsec' to remove quantization error of 0.36arcsec
introduced by the regular "burst_error" value.
[18] The "soln_status" (aka "trig_id") field contains flag bits on the type of solution that was found.
The bit packing of the "soln_status" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 point_src 0=No or 1=Yes, a point source was found, 0=extended src
1 grb 0=No or 1=Yes, it is a GRB
2 undef Not yet defined.
3 catalog_src 0=No or 1=Yes, it is in the catalog (else unknown src)
4 undef Not yet defined.
5 def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-7 undef Not yet defined.
8 G gnd_cat_src 0=No or 1=Yes, BAT_loc is in the BAT ground catalog
9-27 undef Not yet defined.
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 undef Not yet defined.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-11 Not assigned.
2^12 When this bit is a 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
//2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
// is less than the sum of the position error radius and the galaxy radius AND that the position error radius
// is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
//2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
// is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
// is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-21 Not assigned.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 This is an updated position. This is a position notice that changes/improves
the position specified in the original UVOT_Position Notice.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "mag_error" is the uncertainty in the magnitude value (in the specified filter).
The units are in centi-mag (ie the fl.pt. mag_error is multiplied by 100
and then integerized).
[21] The "uvot-xrt" is the angular distance between the UVOT position and the XRT position.
This intrinsically floating point quantity have been multiplied by 10,000 and
then integerized to make an integer quantity with units of 0.0001-degrees.
There are a total of 23 "spare" items in the packet (usually filled
with zeros). They are located at items 12-15, 17, and 22-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=82 PACKET CONTENTS:
The SWIFT_BAT_GRB_POS_TEST packet consists of 40 four-byte quantities.
This is identical in form and content to SWIFT_BAT_GRB_POS_ACK(type=61)
in everything except the first 4-byte quantity: ie the pkt_type value
is 82 instead of 61.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=82)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flue [counts] Num events during trig window, 0 to inf
long 10 burst_ipeak [cnts*ff] Counts in image-plane peak, 0 to infinity
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +70.0 *100)
long 14 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22 bkg_flue [counts] Num events during the bkg interval, 0 to inf
long 23 bkg_start [centi-sec] (int)(sssss.sss *100)
long 24 bkg_dur [centi-sec] (int)(0-80,000 *100)
long 25-35 spare[11] integer 44 bytes for the future
long 36 merit_0-3 integers Merit params 0,1,2,3 (-127 to +127)
long 37 merit_4-7 integers Merit params 4,5,6,7 (-127 to +127)
long 38 merit_8-9 integers Merit params 8,9 (-127 to +127)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_BAT_GRB_POS_TEST is 82.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_flue" is the number of events (burst+background events)
during the 'integ_time' time interval of the successful trigger criterion.
[10] The "burst_ipeak" is the height of the peak in the sky-image plane (ie the result
of the FFT,MaskConvolution,InvFFT calculation). The units are counts
after a multiplicative factor of 0.5-0.7.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are centi-degrees (ie the fl.pt. error was multiplied
by 100 and then integerized). [Initially, this value will be hardwired
at a constant value of 4arcmin (0.067deg) radius. As the mission progresses,
this will be converted to a value which is dependent on the initial flux
of the burst.]
[12-13] The "phi" and "theta" are the BAT instrument coordinates of the trigger (burst)
as determined by the BAT flight software program. Phi is measured phi=0
along the +Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the BAT instrument.
[14] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
They will always be 0.00,0.00 for this Test notice.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" field contains flag bits on the type of solution that was
found in the FFT sky image and about whether it matches anything in the
on-board source catalog.
The bit packing of the "soln_status" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 point_src 0=No or 1=Yes, a point source was found
1 grb 0=No or 1=Yes, it is a GRB
2 interesting 0=No or 1=Yes, it is an interesting src (else boring)
3 catalog_src 0=No or 1=Yes, it is in the catalog (else unknown src)
4 image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
13 near_brt_star 0=No or 1=Yes, there is a nearby bright star
For these Test Notices, the soln_status will always be 3 plus the bright_star flag.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-24 Not assigned.
2^25 This is an updated position. This is a position notice that changes/improves
the position specified in the original BAT_Position Notice.
2^26-28 Not assigned.
2^29 When this bit is a 1, then this Notice was reconstituted; else flight-generated.
If a BAT_LC is received from the s/c before a BAT_Pos is received,
then bits and pieces from other Notices will be used to generate a reconstituted
BAT_Pos Notice and it will be issued (with this flag bit set to 1).
Always 0 for Test Notices.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if the Notice should be issued. This will typically be used
during the early phases of the mission before the automatic TDRSS capability is enabled.
Once the burst position has been validated by humans, a BAT_Pos Notice will be issued
(with this flag bit set to 1).
Always 1 for Test Notices.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection.
It has NOT been pre-scaled -- the units are sigma.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[22] The "bkg_flue" is the total number of events in the time interval used
for the background subtraction of the detector_rate_map (used for the image calc).
The units are counts.
[23] The "bkg_start" is the starting time of the background interval.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). Note that not all trigger criteria have a background interval
specified, so this "bkg_start" value may be zero for some bursts.
[24] The "bkg_dur" is the duration of the background interval.
The units are in centi-seconds.
[36-38] The "merit_0-3", "merit_4-7", and "merit_8-9" are the 10 merit parameters
for this burst. Their values range from -127 to +127. These 'merit params'
are different than the 'merit_value' that is in the SWIFT_FOM_OBS and SWIFT_SC_SLEW
messages. There are 4, 4, & 2 values packed into these 3 longs. The packing order
is "0" in the lowest_address byte in the long, "1" is in the next_lowest, etc.
There are a total of 12 "spare" items in the packet (usually filled
with zeros). They are located at items 15 and 25-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
PACKET ITEM DESCRIPTIONS for type=83:
The SWIFT_POINTDIR packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=83)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 slew_tjd [days] Truncated Julian Day
long 6 slew_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 point_roll [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 10 spare integer 4 bytes for the future
long 11 bat_mode integer BAT inst-mode for AT response
long 12 xrt_mode integer XRT inst-mode for AT response
long 13 uvot_mode integer UVOT inst-mode for AT response
long 14 obs_time [centi-sec] (int)(sssss.sss *100)
long 15 merit [centi-merit] Merit_value *100
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17-18 spare[2] integer 9 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
quad_char 22-38 tgtname[17] chars The name of the target
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_POINTDIR type is 83.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
[5] The "slew_tjd" is the TJD when the next s/c slew starts
eg. TJD=13370 is 01 Jan 2005.
[6] The "slew_sod" is the seconds-of-day (SOD) when the next s/c slew starts.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-9] The "point_ra", "point_dec" and "point_roll" are the RA,Dec and Roll (J2000) coordinates
to which the spacecraft will point after this slew. This is the pointing
direction of the s/c. The target_destiation accuracy of the s/c is 3arcmin worst case.
So for any given slew, the s/c will be actually looking at an RA,Dec location
which is within 0-3 arcmin of the location given in this packet.
The units are 10^04 deg, ie the values where multiplied by 10000 and integerized.
[11-13] The "bat_mode", "xrt_mode", and "uvot_mode" are the 3 sets of flagbits
the determine how each instrument responds for data-taking for each AT burst response.
Each mode is in the bottom 16 bits fo each 4-byte field.
[14] The "obs_time" is the amount of time the sc will observe that new location.
Since the "slew_sod" is the start of the slew to the new location,
in practice the sc will actually be on target 50-100 sec less than the amount
of time specified in this field. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[15] The "merit_value" is the total calculated value for the given burst.
It is a fl.pt. quantity which can theoretically range from -infinity to
+infinity, but given normal operations, we expect it to range from about
-100 to +300. And for the first 6-12 months of flight-ops, it will be
forced to be a constant value of 100 for all bursts.
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-12 Not assigned.
2^13 When this bit is 1, there is a nearby bright star (mag less than 6.5).
2^14-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always be 1 since the POINTDIR information is extracted from ground processing
of ground files.
2^31 Not assigned.
[22-38] The "tgtname" is the name of the object that the sc will be observing next.
It is a name chosen by the science planners at the MOC. The name does not
always fit the IAU standard naming convention (due to limitations in the
planning s/w). This item in the packet spans 17 longwords (ie 68 bytes) and
contains the ASCII string of the target_name. This string can be up to
67 characters long, and will always be null-terminated.
There are a total of 7 "spare" items in the packet (usually filled
with zeros). They are located at items 10 and 16-21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=84 PACKET CONTENTS:
The SWIFT_BAT_TRANS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=84)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 trans_tjd [days] Truncated Julian Day
long 6 trans_sod [centi-sec] (int)(sssss.sss *100)
long 7 trans_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 trans_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 trans_flue [counts] Num events during trig window, 0 to inf
long 10 trans_ipeak [cnts*ff] Counts in image-plane peak, 0 to infinity
long 11 trans_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +70.0 *100)
long 14 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22 bkg_flue [counts] Num events during the bkg interval, 0 to inf
long 23 bkg_start [centi-sec] (int)(sssss.sss *100)
long 24 bkg_dur [centi-sec] (int)(0-80,000 *100)
long 25 cat_num integer On-board cat match ID number
long 26-35 spare[10] integer 40 bytes for the future
long 36 merit_0-3 integers Merit params 0,1,2,3 (-127 to +127)
long 37 merit_4-7 integers Merit params 4,5,6,7 (-127 to +127)
long 38 merit_8-9 integers Merit params 8,9 (-127 to +127)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_BAT_TRANS type is 84.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "trans_tjd" is the Truncated Julian Day of the Swift-BAT transient trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "trans_sod" is the UT seconds-of-day (SOD) of the Swift-BAT transient trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "trans_ra" and "trans_dec" are the RA,Dec coordinates of the transient (J2000 epoch)
as determined by the BAT flight software. These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make an integer quantity
with units of 0.0001-degrees.
[9] The "trans_flue" is the number of events (trans+background events)
during the 'integ_time' time interval of the successful trigger criterion.
[10] The "trans_ipeak" is the height of the peak in the sky-image plane (ie the result
of the FFT,MaskConvolution,InvFFT calculation). The units are counts
after a multiplicative factor of about 0.5-0.7.
[11] The "trans_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). [Initially, this value will be hardwired
at a constant value of 4arcmin (0.067deg) radius. As the mission progresses,
this will be converted to a value which is dependent on the initial flux
of the burst.]
[12-13] The "phi" and "theta" are the BAT instrument coordinates of the transient
as determined by the BAT flight software program. Phi is measured phi=0
along the +Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the BAT instrument.
[14] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star
14-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-20 Not assigned.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22-24 Not assigned.
2^25 This is an updated position. This is a position notice that changes/improves
the position specified in the original BAT_TRANS_Position Notice.
2^26-27 Not assigned.
2^28 When this bit is a 1, then this Notice was derived from a SERS message; else flight-generated.
If none of the regular position-containing messages are received via the real-time
TDRSS comm channel (eg BAT_Pos_Ack, BAT_LC, etc), then the SERS messages
(which come from pipe-line processing of the Malindi playback downlinked data)
will be used to generate a reconstituted BAT_Pos_Ack Notice. But since
the SERS message only contains a subset of the information is a regular TDRSS
messages, these SERS-reconstituted Notices will have (tbd) fields undefined.
These undefined fields are: tbd, tbd, tbd....
2^29 When this bit is a 1, then this Notice was reconstituted; else flight-generated.
If a BAT_LC is received from the s/c before a BAT_Pos is received,
then bits and pieces from other Notices will be used to generate a reconstituted
BAT_Pos Notice and it will be issued (with this flag bit set to 1).
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if the Notice should be issued. This will typically be used
during the early phases of the mission before the automatic TDRSS capability is enabled.
Once the burst position has been validated by humans, a BAT_Trans Notice will be issued
(with this flag bit set to 1).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[22] The "bkg_flue" is the total number of events in the time interval used
for the background subtraction of the detector_rate_map (used for the image calc).
The units are counts.
[23] The "bkg_start" is the starting time of the background interval.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). Note that not all trigger criteria have a background interval
specified, so this "bkg_start" value may be zero for some bursts.
[24] The "bkg_dur" is the duration of the background interval.
The units are in centi-seconds.
[25] The "cat_num" is the catalog number in the on-board catalog for sources
that match a known source in the on-board catalog. (Typically it is a number
in the low 10,000s, 12,000s, or 15,000s.)
[36-38] The "merit_0-3", "merit_4-7", and "merit_8-9" are the 10 merit parameters
for this burst. Their values range from -127 to +127. These 'merit params'
are different than the 'merit_value' that is in the SWIFT_FOM_OBS and SWIFT_SC_SLEW
messages. There are 4, 4, & 2 values packed into these 3 longs. The packing order
is "0" in the lowest_address byte in the long, "1" is in the next_lowest, etc.
There are a total of 11 "spare" items in the packet (usually filled with zeros).
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=85 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_XRT_THRESHPIX packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=85)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 expo_time [0.001-sec] (int)(time*1000.0)
long 10 stop_date [days] Truncated Julian Day
long 11 stop_time [centi-sec] (int)(sssss.sss *100)
long 12 seq_num integer Serial number of message (1-3)
long 13-18 spare[6] integer 24 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...88
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_XRT_THRESHIX type is 85.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT transient trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT transient trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9]
[10]
[11]
[12]
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_TP.
2^21 When this bit is a 1, it indicates the original BAT trigger was an ImageTrigger AND the Startracker was in Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this XRT_ThreshPix Noticed was forced-out via the watchdog timeout.
2^30 Not assigned.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 29 "spare" items in the packet (usually filled
with zeros). They are located at items 9-18 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=86 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_XRT_THRESHPIX_PROC packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=86)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 expo_time [0.001-sec] (int)(time*1000.0)
long 10 stop_date [days] Truncated Julian Day
long 11 stop_time [centi-sec] (int)(sssss.sss *100)
long 12 seq_num integer Serial number of message (1-3)
long 13-18 spare[6] integer 24 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...88
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_XRT_THRESHIX_PROC type is 86.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT transient trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT transient trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[9]
[10]
[11]
[12]
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12-19 Not assigned.
2^20 When this bit is a 1, it indicates that this was originally a SubThresh, but it is now converted to a real XRT_PROC_TP.
2^21 Not assigned.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this original 'raw' ThreshPix Noticed was forced-out via the watchdog timeout.
2^30 Not assigned.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 29 "spare" items in the packet (usually filled
with zeros). They are located at items 9-18 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=87 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_XRT_SPER packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=87)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 expo_time [0.001-sec] (int)(time*1000.0)
long 10 stop_date [days] Truncated Julian Day
long 11 stop_time [centi-sec] (int)(sssss.sss *100)
long 12 num_pkt integer Number of pkts in integration
long 13-18 spare[6] integer 24 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20 num_evt integer Number of events in the integration
long 21 spare integer 4 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...88
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_XRT_SPER type is 87.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT transient trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT transient trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-9 Not assigned.
2^10 When this bit is a 1, it indicates that StarTracker not locked (at the time the SPER is pushed out)
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12-20 Not assigned.
2^21 When this bit is a 1, it indicates the original BAT trigger was an ImageTrigger AND the Startracker was in Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this XRT_SPER Noticed was forced-out via the watchdog timeout.
2^30 Not assigned.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "num_evt" is the number of photon events in the integration.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 28 "spare" items in the packet (usually filled
with zeros). They are located at items 9-18 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=88 PACKET CONTENTS: NOT AVAILABLE TO THE PUBLIC, SWIFT TEAM ONLY
The SWIFT_XRT_SPER_PROC packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=88)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 expo_time [0.001-sec] (int)(time*1000.0)
long 10 stop_date [days] Truncated Julian Day
long 11 stop_time [centi-sec] (int)(sssss.sss *100)
long 12 seq_num integer Serial number of message (1-3)
long 13-18 spare[6] integer 24 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20 num_evt integer Number of events in the integration
long 21 spare integer 4 bytes for the future
quad_char 22-38 url[17] chars The URL for the image
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...88
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_XRT_SPER_PROC type is 88.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT transient trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT transient trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates (J2000)
of the pointing direction of the s/c at the start?/stop???
of the integration interval for the image. These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 0.0001-degrees.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-21 Not assigned.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 This bit is set if this original 'raw' SPER Noticed was forced-out via the watchdog timeout.
2^30 Not assigned.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "num_evt" is the number of photon events in the integration.
[22-38] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_s/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 28 "spare" items in the packet (usually filled
with zeros). They are located at items 9-18 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=89 PACKET CONTENTS:
The SWIFT_UVOT_POS_NACK packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=89)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 src_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 src_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 mag_lim [arb] (int)(uvot_mag_lim *100)
long 10 filter integer Filter_value: x-yy
long 11 src_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 source integer 1-3
long 13-17 spare[5] integer 20 bytes for the future
long 18 soln_status bits Type of source found
long 19 misc bits Misc stuff packed in here
long 20 lim_sigma [arb] (int)(mag_lim_sigma *100)
long 21-38 spare[18] integer 72 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "trig_tjd" is the Truncated Julian Day of the Swift-UVOT data,
eg. TJD=13370 is 01 Jan 2005.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the Swift-UVOT data.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "src_ra" and "src_dec" are the RA,Dec coordinates (J2000) of the center
of the error circle that was searched to determine this limiting magnitude from "source".
These intrinsically floating point quantities have been multiplied by 10,000 and
then integerized to make an integer quantity with units of 0.0001-degrees.
[9] The "mag_lim" is the lower limit magnitude (in the specified filter)
of the burst observation (ie the afterglow has to be fainter than the 'mag_lim' value).
The units are in centi-mag (ie the fl.pt. magnitude is multiplied by 100
and then integerized).
[10] The "filter" is the filter used for the image. The values are:
0 Blocked
1 UV_Grism
2 UVW2
3 V
4 UVM2
5 Vis_Grism
6 UVW1
7 U
8 Magnifier
9 B
10 White
11 unknown
[11] The "src_error" is the radius of the location error circle that was searched in UVOT
to yield the quoted limiting magnitude.
[12] The "source" field indicates the source of the RA,Dec-location error circle
that was searched to yield the limiting magnitude for the UVOT non-detection.
The values are:
0 undefined
1 BAT
2 XRT
3 Other
[18] The "soln_status" field contains flag bits on the type of solution that was found.
The bit packing of the "soln_status" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 point_src 0=No or 1=Yes, a point source was found, 0=extended src
1 grb 0=No or 1=Yes, it is a GRB
2 undef Not yet defined.
3 catalog_src 0=No or 1=Yes, it is in the catalog (else unknown src)
4 undef Not yet defined.
5 def_not_grb 0=No or 1=Yes, it is definitely not a GRB (a Retraction)
6-29 undef Not yet defined.
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 undef Not yet defined.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-11 Not assigned.
2^12 When this bit is 1, it is in the catalog of sources to be blocked (internal use only).
2^13 When this bit is 1, there is a nearby bright star.
2^14-21 Not assigned.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 Not assigned.
2^24 Not assigned.
2^25 Not assigned.
2^26 Not assigned.
2^27 Not assigned.
2^28 Not assigned.
2^29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "lim_sigma" is the number of simga that the mag_limit is quoted for.
The units are in centi-sigma (ie the fl.pt. mag_error is multiplied by 100
and then integerized).
There are a total of 28 "spare" items in the packet (usually filled
with zeros). They are located at items 7-8, 11-18, and 21-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=97 PACKET CONTENTS:
The SWIFT_BAT_QUICKLOOK_POS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=97)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 roll [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 10 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-16 spare[5] integer 20 bytes for the future
long 17 trig_index integer Rate_Trigger index
long 18 AT_slewFlags bits Two flag bits packed here
long 19 misc bits Misc stuff packed in here
long 20 spare integer 4 bytes for the future
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22-37 spare[16] integer 64 bytes for the future
long 38 merit [centi-merit] (int)(Merit_value *100)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...84 ...97
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger.
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). (For this packet type alone: Due to sequencing uncertainties
in the GCN ground s/w, this quantity does not contain the UT_Correction_Factor
about 50% of the instances. It is a small correction; ~5 sec circa Nov 2009.)
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "roll" of the spacecraft (after the slew to this new burst). This intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[10] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). [This value was hardwired at a constant value
of 3arcmin radius.]
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "at_slew_flags" field contains two flag bits related to the status
of the given burst wrt the Automated Target (AT) and Slewing.
The bits are:
2^0 Is this burst worthy of becoming the new Automated Target: 1=yes
2^1 Is this burst of sufficient merit to request a s/c slew: 1=yes
2^8 Is this location in the Gnd_cat: 1=yes
The AT is a special target that the Swift Observatory will keep coming back to
orbit after orbit without any ground commanding intervention. It is distinct
from the PrePlanned Targets (PPTs) that are in the uploaded stored observing table.
Whenever the AT is observable (ie no observing constraint is in effect),
then the AT will override any previous PPT. The override lasts for up to
a commandable amount of time -- typically 60,000 observed-seconds.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0 When this bit is a 1, it indicates that the BAT_Pos TDRSS message was not received for this TrigNum.
2^1-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-21 Not assigned.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23-30 Not assigned.
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[38] The "merit_value" is the total calculated value for the given burst.
It is a fl.pt. quantity which can theoretically range from -infinity to
+infinity, but given normal operations, we expect it to range from about
-100 to +300. And for the first 6-12 months of flight-ops, it will be
forced to be a constant value of 100 for all bursts.
There are a total of 23 "spare" items in the packet (usually filled
with zeros). They are located at items 9-14, 20, and 22-37.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=98 PACKET CONTENTS:
The SWIFT_BAT_SUBTHRESHOLD packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=98)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flue [counts] Num events during trig window, 0 to inf
long 10 burst_ipeak [cnts*ff] Counts in image-plane peak, 0 to infinity
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +70.0 *100)
long 14 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Rate_Trigger index
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21 rate_signif [centi-sigma] (int)(sig2noise *100)
long 22 bkg_flue [counts] Num events during the bkg interval, 0 to inf
long 23 bkg_start [centi-sec] (int)(sssss.sss *100)
long 24 bkg_dur [centi-sec] (int)(0-80,000 *100)
long 25 cat_num integer On-board cat match ID number
long 26-35 spare[10] integer 40 bytes for the future
long 36 merit_0-3 integers Merit params 0,1,2,3 (-127 to +127)
long 37 merit_4-7 integers Merit params 4,5,6,7 (-127 to +127)
long 38 merit_8-9 integers Merit params 8,9 (-127 to +127)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...98
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). Please note that this type
is identical in format and content as type=61 (BAT_POS). The only difference
is that these notices are due to the (so called) Sub-Threshold events.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
The Observation_number is always 0 since these are always (by definition)
the first observation of this new trigger (this new burst).
The Trigger_number started with s/n=100,000 just after launch (Nov 04).
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by +/- 320 msec
for events that have a trigger duration less than 64 msec. This has to do with the way
that the flight software is optimized for execution speed for evaluating trigger criteria.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_flue" is the number of events (burst+background events)
during the 'integ_time' time interval of the successful trigger criterion.
[10] The "burst_ipeak" is the height of the peak in the sky-image plane (ie the result
of the FFT,MaskConvolution,InvFFT calculation). The units are counts
after a multiplicative factor of about 0.5-0.7.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). [Initially, this value was hardwired
at a constant value of 4arcmin (0.067deg) radius. As the mission progressed,
this changed to 3 arcmin. Eventually, it might become intensity-dependant.]
[12-13] The "phi" and "theta" are the BAT instrument coordinates of the trigger (burst)
as determined by the BAT flight software program. Phi is measured phi=0
along the +Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the BAT instrument.
[14] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. The value is the number of 4msec ticks,
eg a value of 16 indicates a 64-msec trigger criterion.
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the BAT trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "trig_index" is the index value (row_number in the BAT on-board flight s/w table)
of the trigger criteria that was the highest-significance successful trigger.
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1 F grb 0=No or 1=Yes, it is a GRB
2 F interesting 0=No or 1=Yes, it is an interesting src (ie a flaring known src)
3 F flt_cat_src 0=No or 1=Yes, it is in the flight catalog (else unknown src)
4 F image_trig 0=No or 1=Yes, it is an image trigger (else rate trig)
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (hi bkg level, ie near SAA)
7 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (low image significance; less then 7.0 sigma)
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 G uncert_grb 0=No or 1=Yes, it is probably not a GRBorTransient (negative bkg slope, exit SAA)
10 G st_loss_lock 0=No or 1=Yes, StarTracker not locked so trigger probably bogus
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-20 Not assigned.
2^21 When this bit is a 1, it indicates that this is an Image-trigger AND that it occurred
during a time when the StarTracker had a Loss-of-Lock.
2^22 When this bit is a 1, it indicates that this Notice was generated as a result
of an uploaded TOO sequence. (Swift is commanded to look at this RA,Dec location
and this Notice was generated as a direct result of that observation.)
2^23 When this bit is a 1, it means the Trig_Time was zero and so the s/c system clock
in the TDRSS Message SecondaryHeader was used to fill the Burst_TJD and Burst_SOD fields.
(This 0-Trig_Time scenario occurs during a ground-commanded GRB_TOO.)
2^24 When this bit is a 1, it indicates that the TDRSS Message was received on the ground
more than 60 sec after the BAT Trigger time. The most likely scenario for this kind of transmission delay
is that the BAT Trigger occured during a Malindi downlink pass (when TDRSS messages are blocked
from immediate transmission; they are buffered onboard until the end of the Malindi Pass).
2^25 This is an updated position. This is a position notice that changes/improves
the position specified in the original BAT_Position Notice.
2^26 Not assigned.
2^27 Not assigned.
2^28 When this bit is a 1, then this Notice was derived from a SERS message; else flight-generated.
If none of the regular position-containing messages are received via the real-time
TDRSS comm channel (eg BAT_Pos_Ack, BAT_LC, etc), then the SERS messages
(which come from pipe-line processing of the Malindi playback downlinked data)
will be used to generate a reconstituted BAT_Pos_Ack Notice. But since
the SERS message only contains a subset of the information is a regular TDRSS
messages, these SERS-reconstituted Notices will have (tbd) fields undefined.
These undefined fields are: tbd, tbd, tbd....
2^29 When this bit is a 1, then this Notice was reconstituted; else flight-generated.
If a BAT_LC is received from the s/c before a BAT_Pos is received,
then bits and pieces from other Notices will be used to generate a reconstituted
BAT_Pos Notice and it will be issued (with this flag bit set to 1).
But since the LC message only contains a subset of the information in a regular
TDRSS BAT_POS messages, these LC-reconstituted Notices will have (tbd) fields undefined.
These undefined fields are: tbd, tbd, tbd....
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a BAT_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there may be rare occaisions when a BAT_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 If there is a CRC error in one or more of the packets that went into
the making of this Notice, then this bit is set to 1, else 0.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
By definition of this Notice type, the 'image_signif' value will never be
greater than 6.50 sigma.
[21] The "rate_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[22] The "bkg_flue" is the total number of events in the time interval used
for the background subtraction of the detector_rate_map (used for the image calc).
The units are counts.
[23] The "bkg_start" is the starting time of the background interval.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). Note that not all trigger criteria have a background interval
specified, so this "bkg_start" value may be zero for some bursts.
[24] The "bkg_dur" is the duration of the background interval.
The units are in centi-seconds.
[25] The "cat_num" is the catalog number in the on-board catalog for sources
that match a known source in the on-board catalog. (Typically it is a number
in the low 30,000's.)
[36-38] The "merit_0-3", "merit_4-7", and "merit_8-9" are the 10 merit parameters
for this burst. Their values range from -127 to +127. These 'merit params'
are different than the 'merit_value' that is in the SWIFT_FOM_OBS and SWIFT_SC_SLEW
messages. There are 4, 4, & 2 values packed into these 3 longs. The packing order
is "0" in the lowest_address byte in the long, "1" is in the next_lowest, etc.
The definition of the 10 parameters is:
Param Description
0 Flag bit indicating GRB or not (1 or 0, resp).
1 Flag bit indicating Transient or not (1 or 0, resp); unknown src with T_trig>64sec.
2 Flag bit indicating Known_src or not (1 or 0, resp); Known_src matches something in on-board catalog.
3 Trigger duration (log2(t_trig/1024msec)).
4 Trigger energy range (0=15-25,1=15-50,2=25-100,3=50-350).
5 Image significance
6 Is it observable (-1 if w/in 30deg of Moon; -5, 20deg Moon; -100, 45deg Sun).
7 Flag bit indicating in a confused or obscurred region (ie Gal Center or Plane).
8 Sun distance (-100*cos(sun_angular_dist)).
9 An offset param to bias for/against PPTs and TOOs wrt ATs (norm param).
There are a total of 13 "spare" items in the packet (usually filled
with zeros). They are located at items 15-16 and 25-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=99 PACKET CONTENTS:
The SWIFT_BAT_SLEW_GRB_POSITION packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=99)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 id_num integer ID number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flue [counts] Num events during image window, 0 to inf
long 10 burst_ipeak [cnts/sec] Counts in image-plane peak, 0 to infinity
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 spare integer 4 bytes for the future
long 13 spare integer 4 bytes for the future
long 14 integ_time [4mSec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 spare integer 4 bytes for the future
long 17 trig_index integer Trigger criterion index
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21-38 spare[18] integer 72 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...98, 99
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). Please note that this type
is very similar but not identical in format and content as type=61 (BAT_POS).
These notices contain positions of bursts (and transients) detected by BAT
during intervals when Swift is slewing. A separate notice type was created
because there will be some delay (0.5 - 6 hrs: tlm downlink delays and
ground-processing time) compared to the 10-20sec delay for the type=61 notices.
And there may well be a slightly larger position uncertainty compared
to type=61.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "id_num" is a uniquely identifying serial number assigned by Harvard.
It started at 1 with GRB 070326.
[5] The "burst_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the ground burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BATSS ground-procesing software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_flue" is the number of events (burst+background events)
during the 'integ_time' time interval of the successful trigger criterion.
The units are counts.
[10] The "burst_ipeak" is the height of the peak in the sky-image plane.
The units are counts/sec.
Always 0 for now.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[14] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. The value is the number of 4msec ticks,
eg a value of 16000 indicates a 64-sec trigger integration.
[17] The "trig_index" is the value of the trigger criteria that had the highest evaluation.
The definitions of the various trigger criteria are listed in the table below:
INDEX CRITERIA COMMENT
1-4 Undefined Undefined
5 S(15-50) > 6.5 sigma OR H(50-150) > 6.5 sigma High confidence of reality (silver-plated).
6 Non-simultaneous detections > 4.0 sigma over more than an orbit Transient (ie too long for a GRB)
7 Non-simultaneous detections > 4.0 sigma within an orbit Transient (ie too long for a GRB)
8 Simul (S(15-50) OR H(50-150)) > 6.0 sigma AND B(15-150) > 4.0 sigma High confidence of reality (silver-plated).
9 Simul (S(15-50) OR H(50-150)) > 4.0 sigma AND B(15-150) > 6.0 sigma High confidence of reality (silver-plated).
10 Simul S(15-50) > 4.0 sigma AND H(50-150) > 4.0 sigma Very high confidence of reality (gold-plated).
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G point_src 0=No or 1=Yes, a point source was found
1 G grb 0=No or 1=Yes, it is definitely a GRB (or a hard x-ray transient, ie astrophysical) Index=10)
2 - spare not defined for this notice type
3 - spare not defined for this notice type
4 G image_trig 0=No or 1=Yes, it is an image trigger (else rate trig) Always I-trigger for BATSS.
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6 - spare not defined for this notice type
7 - spare not defined for this notice type
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9 - spare not defined for this notice type
10 - spare not defined for this notice type
11 - spare not defined for this notice type
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14 G prob_grb 0=No or 1=Yes, it is probably a GRB (or hard x-ray transient, ie astrophysical) (Index=8 or 9)
15-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned (they are ALL gnd-assigned for BAT_Slew_Pos); "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0 When this bit is a 1, it indicates that photons in the 15-50 keV (Soft) band where used in the detection.
2^1 When this bit is a 1, it indicates that photons in the 50-150 keV (Hard) band where used in the detection.
2^3 When this bit is a 1, it indicates that photons in the 15-150 keV (Broad) band where used in the detection.
2^3-10 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Roll,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-24 Not assigned.
2^25 This is an updated position. This is a position notice that changes/improves
the position specified in the original BAT_Slew_Position Notice.
2^26-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
By definition, all BATSS-generated notices are ground-generated (via the pipeline
processing at Harvard).
2^31 Not assigned.
[20] The "image_signif" is the significance level of the peak in the image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
There are a total of 20 "spare" items in the packet (usually filled
with zeros). They are located at items 15-16 and 21-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=100 PACKET CONTENTS:
TYPE=101 PACKET CONTENTS:
TYPE=102 PACKET CONTENTS:
The SuperAGILE_GRB_WAKEUP/_GROUND/_REFINED packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=100-102)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_intenX [0.001-cnts] Num events in each X 1-D
long 10 burst_intenY [0.001-cnts] Num events in each Y 1-D
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-17 spare[6] integers 24 bytes for the future
long 18 trigger_id bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 signif two_2byte_int Misc stuff packed in here
long 21-38 spare[17] integers 68 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 100, 101, 102, 105, 107, 108, 109;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The AGILE types are:
100 = SuperAGILE_GRB_WAKEUP, 101 = SuperAGILE_GRB_GROUND, 102 = SuperAGILE_REFINED,
105 = AGILE_MCAL_ALERT, 107 = AGILE_POINTDIR, 108 = SuperAGILE_TRANS, and
109 = SuperAGILE_GRB_POS_TEST.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of 0.1-secs since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the AGILE burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the AGILE burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[9] The "burst_intenX" is the number of events in the 15-45 keV band
in the X 1-D localization. This intrinsically floating point quantity
have been multiplied by 1000 and then integerized to make an integer quantity
with units of 0.001-counts.
[10] The "burst_intenY" is the number of events in the 15-45 keV band
in the Y 1-D localization. This intrinsically floating point quantity
have been multiplied by 1000 and then integerized to make an integer quantity
with units of 0.001-counts.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. It contains statical plus the systematic contribution.
The units are 0.0001-degrees (ie the fl.pt. error was multiplied by 10000 and
then integerized).
[18] The "trigger_id" field contains (a) flag bits on the type of solution
that was found in the on-board (and SA-OPS) and (b) flag bits that are assigned
in the GCN ground-processing.
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 F grb 0=No or 1=Yes, it is a GRB
2-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-12 - spare spare for future use
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (see MISC for correct location)
14-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near (lss than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GRB_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GRB_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 Not assigned.
[20] The "signif" is composed of two 16-bit quantitites packed into a single 32-bit field.
The two quantities are the X-axis and Y-axis 1-dimentional significance detections.
The X-direction significance is packed in the bottom 16 bits, and the Y-direction
is packed in the upper 16 bits. Prior to packing, both significances were multiplied
by 100 and integerized (i.e centi-sigma)..
There are a total of 17(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 15-16(tbd) and 21-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
PACKET ITEM DESCRIPTIONS for type=103:
The SWIFT_ACTUAL_POINTDIR packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=103)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_obs_num integers Trigger num & Observation num
long 5 slew_tjd [days] Truncated Julian Day
long 6 slew_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 point_roll [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 10-15 spare[6] integer 24 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17-18 spare[2] integer 8 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
//quad_char 22-38 tgtname[17] chars The name of the target
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 60, 61, 62, 63, ...83... 103
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The SWIFT_ACTUAL_POINTDIR type is 103.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_obs_num" is a pair of uniquely identifying serial numbers (Trigger_num and Observation_num)
assigned by the on-board BAT flight software to each trigger.
The lower 24 bits contain the Trigger_number, and the upper 8 bits
contain the Observation_number.
[5] The "slew_tjd" is the TJD when the next s/c slew ends
eg. TJD=13370 is 01 Jan 2005.
[6] The "slew_sod" is the seconds-of-day (SOD) when the next s/c slew ends.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-9] The actual "point_ra", "point_dec" and "point_roll" are the RA,Dec and Roll (J2000) coordinates
of the spacecraft after the slew. This is the pointing direction of the s/c.
The units are 10^04 deg, ie the values where multiplied by 10000 and integerized.
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the notice.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-12 Not assigned.
2^13 When this bit is 1, there is a nearby bright star (mag less than 6.5).
2^14-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This will always be 1 since the POINTDIR information is extracted from ground processing
of ground files.
2^31 Not assigned.
//This might get added at a later date:
//The "tgtname" is the name of the object that the sc will be observing next.
//It is a name chosen by the science planners at the MOC. The name does not
//always fit the IAU standard naming convention (due to limitations in the
//planning s/w). This item in the packet spans 17 longwords (ie 68 bytes) and
//contains the ASCII string of the target_name. This string can be up to
//67 characters long, and will always be null-terminated.
There are a total of 10 "spare" items in the packet (usually filled
with zeros). They are located at items 10-15, 17-18 and 20-21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=105 PACKET CONTENTS:
The AGILE_MCAL_ALERT packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=105)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 spare integer 4 bytes for the future
long 8 spare integer 4 bytes for the future
long 9 burst_tot_cnt[cnts]
long 10 burst_peak_cnt[cnts]
long 11 spare integer 4 bytes for the future
long 12 bin_size [millisec]
long 13 bkg_cnt_rate [cnts/0.032sec] Background Count in a 32msec window
long 14 integ_time [??sec]]
long 15 spare integer 4 bytes for the future
long 16 lon_lat ??????? ???
long 17 peak_signif [sigma*100] Significance of the peak
long 18 trigger_id bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 burst_signif [sigma*100] Significance of the event
long 21 e_low [??keV] Energy of the low end of the band
long 22 e_high [??keV] Energy of the low end of the band
long 23-28 spare[7] integers 28 bytes for the future
quad_char 29-38 url[10] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 100, 101, 102, 105, 107, 108, 109;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The AGILE types are:
100 = SuperAGILE_GRB_WAKEUP, 101 = SuperAGILE_GRB_GROUND, 102 = SuperAGILE_REFINED,
105 = AGILE_MCAL_ALERT, 107 = AGILE_POINTDIR, 108 = SuperAGILE_TRANS, and
109 = SuperAGILE_GRB_POS_TEST.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of 0.1-secs since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the AGILE Alert trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the AGILE Alert trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[9] The "burst_tot_cnt" is the total number of counts in the duration of the burst
in the energy window specified by e_hi and e_low.
Q: Is background subtracted????????
[10] The "burst_peak_cnt" is the total number of counts at the peak of the burst
in the energy window specified by e_hi and e_low.
Q: Is background subtracted????????
[12] The "bin_size" is the binning size (in time) of the bins in the lightcurve.
This intrinsically floating point quantity have been multiplied by 1000 and
then integerized to make an integer quantity with units of 0.001-sec.
[13] The "background" is the total number of background counts in the 32 msec window
in the energy window specified by e_hi and e_low.
The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the AGILE trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[14] The "integ_time" s the duration of the lightcurve used to produce these other parameter values.
This intrinsically floating point quantity have been multiplied by 1000 and
then integerized to make an integer quantity with units of 0.001-sec [msec].
[17] The "peak_signif" is the significance (in sigma) of the peak countrate.
The significance has been multiplied by 100, integerized, and stored in the packet [centi-sigma].
[18] The "trigger_id" field contains (a) flag bits on the type of solution
that was found in the on-board (and SA-OPS) and (b) flag bits that are assigned
in the GCN ground-processing.
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
//1 F grb 0=No or 1=Yes, it is a GRB
2-4 - spare spare for future use
//5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-13 - spare spare for future use
14 F trig_logic_f1 1 bit indicating if 'sub-ms' trigger time interval participated in the Trigger Logic (0=NO, 1=YES)
15 F trig_logic_f2 1 bit indicating if '1ms' trigger time interval participated in the Trigger Logic (0=NO, 1=YES)
16 F trig_logic_f3 1 bit indicating if '16ms' trigger time interval participated in the Trigger Logic (0=NO, 1=YES)
17 F trig_logic_f4 1 bit indicating if '64ms' trigger time interval participated in the Trigger Logic (0=NO, 1=YES)
18 F trig_logic_f5 1 bit indicating if '256ms' trigger time interval participated in the Trigger Logic (0=NO, 1=YES)
19 F trig_logic_f6 1 bit indicating if '1024ms' trigger time interval participated in the Trigger Logic (0=NO, 1=YES)
20 F trig_logic_f7 1 bit indicating if '8192ms' trigger time interval participated in the Trigger Logic (0=NO, 1=YES)
21-17 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
//30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near (lss than 0.3deg) a bright star (mag less than 6.5).
//2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
// is less than the sum of the position error radius and the galaxy radius AND that the position error radius
// is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
//2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
// is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
// is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GRB_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GRB_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 Not assigned.
[20] The "burst_signif" is the significance (in sigma) of the total duration of the burst.
The significance has been multiplied by 100, integerized, and stored in the packet.
[21] The "e_low" is the low energy edge of the window (in keV) used for this event; typically 400 keV.
[22] The "e_hi" is the low energy edge of the window (in keV) used for this event; typically 10,000 keV.
[29-38] The "url" is just the filename portion of the lightcurve URL -- the leading path
for the full URL is "http://www.agilescienceapp.it/notices/" for the Italian archive and
"http://gcn.gsfc.nasa.gov/gcn/notices_a/" for the GCN archive.
This item in the packet spans 10 longwords (ie 40 bytes, ie up to 40 character) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 39 characters long, and will always be null-terminated.
The combined/full url will look like:
"http://www.agilescienceapp.it/notices/
There are a total of 15 "spare" items in the packet (usually filled with zeros).
They are located at items 7, 8, 11, 15, and 28-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=107 PACKET CONTENTS:
The AGILE_POINTDIR packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=107)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for the future
long 5 start_tjd [days] Truncated Julian Day
long 6 start_sod [centi-sec] (int)(sssss.sss *100)
long 7 curr_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 curr_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-11 spare[3] integer 12 bytes for the future
long 12 stop_tjd [days] Truncated Julian Day
long 13 stop_sod [centi-sec] (int)(sssss.sss *100)
long 14-18 spare[5] integer 20 bytes for the future
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 48 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
[0] The "pkt_type" is an integer with a value of 100, 101, 102, 107, 108, 109;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The AGILE types are:
100 = SuperAGILE_GRB_WAKEUP, 101 = SuperAGILE_GRB_GROUND, 102 = SuperAGILE_REFINED,
105 = AGILE_ALERT (MCAL), 107 = AGILE_POINTDIR, 108 = SuperAGILE_TRANS, and
109 = SuperAGILE_GRB_POS_TEST.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[5] The "start_tjd" is the Truncated Julian Day of the start of the AGILE pointing session.
It is NOT the "current" TJD. The distinction being that the AGILE spacecraft
does "pointing sessions" for 2-4 weeks (mostly), and during that session
the instantaneous RA,Dec direction slowly drifts about 1 deg per day.
The Start and Stop dates/times give the beginning and end of that pointing session,
and the "Curr_RA/_Dec" give the RA,Dec pointing direction of the spacecraft
at the time of the Notice.
[6] The "start_sod" is the UT seconds-of-day (SOD) of the start of the AGILE pointing session.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "curr_ra" and "curr_dec" are the RA,Dec coordinates of the current
pointing direction (bore sight) of AGILE (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[12] The "stop_tjd" is the Truncated Julian Day of the end of the AGILE pointing session.
[13] The "stop_sod" is the UT seconds-of-day (SOD) of the end of the AGILE pointing session.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[19] The "misc" field contains miscellaneous flag bits.
2^0-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
This notice type will ALWAYS be ground-generated.
2^31 Not assigned.
There are a total of 28 "spare" items in the packet (usually filled
with zeros). They are located at items 4, 9-11, 14-19, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=108 PACKET CONTENTS:
The SuperAGILE_TRANS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=108)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trans_tjd [days] Truncated Julian Day
long 6 trans_sod [centi-sec] (int)(sssss.sss *100)
long 7 trans_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 trans_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 trans_intenX [0.001-cnts] Num events in each X 1-D
long 10 trans_intenY [0.001-cnts] Num events in each Y 1-D
long 11 trans_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-13 spare[2] integers 8 bytes for the future
long 14 integ_time [centi-sec] Duration of the trigger interval, 1 to inf
long 15-17 spare[3] integer 12 bytes for the future
long 18 trigger_id bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 signif two_2byte_int Misc stuff packed in here
long 21-38 spare[17] integers 68 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 100, 101, 102, 107, 108, 109;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The AGILE types are:
100 = SuperAGILE_GRB_WAKEUP, 101 = SuperAGILE_GRB_GROUND, 102 = SuperAGILE_REFINED,
105 = AGILE_ALERT (MCAL), 107 = AGILE_POINTDIR, 108 = SuperAGILE_TRANS, and
109 = SuperAGILE_GRB_POS_TEST.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of 0.1-secs since 01 Jan 2001.
[5] The "trans_tjd" is the Truncated Julian Day of the AGILE burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "trans_sod" is the UT seconds-of-day (SOD) of the AGILE burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "trans_ra" and "trans_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[9] The "trans_intenX" is the number of events in the 15-45 keV band
in the X 1-D localization. This intrinsically floating point quantity
have been multiplied by 1000 and then integerized to make an integer quantity
with units of 0.001-counts.
[10] The "trans_intenY" is the number of events in the 15-45 keV band
in the Y 1-D localization. This intrinsically floating point quantity
have been multiplied by 1000 and then integerized to make an integer quantity
with units of 0.001-counts.
[11] The "trans_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[14] The "integ_time" is the duration the data was collected. The units are 0.001
multiplied by 1000 and then integerized.
[18] The "trigger_id" field contains (a) flag bits on the type of solution
that was found in the on-board (and SA-OPS) and (b) flag bits that are assigned
in the GCN ground-processing.
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (a Retraction)
6-7 - spare spare for future use
//8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9-12 - spare spare for future use
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star
14-29 - spare spare for future use
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near (less than0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GRB_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GRB_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 Not assigned.
[20] The "signif" is composed of two 16-bit quantitites packed into a single 32-bit field.
The two quantities are the X-axis and Y-axis 1-dimentional significance detections.
The X-direction significance is packed in the bottom 16 bits, and the Y-direction
is packed in the upper 16 bits. Prior to packing, both significances were multiplied
by 100 and integerized (i.e centi-sigma).
There are a total of 17(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 15-16(tbd) and 21-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=109 PACKET CONTENTS:
The SuperAGILE_GRB_POS_TEST packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=109)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_intenX [0.001-cnts] Num events in each X 1-D
long 10 burst_intenY [0.001-cnts] Num events in each Y 1-D
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-13 spare[2] integers 8 bytes for the future
long 14 integ_time [centi-sec] Duration of the trigger interval, 1 to inf
long 15-17 spare[3] integer 12 bytes for the future
long 18 trigger_id bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 signif two_2byte_int Misc stuff packed in here
long 21-38 spare[17] integers 68 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 100, 101, 102, 107, 108, 109;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The AGILE types are:
100 = SuperAGILE_GRB_WAKEUP, 101 = SuperAGILE_GRB_GROUND, 102 = SuperAGILE_REFINED,
105 = AGILE_ALERT (MCAL), 107 = AGILE_POINTDIR, 108 = SuperAGILE_TRANS, and
109 = SuperAGILE_GRB_POS_TEST.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of 0.1-secs since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the AGILE burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the AGILE burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[9] The "burst_intenX" is the number of events in the 15-45 keV band
in the X 1-D localization. This intrinsically floating point quantity
have been multiplied by 1000 and then integerized to make an integer quantity
with units of 0.001-counts.
[10] The "burst_intenY" is the number of events in the 15-45 keV band
in the Y 1-D localization. This intrinsically floating point quantity
have been multiplied by 1000 and then integerized to make an integer quantity
with units of 0.001-counts.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
???[14] The "integ_time" is the duration the data was collected. The units are 0.001
multiplied by 1000 and then integerized.
[18] The "trigger_id" field contains (a) flag bits on the type of solution
that was found in the on-board (and SA-OPS) and (b) flag bits that are assigned
in the GCN ground-processing.
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-7 - spare spare for future use
//8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9-12 - spare spare for future use
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star
14-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event (NOOP for TEST)
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event (NOOP for TEST)
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GRB_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GRB_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 Not assigned.
[20] The "signif" is composed of two 16-bit quantities packed into a single 32-bit field.
The two quantities are the X-axis and Y-axis 1-dimentional significance detections.
The X-direction significance is packed in the bottom 16 bits, and the Y-direction
is packed in the upper 16 bits. Prior to packing, both significances were multiplied
by 100 and integerized (i.e centi-sigma).
There are a total of 17(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 15-16(tbd) and 21-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=110 (&116) PACKET CONTENTS:
The FERMI_GBM_ALERT (& FERMI_GBM_ALERT_INTERNAL) packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=110 or 116)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7-8 spare[2] integer 8 bytes for the future
long 9 algorithm integer Which loc calc algorithm used
long 10-13 spare[4] integer 20 bytes for the future
long 14 trig_dur [milli-sec] Trigger Integration time [msec]
long 15 lo_chan integer ???
long 16 hi_chan integer ???
long 17 adc_lochan integer ???
long 18 adc_hichan integer ???
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~20)
long 21 trig_signif [deci-sigma] (int)(Trigger significance *10)
long 22 longitude [arcmin] Geo (East) Longitude of s/c
long 23 latitude [arcmin] Geo Latitude of s/c
long 24-25 spare[2] integer 8 bytes of the trigger criterion
long 26 dets bits The 2 dets that triggered
long 27-30 spare[4] integer 16 bytes for the future
long 31 lc_yymmdd integer The YYMMDD for the lc_url
long 32 lc_fff integer The FFF fraction-of-day for the lc_url
long 33-38 spare[6] integer 24 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 110, 111, 112, 117, 118, and 119;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-GBM trigger,
eg. TJD=13370 is 01 Jan 2005. (Note that at the time when this Alert Notice
is issued, it is not yet known if this trigger is due to a real GRB,
or some non-GRB cause (eg. failed or false trigger).)
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). (Since this is the Alert Notice, it is not known yet
if this trigger is a real GRB or just a false trigger.)
[9] The "algorithm" is the index value identifying which location_calculation
algorithm was used for this event.
[14] The "trig_dur" is the duration of the trigger criteria that initiated this event.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized).
[15-16] The "lo_chan" and "hi_chan" are ....
[17-18] The "adc_lochan" and "adc_hichan" are ...
[19] The "misc" field contains miscellaneous flag bits.
2^0-27 Not assigned.
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
(note the non-standard location; these coinc bits are usually in the trigger_id slot)
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled.
2^31 Not assigned.
[20] The "rec_seq_num" is the Record Sequence Number. It is a packet serial number
spanning all the messages that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
[21] The "trig_signif" is the significance of the trigger in units of deci-sigma.
It is the significance of the initial trigger (ie of the data in the trigger_time interval).
The value is multiplied by 10 and integerized (i.e. the units are deci-sigma).
(This should not be confused with the "Data Significance" in the FLT_POS and GND_POS notices,
which is the significance of the data in the ongoing integration time interval.)
(This is a deviation from the way 'sigma' is usually stored in GCN packets -- it is
in deci-sigma instead of the usual centi-sigma.)
[22] The "longitude" is the East geographic longitude of the s/c at the time of the trigger.
The units are arcmin (ie divide the 4-byte integer by 60.0 to get fl.pt. degrees).
[23] The "latitude" is the geographic latitude of the s/c at the time of the trigger.
The units are arcmin (ie divide the 4-byte integer by 60.0 to get fl.pt. degrees).
[26] The "det" contains which two of the 14 detectors that resulted in this event.
There are 12 position-determining detectors and 2 spectrum-measuring detectors (BGO).
The packing sequence starts with Det0 in the 2^0 bit, Det1 in 2^1, ..., DetB in 2^11,
and the two BGO dets in 2^12 and 2^13.
[31] The "lc_yymmdd" contains the YYMMDD information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%06d" (ie decimal form in the C-language) to for the "YYMMDD" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
[32] The "lc_fff" contains the FFF fraction-of-day information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%03d" (ie decimal form in the C-language) to for the "fff" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
There are a total of 18 "spare" items in the packet (usually filled
with zeros). They are located at items 7-8, 10-13, 24-25, 27-30, and 32-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=111 (&117) PACKET CONTENTS:
The FERMI_GBM_FLT_POS (& FERMI_GBM_FLT_INTERNAL) packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=111 or 117)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flue [counts] Num events during trig window, 0 to inf
long 10 spare integer 4 bytes for the future
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 trigTmScale [milli-sec] Trigger Time Scale
long 15-16 spare[2] integer 8 bytes for the future
long 17 dataTmScale [milli-sec] Data Time Scale
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21 data_signif [centi-sigma] (int)(sig2noise *100)
long 22 loc_algor integer Location algorithm (1-???)
long 23 most_likely integer Mostly class ID & probability
long 24 2most_likely integer 2nd Mostly class ID & probability
long 25 hard_ratio [centi-dn] (int)(hardness_ratio *100)
long 26 dets bits The 2 dets that triggered
long 26-30 spare[5] integers 20 bytes for the future
long 31 lc_yymmdd integer The YYMMDD for the lc_url
long 32 lc_fff integer The FFF fraction-of-day for the lc_url
long 33-36 spare[4] integer 16 bytes for the future
long 37 longitude [arcmin] Geo (East) Longitude of s/c
long 38 latitude [arcmin] Geo Latitude of s/c
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 110, 111, 112, 117, 118, and 119;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the FERMI-GBM burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the GBM flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[9] The "burst_flue" is the number of events in the 50-300 keV band
during the 'integ_time' time interval of the successful trigger criterion.
(is this bkg subtracted?????)
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" are the GBM instrument coordinates of the trigger (burst)
as determined by the GBM flight software program. Phi is measured phi=0
along the +X-axis of the s/c and increasing towards the +Y axis,
and theta is measured from the boresight of the LAT instrument (the +Z axis).
The units are in centi-degees (ie the fl.pt. degrees were multiplied by 100
and then integerized).
[14] The "trigTmScale" is the binning (ie timesampling) of the countrate lightcurve
used for the initial countrate lightcurve trigger detection.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized).
[17] The "dataTmScale" is the binning (ie timesampling) of the countrate lightcurve
used during the iterative location calculation phase of the processing.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized).
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
These bits will be determined largely (but not completely) by the ClassID in the Most_Likely fields.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spares for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-11 - spare spares for future use
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13-27 - spare spares for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-10 Not asigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Lon,Lat values
were out of valid range (eg RA was 361 deg).
2^12-23 Not assigned.
2^24 When this bit is a 1, then the Dets (slot 26) and Lon,Lat (slots 37,38) have been filled
from the GBM_ALERT Notice.
2^25-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GBM_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GBM_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 Not assigned.
[20] The "rec_seq_num" is the Record Sequence Number. It is a serial number spanning
all the messages (of all types) that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
[21] The "data_signif" is the significance level of the data in the on-going integrated data.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 100 and then integerized (ie units are centi-sigma).
(This should not be confused with the "trigger Significance" in the ALERT Notice,
which is the significance of the data in a just the initial trigger interval.)
[22] The "loc_algorithm" field contains the version_number of the Flt S/W Location Algorithm
that was used to derive this RA,Dec location for this event. The values are:
1 (Only one is defined so far in the FSW)
2 (Future use as on-orbit experience dictates)
3 (Future use as on-orbit experience dictates)
[23] The "most_likely" field contains two values (2 shorts into the 1 long).
The least significant two bytes contains an the index value identifying
the source_object class of this event (eg GRB, solar flare, electron precip, etc).
The most significant two bytes contain the probability (ie confidence level) that
this class assignment is correct. The range of the probability is 0.0 to 1.0;
and the units are in centi-probability (ie prob*100).
CLASS TABLE:
// Classes 0 to 3 are "single classes": the probabilities of these
// will be either 0 or 1, never an in between value.
0 ERROR - ????????????precise wording needed!!!!!!
1 UNRELIABLE_LOCATION - ????????????precise wording needed!!!!!!
2 LOCAL_PARTICLES - Local particles, equal rates in opposite detectors
3 BELOW_HORIZON - Distant particles, assumed to come from the horizon
// The remaining classes have probabilities calculated
// from Bayes Theorem: any value from 0.0 to 1.0 is possible.
4 GRB - For bursts with good localizations
5 GENERIC_SGR - This is any SGR (except 1806-20)
6 GENERIC_TRANSIENT - Any astrophysical transient not included elsewhere
7 DISTANT_PARTICLES - Particles at a distance
8 SOLAR_FLARE - This is a Solar Flare event
9 CYG_X1 - This trigger was caused by a CygX1 fluctuation
10 SGR_1806_20 - This trigger came from SGR 1806-20
11 GROJ_0422_32 - This trigger came from GRO J0422-32
12-18 undefined - (spares for future use)
19 TGF - Terrestial Gamma Flashes
[24] The "2most_likely" field contains two values (2 shorts into the 1 long).
The least significant two bytes contains an the index value identifying
the second-most-likely source_object class of this event.
The most significant two bytes contain the probability (ie confidence level) that
this class assignment is correct. The range of the probability is 0.0 to 1.0;
and the units are in centi-probability (ie prob*100).
The Class Table is the same as above.
[25] The "hardness_ratio" is the hardness ratio (HR = Cnts(15-50keV) / Cnts(50-300keV)).
The units are in centi-dig_number (ie hard_ratio = (int)(HR*100)).
[26] The "det" contains which two of the 14 detectors that resulted in this event.
There are 12 position-determining detectors and 2 spectrum-measuring detectors (BGO).
The packing sequence starts with Det0 in the 2^0 bit, Det1 in 2^1, ..., DetB in 2^11,
and the two BGO dets in 2^12 and 2^13. This field is valid only if the 2^24 bit in MISC
is set.
[31] The "lc_yymmdd" contains the YYMMDD information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%06d" (ie decimal form in the C-language) to for the "YYMMDD" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
[32] The "lc_fff" contains the FFF fraction-of-day information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%03d" (ie decimal form in the C-language) to for the "fff" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
[37] The "longitude" is the East geographic longitude of the s/c at the time of the trigger.
The units are arcmin (ie divide the 4-byte integer by 60.0 to get fl.pt. degrees).
[38] The "latitude" is the geographic latitude of the s/c at the time of the trigger.
The units are arcmin (ie divide the 4-byte integer by 60.0 to get fl.pt. degrees).
There are a total of 12 "spare" items in the packet (usually filled
with zeros). They are located at items 15-16, 25-30, and 33-36.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=112 PACKET CONTENTS:
The FERMI_GBM_GND_POS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=112)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integers 8 bytes for the future
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 data_interval[milli-sec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 lon_lat integer Longitude, Lattitude
long 17 spare[3] integer 4 bytes for the future
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21 burst_signif [deci-sigma] (int)(sig2noise *10)
long 22 loc_algor integer Location algorithm (1-???)
long 23-25 spare[3] integers 12 bytes for the future
long 26 lo_E integer E_range_lo *1000 keV
long 27 hi_E integer E_range_hi *1000 keV
long 28 sc_x integer X-coordinate of s/c *4.0 km
long 29 sc_y integer Y-coordinate of s/c *4.0 km
long 30 sc_z integer Z-coordinate of s/c *4.0 km
long 31 lc_yymmdd integer The YYMMDD for the lc_url
long 32 lc_fff integer The FFF fraction-of-day for the lc_url
long 33-38 spare[6] integer 24 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 110, 111, 112, 117, 118, and 119;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the FERMI-GBM burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the GBM flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" are the GBM instrument coordinates of the trigger (burst)
as determined by the GBM flight software program. Phi is measured phi=0
along the +X-axis of the s/c and increasing towards the +Y axis,
and theta is measured from the boresight of the LAT instrument (the +Z axis).
The units are in centi-degees (ie the fl.pt. degrees were multiplied by 100
and then integerized).
[14] The "data_interval" is the interval over which the data were accumulated in the MAXRATES packet,
also known as integration_interval.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized).
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
These bits will be determined largely (but not completely) by the ClassID in the Most_Likely fields.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G LAT_FOV In the LAT_FoV
1 G Hi_E GBM_hiE_inten_>_some_threshold
2-4 - spare spares for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-11 - spare spares for future use
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13-25 - spare spares for future use
26-27 - l-v-s 2 bits: 0=Undef,1=ShortGRB,2=LongGRB,3=not_used
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-10 spares.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12-29 spares.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GBM_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GBM_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 spare.
[20] The "rec_seq_num" is the Record Sequence Number. It is a serial number spanning
all the messages (of all types) that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
[21] The "burst_signif" is the significance level of the initial 'rate trigger'.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 10 and then integerized (ie units are deci-sigma). (Please note that
this is a deviation from the way 'sigma' is usually stored in GCN packets -- it is
in deci-sigma instead of the usual centi-sigma.)
[22] The "loc_algorithm" field contains the version_number of the Location Algorithm Gnd s/w
that was used to derive this RA,Dec location for this event. The values are:
1 (Only one is defined so far in the Gnd SW)
2 (Future use as on-orbit experience dictates)
3 (Future use as on-orbit experience dictates)
[26] The 'lo_E' is the bottom of the energy range for ...
It is in eV -- keV/1000 and then integerized.
[27] The 'hi_E' is the bottom of the energy range for ...
It is in eV -- keV/1000 and then integerized.
[31] The "lc_yymmdd" contains the YYMMDD information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%06d" (ie decimal form in the C-language) to for the "YYMMDD" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
[32] The "lc_fff" contains the FFF fraction-of-day information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%03d" (ie decimal form in the C-language) to for the "fff" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
There are a total of 18 "spare" items in the packet (usually filled
with zeros). They are located at items 9-10, 15-17, and 32-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=113 PACKET CONTENTS:
The FERMI_GBM_LC packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=113)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [counts] Num events during trig window, 0 to inf
long 10-15 spare[6] integers 24 bytes for the future
//long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
//long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
//long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 spare integer 4 bytes for the future
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~20)
long 21-38 spare[18] integer 72 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 110, 111, 112, 117, 118, and 119;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the FERMI-GBM trigger,
eg. TJD=13370 is 01 Jan 2005. (Note that at the time when this Alert Notice
is issued, it is not yet known if this trigger is due to a real GRB,
or some non-GRB cause (eg. failed or false trigger).)
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). (Since this is the Alert Notice, it is not known yet
if this trigger is a real GRB or just a false trigger.)
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the GBM flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_flue" is the number of events in the 50-300 keV band
during the 'integ_time' time interval of the successful trigger criterion.
(is this bkg subtracted?????)
OR
The "burst_inten" is the number of events in the 50-300 keV band
averaged over the two closed detectors and cosine-corrected.
(is this bkg subtracted?????)
//The "burst_error" is the radius of the circle that will contain on average
//TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
//by 10000 and then integerized).
//The "phi" and "theta" are the GBM instrument coordinates of the trigger (burst)
//as determined by the GBM flight software program. Phi is measured phi=0
//along the (TBC)+Y-axis of the s/c and increasing towards the -Z axis,
//and theta is measured from the boresight of the GBM instrument.
//The units are in centi-degees (ie the fl.pt. degrees were multiplied by 100
//and then integerized).
??????????????lon_lat???????????
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spares for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-11 - spare spares for future use
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13-29 - spare spares for future use
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-10 spares.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12-29 spares.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GBM_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there may be occaisions when a GBM_LC notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 spare.
[20] The "rec_seq_num" is the Record Sequence Number. It is a serial number spanning
all the messages that come from the s/c during a given trigger. It will start
with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
There are a total of 13(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 15-16 and 25-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=114 PACKET CONTENTS:
Not for public distribution -- Fermi-GBM team only.
The FERMI_GBM_GND_INTERNAL packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Same as 112 except slots 23 and 24 are filled.
long 23 most_likely integer Mostly class ID and probability
long 24 2most_likely integer 2nd Mostly class ID and probability
TYPE=115 (& 146) PACKET CONTENTS:
The FERMI_GBM_FINAL_POS (& FERMI_GBM_FINAL_POS_INTERNAL) packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=115)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integers 8 bytes for the future
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14-17 spare[4] integer 16 bytes for the future
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
long 22 loc_algor integer Location algorithm (1-???)
long 23-30 spare[8] integers 32 bytes for the future
long 31 lc_yymmdd integer The YYMMDD for the lc_url
long 32 lc_fff integer The FFF fraction-of-day for the lc_url
long 33-38 spare[6] integer 24 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 110, 111, 112, 117, 118, and 119;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the FERMI-GBM burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the GBM flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" are the GBM instrument coordinates of the trigger (burst)
as determined by the GBM flight software program. Phi is measured phi=0
along the +X-axis of the s/c and increasing towards the +Y axis,
and theta is measured from the boresight of the LAT instrument (the +Z axis).
The units are in centi-degees (ie the fl.pt. degrees were multiplied by 100
and then integerized).
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
These bits will be determined largely (but not completely) by the ClassID in the Most_Likely fields.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G LAT_FOV In the LAT_FoV
1 G Hi_E GBM_hiE_inten_>_some_threshold
2-4 - spare spares for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-11 - spare spares for future use
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13-25 - spare spares for future use
26-27 - l-v-s 2 bits: 0=Undef,1=ShortGRB,2=LongGRB,3=not_used
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0 When this bit is a 1, then bits 2^0, 2^1, and 2^26-27 in slot 18 are assigned and valid;
when not set, those 4 bits are undefined.
2^0-10 spares.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12-29 spares.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GBM_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GBM_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 spare.
[22] The "loc_algorithm" field contains the version_number of the Location Algorithm Gnd s/w
that was used to derive this RA,Dec location for this event. The values are:
1 (Only one is defined so far in the Gnd SW)
2 (Future use as on-orbit experience dictates)
3 (Future use as on-orbit experience dictates)
[31] The "lc_yymmdd" contains the YYMMDD information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%06d" (ie decimal form in the C-language) to for the "YYMMDD" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
[32] The "lc_fff" contains the FFF fraction-of-day information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%03d" (ie decimal form in the C-language) to for the "fff" portion of the string:
http://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/triggers/20YY/bnYYMMDDFFF/quicklook/glg_lc_medres34_bnYYMMDDFFF.gif
There are a total of 15(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 15-16(tbd) and 25-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=118 PACKET CONTENTS:
The FERMI_GBM_TRANS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=118)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 trans_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 trans_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 trans_inten [counts] Num events during trig window, 0 to inf
long 10 spare integer 4 bytes for the future
long 11 trans_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 integ_time [centi-sec] Duration of the trigger interval, 1 to inf
long 15 spare integer 4 bytes for the future
long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 spare integer 4 bytes for the future
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21 burst_signif [deci-sigma] (int)(sig2noise *10)
long 22 loc_algor integer Location algorithm (1-???)
long 23 most_likely integer Mostly class ID & probability
long 24 2most_likely integer 2nd Mostly class ID & probability
long 25-38 spare[14] integers 56 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 110, 111, 112, 117, 118, and 119;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-GBM trigger,
eg. TJD=13370 is 01 Jan 2005. (Note that at the time when this Alert Notice
is issued, it is not yet known if this trigger is due to a real GRB,
or some non-GRB cause (eg. failed or false trigger).)
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). (Since this is the Alert Notice, it is not known yet
if this trigger is a real GRB or just a false trigger.)
[7-8] The "trans_ra" and "trans_dec" are the RA,Dec coordinates of the trans
as determined by the GBM flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
The "trans_flue" is the number of events in the 50-300 keV band
during the 'integ_time' time interval of the successful trigger criterion.
(is this bkg subtracted?????)
The "trans_inten" is the number of events in the 50-300 keV band
averaged over the two closed detectors and cosine-corrected.
(is this bkg subtracted?????)
[11] The "trans_error" is the radius of the circle that will contain on average
TBD% of the transients. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" are the GBM instrument coordinates of the trigger (transient)
as determined by the GBM flight software program. Phi is measured phi=0
along the (TBC)+Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the LAT instrument.
The units are in centi-degees (ie the fl.pt. degrees were multiplied by 100
and then integerized).
[14] The "integ_time" is the duration of the sampling interval
of the successful trigger criteria. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
The "loc_algorithm" field contains the index value of which Location Algorithm
was used to derive this RA,Dec location for this event. The values are:
1 (Only one is defined so far in the FSW; it really does not have a name)
2 (Future use as on-orbit experience dictates)
3 (Future use as on-orbit experience dictates)
The "most_likely" field contains two values (2 shorts into the 1 long).
The least significant two bytes contains an the index value identifying
the source_object class of this event (eg GRB, solar flare, electron precip, etc).
The most significant two bytes contain the probability (ie confidence level) that
this class assignment is correct. The range of the probability is 0.0 to 1.0;
and the units are in centi-probability (ie prob*100).
CLASS TABLE:
// Classes 0 to 3 are "single classes": the probabilities of these
// will be either 0 or 1, never an in between value.
0 ERROR - ????????????precice wording needed!!!!!!
1 UNRELIABLE_LOCATION - ????????????precice wording needed!!!!!!
2 LOCAL_PARTICLES - Local particles, equal rates in opposite detectors
3 BELOW_HORIZON - Distant particles, assumed to come from the horizon
// The remaining classes have probabilities calculated
// from Bayes Theorem: any value from 0.0 to 1.0 is possible.
4 GRB - For bursts with good localizations
5 GENERIC_SGR - This is any SGR (except 1806-20)
6 GENERIC_TRANSIENT - Any astrophysical transient not included elsewhere
7 DISTANT_PARTICLES - ????????????precice wording needed!!!!!!
8 SOLAR_FLARE - This is a Solar Flare event
9 CYG_X1 - This trigger was caused by a CygX1 fluctuation
10 SGR_1806_20 - This trigger came from SGR 1806-20
11 GROJ_0422_32 - This trigger came from GRO J0422-32
12-18 undefined - (spares for future use)
19 TGF - Terrestial Gamma Flashes
The "2most_likely" field contains two values (2 shorts into the 1 long).
The least significant two bytes contains an the index value identifying
the second-most-likely source_object class of this event.
The most significant two bytes contain the probability (ie confidence level) that
this class assignment is correct. The range of the probability is 0.0 to 1.0;
and the units are in centi-probability (ie prob*100).
The Class Table is the same as above.
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spares for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (a Retraction)
6-11 - spare spares for future use
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13-27 - spare spares for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-10 spares.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12-29 spares.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GBM_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there may be rare occaisions when a GBM_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 spare.
[20] The "rec_seq_num" is the Record Sequence Number. It is a serial number spanning
all the messages that come from the s/c during a given trigger. It will start
with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
[21] The "burst_signif" is the significance level of the data in the on-going integrated data.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 10 and then integerized (ie units are deci-sigma).
(This should not be confused with the "trigger Significance" in the ALERT Notice,
which is the significance of the data in a just the initial trigger interval.)
(This is a deviation from the way 'sigma' is usually stored in GCN packets -- it is
in deci-sigma instead of the usual centi-sigma.)
{stuff???}
There are a total of 14(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 15-16 and 25-35.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=119 PACKET CONTENTS:
The FERMI_GBM_POS_TEST packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=119)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_flue [counts] Num events during trig window, 0 to inf
long 10 spare integer 4 bytes for the future
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 trigTmScale [milli-sec] Trigger Time Scale
long 15-16 spare[2] integer 8 bytes for the future
long 17 dataTmScale [milli-sec] Data Time Scale
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21 data_signif [deci-sigma] (int)(sig2noise *10)
long 22 loc_algor integer Location algorithm (1-???)
long 23 most_likely integer Mostly class ID & probability
long 24 2most_likely integer 2nd Mostly class ID & probability
long 25 hard_ratio [centi-dn] (int)(hardness_ratio *100)
long 26 dets bits The 2 dets that triggered
long 26-30 spare[8] integers 32 bytes for the future
long 31 lc_yymmdd integer The YYMMDD for the lc_url
long 32 lc_fff integer The FFF fraction-of-day for the lc_url
long 33-36 spare[4] integer 16 bytes for the future
long 37 longitude [arcmin] Geo (East) Longitude of s/c
long 38 latitude [arcmin] Geo Latitude of s/c
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 110, 111, 112, 117, 118, and 119;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "burst_tjd" is the Truncated Julian Day of the FERMI-GBM burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the GBM flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[9] The "burst_flue" is the number of events in the 50-300 keV band
during the 'integ_time' time interval of the successful trigger criterion.
(is this bkg subtracted?????)
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" are the GBM instrument coordinates of the trigger (burst)
as determined by the GBM flight software program. Phi is measured phi=0
along the +X-axis of the s/c and increasing towards the +Y axis,
and theta is measured from the boresight of the LAT instrument (the +Z axis).
The units are in centi-degees (ie the fl.pt. degrees were multiplied by 100
and then integerized).
[14] The "trigTmScale" is the binning (ie timesampling) of the countrate lightcurve
used for the initial countrate lightcurve trigger detection.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized).
[17] The "dataTmScale" is the binning (ie timesampling) of the countrate lightcurve
used during the iterative location calculation phase of the processing.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized).
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
These bits will be determined largely (but not completely) by the ClassID in the Most_Likely fields.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spares for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-11 - spare spares for future use
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13-27 - spare spares for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-10 Not asigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Lon,Lat values
were out of valid range (eg RA was 361 deg).
2^12-23 Not assigned.
2^24 When this bit is a 1, then the Dets (slot 26) and Lon,Lat (slots 37,38) have been filled
from the GBM_ALERT Notice.
2^25-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GBM_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GBM_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 Not assigned.
[20] The "rec_seq_num" is the Record Sequence Number. It is a serial number spanning
all the messages (of all types) that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
[21] The "data_signif" is the significance level of the data in the on-going integrated data.
This is the signal/noise (ie number of sigma) of the rate-trigger detection
multiplied by 10 and then integerized (ie units are deci-sigma).
(This should not be confused with the "trigger Significance" in the ALERT Notice,
which is the significance of the data in a just the initial trigger interval.)
(This is a deviation from the way 'sigma' is usually stored in GCN packets -- it is
in deci-sigma instead of the usual centi-sigma.)
[22] The "loc_algorithm" field contains the version_number of the Flt S/W Location Algorithm
that was used to derive this RA,Dec location for this event. The values are:
1 (Only one is defined so far in the FSW)
2 (Future use as on-orbit experience dictates)
3 (Future use as on-orbit experience dictates)
[23] The "most_likely" field contains two values (2 shorts into the 1 long).
The least significant two bytes contains an the index value identifying
the source_object class of this event (eg GRB, solar flare, electron precip, etc).
The most significant two bytes contain the probability (ie confidence level) that
this class assignment is correct. The range of the probability is 0.0 to 1.0;
and the units are in centi-probability (ie prob*100).
CLASS TABLE:
// Classes 0 to 3 are "single classes": the probabilities of these
// will be either 0 or 1, never an in between value.
0 ERROR - ????????????precise wording needed!!!!!!
1 UNRELIABLE_LOCATION - ????????????precise wording needed!!!!!!
2 LOCAL_PARTICLES - Local particles, equal rates in opposite detectors
3 BELOW_HORIZON - Distant particles, assumed to come from the horizon
// The remaining classes have probabilities calculated
// from Bayes Theorem: any value from 0.0 to 1.0 is possible.
4 GRB - For bursts with good localizations
5 GENERIC_SGR - This is any SGR (except 1806-20)
6 GENERIC_TRANSIENT - Any astrophysical transient not included elsewhere
7 DISTANT_PARTICLES - Particles at a distance
8 SOLAR_FLARE - This is a Solar Flare event
9 CYG_X1 - This trigger was caused by a CygX1 fluctuation
10 SGR_1806_20 - This trigger came from SGR 1806-20
11 GROJ_0422_32 - This trigger came from GRO J0422-32
12-18 undefined - (spares for future use)
19 TGF - Terrestial Gamma Flashes
[24] The "2most_likely" field contains two values (2 shorts into the 1 long).
The least significant two bytes contains an the index value identifying
the second-most-likely source_object class of this event.
The most significant two bytes contain the probability (ie confidence level) that
this class assignment is correct. The range of the probability is 0.0 to 1.0;
and the units are in centi-probability (ie prob*100).
The Class Table is the same as above.
[25] The "hardness_ratio" is the hardness ratio (HR = Cnts(15-50keV) / Cnts(50-300keV)).
The units are in centi-dig_number (ie hard_ratio = (int)(HR*100)).
[26] The "det" contains which two of the 14 detectors that resulted in this event.
There are 12 position-determining detectors and 2 spectrum-measuring detectors (BGO).
The packing sequence starts with Det0 in the 2^0 bit, Det1 in 2^1, ..., DetB in 2^11,
and the two BGO dets in 2^12 and 2^13. This field is valid only if the 2^24 bit in MISC
is set.
The "longitude" is the East geographic longitude of the s/c at the time of the trigger.
The units are arcmin (ie divide the 4-byte integer by 60.0 to get fl.pt. degrees).
The "latitude" is the geographic latitude of the s/c at the time of the trigger.
The units are arcmin (ie divide the 4-byte integer by 60.0 to get fl.pt. degrees).
The "lc_yymmdd" contains the YYMMDD information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%06d" (ie decimal form in the C-language) to for the "YYMMDD" portion of the string.
The "lc_fff" contains the FFF fraction-of-day information for building the lightcurve URL.
When forming the url string (to wget the lc file) this file should be converted
using the "%03d" (ie decimal form in the C-language) to for the "fff" portion of the string.
There are a total of 19(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 15-16(tbd) and 25-36.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=120 PACKET CONTENTS:
The FERMI_LAT_GRB_POS_INI packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=120)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [counts] Num events used in location calc, 0 to inf
long 10 inten_4 4_bytes Evt_cnts in 4 energy bands
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 int_time [msec] Integration time
long 15-16 spare[2] integer 8 bytes for the future
long 17 trig_index integer Trigger index
long 18 Trig_ID bits LAT burst candidate, 1=yes,0=no
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21-24 spare[4] integer 16 bytes for the future
long 25 temp_stat integer (int)(4*(-log10(probability)))
long 26 image_stat integer (int)(4*(-log10(probability)))
long 27-30 spare[4] integer 16 bytes for the future
long 31 1st_ph_tjd [days] First photon used in loc calc
long 32 1st_ph_sod [centi-sec] (int)(sssss.sss *100)
long 33 last_ph_tjd [days] last photon used in loc calc
long 34 last_ph_sod [centi-sec] (int)(sssss.sss *100)
long 35-36 spare[2] integer 8 bytes for the future
long 37 misc bits Misc stuff packed in here
long 38 loc_qual [0.0001] Location quality (0.0 - 1.0)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 120, 121, 122, and 123;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-LAT trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec. This uncertainty
is governed by the variable trigger window duration, which is defined in terms
of a fixed number of events rather than an interval of time.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the LAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_inten" is the subset of the total number of events in the standard 4 energy bands
that were used in the location calculation.
[10] The "inten_4" contains 4 unsigned_char counts of the number of events
in the standard 4 energy bands during the 'int_time' interval.
The least significant byte (lsb) contains the number of events in the 0-100 MeV band,
the next lsb contains number of events in the 100MeV-1GeV band,
3rd has 1-10GeV, and the most significant byte has the number of events in the greater_than_10GeV band.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" is the location of the source in LAT instrument coordinates.
Theta is the angle off the bore sight. //And phi is the azimuthal angle
//with 0 starting at..... measured CW(tbd)....
[14] The "int_time" is the time interval between the first and last photons
which went into the successful trigger criteria. The units are milli-seconds.
[17] The "trig_index" is the index value of the trigger criterion that provided
the successful trigger (precise definition is TBD).
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found on-board and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F G-vs-L The starting/seed location came from 0=GBM, 1=from_LAT
1 F gam_used 0=all gammas used, or 1=only gammas above a cut used in loc method
2-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0 A 1 means a Repoint_Request was made to the s/c. [Not defined for INI]
2^1-10 spare.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less then 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-31 spare.
[20] The "rec_seq_num" is the Record Sequence Number. It is a packet serial number
spanning all the messages that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
[25] The "temp_stat" is the measure of the Temporal Test Statistic.
The value is 4*(-log10(temporal_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
[26] The "image_stat" is the measure of the Image Test Statistic.
The value is 4*(-log10(spatial_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
[31] The "1st_ph_tjd" is the Truncated Julian Day of the first photon used
in the location calculation.
[32] The "1st_ph_sod" is the UT seconds-of-day (SOD) of the first photon used
in the location calculation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
[33] The "last_ph_tjd" is the Truncated Julian Day of the last photon used
in the location calculation.
[34] The "last_ph_sod" is the UT seconds-of-day (SOD) of the last photon used
in the location calculation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
The "burst_id" is an index value specifying the source_type of the triggered event.
The "loc_qual" is the quality of the location determination. It is a probability
that runs from 0.0 to 1.0 (0.0001 quantization), with a value of -1
if undefined. The bigger the number, the more likely that is a real event
(and converely, a small number indicates random photons in the LAT).
There are a total of 17(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 12-13, 15, 20 and 22-37.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=121 PACKET CONTENTS:
The FERMI_LAT_GRB_POS_UPD packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=121)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [counts] Num events used in location calc, 0 to inf
long 10 inten_4 4_bytes Evt_cnts in 4 energy bands
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 int_time [msec] Integration time
long 15-16 spare[2] integer 8 bytes for the future
long 17 trig_index integer Trigger index
long 18 Trig_ID bits LAT burst candidate, 1=yes,0=no
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21-24 spare[4] integer 16 bytes for the future
long 25 temp_stat integer (int)(4*(-log10(probability)))
long 26 image_stat integer (int)(4*(-log10(probability)))
long 27-30 spare[4] integer 16 bytes for the future
long 31 1st_ph_tjd [days] First photon used in loc calc
long 32 1st_ph_sod [centi-sec] (int)(sssss.sss *100)
long 33 last_ph_tjd [days] last photon used in loc calc
long 34 last_ph_sod [centi-sec] (int)(sssss.sss *100)
long 35-36 spare[2] integer 8 bytes for the future
long 37 misc bits Misc stuff packed in here
long 38 loc_qual [0.0001] Location quality (0.0 - 1.0)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 120, 121, 122, and 123;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-LAT trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec. This uncertainty
is governed by the variable trigger window duration, which is defined in terms
of a fixed number of events rather than an interval of time.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the LAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_inten" is the subset of the total number of events in the standard 4 energy bands
that were used in the location calculation.
[10] The "inten_4" contains 4 unsigned_char counts of the number of events
in the standard 4 energy bands during the 'int_time' interval.
The least significant byte (lsb) contains the number of events in the 0-100 MeV band,
the next lsb contains number of events in the 100MeV-1GeV band,
3rd has 1-10GeV, and the most significant byte has the number of events in the greater_than_10GeV band.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" is the location of the source in LAT instrument coordinates.
Theta is the angle off the bore sight. //And phi is the azimuthal angle
//with 0 starting at..... measured CW(tbd)....
[14] The "int_time" is the time interval between the first and last photons
which went into the successful trigger criteria. The units are milli-seconds.
[17] The "trig_index" is the index value of the trigger criterion that provided
the successful trigger (precise definition is TBD).
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found on-board and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F G-vs-L The starting/seed location came from 0=GBM, 1=from_LAT
1 F gam_used 0=all gammas used, or 1=only gammas above a cut used in loc method
2-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0 When this bit is a 1, then a Repoint_Request was made to the s/c.
2^1-10 spare.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-31 spare.
[20] The "rec_seq_num" is the Record Sequence Number. It is a packet serial number
spanning all the messages that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
The "temp_stat" is the measure of the Temporal Test Statistic.
The value is 4*(-log10(temporal_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
The "image_stat" is the measure of the Image Test Statistic.
The value is 4*(-log10(spatial_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
The "1st_ph_tjd" is the Truncated Julian Day of the first photon used
in the location calculation.
The "1st_ph_sod" is the UT seconds-of-day (SOD) of the first photon used
in the location calculation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
The "last_ph_tjd" is the Truncated Julian Day of the last photon used
in the location calculation.
The "last_ph_sod" is the UT seconds-of-day (SOD) of the last photon used
in the location calculation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
The "burst_id" is an index value specifying the source_type of the triggered event.
The "loc_qual" is the quality of the location determination. It is a probability
that runs from 0.0 to 1.0 (0.0001 quantization), with a value of -1
if undefined. The bigger the number, the more likely that is a real event
(and converely, a small number indicates random photons in the LAT).
There are a total of 17(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 12-13, 15, 20 and 22-37.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=122 PACKET CONTENTS:
The FERMI_LAT_GRB_POS_DIAG packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=122)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [counts] Num events used in location calc, 0 to inf
long 10 inten_4 4_bytes Evt_cnts in 4 energy bands
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 int_time [msec] Integration time
long 15-16 spare[2] integer 8 bytes for the future
long 17 trig_index integer Trigger index
long 18 Trig_ID bits LAT burst candidate, 1=yes,0=no
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21-24 spare[4] integer 16 bytes for the future
long 25 temp_stat integer (int)(4*(-log10(probability)))
long 26 image_stat integer (int)(4*(-log10(probability)))
long 27-30 spare[4] integer 16 bytes for the future
long 31 1st_ph_tjd [days] First photon used in loc calc
long 32 1st_ph_sod [centi-sec] (int)(sssss.sss *100)
long 33 last_ph_tjd [days] last photon used in loc calc
long 34 last_ph_sod [centi-sec] (int)(sssss.sss *100)
long 35-36 spare[2] integer 8 bytes for the future
long 37 misc bits Misc stuff packed in here
long 38 spare integer 4 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 120, 121, 122, and 123;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-LAT trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec. This uncertainty
is governed by the variable trigger window duration, which is defined in terms
of a fixed number of events rather than an interval of time.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the LAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
The "burst_inten" is the subset of the total number of events in the standard 4 energy bands
that were used in the location calculation.
The "inten_4" contains 4 unsigned_char counts of the number of events
in the standard 4 energy bands during the 'int_time' interval.
The least significant byte (lsb) contains the number of events in the 0-100 MeV band,
the next lsb contains number of events in the 100MeV-1GeV band,
3rd has 1-10GeV, and the most significant byte has the number of events in the greater_than_10GeV band.
The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
The "phi" and "theta" is the location of the source in LAT instrument coordinates.
Theta is the angle off the bore sight. //And phi is the azimuthal angle
//with 0 starting at..... measured CW(tbd)....
The "int_time" is the time interval between the first and last photons
which went into the successful trigger criteria. The units are milli-seconds.
[17] The "trig_index" is the index value of the trigger criterion that provided
the successful trigger (precise definition is TBD).
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found on-board and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F G-vs-L The starting/seed location came from 0=GBM, 1=from_LAT
1 F gam_used 0=all gammas used, or 1=only gammas above a cut used in loc method
2-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0 When this bit is a 1, then a Repoint_Request was made to the s/c.
2^1-10 spare.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-31 spare.
[20] The "rec_seq_num" is the Record Sequence Number. It is a packet serial number
spanning all the messages that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
The "temp_stat" is the measure of the Temporal Test Statistic.
The value is 4*(-log10(temporal_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
The "image_stat" is the measure of the Image Test Statistic.
The value is 4*(-log10(spatial_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
The "1st_ph_tjd" is the Truncated Julian Day of the first photon used
in the location calculation.
The "1st_ph_sod" is the UT seconds-of-day (SOD) of the first photon used
in the location calculation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
The "last_ph_tjd" is the Truncated Julian Day of the last photon used
in the location calculation.
The "last_ph_sod" is the UT seconds-of-day (SOD) of the last photon used
in the location calculation. The units are in centi-seconds
(ie the fl.pt. seconds were multiplied by 100 and then integerized).
The "burst_id" is an index value specifying the source_type of the triggered event.
There are a total of 17(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 12-13, 15, 20 and 22-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=123 PACKET CONTENTS:
The FERMI_LAT_TRANS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=123)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer Reference number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 trans_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 trans_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 trans_flux [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 10 base_flux [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 11 trans_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 cur_flx_err [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 13 bas_flx_err [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 14 time_scale [integer] Index: 1=1day, 2=1week
long 15 e_band [integer] e1-e2 [GeV] energy_band
long 16-17 spare[2] integer 8 bytes for the future
long 18 trig_id bits ????????
long 19 misc bits Misc stuff packed in here
long 20-24 spare[5] integer 20 bytes for the future
long 25 signif [centi-sigma] (int)(100*sigma_signif)
long 26-31 spare[6] integer 24 bytes for the future
quad_char 32-38 srcname[17] chars The SourceName
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 120, 121, 122, and 123;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "ref_num" is a uniquely identifying reference number for each trigger.
It is the number of seconds since 01 Jan 2001 (when the notice was created).
[4] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[5] The "trig_tjd" is the Truncated Julian Day of the transient trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the transient trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "trans_ra" and "trans_dec" are the RA,Dec coordinates of the transient
as determined by the ground processing software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
The "trans_current_flux" is the flux of the transient in units of photon/cm2/sec
multiplied by 1.0e9, and then integerized. It is the current flux (ie at the
time of the notice).
//The "trans_base_flux" is the flux of the transient in units of photon/cm2/sec
//multiplied by 1.0e9, and then integerized. This is the baseline flux prior
//to the flare that triggered the ground-processing analysis that resulted
//in producing this notice.
The "trans_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
The "current_flux_error" is the uncertainty on the "trans_current_flux" value.
Also in photons/cm2/sec multiplied by 1.0e9, and then integerized.
//The "base_flux_error" is the uncertainty on the "trans_current_flux" value.
//Also in photons/cm2/sec multiplied by 1.0e9, and then integerized.
The "time_scale" is the time interval of the trigger criteria that found the new source.
A value of 1 for 1-day timescale, and a value of 2 for a 1-week scale.
The "e_band" contains the E_lo - E_hi energy band used for this detection,
where E_lo is in the bottem 16 bits and E_hi is in the upper 16 bits.
Both have been multiplied by 10 and integerized. The units are deci-GeV.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found on-board and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spare for future use
5 G retract This is a retraction (=1)
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-10 spare.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^1-31 spare.
[25] The "signif" is the detection significance of the new unknown source.
The units are centi-sigma (divide by 100 to get S.SS value in units of sigma).
[32-38] The "sourcename" is the name of the new source.
This item in the packet spans 7 longwords (ie 28 bytes) and contains
the ASCII string of the name. This string can be up to 27 characters long,
and will always be null-terminated.
There are a total of 21(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 12-13, 15, 20 and 22-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=124 PACKET CONTENTS:
The FERMI_LAT_GRB_POS_TEST packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=124)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [counts] Num events used in location calc, 0 to inf
long 10 inten_4 4_bytes Evt_cnts in 4 energy bands
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long 14 int_time [msec] Integration time
long 15-16 spare[2] integer 8 bytes for the future
//long 16 lon_lat 2_shorts (int)(Longitude,Lattitude *100)
long 17 trig_index integer Trigger index
long 18 Trig_ID bits LAT burst candidate, 1=yes,0=no
long 19 misc bits Misc stuff packed in here
long 20 rec_seq_num integer SerNum of the messages (1-~40)
long 21-24 spare[4] integer 16 bytes for the future
long 25 temp_signif integer (int)(4*(-log10(probability)))
long 26 image_signif integer (int)(4*(-log10(probability)))
long 27-37 spare[12] integer 48 bytes for the future
long 38 loc_qual [0.0001] Location quality (0.0 - 1.0)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 120, 121, 122, 123, and 124;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
But for this test notice type, it is hardwired to be a fixed value of 99999.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-LAT trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec. This uncertainty
is governed by the variable trigger window duration, which is defined in terms
of a fixed number of events rather than an interval of time.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the LAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "burst_inten" is the subset of the total number of events in the standard 4 energy bands
that were used in the location calculation.
[10] The "inten_4" contains 4 unsigned_char counts of the number of events
in the standard 4 energy bands during the 'int_time' interval.
The least significant byte (lsb) contains the number of events in the 0-100 MeV band,
the next lsb contains number of events in the 100MeV-1GeV band,
3rd has 1-10GeV, and the most significant byte has the number of events in the greater_than_10GeV band.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" is the location of the source in LAT instrument coordinates.
Theta is the angle off the bore sight. //And phi is the azimuthal angle
//with 0 starting at..... measured CW(tbd)....
[14] The "int_time" is the time interval between the first and last photons
which went into the successful trigger criteria. The units are milli-seconds.
[17] The "trig_index" is the index value of the trigger criterion that provided
the successful trigger (precise definition is TBD).
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found on-board and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F G-vs-L The starting/seed location came from 0=GBM, 1=from_LAT
1 F gam_used 0=all gammas used, or 1=only gammas above a cut used in loc method
2-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event (NOOP for TEST)
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event (NOOP for TEST)
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0 When this bit is a 1, then a Repoint_Request was made to the s/c.
2^1-10 spare.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^1-31 spare.
[20] The "rec_seq_num" is the Record Sequence Number. It is a packet serial number
spanning all the messages that come from the s/c during a given trigger.
It will start with a value of 1 for the FERMI_GBM_ALERT Notice and increment during
the multiple GBM_POS Notices, etc.
[25] The "temp_stat" is the measure of the Temporal Test Statistic.
The value is 4*(-log10(temporal_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
[26] The "image_stat" is the measure of the Image Test Statistic.
The value is 4*(-log10(spatial_probability)). The bigger the number,
the more likely the trigger is a real GRB. The Fermi-LAT team
has determined that sum of the Temporal and Image Stats >120 is a good working threshold.
[38] The "loc_qual" is the quality of the location determination. It is a probability
that runs from 0.0 to 1.0 (0.0001 quantization), with a value of -1
if undefined. The bigger the number, the more likely that is a real event
(and converely, a small number indicates random photons in the LAT).
There are a total of 21(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 12-13, 15, 20 and 22-37.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=125 PACKET CONTENTS:
The FERMI_LAT_MONITOR packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=125)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer Reference number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 trans_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 trans_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 trans_flux [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 10 base_flux [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 11 trans_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 cur_flx_err [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 13 bas_flx_err [ph/cm*2] (int)(flux*1e9 ph/cm2/sec)
long 14 time_scale [integer] Index: 1=1day, 2=1week
long 15 e_band [integer] e1-e2 [GeV] energy_band
long 16-17 spare[2] integer 8 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-24 spare[5] integer 20 bytes for the future
long 25 signif [centi-sigma] (int)(100*sigma_signif)
long 26-31 spare[6] integer 24 bytes for the future
quad_char 32-38 src[17] chars The Source name
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 125,
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the point_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "ref_num" is a uniquely identifying reference number for each trigger.
It is the number of seconds since 01 Jan 2001 (when the notice was created).
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-LAT_MONITOR flare trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT_MONITOR flare trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "trans_ra" and "trans_dec" are the RA,Dec coordinates of the flare
as determined by the ground processing software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "trans_current_flux" is the flux of the transient in units of photon/cm2/sec
mulitplied by 1.0e9, and then integerized. It is the current flux (ie at the
time of the notice).
[10] The "trans_base_flux" is the flux of the transient in units of photon/cm2/sec
mulitplied by 1.0e9, and then integerized. This is the baseline flux prior
to the flare that triggered the ground-processing analysis that resulted
in producing this notice.
[11] The "trans_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12] The "current_flux_error" is the uncertainty on the "trans_current_flux" value.
Also in photons/cm2/sec multiplied by 1.0e9, and then integerized.
[13] The "base_flux_error" is the uncertainty on the "trans_current_flux" value.
Also in photons/cm2/sec multiplied by 1.0e9, and then integerized.
[14] The "time_scale" is the time interval of the trigger criteria that detected te flare.
A value of 1 for 1-day timescale, and a value of 2 for a 1-week scale.
[15] The "e_band" contains the E_lo - E_hi energy band used for this detection,
where E_lo is in the bottem 16 bits and E_hi is in the upper 16 bits.
Both have been multiplied by 10 and integerized. The units are deci-GeV.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found in the Fermi ground processing and (b) flag bits that are assigned in
the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G not_mon This is a known source, but is not Monitored (=1)
1-4 - spare spare for future use
5 G retract This is a retraction (=1)
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-10 spare.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^1-31 spare.
[25] The "signif" is the rate increase.
Both are in units of centi-sigma (divide by 100 to get S.SS value in units of sigma).
[32-38] The "src" is just the SourceName of the object. Most of the time it can be used
as the filename portion of the URL -- the leading path for the full URL is
"http://fermi.gsfc.nasa.gov/FTP/glast/data/lat/catalogs/asp/current/lightcurves/".
This item in the packet spans 7 longwords (ie 28 bytes) and contains
the ASCII string of the filename portion of the lightcurve URL. This string
can be up to 27 characters long, and will always be null-terminated.
There are a total of 21(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items 12-13, 15, 20 and 22-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=126 (&144) PACKET CONTENTS:
The FERMI_SC_SLEW (& FERMI_SC_SLEW_INTERNAL) packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=126 or 144)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 point_tjd [days] Truncated Julian Day
long 6 point_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-13 spare[5] integer 20 bytes for the future
long 14 dwell_time [centi-sec] (int)(sssss.sss *100)
long 15-17 spare[3] integer 12 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 126
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the point_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "point_tjd" is the Truncated Julian Day of the FERMI-LAT request to the s/c
to repoint to the newly detected target by the LAT (ie an autonomous report request (ARR),
eg. TJD=14466 is 01 Jan 2008.
[6] The "point_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT request to the s/c
to repoint to the newly detected target by the LAT (ie an autonomous report request (ARR),
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec coordinates of the request
as determined by the LAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[14] The "dwell_time" is the observation duration of the request.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found in the Fermi ground processing and (b) flag bits that are assigned in
the GCN ground-processing. This "trig_id" field is a little out of place
for the SLEW notice, but it is maintained for continuity with the other notice types,
and there are two bitfields that are still appropriate for a slew notice.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spare for future use
5 G retract This is a retraction (=1)
6-29 - spare spare for future use
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0 When this bit is a 1, then the s/c decided to slew to the requested position.
2^1-10 spare.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec values
were out of valid range (eg RA was 361 deg).
2^12-29 spare.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued.
2^31 spare.
There are a total of 19(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items (tbr)10-12, 15-16, 20, and 25-37.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=127 PACKET CONTENTS:
The FERMI_LAT_GND packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=127)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 tot_inten integer Total Intensity
long 10 spare integer 4 bytes for the future
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +100.0 *100)
long //14 int_time [msec] Integration time
long 15-17 spare[3] integer 12 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-25 spare[6] integer 24 bytes for the future
long 26 signif integer (int)(sqrt(TS)*100)
long 27 inten2 centi-cnts Evt_cnts in the 0.1-1.0 GeV band
long 28 inten3 centi-cnts Evt_cnts in the 1.0-10 GeV band
long 29 inten4 centi-cnts Evt_cnts in the 10-inf GeV band
long 30-38 spare[9] integer 36 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 127
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-LAT trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec. This uncertainty
is governed by the variable trigger window duration, which is defined in terms
of a fixed number of events rather than an interval of time.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the LAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "tot_inten" is the total number of events in the lowest 3 energy bands
during the 'int_time' time interval (ie the sum of the values in slots 27-29).
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12-13] The "phi" and "theta" is the location of the source in LAT instrument coordinates.
Theta is the angle off the bore sight. And phi is the azimuthal angle
with 0 deg starting at..... measured CW(tbd)....
//The "int_time" is the time interval between the first and last photons
//which went into the successful trigger criteria. The units are milli-seconds.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found on-board and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-2 G Seed_index 3 bits giving the index value of the starting/seed location:
1=GBM,2=LAT_blind,3=LAT_onboard,4=Swift,5=INTEGRAL,6=AGILE.
3-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs Ground-assigned
(they will all be ground for this notice type);
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-31 spare.
[26] The "signif" is the sqrt(TS) (with 2 dof) of the detection.
It has been multiplied by 100 and integerized.
[27-29] The "inten2", "inten3", and "inten4" contain the number of counts
in the three specified energy bands. The units are centi-counts,
ie the counts have been multiplied by 100 and interegerized.
(I am not sure how fractional counts come to be in the Fermi analysis.)
The analysis used for these ground-generated LAT notices does not allow
for the "inten1" to be calculated.
The "spare" items are usually filled with zeros.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=128 PACKET CONTENTS:
The FERMI_LAT_OFFLINE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=128)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 burst_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 burst_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integer 8 bytes for the future
long 11 burst_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12-17 spare[6] integer 24 bytes for the future
long 18 Trig_ID bits LAT burst candidate, 1=yes,0=no
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 120, 121, 122, and 123;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types). The types are:
120 = FERMI_LAT_GRB_POS_INI, 121 = FERMI_LAT_POS_UPD.
122 = FERMI_LAT_GRB_POS_DIAG, and 123 = FERMI_LAT_TRANS.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the FERMI-LAT trigger,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the FERMI-LAT trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec. This uncertainty
is governed by the variable trigger window duration, which is defined in terms
of a fixed number of events rather than an interval of time.
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the LAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[11] The "burst_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found on-board and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-2 G Seed_index 3 bits giving the index value of the starting/seed location:
1=GBM,2=LAT_blind,3=LAT_onboard,4=Swift,5=INTEGRAL,6=AGILE.
3-4 - spare spare for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-29 - spare spare for future use
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
2^0-12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-29 spare.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued.
2^31 spare.
There are "spare" items in the packet (usually filled with zeros).
They are located at items 9-10, 12-17, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
TYPE=129 PACKET CONTENTS:
The FERMI_POINTDIR packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=129)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 -
long 5 start_tjd [days] Truncated Julian Day
long 6 start_sod [centi-sec] (int)(sssss.sss *100)
long 7 start_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 start_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 delta_t [sec] Typically 120 sec
long 10 ra_dec_1dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 11 ra_dec_2dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 12 ra_dec_3dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 13 ra_dec_4dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 14 ra_dec_5dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 15 ra_dec_6dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 16 ra_dec_7dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 17 ra_dec_8dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 18 ra_dec_9dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 19 ra_dec_10dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 20 ra_dec_11dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 21 ra_dec_12dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 22 ra_dec_13dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 23 ra_dec_14dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 24 ra_dec_15dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 25 ra_dec_16dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 26 ra_dec_17dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 27 ra_dec_18dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 28 ra_dec_19dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 29 ra_dec_20dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 30 ra_dec_21dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 31 ra_dec_22dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 32 ra_dec_23dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 33 ra_dec_24dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 34 ra_dec_25dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 35 ra_dec_26dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 36 ra_dec_27dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 37 ra_dec_28dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 38 ra_dec_29dt [two 0.1-deg] (int)(RA*10) in Hi, (int)(Dec*10) in Lo
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 129
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the "start_sod" (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[5] The "start_tjd" is the Truncated Julian Day of the of the first RA,Dec pointing sample
(ie "point_ra" and "point_dec").
[6] The "start_sod" is the UT seconds-of-day (SOD) of the first RA,Dec pointing sample
(ie "point_ra" and "point_dec"). The units are in centi-seconds (ie the fl.pt. seconds
were multiplied by 100 and then integerized).
[7-8] The "point_ra" and "point_dec" are the RA,Dec pointing coordinates of FERMI
at the time specified by "start_tjd" and "start_sod". J2000 epoch.
These intrinsically floating point quantities have been multiplied by 10,000
and then integerized to make an integer quantity with units of 0.0001-degrees.
[9] The "delta_time" is the amount of time between the ra,dec pointing samples.
The units are integer seconds. (It is believed that this value will always
be 120 sec, but do not count on it, ie have your software check the delta_time value
for every packet received.)
[10-38] The "saa_ra_dec_Ndt" are a series of 29 (N=1 to 29) SAA_flag,RA,Dec values
for the FERMI s/c pointing sampled every "delta_time" sec (SAA_flag indicates
the s/c is inside the SAA region, and the RA,Dec values (J2000) are the pointing
direction of the LAT instrument). Example:
"saa_ra_dec_1dt" is the SAA_flag,RA,Dec pointing at "start_sod+1*delta_time";
"saa_ra_dec_2dt" would be the pointing direction at "start_sod+2*delta_time"; etc.
The SAA,RA,Dec values are packed into a single 4-byte slot.
The SAA_flag occurpies the 2^31 bit, RA occupies bits 30-16, and the Dec
is in the lower 2 bytes (bits 15-0).
The RA,Dec values are in units of deci-degrees (ie the fl.pt. degress
were multiplied by 10 and then integerized).
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=130 PACKET CONTENTS:
This packet is for GCN programs internal use only. The packet is NEVER itself
distributed to socket sites. This packet is used to signal the GCN programs
to produce the ONLY full-format email Notice (to got to sites requesting that Notice
Type and the full-format email format). [The variable number of "sources"
makes this notice type incompatible with the socket and voevent formats and
with the email formats other than the full-format.]
The SIMBAD-NED packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=130)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger number
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integer 8 bytes for the future
long 11 event_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 otype integer Original Type number
long 13-21 spare[9] integer 36 bytes for the future
quad_char 22-38 fname[17] chars Filename (up to 68 chars long)
long 39 pkt_term integer Pkt Termination (always = \n)
[0] The "pkt_type" is an integer with a value of 130.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the event_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each transient.
It is the number of seconds since 01 Jan 2001.
[5] The "trig_tjd" is the Truncated Julian Day of the ???? transient,
eg. TJD=13370 is 01 Jan 2005.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the ???? transient.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "burst_ra" and "burst_dec" are the RA,Dec coordinates of the object
that is to be searched in SIMBAD and NED. These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[11] The "burst_error" is the radius of the circle to search.
The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12] The "otype" is the "pkt_type" value of the notice that spawned this SIMBAD/NED search.
[22-38] The "fname" is the full-path filename of the file containing the results
of the SIMBAD/NED search.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=131 PACKET CONTENTS:
The FERMI_GBM_SUBTHRESHOLD (there is no "internal" for of this type) packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=131)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 tran_num integer Transient number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integer 8 bytes for the future
long 11 event_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 evt_sod_subsec [micro-sec] Event_SOD subsec portion
long 13 earth_angle [centi-deg] (int)(0.0 to +180.0 *100)
long 14 duration [milli-sec] Event duration (int)(sss.sss *1000)
long 15-17 spare[3] integer 12 bytes for the future
long 18 soln_status bits Type of source/transient found
long 19 misc bits Misc stuff packed in here
long 20-22 spare[3] integer 12 bytes for the future
long 23 reliability integer Mostly class ID & probability
long 24-26 spare[3] integers 12 bytes for the future
quad_char 27-38 url[12] chars The filename portion of the URLs
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 131;
that tells which type of packet this is and therefore what the contents are
(the contents change between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the event_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trans_num" is a uniquely identifying number for each transient.
It is the number of seconds since 01 Jan 2001.
[5] The "event_tjd" is the Truncated Julian Day of the FERMI-GBM transient,
eg. TJD=13370 is 01 Jan 2005.
[6] The "event_sod" is the UT seconds-of-day (SOD) of the FERMI-GBM transient.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[7-8] The "event_ra" and "event_dec" are the RA,Dec coordinates of the event (or grb, transient, or noise)
as determined by the ground-processing software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees (over-precision,
but this is the new standard scaling for all missions/instruments).
[11] The "event_error" is the radius of the circle that will contain on average
68% of the transients. It includes both the statistical error plus the
systematic error. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[12] The "event_sod_subsec" is the UT micro-seconds portion of the GBM transient time (event_sod).
The units are in micro-seconds (ie the fl.pt. subseconds portior were multiplied by 1e6
and then integerized).
[13] The "earth_angle" is the angle between the event direction and the center of the Earth.
The units are in centi-degees (ie the fl.pt. degrees were multiplied by 100
and then integerized).
[14] The "duration" is the length of the event.
The units are in milli-seconds (ie the fl.pt. seconds were multiplied by 1000
and then integerized).
[18] The "soln_status" (aka trans_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
These bits will be determined largely (but not completely) by the ClassID in the Most_Likely fields.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spares for future use
5 G def_not_grb 0=No or 1=Yes, it is definitely not a GRB (bad label; its really a Retraction)
6-11 - spare spares for future use
12 G blk_cat_src 0=No or 1=Yes, it is in the catalog of sources to be blocked (internal use only)
13-27 - spare spares for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
0 Contains spectral classification: 0=soft, 1=hard
1 Not asigned.
2 Contains type classification: 0=short, 1=long
2^3-10 Not asigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Lon,Lat values
were out of valid range (eg RA was 361 deg).
2^12-29 Not assigned.
2^30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
A Gnd-generated Notice is issued anytime humans during ground operations
have determined if this Notice should be issued. This will typically be used
during the early phases of the mission before the automatic real-time distribution
capability is enabled. Once the burst position has been validated by humans,
a GBM_Pos Notice will be issued (with this flag bit set to 1).
After the Verification phase, there still may be occaisions when a GBM_POS notice
is (re)created by human-processing and will be distributed (with this bit set to 1).
2^31 Not assigned.
[23] The "reliability" is a measure of confidence on the detection.
It is a number from 1 to 10, where 2 is "low", 5 is "medium", and 8 is "high.
[23-38] The "url" is just the filename portion of the URL, where the leading path portion
for the URL is "https://gcn.gsfc.nasa.gov/notices_gcb_sub/".
So the full URL would look like:
"https://gcn.gsfc.nasa.gov/notices_gcb_sub/gbm_subthresh_NNNNNNNNN.nnnnnn_healpix.fits".
The other two URLs can be made by appropriate modification:
"https://gcn.gsfc.nasa.gov/notices_gcb_sub/gbm_subthresh_NNNNNNNNN.nnnnnn_map.png".
"https://gcn.gsfc.nasa.gov/notices_gcb_sub/gbm_subthresh_NNNNNNNNN.nnnnnn_lc.pdf".
This "url" item in the packet spans 12 longwords (ie 48 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 47 characters long, and will always be null-terminated.
There are a total of 21 "spare" items in the packet (usually filled
with zeros). They are located at items 9-10, 15-17, 20-22, and 24-26.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=133 PACKET CONTENTS:
The SWIFT_BAT_MONITOR packet contains detections of increases in known sources
periodically monitored by Swift-BAT.
The SWIFT_BAT_MONITOR packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=133)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer Some reference number
long 5 tjd [days] Truncated Julian Day
long 6 sod [centi-sec] (int)(sssss.sss *100)
long 7 ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 crab_flux [centi-mCrab] (int)(mm.mm *100)
long 10 curr_flux [10^-4-cnts/cm2/sec] (int)(c.cccc *10000)
long 11 base_flux [10^-4-cnts/cm2/sec] (int)(c.cccc *10000)
long 12 signif [centi-sigma] (int)(ss.ss *100)
quad_char 13-17 srcname[5] chars The name of the source
long 18 flags bits Flag bits on source-type
long 19 misc bits Misc flag bits and fields
long 20-21 spare[2] integer 8 bytes for future use
quad_char 22-38 lc_url[17] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=133):
[0] The "pkt_type" is an integer with a value of 133, which tells that this packet
is of type SWIFT_BAT_MONITOR and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "ref_num" is a reference number. This is a sequential number that is assigned;
it is not guarenteed to be unique.
[5] The "tjd" is the Truncated Julian Day of the strt of the outburst,
eg. TJD=12275 is 01 Jan 2002. Please note that "start" is a somewhat
poorly determined quantity given the sampling of BAT Monitor program (orbital or daily)
and that the algorithm used to detect these outbursts is simplistic and biased
towards getting earlier detection (rather than more accurate but later detections).
[6] The "sod" is the UT seconds-of-day (SOD) of the outburst. The SOD
is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689568 = 46895.68 sec-of-day =
13:01:35.68 UT.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the source object
undergoing the transient outburst (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "crab_flux" is the current intensity of the source object in mCrab units
(where the cnt/cm2/sec units have been converted to mCrab units with the usual
qualifier that spectral index differences between the source and the Crab make
this measure of intensity a semi-quantitative measure at best). The units
are mCrab multiplied by 100 and then integerized.
[10] The "curr_flux" is the current intensity of the source. The units are cnts/cm2/sec
multiplied by 10000 and then integerized.
[11] The "base_flux" is the baseline intensity of the source before the transient outburst occurred.
The units are cnts/cm2/sec multiplied by 10000 and then integerized.
[12] The "signif" is the significance of the increase of the source outburst. It is the
difference between "curr_flux" and "base_flux" in units of sigma (multiplied by 100
and then integerized, ie centi-sigma).
[13-17] The "srcname" is the name of the object that is undergoing the transient outburst.
This item in the packet spans 5 longwords (ie 20 bytes) and contains the ASCII string
of the source_name. This string can be up to 19 characters long, and will always be null-terminated.
[18] The "flags" field contains flag bit bits relating to the source-type identity.
Bit_Number Item_name Description
---------- --------- -----------
0 test_blank_sky This is a test "blank" skypatch "source"
1 unknown_src This is a new, previously unknown source
2 known_src This is an outburst/flare from a previously known source
3 prov_src This is a marginal detection, aka a provisional source
2-31 x_x_x_x spare
[19] The "misc" field contains various miscelaneous flags and fields.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0-3 n/a Sampling index (0=Orbital, 1=Daily)
4-12 spare.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
16-29 spare.
30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
For this Notice Type, they are always ground-generated.
31 spare.
[22-38] The "lc_url" is just the filename portion of the URL -- the leading path
for the full URL is "http://swift.gsfc.nasa.gov/docs/swift/results/transients/".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 2 "spare" items in the packet (usually filled
with zeros). They are located at items 20 and 21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as multiple sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
TYPE=134 PACKET CONTENTS:
The MAXI_UNKNOWN_SOURCE packet contains detections of increases of previously uncataloged sources
on the sky periodically monitored by MAXI instrument on the ISS.
The MAXI_UNKNOWN_SOURCE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=134)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer A unique ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 event_flux [deci-mCrab] Flux in mCrabs during trig window, 0 to inf
long 10 flux_err [deci-mCrab] Flux_Error in mCrabs during trig window
long 11 event_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
//long 12 src_bkg_lo [deci-mCrab] Source and Bkg flux per scan in Lo band *10
//long 13 src_bkg_med [deci-mCrab] Source and Bkg flux per scan in Med band *10
//long 14 src_bkg_hi [deci-mCrab] Source and Bkg flux per scan in Hi band *10
long 15 t_and_e integer timescale and e_band of the detection trigger criteria
//long 16 lon_lat two_shorts (int)(Latitude *100; ditto Lon
long 17 spare integer 4 bytes for future use
long 18 event_flags bits Type of source/trigger found
long 19 misc bits Misc flag bits and fields
long 20-38 spare[19] integer 76 bytes for future use
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=134):
[0] The "pkt_type" is an integer with a value of 134, which tells that this packet
is of type MAXI_UNKNOWN_SOURCE and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
//[4] As of 31Aug2011, the MAXI Team changed the way these Unknown transients are identified.
//The "trig_num" is a number which uniquely identifies this trigger.
//It is a sequential serial number assigned by the analysis processing.
//As of 24Sep2011, it is 30.
//And then at DDmmmYY, the "trig_num" was changed to the method the MAXI_KNOWN_SOURCE uses:
[4] The "trig_num" is a number which uniquely identifies this trigger.
It is composed of 4 parts dDDDOPPPPP, where "dDDD" is the day_number of the event,
and where the "d" is the most significant digit of the total 4-digit day_number. For space limitations
the full 10-digit ID number can not be stored in a 4-byte packet slot. The 'd' is stored
in slot 19 (see "misc" below). The "O" is the orbit number for that day.
And "PPPPP" is the position. This 10-digit number provides a unique ID number for each event.
[5] The "event_tjd" is the Truncated Julian Day of the MAXI trigger,
eg. TJD=15197 is 01 Jan 2010.
[6] The "event_sod" is the UT seconds-of-day (SOD) of the outburst. The SOD
is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689500 = 46895.00 sec-of-day =
13:01:35.00 UT.
[7-8] The "event_ra" and "dec" fields specify the RA,Dec location of the source object
undergoing the transient outburst (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[9] The "event_flux" is the flux (in mCrab units) of the event
during the time duration of the successful trigger criterion.
The units are deci-counts (the counts value has been multiplied by 10
and then integerized).
As of 31Aug2011, the MAXI Team added this flux_error field.
The "event_flux_error" is the uncertainty on the flux (in mCrab units).
The units are deci-counts (the counts value has been multiplied by 10
and then integerized).
[11] The "event_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). The MAXI team has hardwire fixed this value
to be 0.5 deg. It contains the statistical error and the systematic error.
As of 31Aug2011, the MAXI Team stopped giving these value for the Unknown Transients.
//[12-14] The "src_bkg_lo", "src_bkg_med", and "src_bkg_hi" each contain the 'source' and
//'background' mCrabs in the lo/medium/high energy_bands. The 'source'
//has been multiplied by 10 and up-shifted into the most significant two bytes
//of the 4-byte slot. The 'background' counts has been multiplied by 10
//and included in the least significant two bytes of the 4-byte slot.
//(ie the 'source' (total-bkg) for each band is in units of deci-nCrabs in the hi-word,
//and the 'background' also in deci-nCrabs is in the lo-word for each of the
//3 energy_bands in each of the 3 4-byte slots.)
[15] The 't_and_e' contains the index values indicating which timescale and energy_band
for the sucessful trigger criteria. The timescale index value occupies the first 4 bits (2^0 - 2^3),
and has values defined for 0 to 8 representing 'undefined/unavailable', 1 sec, 3 sec, 10 sec,
30 sec, 1 scan, 1 orbit, 4 orbits, 1 day; respectively.
The energy_band occupies bits 2^8 through 2^11, and has values defined for 0 to 4
representing "undefined/unavailable", "Low, 2-4 keV","Medium, 4-10 keV","High, 10-20 keV", "L+M, 2-10 keV".
As of 31Aug2011, the MAXI Team stopped giving these Lon,Lat values for the Unknown Transients.
//[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the MAXI trigger.
//This 4-byte quantity is composed of two 2-byte integers. The high-order short
//is the latitude multiplied by 100 and integerized; the low-order short
//is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[18] The "event_flags" field contains flag bit bits relating to the trigger solution and the source-type identity.
Bit_Number Item_name Description
---------- --------- -----------
0-3 x_x_x_x spare
4 neg_flux Indicates message received from MAXI team contained a negative flux value(s)
5-31 x_x_x_x spare
[19] The "misc" field contains various miscelaneous flags and fields.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0-3 day_units The most-signif digit of the DDDDD portion of the Trigger_ID_Number
4-29 spare.
30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
For this Notice Type, they are always ground-generated.
31 spare.
There are a total of 24 "spare" items in the packet (usually filled with zeros).
They are located at items 12-14, 16-17 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as multiple sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
TYPE=135 PACKET CONTENTS:
The MAXI_KNOWN_SOURCE packet contains detections of flux increases in known sources
periodically monitored by MAXI instrument on the ISS.
The MAXI_KNOWN_SOURCE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=135)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer A unique ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 event_flux [deci-mCrab] Flux in mCrabs during trig window, 0 to inf
long 10 spare integer 4 bytes for future use
long 11 event_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 src_bkg_lo [deci-mCrab] Source and Bkg flux per scan in Lo band *10
long 13 src_bkg_med [deci-mCrab] Source and Bkg flux per scan in Med band *10
long 14 src_bkg_hi [deci-mCrab] Source and Bkg flux per scan in Hi band *10
long 15 t_and_e integer timescale and e_band of the detection trigger criteria
long 16 lon_lat two_shorts (int)(Latitude *100; ditto Lon
long 17 spare integer 4 bytes for future use
long 18 event_flags bits Type of source/trigger found
long 19 misc bits Misc flag bits and fields
long 20-21 spare[2] integer 8 bytes for future use
quad_char 22-29 srcname[8] chars Filename (up to 32 chars long)
long 30-38 spare[9] integer 36 bytes for future use
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=135):
[0] The "pkt_type" is an integer with a value of 135, which tells that this packet
is of type maXI_KNOWN_SOURCE and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a number which uniquely identifies this trigger.
It is composed of 4 parts dDDDOPPPPP, where "dDDD" is the day_number of the event,
and where the "d" is the most significant digit of the total 4-digit day_number. For space limitations
the full 10-digit ID number can not be stored in a 4-byte packet slot. The 'd' is stored
in slot 19 (see "misc" below). The "O" is the orbit number for that day.
And "PPPPP" is the position. This 10-digit number provides a unique ID number for each event.
[5] The "event_tjd" is the Truncated Julian Day of the MAXI trigger,
eg. TJD=15197 is 01 Jan 2010.
[6] The "event_sod" is the UT seconds-of-day (SOD) of the outburst. The SOD
is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689500 = 46895.00 sec-of-day =
13:01:35.00 UT.
[7-8] The "event_ra" and "dec" fields specify the RA,Dec location of the source object
undergoing the transient outburst (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[9] The "event_flux" is the flux of the source (in mCrab units)
during the time duration of the successful trigger criterion.
The units are deci-counts (the counts value has been multiplied by 10
and then integerized).
[11] The "event_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). The MAXI team has hardwire fixed this value
to be 0.5 deg. It contains the statistical error and the systematic error.
[12-14] The "src_bkg_lo", "src_bkg_med", and "src_bkg_hi" each contain the 'source' and
'background' mCrabs in the lo/medium/high energy_bands. The 'source'
has been multiplied by 10 and up-shifted into the most significant two bytes
of the 4-byte slot. The 'background' counts has been multiplied by 10
and included in the least significant two bytes of the 4-byte slot.
(ie the 'source' (total-bkg) for each band is in units of deci-nCrabs in the hi-word,
and the 'background' also in deci-nCrabs is in the lo-word for each of the
3 energy_bands in each of the 3 4-byte slots.)
[15] The 't_and_e' contains the index values indicating which timescale and energy_band
for the sucessful trigger criteria. The timescale index value occupies the first 4 bits (2^0 - 2^3),
and has values defined for 0 to 8 representing 'undefined/unavailable', 1 sec, 3 sec, 10 sec,
30 sec, 1 scan, 1 orbit, 4 orbits, 1 day; respectively.
The energy_band occupies bits 2^8 through 2^11, and has values defined for 0 to 4
representing "undefined/unavailable", "Low, 2-4 keV","Medium, 4-10 keV","High, 10-20 keV", "L+M, 2-10 keV".
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the MAXI trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[18] The "event_flags" field contains flag bit bits relating to the trigger solution and the source-type identity.
Bit_Number Item_name Description
---------- --------- -----------
0-3 class Undef(=0), GRB(=1), nova-cv(=2), SN(=3), x-ray-star(=4), AGN(=5)
4 neg_flux Indicates messages received from MAXI team containing negative flux value(s)
5-31 x_x_x_x spare
[19] The "misc" field contains various miscelaneous flags and fields.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0-3 day_units The most-signif digit of the DDDDD portion of the Trigger_ID_Number
4-29 spare.
30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
For this Notice Type, they are always ground-generated.
31 spare.
[22-29] The "srcname" is the name of the object that is undergoing the transient outburst.
This item in the packet spans 8 longwords (ie 32 bytes) and contains the ASCII string
of the source_name. This string can be up to 31 characters long, and will always be null-terminated.
There are a total of 13 "spare" items in the packet (usually filled with zeros).
They are located at items 10, 17, 20-21, and 30-38.
The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as multiple sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
TYPE=136 PACKET CONTENTS:
The MAXI_TEST packet duplicates/mimicks the MAXI_UNKNOWN_SOURCE packet.
The MAXI_TEST packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=136)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer A unique ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 event_flux [deci-mCrab] Flux mCrab during trig window, 0 to inf
long 10 spare integer 4 bytes for future use
long 11 event_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 src_bkg_lo [deci-mCrab] Source and Bkg flux per scan in Lo band *10
long 13 src_bkg_med [deci-mCrab] Source and Bkg flux per scan in Med band *10
long 14 src_bkg_hi [deci-mCrab] Source and Bkg flux per scan in Hi band *10
long 15 t_and_e integer timescale and e_band of the detection trigger criteria
long 16 lon_lat two_shorts (int)(Latitude *100; ditto Lon
long 17 spare integer 4 bytes for future use
long 18 event_flags bits Type of source/trigger found
long 19 misc bits Misc flag bits and fields
long 20-38 spare[19] integer 76 bytes for future use
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=136):
[0] The "pkt_type" is an integer with a value of 136, which tells that this packet
is of type SWIFT_BAT_MONITOR and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] 3he "trig_num" is a number which uniquely identifies this trigger.
If is composed of 4 parts DDDdOPPPPP, where "DDDd" is the day_number of the event,
and where the "d" is the units portion of the total 4-digit day_number. For space limitations
the full 10-digit ID number can not be stored in a 4-byte packet slot. The 'd' is stored
in slot 15 (see "misc" below). The "O" is the orbit number for that day.
And "PPPPP" is the position. This 10-digit umber provides a unique ID number for each event.
[5] The "event_tjd" is the Truncated Julian Day of the MAXI trigger,
eg. TJD=15197 is 01 Jan 2010.
[6] The "event_sod" is the UT seconds-of-day (SOD) of the outburst. The SOD
is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689500 = 46895.00 sec-of-day =
13:01:35.00 UT.
[7-8] The "event_ra" and "dec" fields specify the RA,Dec location of the source object
undergoing the transient outburst (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[9] The "event_flux" is the source flux (in mCrab units)
during the time duration of the successful trigger criterion.
The units are deci-mCrabs (the value has been multiplied by 10
and then integerized).
[11] The "event_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). The MAXI team has hardwire fixed this value
to be 0.5 deg. It contains the statistical error and the systematic error.
[12-14] The "src_bkg_lo", "src_bkg_med", and "src_bkg_hi" each contain the 'source' and
'background' mCrabs in the lo/medium/high energy_bands. The 'source'
has been multiplied by 10 and up-shifted into the most significant two bytes
of the 4-byte slot. The 'background' counts has been multiplied by 10
and included in the least significant two bytes of the 4-byte slot.
(ie the 'source' (total-bkg) for each band is in units of deci-mCrabs in the hi-word,
and the 'background' also in deci-mCrabs is in the lo-word for each of the
3 energy_bands in each of the 3 4-byte slots.)
[15] The 't_and_e' contains the index values indicating which timescale and energy_band
for the sucessful trigger criteria. The timescale index value occupies the first 4 bits (2^0 - 2^3),
and has values defined for 0 to 8 representing 'undefined/unavailable', 1 sec, 3 sec, 10 sec,
30 sec, 1 scan, 1 orbit, 4 orbits, 1 day; respectively.
The energy_band occupies bits 2^8 through 2^11, and has values defined for 0 to 4
representing "undefined/unavailable", "Low, 2-4 keV","Medium, 4-10 keV","High, 10-20 keV", "L+M, 2-10 keV".
[16] The "lon_lat" is the Longitude and Lattitude of the s/c at the time of the MAXI trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order short
is the latitude multiplied by 100 and integerized; the low-order short
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[18] The "event_flags" field contains flag bit bits relating to the trigger solution and the source-type identity.
Bit_Number Item_name Description
---------- --------- -----------
0-3 x_x_x_x spare
4 neg_flux Indicates messages received from MAXI team containing negative flux value(s)
5-31 x_x_x_x spare
[18] The "misc" field contains various miscelaneous flags and fields.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0-3 day_units The most-signif digit of the DDDDD portion of the Trigger_ID_Number
4-29 spare.
30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
For this Notice Type, they are always ground-generated.
31 spare.
There are a total of 21 "spare" items in the packet (usually filled with zeros).
They are located at items 10, 17 and 20-38.
The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as multiple sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
TYPE=137 PACKET CONTENTS:
UNDER CONSTRUCTION!!!!! UNDER CONSTRUCTION!!!!! UNDER CONSTRUCTION!!!!!
The OGLE packet contains detections of gravitational lensing events.
The OGLE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=137)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 id_num integer ID number
long 5 det_tjd [days] Truncated Julian Day
long 6 det_sod [centi-sec] (int)(sssss.sss *100)
long 7 src_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 src_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 max_mag [centi-mag] (int)(mm.mm *100)
long 10 spare integer 4 bytes for future use
long 11 base_mag [centi-mag] (int)(0.0 to 180.0 *10000)
long 12 b_mag_err [centi-mag] (int)(mm.mm *100)
long 13 max_tjd [days] Truncated Julian Day
long 14 max_sod [centi-sec] (int)(ss.ss *100)
long 15 max_t_err [centi-days] (int)(dd.dd *100)
long 16 umin [d/n] Impact Param [Einstein ring units]
long 17 umin_err [d/n] Impact Param error
long 18 flags bits Flag bits on source-type
long 19 misc bits Misc flag bits and fields
long 20 ampl-n-err [centi] Amplification factor and error
long 21 tau_width [centi-days] Width of the cusp
long 22 tau_err [centi-days] Error in the wifth
long 23-24 spare[2] integer 8 bytes for the future
long 25 LeadTime [centi-days] Time until the maximum
long 26-29 spare[4] integer 16 bytes for the future
quad_char 30-38 lc_url[9] chars The URL to the OGLE webpage on this event
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=137):
[0] The "pkt_type" is an integer with a value of 137, which tells that this packet
is of type OGLE and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "id_num" is a reference number for the event. It is the year-field*100000 plus
the serial_number-field from their "unique_ID" (eg "2011-GLG-231").
[5] The "det_tjd" is the Truncated Julian Day of the detection/declaration of the event.
eg. TJD=15726 is 14 Uun 2011.
[6] The "det_sod" is the UT seconds-of-day (SOD) of the detection/declaration of the event.
The SOD is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689568 = 46895.68 sec-of-day =
13:01:35.68 UT.
[7-8] The "src_ra" and "src_dec" fields specify the RA,Dec location of the detected
optical transient (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "max_mag" field contains the projected maximum magnitude of the lensed star.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
then integerized).
[11] The "base_mag" field contains the baseline/quiescent magnitude of the lensed star.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
then integerized).
[12] The "base_mag_err" field contains the error in the baseline/quiescent magnitude value.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
then integerized).
[13] The "max_tjd" is the Truncated Julian Day of the maximum of the lightcurve (the cusp).
[14] The "max_sod" is the UT seconds-of-day (SOD) of the maximum of the lightcurve (the cusp).
The SOD is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec).
[15] The "max_t_err" ....
[16] The "umin" (aka "u0") is the impact parameter [in Einstein Ring units] for the lensing compact object.
The value has been multiplied by 100 and integerized.
[17] The "umin_err" is the uncertainty on "umin".
The value has been multiplied by 100 and integerized.
[18] The "flags" field contains flag bit bits relating to the source-type identity.
Bit_Number Item_name Description
---------- --------- -----------
0-2 type_id 3 bits to indicate the source type: 0=grav_lens,1=CV,2=???
3-4 x_x_x_x spare
//5 def_not_evt 0=No or 1=Yes, it is definitely not a Lensing Event (bad label; its really a Retraction).
//6 not_astro When set, this trigger has been determined to not be anything astrophysical.
7-31 x_x_x_x spare
[19] The "misc" field contains various miscelaneous flags and fields.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
//0 Amax_0 Flagbit is set when Amax was equal to 0.
//1 Amax_1 Flagbit is set when Amax is equal to unity.
//2 U0_0 Flagbit is set when u0 was equal to 0.
//3 spare spare bit, not yet assigned.
//4 tE Flagbit is set when tE or tEErr was 'nan'.
//5 Ibase Flagbit is set when Ibase was 'nan'.
6 Amax_err_error Flagbit is set when Amax_err was 'nan'.
7-24 spares spare bits, not yet assigned.
//25 Update Flagbit is set when this is an updated/improved notice of a previous notice.
//26 Ampl_inc Flagbit is set when the Amplitude value has increased from the original notice.
//27 Ampl_dec Flagbit is set when the Amplitude value has decreased from the original notice.
//28 Hi-Ampl Flagbit is set when the has identified as a high-amplitude event.
//29 Planet Flagbit is set when the lightcurve fit solution now includes a planet.
29-31 spares spare bits, not yet assigned.
[20] The "ampl-n-err" has two values combined into a single 4-byte slot in the packet.
The "amplification" is the projected (based on a fit to the lightcurve)
of how bright the lensed star will get (ie the ratio of the maximum flux over
the baseline flux). It is multiplied by 100, integerized, and packed into the
two most-significant bytes in the 4-byte slot. The lower two bytes
contain the uncertainty in the applification factor. It is also multiplied
by 100, integerized, and packed into the 2 least-significant bytes.
[21] The "tau" (aka "tE_width") is the "Einstein crossing time"
The value is multiplied by 100, and converted to a 32-bit integer for the packet.
[22] The "tau_err" (aka "tE_err") is the uncertainty in the "tau".
The value is multiplied by 100, and converted to a 32-bit integer for the packet.
[25] The "LeadTime" is the difference between the "max_tjd+sod" and the "det_tjd+sod".
It is provided here as a convenience so that the calculation with the above
four quantities need not be repeated by the recipient ('max' minus 'det').
Positive values indicate that the maximum has not occurred yet; negative values
indicate the maximum has already passed (according to the fit of the lightcurve
at the time of issuance of the OGLE Event Message).
The value is multiplied by 100, and converted to a 32-bit integer for the packet.
As such, the quantization is 0.01 days (ie 14.4 minutes).
[30] The "lc_url" is just the filename portion of the URL -- the leading path
for the full URL is "http://www.astrouw.edu.pl/~ogle/ogle3/ews/"
The full URL points to a OGLE webpage containing the initial and on-going information
about this lensing event (lightcurves, finding chart, reference stars, and data files).
This item in the packet spans 9 longwords (ie 36 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 35 characters long, and will always be null-terminated.
There are a total of 7 "spare" items in the packet (usually filled
with zeros). They are located at items 10, 23-24 and 26-29.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as many sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
TYPE=139 PACKET CONTENTS:
The MOA packet contains detections of gravitational lensing events.
The MOA packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=139)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 id_num integer ID number
long 5 det_tjd [days] Truncated Julian Day
long 6 det_sod [centi-sec] (int)(sssss.sss *100)
long 7 src_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 src_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 max_mag [centi-mag] (int)(mm.mm *100)
long 10 spare integer 4 bytes for future use
long 11 base_mag [centi-mag] (int)(0.0 to 180.0 *10000)
long 12 b_mag_err [centi-mag] (int)(mm.mm *100)
long 13 max_tjd [days] Truncated Julian Day
long 14 max_sod [centi-sec] (int)(ss.ss *100)
long 15 max_t_err [centi-days] (int)(dd.dd *100)
long 16 u0 [d/n] Impact Param [Einstein ring units]
long 17 u0_err [d/n] Impact Param error
long 18 flags bits Flag bits on source-type
long 19 misc bits Misc flag bits and fields
long 20 ampl-n-err [centi] Amplification factor and error
long 21 tE_width [centi-days] Width of the cusp
long 22 tE_err [centi-days] Error in the width
long 23-24 spare[2] integer 8 bytes for the future
long 25 LeadTime [centi-days] Time until the maximum
long 26-29 spare[4] integer 16 bytes for the future
quad_char 30-38 lc_url[9] chars The URL to the MOA webpage on this event
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=139):
[0] The "pkt_type" is an integer with a value of 139, which tells that this packet
is of type MOA and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "id_num" is a reference number for the event. It is the year-field*100000 plus
the serial_number-field from their "unique_ID" (eg "2011-GLG-231").
[5] The "det_tjd" is the Truncated Julian Day of the detection/declaration of the event.
eg. TJD=15726 is 14 Uun 2011.
[6] The "det_sod" is the UT seconds-of-day (SOD) of the detection/declaration of the event.
The SOD is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689568 = 46895.68 sec-of-day =
13:01:35.68 UT.
[7-8] The "src_ra" and "src_dec" fields specify the RA,Dec location of the detected
optical transient (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "max_mag" field contains the projected maximum magnitude of the lensed star.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
then integerized).
[11] The "base_mag" field contains the baseline/quiescent magnitude of the lensed star.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
then integerized).
[12] The "base_mag_err" field contains the error in the baseline/quiescent magnitude value.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
then integerized).
[13] The "max_tjd" is the Truncated Julian Day of the maximum of the lightcurve (the cusp).
[14] The "max_sod" is the UT seconds-of-day (SOD) of the maximum of the lightcurve (the cusp).
The SOD is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec).
[15] The "max_t_err" ...
[16] The "u0" is the impact parameter [in Einstein Ring units] for the lensing compact object.
The value has been multiplied by 100 and integerized.
[17] The "u0_err" is the uncertainty on "u0".
The value has been multiplied by 100 and integerized.
[18] The "flags" field contains flag bit bits relating to the source-type identity.
Bit_Number Item_name Description
---------- --------- -----------
0-2 type_id 3 bits to indicate the source type: 0=grav_lens,1=CV,2=???
3-4 x_x_x_x spare
//5 def_not_evt 0=No or 1=Yes, it is definitely not a Lensing Event (bad label; its really a Retraction).
//6 not_astro When set, this trigger has been determined to not be anything astrophysical.
7-31 x_x_x_x spare
[19] The "misc" field contains various miscelaneous flags and fields.
The bit packing of the "misc" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 Amax_0 Flagbit is set when Amax was equal to 0.
1 Amax_1 Flagbit is set when Amax is equal to unity.
2 U0_0 Flagbit is set when u0 was equal to 0.
3 spare spare bit, not yet assigned.
4 tE Flagbit is set when tE or tEErr was 'nan'.
5 Ibase Flagbit is set when Ibase was 'nan'.
6-24 spares spare bits, not yet assigned.
//25 Update Flagbit is set when this is an updated/improved notice of a previous notice.
//26 Ampl_inc Flagbit is set when the Amplitude value has increased from the original notice.
//27 Ampl_dec Flagbit is set when the Amplitude value has decreased from the original notice.
//28 Hi-Ampl Flagbit is set when the has identified as a high-amplitude event.
//29 Planet Flagbit is set when the lightcurve fit solution now includes a planet.
29-31 spares spare bits, not yet assigned.
[20] The "ampl-n-err" has two values combined into a single 4-byte slot in the packet.
The "amplification" is the projected (based on a fit to the lightcurve)
of how bright the lensed star will get (ie the ratio of the maximum flux over
the baseline flux). It is multiplied by 100, integerized, and packed into the
two most-significant bytes in the 4-byte slot. The lower two bytes
contain the uncertainty in the applification factor. It is also multiplied
by 100, integerized, and packed into the 2 least-significant bytes.
[21] The "tE_width" is the "Einstein crossing time"
The value is multiplied by 100, and converted to a 32-bit integer for the packet.
[22] The "tE_err" is the uncertainty in the "tE_width".
The value is multiplied by 100, and converted to a 32-bit integer for the packet.
[25] The "LeadTime" is the difference between the "max_tjd+sod" and the "det_tjd+sod".
It is provided here as a convenience so that the calculation with the above
four quantities need not be repeated by the recipient ('max' minus 'det').
Positive values indicate that the maximum has not occurred yet; negative values
indicate the maximum has already passed (according to the fit of the lightcurve
at the time of issuance of the MOA Event Message).
The value is multiplied by 100, and converted to a 32-bit integer for the packet.
As such, the quantization is 0.01 days (ie 14.4 minutes).
[30] The "lc_url" is just the filename portion of the URL -- the leading path
for the full URL is "https://it019909.massey.ac.nz/moa/alert/display.php?id="
The full URL points to a MOA webpage containing the initial and on-going information
about this lensing event (lightcurves, finding chart, reference stars, and data files).
This item in the packet spans 9 longwords (ie 36 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 35 characters long, and will always be null-terminated.
There are a total of 21(tbr) "spare" items in the packet (usually filled
with zeros). They are located at items (tbr)17 and 21-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long in
the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of GCN operation
(called BACODINE in those days). It has since become a permanent fixture
as many sites are now operating, and it is not wise to play
with format/content changes. And it still does function as a fixed-content
termination value for processing/transmission checking.
================================================================================
TYPE=140 and 141 PACKET CONTENTS:
The SWIFT_BAT_SUB_SUB_THRESH_POS & SWIFT_BAT_KNOWN_SRC_POS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=140/141)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer Some reference number
long 5 evt_tjd [days] Truncated Julian Day
long 6 evt_sod [centi-sec] (int)(sssss.sss *100)
long 7 evt_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 evt_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 evt_inten [counts] Num events during trig window, 0 to inf
long 10 spare integer 4 bytes for the future
long 11 evt_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 phi [centi-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [centi-deg] (int)(0.0 to +70.0 *100)
long 14 int_time [milli-sec] (int)(integration_time *100)
long 15-17 spare[4] integers 16 bytes for the future
long 18 soln_status bits Type of source/trigger found
long 19 misc bits Misc stuff packed in here
long 20 image_signif [centi-sigma] (int)(sig2noise *100)
long 21-24 spare[4] integer 16 bytes for the future
long 25 cat_num integer On-board cat match ID number (only 141)
long 26 apid integer The APID this came from
long 27-38 spare[12] integer 48 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 140 or 141, which tells that this packet
is of type SWIFT_BAT_SUB_SUB_THRESH_POS or SWIFT_BAT_KNOWN_SRC_POS and
therefore indicates the contents and format for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the evt_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "ref_num" is a uniquely identifying reference number for each trigger.
It is the number of seconds since 01 Jan 2001 (when the notice was created).
[5] The "evt_tjd" is the Truncated Julian Day of the Swift-BAT burst trigger,
eg. TJD=13370 is 01 Jan 2005.
[6] The "evt_sod" is the UT seconds-of-day (SOD) of the Swift-BAT burst trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by +/- 320 msec
for events that have a trigger integration duration less than 64 msec.
This has to do with the way that the flight software is optimized
for execution speed for evaluating trigger criteria.
There is an additional +/- 20 msec of uncertainty in applying the UT Correction Factor.
Note that both of these uncertainties can be reduced by off-line/ground processing,
but for these automated notices, these large uncertainties exist.
This is important if you are using these SubSub triggers for temporal
correlations with other data sets.
[7-8] The "evt_ra" and "evt_dec" are the RA,Dec coordinates of the burst (or transient)
as determined by the BAT flight software (J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
[9] The "evt_inten" is the height of the peak in the sky-image plane (ie the result
of the FFT,MaskConvolution,InvFFT calculation). The units are counts
after a multiplicative factor of about 0.5-0.7.
[11] The "evt_error" is the radius of the circle that will contain on average
TBD% of the bursts. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). [Initially, this value was hardwired
at a constant value of 4arcmin (0.067deg) radius. As the mission progressed,
this changed to 3 arcmin. Eventually, it might become intensity-dependant.]
[12-13] The "phi" and "theta" are the BAT instrument coordinates of the trigger (event)
as determined by the BAT flight software program. Phi is measured phi=0
along the +Y-axis of the s/c and increasing towards the -Z axis,
and theta is measured from the boresight of the BAT instrument (it would have
been better to call this the 'zenith' angle).
[14] The "int_time" is the intgration time of the image from which these "peaks"
were extracted. The units are seconds. This intrinsically
floating point quantity has been multiplied by 1000 and then integerized
to make an integer quantity with units of 0.001-seconds.
[18] The "soln_status" (aka trigger_id) field contains (a) flag bits on the type of solution
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 F point_src 0=No or 1=Yes, a point source was found
1-7 - spare spare for future use
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9-10 - spare spare for future use
11 G uncert_grb 0=No or 1=Yes, it is really probably not a GRBorTransient (VERY low image significance; less than 6.5 sigma)
12 - spare spare for future use
13 G near_brt_star 0=No or 1=Yes, there is a nearby bright star (this is a duplicate of the "misc" 2^13).
14-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-11 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12 Not assigned.
2^13 When this bit is a 1, it indicates that this position is near (less than 0.3deg) a bright star (mag less than 6.5).
2^14 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the position error radius
is smaller than the galaxy radius. This position is inside the (circularized) NGC galaxy (or nearly in).
2^15 When this bit is a 1, it indicates that the distance between the position and the center of the galaxy
is less than the sum of the position error radius and the galaxy radius AND that the galaxy radius
is smaller than the position error radius. This galaxy is inside the position error circle (or nearly in).
2^16-31 Not assigned.
[20] The "image_signif" is the significance level of the peak in the FFT image plane.
This is the signal/noise (ie number of sigma) of the grb peak detection
multiplied by 100 and then integerized (ie units are centi-sigma).
[25] The "cat_num" is the catalog number in the on-board catalog for sources
that match a known source in the on-board catalog. (Typically it is a number
in the low 10,000s, 12,000s, or 15,000s.) This is true only for Type=141;
for Type=140, this field will always be 0.
[26] The "apid" is the APID that this particular sub_sub event came from;
either 0x23b or 0x129.
There are a total of 21 "spare" items in the packet (usually filled with zeros).
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=145 PACKET CONTENTS:
The COINCIDENCE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=145)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 c1_fields bits Flags, mission, type
long 5 c1_trignum [dn] Trigger Number ID
long 6 c1_tjd [integer] Truncated Julian Day
long 7 c1_sod [0.001-sec] (int)(0.0 to 86400 *1000)
long 8 c1_ra [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 9 c1_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 10 c2_fields bits Flags, mission, type
long 11 c2_trignum [dn] Trigger Number ID
long 12 c2_tjd [integer] Truncated Julian Day
long 13 c2_sod [0.001-sec] (int)(0.0 to 86400 *1000)
long 14 c2_ra [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 15 c2_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 16 c3_fields bits Flags, mission, type
long 17 c3_trignum [dn] Trigger Number ID
long 18 c3_tjd [integer] Truncated Julian Day
long 19 c3_sod [0.001-sec] (int)(0.0 to 86400 *1000)
long 20 c3_ra [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 21 c3_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 22 c4_fields bits Flags, mission, type
long 23 c4_trignum [dn] Trigger Number ID
long 24 c4_tjd [integer] Truncated Julian Day
long 25 c4_sod [0.001-sec] (int)(0.0 to 86400 *1000)
long 26 c4_ra [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 27 c4_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 28 c5_fields bits Flags, mission, type
long 29 c5_trignum [dn] Trigger Number ID
long 30 c5_tjd [integer] Truncated Julian Day
long 31 c5_sod [0.001-sec] (int)(0.0 to 86400 *1000)
long 32 c5_ra [0.0001-deg] (int)(0.0 to 360.0 *10000)
long 33 c5_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 34 c6_fields bits Flags, mission, type
long 35 c7_fields bits Flags, mission, type
long 36 total_cnt integer Count of the total number of participants
long 37 trig_id bits Flags about the triggers
long 38 misc bits Flags from ground analysis
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 145 , which tells that this packet
is of type TYPE_COINCIDENCE and
therefore indicates the contents and format for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the evt_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
The "c1_fields" entry 3 quantities: type, mission_id, and spatial/temporal coincidence flags.
The "type" field gives the Noice Type number (1-172...) of the notice that contributed
to this multi-mission/instrument coincidence.
The "mission_id" field specifics which mission (and instrument) that contributed;
the values (1-~50) are defined in the table below.
And the "Spatial" and "Temporal" flag bits indicate which coincidence type occurred
(one or both flags can be set to 1 to indicate the respective coincidence).
BitNum Item_name Description
------ --------- -----------
0-15 type The Notice type number of this event that contributed
16-23 mission_id The Mission_ID number of this event that contributed
24-29 spare spare bits, unused
30 Spatial Indicates that this contribution was a spatial match
31 Temporal Indicates that this contribution was a temporal match
The "c1_trignum" is a uniquely identifying reference number for each trigger.
It is assigned by each contributing mission/instrument.
It is the number of seconds since 01 Jan 2001 (when the notice was created).
The "c1_tjd" is the Truncated Julian Day of the contributing trigger,
eg. TJD=13370 is 01 Jan 2005.
The "c1_sod" is the UT seconds-of-day (SOD) of the trigger time of the contributor.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
The "c1_ra" and "c1_dec" fields of the event. These are only valid for
notice types that have position information. These fields are set to 0.0 and 0.0
for those notice types that do not contain event position information.
These intrinsically floating point quantities have been multiplied by 10,000
and then integerized to make an integer quantity with units of 0.0001-degrees.
The "c2_fields", "c2_trignum", "c2_tjd", "c2_sod", "c2_ra", and "c2_dec" fields are identical
to the definitions listed ifor "c1_*" above, but for the 2nd contributing mission/instrument.
Obviously, since this is a coincidence notice type, there will always have to be
at least two contributors.
The "c3_fields", "c3_trignum", "c3_tjd", "c3_sod", "c3_ra", and "c3_dec" fields are identical
to the defintions listed ifor "c1_*" above, but for the 3rd contributing mission/instrument.
These fields will be 0 if there was no 3rd contributor.
The "c4_fields", "c4_trignum", "c4_tjd", "c4_sod", "c4_ra", and "c4_dec" fields are identical
to the definitions listed ifor "c1_*" above, but for the 4th contributing mission/instrument.
These fields will be 0 if there was no 4th contributor.
The "c5_fields", "c5_trignum", "c5_tjd", "c5_sod", "c5_ra", and "c5_dec" fields are identical
to the definitions listed ifor "c1_*" above, but for the 5th contributing mission/instrument.
These fields will be 0 if there was no 5th contributor.
The "c6_fields" slot is filled if there is a 6th participant in the coincidence (else 0).
It has the same content/definition as the "c1_fields" (but for the 6th participant).
These fields will be 0 if there was no 6th contributor. For the 6th and 7th contributors
there are no "cN_trignum", "cN_tjd", "cN_sod", "cN_ra", and "cN_dec" fields
because there was not suficient space in the 60-byte packet to holds these fields.
This is acceptable because it is extremely rare that there are more than 5 participants.
The "c7_fields" slot is filled if there is a 7th participant in the coincidence (else 0).
It has the same content/definition as the "c1_fields" (but for the 7th participant).
These fields will be 0 if there was no 7th contributor.
The "total_cnt" is the total number of mission/instruments that participated
in the coincidence.
The "trigger_id" field contains (a) flag bits on the type of solution(s)
that was found in the on-board image and about whether it matches anything in the
on-board source catalog, and (b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "soln_status" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G def_not_evt 0=No or 1=Yes, it is definitely not a real Event (it is a Test event).
2-7 - spare spare for future use
8 G gnd_cat_src 0=No or 1=Yes, it is in the ground catalog
9-29 - spare spare for future use
30 G test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word; "F-v-G" is Flight-assigned vs
Ground-assigned; "Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
The "misc" field contains miscellaneous flag bits.
The defined bits are:
2^0-11 Not assigned.
2^11 When this bit is a 1, it indicates that 1 (or more) of the RA,Dec,Theta,Phi values
were out of valid range (eg RA was 361 deg).
2^12-29 Not assigned.
30 When this bit is a 1, then this Notice was ground-generated; else flight-generated.
For this Notice Type, they are always ground-generated.
31 spare.
The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
MISSION_ID DEFINTION TABLE
The Mission-Instrument IDs are:
#define MI_ID_UNDEF 0 // This Mission-Inst type is undefined
#define MI_ID_GRO_BATSE 1 // GRO-BATSE
#define MI_ID_GRO_COMPTEL 2 // GRO-COMPTEL
#define MI_ID_GRO_OSSET 3 // GRO-OSSE
#define MI_ID_GRO_EGRET 4 // GRO-EGRET
#define MI_ID_IPN 5 // IPN (for all 3 variants)
#define MI_ID_BRADFORD 6 // BRADFORD (the test pkt only)
#define MI_ID_ALEXIS 7 // ALEXIS
#define MI_ID_XTE_PCA 8 // XTE-PCA
#define MI_ID_XTE_ASM 9 // XTE-ASM
#define MI_ID_SAX_WFC 10 // SAX-WFC
#define MI_ID_SAX_NFI 11 // SAX-NFI
#define MI_ID_HETE 12 // HETE (both WXM and SXC)
#define MI_ID_CNTRPART 13 // Counterpart (can be any gnd-gen)
#define MI_ID_INTEGRAL 14 // INTEGRAL (99% IBIS, 1% SPI)
#define MI_ID_INTEGRAL_SPIACS 15 // INTEGRAL_SPIACS
#define MI_ID_AAVSO 16 // AAVSO
#define MI_ID_MILAGRO 17 // MILAGRO
#define MI_ID_KONUS 18 // KONUS
#define MI_ID_SWIFT_BAT 19 // SWIFT-BAT (includes FOM and SC_SLEW)
#define MI_ID_SWIFT_XRT 20 // SWIFT-XRT
#define MI_ID_SWIFT_UVOT 21 // SWIFT-UVOT
#define MI_ID_AGILE 22 // AGILE
#define MI_ID_GLAST_GBM 23 // Fermi-GBM
#define MI_ID_GLAST_LAT 24 // Fermi-LAT
#define MI_ID_OGLE 25 // OGLE
#define MI_ID_PIOTS 26 // PIOTS
#define MI_ID_KAIT 27 // KAIT
#define MI_ID_MAXI 28 // MAXI
#define MI_ID_NEAR 29 // NEAR
#define MI_ID_CBAT 30 // CBAT
#define MI_ID_MOA 31 // MOA
#define MI_ID_LVC 32 // LVC = LIGO+Virgo Consortium
#define MI_ID_CRTS 33 // CRTS
#define MI_ID_SUZAKU 34 // Suzaku
#define MI_ID_SNEWS 35 // SNEWS
#define MI_ID_AMON_ICECUBE_HESE 36 // AMON IceCube HESE
#define MI_ID_CALET 37 // CALET_GBM
#define MI_ID_AMON_ICECUBE_EHE 38 // AMON IceCube EHE
#define MI_ID_GWHEN 39 // GW_HEN Coincidence
#define MI_ID_AMON_ICECUBE_COINC 40 // AMON IceCube COINC
#define MI_ID_POLAR 41 // POLAR
#define MI_ID_AMON_ICECUBE_CLUSTER 42 // AMON IceCube CLUSTER
#define MI_ID_AMON_ANTARES_FERMILAT_COINC 43 // AMON ANTARES Fermi-LAT coincidence [Terminated by AMON 08sep19]
#define MI_ID_HAWC_BURST_MONITOR 44 // HAWC Burst Monitor
#define MI_ID_AMON_NU_EM_COINC 45 // Neutrino-EM coincidences
#define MI_ID_ICECUBE_G_B 46 // ICECUBE Gold & Bronze events
================================================================================
TYPE=148 PACKET CONTENTS:
The SUZAKU_LIGHTCURVE packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=148)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 spare integer 4 bytes for the future
long 5 trigger_tjd [days] Truncated Julian Day
long 6 trigger_sod [centi-sec] (int)(sssss.sss *100)
long 7-17 spare[11] integer 44 bytes for the future
long 18 trigger_id bits Trigger identification flags
long 19-21 spare[3] integer 12 bytes for the future
quad_char 22-38 url[17] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 148, which tells that this packet
is of type SUZAKU_LC and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[There is no "trig_num" for SUZAKU_LC at the time the notice is sent to GCN for distribution.]
[5] The "trigger_tjd" is the Truncated Julian Day of the trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "trigger_sod" is the UT seconds-of-day (SOD) of the trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized).
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of event that triggered the KONUS instrument.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 times_only 0=No or 1=Yes, this packet contains only the times (trig,window,duration; no ra,dec,err) (from IPN_RAW copy)
1-8 x_x_x_x spare
9 trig_time_only 0=No or 1=Yes, this packet contains only the trigger_time (no t_window, t_duration)) (from IPN_RAW copy)
10-14 x_x_x_x spare
//15 def_not_grb 0=No or 1=Yes, it is definitely not a GRB
16-19 x_x_x_x spare
20 det_BST01 0=No or 1=Yes, this was triggered from the BST01 detector
21 det_BST02 0=No or 1=Yes, this was triggered from the BST02 detector
22 transient 0=No or 1=Yes, this was triggered from the (ground) processing transient detection s/w
//29 temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 x_x_x_x spare
[22] The "url" is just the filename portion of the URL -- the leading path
for the full URL is "http://gcn.gsfc.nasa.gov/gcn/notices_suz".
This item in the packet spans 17 longwords (ie 68 bytes) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 67 characters long, and will always be null-terminated.
There are a total of 15 "spare" items in the packet (usually filled
with zeros). They are located at items 7-17 and 19-21.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=149 PACKET CONTENTS:
The SNEWS packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=149)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 event_flue [counts] Number of neutrinos (0 to infinity)
long 10 spare integer 4 bytes for the future
long 11 event_error [0.0001-deg] (int)(0.0 to 180.0 *10000)
long 12 containment [centi-%] (int)(0.00 to 100.00 *100)
long 13 duration [centi-sec] (int)(0.0 to inf *100)
long 14-17 spare[4] integer 16 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 149, which tells that this packet
is of type SNEWS and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the event_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is the uniquely identifying serial number
assigned by the SNEWS software to each trigger.
[5] The "event_tjd" is the Truncated Julian Day of the trigger,
eg. TJD=12640 is 01 Jan 2003.
[6] The "event_sod" is the UT seconds-of-day (SOD) of the trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). This is the beginning of of the 'duration' search window
of the successful trigger.
[7-8] The "event_ra" and "event_dec" are the RA,Dec coordinates (J2000 epoch) of the trigger/event
as determined by the detector in the coincidence with the best directional information.
These intrinsically floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 0.0001-degrees.
These two fields are undefined for any trigger that dow not have Super-K as a contributor.
[9] The "event_fluence" is actually the integrated fluence of the event
over the duration of the trigger. The units are counts (ie number of neutrinos).
If this is an 'individual' notice sub-type, then it is the number of neutrinos
detected in that detector. If it is a 'coincidence' sub-type, then it is
the number neutrinos detected by the first detector contributing to the coincidence.
More detailed information will be provided at snews.bnl.gov.
[11] The "event_error" is the radius of the circle that will contain on average
containment_percentage of the event locations. The units are 0.0001-deg (ie the error was multiplied
by 10000 and then integerized).
[12] The "event_cont" is the containment percentage for the quoted event_error value.
It is stored in the packet in centi-percentage (e.g. 98.5% would be an integer value of 9850).
[13] The "duration" is the time interval of the search window of the event_times stream
looking for an increase. The units are seconds, quantized at the 0.1 sec level.
For the "coincidence" sub-type, this will always be 10.0 sec;<
and for the "individual" sub-type, it will be variable and will typically be the delta_time
between the first neutrino detected in that detector and the last detected;
each detector may have a different definition.
[18] The "trigger_id" field contains bit_flags which attempt to identify
the type of transient event that triggered the SNEWS system.
The bit packing of the "trigger_id" entry in the packet is:
Bit_Number Item_name Description
---------- --------- -----------
0 Subtype Notice sub-type: 0=Individual, 1=Coincidence
1 Test Notice: 0=Real, 1=Test
2 Radec_undef RA,Dec knowledge: 0=defined, 1=Undefined (no position known)
3-4 spare spare for future use
5 Retract 0=No or 1=Yes, it is definitely not a core-collapse supernova (a Retraction)
6-29 spare spare for future use
30 Test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 spare spare for future use
[19] The "misc" field contains various bit_flags (ie which detectors contributed to the coincidence and.
if it was a 'possible' or 'good' contribution).
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 Super-K_part Super-K contribution flag (aka 'participated')
1 Super-K_good Quality_factor is 'possible'
2 Super-K_poss Quality_factor is 'good'
3 Super-K_oride Quality_factor is 'override'
4 LVD_part LVD contribution flag
5 LVD_good Quality_factor is 'possible'
6 LVD_poss Quality_factor is 'good'
7 LVD_oride Quality_factor is 'override'
8 IceCube_part IceCube contribution flag
9 IceCube_good Quality_factor is 'possible'
10 IceCube_poss Quality_factor is 'good'
11 IceCube_oride Quality_factor is 'override'
12 KamLAND_part KamLAND contribution flag
13 KamLAND_good Quality_factor is 'possible'
14 KamLAND_poss Quality_factor is 'good'
15 KamLAND_oride Quality_factor is 'override'
16 Borexino_part Borexino instrument contribution flag
17 Borexino_good Quality_factor is 'possible'
18 Borexino_poss Quality_factor is 'good'
19 Borexino_oride Quality_factor is 'override'
20 Daya_Bay_part Daya Bay instrument contribution flag
21 Daya_Bay_good Quality_factor is 'possible'
22 Daya_Bay_poss Quality_factor is 'good'
23 Daya_Bay_oride Quality_factor is 'override'
24 HALO_part HALO instrument contribution flag
25 HALO_good Quality_factor is 'possible'
26 HALO_poss Quality_factor is 'good'
27 HALO_oride Quality_factor is 'override'
28 TBD_part TBD instrument contribution flag
29 TBD_good Quality_factor is 'possible'
30 TBD_poss Quality_factor is 'good'
31 TBD_oride Quality_factor is 'override'
The 4 bits:
a) The 'contribution' flag means that that detector contributed to the notice.
b) The 'possible' flag means the trigger observed by that detector was possibly real.
c) The 'good' flag means the trigger within that detector was very likely real.
d) The 'override' flag means the trigger observed by that detector human-checked and is real with extremely high confiden.
There are a total of 24 "spare" items in the packet (usually filled
with zeros). They are located at items 10, 14-17, and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=150-153 PACKET CONTENTS:
NOTE(08dec18-14mar19) CONTENT/FORMAT CHANGES:
LIGO-Virgo have made some changes (from their O1/O2 science operations intervals
to ER14/O3 science operation interval) to the content of their alert messages,
and as such those changes have been propagated into the various GCN distribution formats.
It is mostly due to the adding of the prefix letter, the suffix letters,
the 5 probabilities, and the url in the Preliminary type.
The LVC Preliminary(150), Initial(151), Update(152), and Test(153) [Test(153) Discontinued by LVC]
packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=150-152)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 id_num integer Identification num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7-8 spare[2] integer 8 bytes for the future
long 9 fluence [J/m2]] (int)(log10(fluence)*10000)
long 10 peak_freq [centi-Hz] (int)(Hz*100.0)
long 11 FAR [Hz] (int)(log10(FAR)*10000)
long 12 event_type bit_fields Search/Pipeline/Group index values
long 13 trig_subsec [micro-sec] (int)(0 to 999999)
long 14 duration [centi-sec] (int)(0 to NNN.NN *100)
long 15-17 spare[3] integer 12 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 ProbNS,Rem bits (ProbNS*100)*2^16)+(ProbRemnant*100)
long 21 MassGap/Let bits (MassGap*100)*2^24)+(2nd_opt_suffixLetter)
long 22 ClassProb 4 bytes Prob BNS,NSBH,BBH,Terrestrial (*100 each)
long 23 ProbInvalFlags bits Flags indicating which probabilities are invalid
long 24-28 spare[5] integer 20 bytes for the future
quad_char 29-38 url[10] chars The URL for the skymap (?for a retraction?)
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (for 150-152):
[0] The "pkt_type" is an integer with a value of 150-152 for the Preliminary,
Initial, and Update. (The Retraction(type=164) and Counterpart(type=154) types will be described later.)
It tells which type of packet this is and therefore what the contents are
(the contents change somewhat between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "id_num" is a (semi-)uniquely identifying number for each trigger.
It is the YYMMDD portion of the ID_string (SYYMMDDa[b] (where "S" is "S" for real events,
and "MS" for MockSuperevents).
[5] The "trig_tjd" is the Truncated Julian Day of the LVC event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the LVC event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
LVC has higher precission for the actual trigger SOD, but this field is kept
for LVC to be uniform with all the other GCN Notice types. See slot 13
for the full 6 digits of precision (ie micro-sec) for the LVC Trigger SOD.
Slots 7 and 8 normally contain the RA,Dec of an event in nearly all the notice types,
but for LVC Notices the localization is large and so these slots are filled with zero's.
(Location of an LVC event is specified by the probability map pointed to by the
URL string in slots 29-28.)
[9] The "fluence" is the estimated fluence of the GW burst signal. The units are [J/m2].
It is defined (ie filled) only for the 'burst' class of trigger events.
The quantity stored in slot 9 is the log10() of the fleunce value from LVC
multiplied by 10,000 and then integerized. To retrieve the fluence value at the
receiving end, call fluence=pow(10.0,slot[9]/10000.0) [this is in C-code].
[10] The "peak_freq" is peak frequency of the GW burst signal. The units are [Hz].
It is defined (ie filled) only for the 'burst' class of trigger events;
else the value is -100 to indicate it has not been filled..
[11] The "FAR" is the false alarm rate. The units are [Hz].
The quantity stored in slot 11 is the log10() of the FAR value from LVC
multiplied by 10,000 and then integerized. To retrieve the FAR value at the
receiving end, call FAR=pow(10.0,slot[11]/10000.0) [this is in C-code].
[12] The "event_type" is a combination of the group-type, search-method and pipeline used.
The pipeline is packed in the bottom 8 bits (2^0 - 2^7), and the search-method is
packed into the next higher 8 bits (2^8 - 2^15), and group-type is packed
in the next higher 8 bits (2^16 - 2^23).
Pipeline:
0 undefined/illegal
1 MTBAOnline
2 CWB
3 CWB2G
4 GSTLAL
5 GSTLAL_Spiir
6 Hardware Injection
7 X
8 Q
9 Omega
10 Ringdown
11 LIB
12 Fermi
13 Swift
14 SNEWS
15 pycbc
Search:
0 undefined/illegal
1 AllSky
2 LowMass
3 HighMass
4 GRB
5 Supernova
6 MockDataChallenge
7 AllSkyLong
8 BBH
Group:
0 undefined/illegal
1 CBC
2 Burst
5 Test
[13] The "trig_sod_usec" is the sub-seconds portion of the Trigger_SOD.
The units are [microsec].
[14] The "duration" is duration of the GW burst signal. The units are [sec].
It is defined (ie filled) only for the 'burst' class of trigger events;
else the value is -100 to indicate it has not been filled.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the LVC pipeline processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G internal_flag LCV_Team_internal distribution(=1), Full (Priv Phase) LV-EM-Forum_sign-up distribution(=0)
1 G test_flag Test-type: 0=Real, 1=Test
2 G hardware_inj Is this a hardware injection event: 0=no, 1=yes
3 G vetted Has this event been vetted by a human: 0=no, 1=yes
4 G open_alert Is this event an open alert: 0=no, 1=yes
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 spare spare for furture use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description/definition of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 LHO LIGO-Handford Obs contribution flag (aka 'participated')
1 LLO LIGO-Livingston Obs contribution flag (aka 'participated')
2 Virgo Virgo Obs contribution flag (aka 'participated')
3 GEO600 GEO600 Obs contribution flag (aka 'participated')
4 KAGRA KAGRA Obs contribution flag (aka 'participated')
5 LIO LIGO-India Obs contribution flag (aka 'participated')
6 spare_inst1 TBD1 Obs contribution flag (aka 'participated')
7 spare_inst2 TBD2 Obs contribution flag (aka 'participated')
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-17 alpha_letter The first letter suffix ('a' in SYYMMDDa)
18 spare Spare bit within 'misc'.
19 Gnd_gen When this bit is a 1, then this Notice was ground-generated; else flight-generated.
Always 1 for Test Notices.
20-23 Letter The Letter prefix on the ID_number: 1="G", 2="T", 3="M", 4="Y", 5="H", 6="E", 7="K", 8="S" 9="GW", 10="TS", 11="TGW", 12="MS", 13="MGW".
24-31 serial LVC-generated serial number for message sequence in this trig_num.
[20] The "ProbNS" field contains the probability that at least one object in the event
has a mass less than 3 solar masses. It is located in the upper 16 bits of the 32-bit quantity.
The "ProbRemnant" is in the lower 16 bits has the probability that there is matter in the surrounding central object.
Both quantities are in units of centi-percent (ie they have been multiplied by 100 and integerized).
It is present on only Initial and Update notice types (but not the Preliminary notice type).
Here is a snipet of C-code to show the proper extraction of the two probabilities in slot 20:
if((lbuf[23] & BIT05) == 0)
Prob_NS = ((lbuf[20]>>16) & 0xFFFF)/100.0;
//else
// Prob_NS VALUE NOT ASSIGNED!;
if((lbuf[23] & BIT06) == 0)
Prob_Remnant = (lbuf[20] & 0xFFFF)/100.0;
//else
// Prob_Remnant VALUE NOT ASSIGNED!;
[21] The 2nd suffix letter (SYYMMDDab) in the IDname for the event (in bits 0-7).
The "Prob Mass Gap" value is the probability that one of the sources falls in the 3.0-5.0 Msolar range.
This is the 5th probability -- the other 4 are in slot 22).
The MassGap probability (on a scale of 0.0 to 1.0) is multiplied by 100 and then integerized
down to a single byte each (value 0 to 100). This byte is packed in the top 8 bits of slot 21.
The bit/byte packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 alpha2_letter 2nd suffix letter in IDname for the event ('b' in SYYMMDDab)
8-15 spare Spare 8 bits
16-23 spare Spare 8 bits
24-31 MassGap Probability that one of the masses is in the 3.0-5.0 Msolar band
if((lbuf[23] & BIT03) == 0)
PROB_MassGap = ((lbuf[21]>>24) & 0xFF)/100.0;
//else
// PROB_MassGap VALUE NOT ASSIGNED!;
[22] The "Prob BNS,NSBH,BBH,Terrestrial" values are the probabilities of the given event/trigger
being due to: Binary Neutron Star system (BNS), Neutron Star - Black Hole system (NSBH),
Binary Black Hole system (BBH), and Terrestrial (not due to anything astrophysical). [The 5th
probability of this quintet (MassGap) is stored in slot 21 -- see above.]
The 4 probabilities (on a scale of 0.0 to 1.0) are each multiplied by 100 and then integerized
down to a single byte each (value 0 to 100). The 4 bytes are packeted together into a single
4-byte quantity with the BNS being the most significant byte, then NSBH, then BBH, and
Terrestrial being the least significant byte.
The bit/byte packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 Terrestrial Probability that this event/trigger is non-astrophysical
8-15 BBH Probability that it is due to Binary Back Hole system,
16-23 NSBH Probability that it is due to Neutron Star - Back Hole system,
24-31 BNS Probability that it is due to Binary Neutron Star system.
if((lbuf[23] & BIT00) == 0)
Prob_BNS = ((lbuf[22]>>24) & 0xFF)/100.0;
//else
// Prob_BNS VALUE NOT ASSIGNED!;
if((lbuf[23] & BIT01) == 0)
Prob_NSBH = ((lbuf[22]>>16) & 0xFF)/100.0;
//else
// Prob_NSBH VALUE NOT ASSIGNED!\n");
if((lbuf[23] & BIT02) == 0)
Prob_BBH = ((lbuf[22]>>8) & 0xFF)/100.0;
//else
// Prob_BBH VALUE NOT ASSIGNED!\n");
if((lbuf[23] & BIT04) == 0)
PROB_TERRES = ((lbuf[22] ) & 0xFF)/100.0;
//else
// PROB_TERRES VALUE NOT ASSIGNED!;
[23] The "prob_invalid_flags" field contains bit_flags indicating which of the 7 probabilities
are invalid (ie were not included in the riginal message from LIGO-Virgo).
The bit packing is:
Bit_Number Item_name Description
---------- -------------- -----------
0 ProbNS_invalid Is the value invalid (1=Yes (do not use), 0=No)
1 ProbRem_invalid Is the value invalid (1=Yes (do not use), 0=No)
2 ProbBNS_invalid Is the value invalid (1=Yes (do not use), 0=No)
3 ProbNSBH_invalid Is the value invalid (1=Yes (do not use), 0=No)
4 ProbBBH_invalid Is the value invalid (1=Yes (do not use), 0=No)
5 ProbMassGap_invalid Is the value invalid (1=Yes (do not use), 0=No)
6 ProbTerr_invalid Is the value invalid (1=Yes (do not use), 0=No)
[29] URL for the skymap:
The "url_c0-3" is the start of slot 29 for Types Preliminary/Initial/Update.
It is present in all 3 packet types Preliminary, Initial, and Update notices.
It is not defined for the Retraction Notice and Counterpart Notice types.
It is a string that looks like: S190419a/files/bayestar.fits.gz
(Sometimes the suffix can be 2 letters (ie "aa" instead of "a").
It needs to be combined with: https://gracedb.ligo.org/superevents/
to make the full url string: https://gracedb.ligo.org/api/superevents/S190814bv/files/bayestar.fits.gz
There are a total of 11 "spare" items in the packet (usually filled with zeros).
They are located at items 7-8, 15-17, and 24-28.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=154 PACKET CONTENTS:
The LVC_COUNTERPART packet contains detections of the burst counterpart
in both the optical, radio, and other (x-ray, TeV, neutrinos, etc ...) bandpasses.
However, to make the field_names shorter, they were given names
with an optical bias. Only the name has this bias, the contents
cover the optical, the radio, the x-ray, particles, etc.
The LVC_COUNTERPART packet consists of 40 four-byte quantities.
The order and contents are listed in the table below:
This is intensionally identical to the Type=45 GRB_COUNTERPART packet.
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=154)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 ref_num integer Some reference number (eg trig_num)
long 5 burst_tjd [days] Truncated Julian Day
long 6 burst_sod [centi-sec] (int)(sssss.sss *100)
long 7 cp_ra [10^-4-deg] (int)(0.0 to 359.9999 *10000)
long 8 cp_dec [10^-4-deg] (int)(-90.0 to +90.0 *10000)
long 9 cp_inten [centi-mag] (int)(mm.mm *100)
long 10 inten_err [centi-mag] (int)(mm.mm *100)
long 11 cp_error [10^-4-deg] (int)(0.0 to 180.0 *10000)
long 12 filter integer Opt_fltr, Radio_freq, Oth_??
long 13 seeing [centi-arcsec] (int)(ss.ss *100)
long 14 obs_tjd [days] Truncated Julian Day
long 15 obs_time [centi-sec] (int)(sssss.sss *100)
long 16 obs_dur [centi-sec] (int)(sssss.sss *100)
long 17 id_conf [centi-%] (int)(0.0 to 100.00 *100)
long 18 flags bits Flag bits on source-type & ID suffix letters
long 19 misc bits Misc flag bits and fields
quad_char 20-23 telescope[4] chars The name of the telescope
quad_char 24-38 name[15] chars The name of the submittor
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (type=154):
[0] The "pkt_type" is an integer with a value of 154, which tells that this packet
is of type LVC_COUNTERPART and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start from 1 when
the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 1.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the burst_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "ref_num" is a reference number for that burst. Typically it is a trigger_number
of the burst for that mission that made the original detection of the burst.
[5] The "burst_tjd" is the Truncated Julian Day of the burst,
eg. TJD=12275 is 01 Jan 2002.
[6] The "burst_sod" is the UT seconds-of-day (SOD) of the burst. The SOD
is multiplied by 100, and converted to a 32-bit integer for the packet
(i.e the units are centi-sec; 10 msec), eg. 4689568 = 46895.68 sec-of-day =
13:01:35.68 UT.
[7-8] The "cp_ra" and "cp_dec" fields specify the RA,Dec location of the detected
GRB counterpart (in J2000 epoch). These intrinsically floating point
quantities have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "cp_inten" field contains the magnitude of the detected optical transient.
The units are centi-magnitudes (ie the magnitude was multiplied by 100 and
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=abc, 3=def, ...
The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
Revisions can happen when (a) one of the original detectors updates their
information (eg change in the number of neutrinos in their event), or
(b) a 3rd detector now has a coincidence with the original two detectors
(ie some detectors have longer data analysis times).
The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 IceCube They constributed to the AMON coincidence event
1 ANTARES They constributed to the AMON coincidence event
2-7 spare Spare bits within 'misc'.
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-31 spare Spare bits within 'misc'.
The "pvalue" field contains the probability value that the trigger is real
(ie astrophysical, and not a chance coincidence).
This alert p-value is calculated by combining p-values of each individual neutrino
contributing to a given alert. Observatories should send AMON the p-values for their events.
These event p-values measure some event quality from each observatory
(e.g., for IceCube subthrehsold stream event p-value is a probability of an event
being atmospheric neutrino of energy larger or equal than energy observed P(E>=E_observed)).
In case that some observatory does not send AMON their event p-value,
we can only report false alarm rate, but not valid combined p-value
associated with the corresponding alert.
The range of valuesi 0.0 to 1.0.
The quantity stored in slot 20 is the log10() of the Prob_value value from AMON
multiplied by 10,000 and then integerized. To retrieve the Prob_value value at the
receiving end, call pvalue=pow(10.0,slot[20]/10000.0).
The "substream" field contains the index number identifying to which instrument
should receive it during the proprietary phase. It ranges from 1 - NN.
The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
The "sub_sec" field contains the subseconds portion of the trigger_sod.
It contains the fractional-seconds portion to 6 significant digits;
0.123456*1e6 and then integerized.
There are a total of 17 "spare" items in the packet (usually filled
with zeros). They are located at items 21-88.
The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=158 PACKET CONTENTS:
NOTE: Type=158 packets (AMON_ICECUBE_HESE) are NO LONGER AVAILABLE.
They have been replaced by the 173/174 packets.
The AMON_ICECUBE_HESE Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 158
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=158)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_events [evts] Events [counts] (always 1)
long 10 false_pos [s^-1 sr^-1] (int)(log10(far)*10000)
long 11 evt_error90 [0.0001-deg] (int)(0.0 to 180.0 *10000) 90% Conf
long 12 spare integer 4 bytes for the future
long 13 deltaT [centi-sec] (int)(0.0 to 0.999999 *100)
long 14 sigmaT [centi?-sec] (int)(0 to NNN.NN *100)
long 15 spare integer 4 bytes for the future
long 16 stream integer Which instrument/data source
long 17 rev [dn] 0-N (revision/update serial number)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 pvalue [dn] (int)(log10(pvalue)*10000)
long 21 charge [centi-pe] (int)(0.0 to NNNN.N *100
long 22 signal_track [0.01-1.0] (int)(0.0 to NNNN.N *100 ???
long 23 run_num [dn] Run number in which the Event was found
long 24 evt_error50 [0.0001-deg] (int)(0.0 to 180.0 *10000) 50% Conf
long 25 sub_sec [micro-sec] (int)(0.sssssss *1e6)
long 26-38 spare[12] integer 52 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 158, which tells that this packet
is of type AMON_ICECUBE_HESE and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_num" is a uniquely identifying number for each event/trigger.
(See also 'run_num' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "n_events" field contains the number of events (ie neutrinos)
that occurred during the deltaT window. For ICECUBE_HESE type,
this number will always be 1 (ie one PeV neutrino). (Alway one, but this field
is still included in the HESE type to be symetric with the EHE and COINC types.)
[10] The "false_pos" (flase positive rate) field specifies how often a trigger of this intensity
would happen from just noise fluctuations (an identically 0 value means it was not calculated).
The units are number per steradian per second.
The range of valuesi 0.0 to 1.0.
The quantity stored in slot 10 is the log10() of the False_pos value from AMON
multiplied by 10,000 and then integerized. To retrieve the False_pos value at the
receiving end, call false_pos=pow(10.0,slot[10]/10000.0).
[11] The "event_error90" is the radius of the circle that will contain on average
90% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
[13] The "deltaT" field contains the Time window of the burst.
The units are centi-sec (ie the deltaT was multiplied by 100 and
then integerized).
This will always be identically 0 for HESE notice type.
[14] The "sigmaT" field contains the Uncertainty of the time window.
The units are centi-sec (ie the sigmaT was multiplied by 100 and
then integerized).
This will always be identically 0 for HESE notice type.
[16] The "stream" field contains the index number identifying
which analysis stream produced this trigger. It ranges from 1 - NN.
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=abc, 3=def, ...
[17] The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
For AMON_ICECUBE_HESE type notices, the changes are most likely due to the RA,Dec,Error
values changing.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G role=test Received with role="test"
2-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-23 spare Spare bits within 'misc'.
24-31 sernum 8 bits containing the type of the HESE serial number(???)
[20] P-value is a chance probability of alert being an atmospheric neutrino.
Low p-value (p less than 0.0027 (3 sigma) indicates a given alert is less likely to be background.
The range is from 0 to 1 (an identically 0 value means it was not calculated).
The quantity stored in slot 20 is the log10() of the Prob_value value from AMON
multiplied by 10,000 and then integerized. To retrieve the Prob_value value at the
receiving end, call pvalue=pow(10.0,slot[20]/10000.0).
[21] The "charge" field contains the total neutrino event charge (in units of photo-electrons).
The units are centi-pe (ie the pe-count was multiplied by 100.0 and
then integerized).
[Note that this is not the same packing method as 'charge' in the AMON_ICECUBE_EHE packet.]
[22] The "signal_trackness" field contains the probability that the neutrino event was signal and track-like.
The range is 0.0 to 1.0.
The units are centi-probability (ie the magnitude was multiplied by 100.0 and
then integerized).
[23] The 'run_num' is the 2nd of two parts ('event_num' is first part, see above)
that uniquely identifies this event.
[24] The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
[25] The "sub_sec" field contains the subseconds portion of the trigger_sod.
It contains the fractional-seconds portion to 6 significant digits;
0.123456*1e6 and then integerized.
There are a total of TBD "spare" items in the packet (usually filled
with zeros). They are located at items TBD-TBD.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=159 PACKET CONTENTS:
The AMON_ICECUBE_TEST Event packets consist of 40 four-byte quantities.
The exact same contents as type 158, except that slot[0] is filled with a value of 159.
================================================================================
TYPE=160 PACKET CONTENTS:
The CALET_GBM_FLT_LC Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 160
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=160)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 id_num integer Trigger num
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 lc_signif [centi-sigma] (int)(0.0 to inf *100)
long 10 fore_dur [centi-sec] (int)(log10(far)*100)
long 11 bkg_dur1 [centi-sec] (int)(0.0 to 180.0 *100)
long 12 bkg_dur2 [centi-sec] Always 0 for FLT_LC
long 13-15 spare[3] integer 12 bytes for the future
long 16 lon_lat two_shorts (int)(Latitude *100); ditto Lon
long 17 lo_e_hi_e two_shorts (int)(Lo_energy *100); ditto Hi_energy
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-28 spare[9] integer 36 bytes for the future
quad_char 29-38 url[10] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 160, which tells that this packet
is of type CALET_GBM_FLT_LC and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the on-board MET clock value at the time of the trigger.
The URL for retrieving the lightcurve can be generated by inserting trig_num into:
http://cgbm.calet.jp/cgbm_trigger/flight/%d/index.html
[5] The "trig_tjd" is the Truncated Julian Day of the CALET-GBM trigger,
eg. TJD=17023 is 01 Jan 2015.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the CALET-GBM trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
(CALET has higher precission for the actual trigger SOD(tbd), but this field is kept
at centi-sec for CALET to be uniform with all the other GCN Notice types.)
[7-8] The "point_ra" and "point_dec" fields specify the RA,Dec pointing direction
of the boresight of the spacecraft (in J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 10^-4-degrees.
[9] The "lc_signif" signal-to-noise ratio (in units of centi-sigma) during the foreground interval
over the background interval(s). The intrinsically floating point quantity
has been multiplied by 100 and then integerized.
[10] The "fore_dur" the amount of time (in units of centi-sec) the defines the triggering interval.
There are only 4 foreground/triggering intervals 0.25s, 0.5s, 1s and 4s defined
in the on-board triggering logic. This intrinsically floating point quantity
has been multiplied by 100 and then integerized.
[11] The "bkg_dur1" is the amount of time (units centi-sec) used to determine the background countrate
when used for the lc_significance. For the (on-board) Flight triggers, there is only
one background interval used, and it occurs before the foreground interval
(with a separation of X.X sec between the end of the background interval and
the beginning of the foreground interval). This intrinsically floating point quantity
has been multiplied by 100 and then integerized.
[12] The "bkg_dur2" is the amount of time (units sec) used to determine the background countrate
when used for the lc_significance. This is NOT defined (empty) for the Flight Lightcurve notice type.
[16] The "lon_lat" is the Longitude and Latitude of the CALET s/c at the time of the CALET-GBM trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order 2-byte word
is the latitude multiplied by 100 and integerized; the low-order 2-byte word
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "lo_e_hi_e" is the Lo_energy band limit and Hi_energy band limit of the trigger criteria.
This 4-byte quantity is composed of two 2-byte integers. The high-order 2-byte word
is the hi_energy multiplied by 100 and integerized; the low-order 2-byte word
is the lo_energy multiplied by 100 and integerized; ie both values are in centi-keV.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the CALET pipeline processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 HMX1_det HMX1 detector participated in the trigger
1 HMX2_det HMX2 detector participated in the trigger
2 SGM_det SGM detector participated in the trigger
3-31 spare spare
[29] The URL for retrieving the lightcurve can be generated by appending
the string stored at starting location url_c0_3 onto:
http://cgbm.calet.jp/cgbm_trigger/flight/
You can then use wget or curl (or similar) to retrieve
the lightcurve file from the CALET science data center.
There are a total of 13 "spare" items in the packet (usually filled
with zeros). They are located at items 13-15, and 20-28.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=161 PACKET CONTENTS:
The CALET_GBM_GND_LC Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 161
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=161)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 id_num integer Trigger num
long 5 trig_tjd [days] Truncated Julian Day
long 6 trig_sod [centi-sec] (int)(sssss.sss *100)
long 7 point_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 point_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 lc_signif [centi-sigma] (int)(0.0 to inf *100)
long 10 fore_dur [centi-sec] (int)(log10(far)*100)
long 11 bkg_dur1 [centi-sec] (int)(0.0 to 180.0 *100)
long 12 bkg_dur2 [centi-sec] (int)(0.0 to 180.0 *100)
long 13-15 spare[3] integer 12 bytes for the future
long 16 lon_lat two_shorts (int)(Latitude *100); ditto Lon
long 17 lo_e_hi_e two_shorts (int)(Lo_energy *100); ditto Hi_energy
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-28 spare[9] integer 36 bytes for the future
quad_char 29-38 url[10] chars The URL for the lightcurve
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 160, which tells that this packet
is of type CALET_GBM_GND_LC and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
It is the on-board MET clock value at the time of the trigger.
The URL for retrieving the lightcurve can be generated by inserting trig_num into:
http://cgbm.calet.jp/cgbm_trigger/ground/%d/index.html
[5] The "trig_tjd" is the Truncated Julian Day of the CALET-GBM trigger,
eg. TJD=17023 is 01 Jan 2015.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the CALET-GBM trigger.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
(CALET has higher precission for the actual trigger SOD(tbd), but this field is kept
at centi-sec for CALET to be uniform with all the other GCN Notice types.)
[7-8] The "point_ra" and "point_dec" fields specify the RA,Dec pointing direction
of the boresight of the spacecraft (in J2000 epoch). These intrinsically
floating point quantities have been multiplied by 10,000 and then integerized
to make an integer quantity with units of 10^-4-degrees.
[9] The "lc_signif" signal-to-noise ratio (in units of centi-sigma) during the foreground interval
over the background interval(s). The intrinsically floating point quantity
has been multiplied by 100 and then integerized.
[10] The "fore_dur" the amount of time (in units of centi-sec) the defines the triggering interval.
There are only 4 foreground/triggering intervals 0.25s, 0.5s, 1s and 4s defined
in the on-board triggering logic. This intrinsically floating point quantity
has been multiplied by 100 and then integerized.
[11] The "bkg_dur1" is the amount of time (units centi-sec) used to determine the background countrate
when used for the lc_significance. For the (on-board) Flight triggers, there is only
one background interval used, and it occurs before the foreground interval
(with a separation of X.X sec between the end of the background interval and
the beginning of the foreground interval). This intrinsically floating point quantity
has been multiplied by 100 and then integerized.
[12] The "bkg_dur2" is the amount of time (units centi-sec) used to determine the background countrate
when used for the lc_significance. It is used only for the Ground-porcessed triggers.
It comes after the fore_dur interval. The separation between the end of the fore_dur
and the beginning of the bkg_dur2 interval is X.X sec. This intrinsically floating point quantity
has been multiplied by 100 and then integerized.
[16] The "lon_lat" is the Longitude and Latitude of the CALET s/c at the time of the CALET-GBM trigger.
This 4-byte quantity is composed of two 2-byte integers. The high-order 2-byte word
is the latitude multiplied by 100 and integerized; the low-order 2-byte word
is the longitude multiplied by 100 and integerized; ie both values are in centi-degrees.
[17] The "lo_e_hi_e" is the Lo_energy band limit and Hi_energy band limit of the trigger criteria.
This 4-byte quantity is composed of two 2-byte integers. The high-order 2-byte word
is the hi_energy multiplied by 100 and integerized; the low-order 2-byte word
is the lo_energy multiplied by 100 and integerized; ie both values are in centi-keV.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the CALET pipeline processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 HMX1_det HMX1 detector participated in the trigger
1 HMX2_det HMX2 detector participated in the trigger
2 SGM_det SGM detector participated in the trigger
3-31 spare spare
[29] The URL for retrieving the lightcurve can be generated by appending
the string stored at starting location url_c0_3 onto:
http://cgbm.calet.jp/cgbm_trigger/ground/
You can then use wget or curl (or similar) to retrieve
the lightcurve file from the CALET science data center.
There are a total of 13 "spare" items in the packet (usually filled
with zeros). They are located at items 13-15, and 20-28.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=163 PACKET CONTENTS:
The LVC Early Warning(163) packet (like the 150-153,164 packets)
consist of 40 four-byte quantities.
The order and contents are listed in the table below:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=163)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 id_num integer Identification num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7-8 spare[2] integer 8 bytes for the future
long 9 fluence [J/m2]] (int)(log10(fluence)*10000)
long 10 peak_freq [centi-Hz] (int)(Hz*100.0)
long 11 FAR [Hz] (int)(log10(FAR)*10000)
long 12 event_type bit_fields Search/Pipeline/Group index values
long 13 trig_subsec [micro-sec] (int)(0 to 999999)
long 14 duration [centi-sec] (int)(0 to NNN.NN *100)
long 15-17 spare[3] integer 12 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 ProbNS,Rem bits (ProbNS*100)*2^16)+(ProbRemnant*100)
long 21 MassGap/Let bits (MassGap*100)*2^24)+(2nd_opt_suffixLetter)
long 22 ClassProb 4 bytes Prob BNS,NSBH,BBH,Terrestrial (*100 each)
long 23 ProbInvalFlags bits Flags indicating which probabilities are invalid
long 24-28 spare[5] integer 20 bytes for the future
quad_char 29-38 url[10] chars The URL for the skymap
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (for 163):
[0] The "pkt_type" is an integer with a value of 167 for the Premerger.
(The Preliminary, Initial, Updated(150-152), Early Warning, Retraction(type=164) and
Counterpart(type=154) types are described above.)
It tells which type of packet this is and therefore what the contents are
(the contents change somewhat between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "id_num" is a (semi-)uniquely identifying number for each trigger.
It is the YYMMDD portion of the ID_string (SYYMMDDa[b] (where "S" is "S" for real events,
and "MS" for MockSuperevents).
[5] The "trig_tjd" is the Truncated Julian Day of the LVC event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the LVC event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
LVC has higher precission for the actual trigger SOD, but this field is kept
for LVC to be uniform with all the other GCN Notice types. See slot 13
for the full 6 digits of precision (ie micro-sec) for the LVC Trigger SOD.
????Slots 7 and 8 normally contain the RA,Dec of an event in nearly all the notice types,
but for LVC Notices the localization is large and so these slots are filled with zero's.
(Location of an LVC event is specified by the probability map pointed to by the
URL string in slots 29-28.)
[9] The "fluence" is the estimated fluence of the GW burst signal. The units are [J/m2].
It is defined (ie filled) only for the 'burst' class of trigger events.
The quantity stored in slot 9 is the log10() of the fleunce value from LVC
multiplied by 10,000 and then integerized. To retrieve the fluence value at the
receiving end, call fluence=pow(10.0,slot[9]/10000.0) [this is in C-code].
[10] The "peak_freq" is peak frequency of the GW burst signal. The units are [Hz].
It is defined (ie filled) only for the 'burst' class of trigger events;
else the value is -100 to indicate it has not been filled..
[11] The "FAR" is the false alarm rate. The units are [Hz].
The quantity stored in slot 11 is the log10() of the FAR value from LVC
multiplied by 10,000 and then integerized. To retrieve the FAR value at the
receiving end, call FAR=pow(10.0,slot[11]/10000.0) [this is in C-code].
[12] ????The "event_type" is a combination of the group-type, search-method and pipeline used.
The pipeline is packed in the bottom 8 bits (2^0 - 2^7), and the search-method is
packed into the next higher 8 bits (2^8 - 2^15), and group-type is packed
in the next higher 8 bits (2^16 - 2^23).
Pipeline:
0 undefined/illegal
1 MTBAOnline
2 CWB
3 CWB2G
4 GSTLAL
5 GSTLAL_Spiir
6 Hardware Injection
7 X
8 Q
9 Omega
10 Ringdown
11 LIB
12 Fermi
13 Swift
14 SNEWS
15 pycbc
Search:
0 undefined/illegal
1 AllSky
2 LowMass
3 HighMass
4 GRB
5 Supernova
6 MockDataChallenge
7 AllSkyLong
8 BBH
Group:
0 undefined/illegal
1 CBC
2 Burst
5 Test
[13] The "trig_sod_usec" is the sub-seconds portion of the Trigger_SOD.
The units are [microsec].
[14] The "duration" is duration of the GW burst signal. The units are [sec].
It is defined (ie filled) only for the 'burst' class of trigger events;
else the value is -100 to indicate it has not been filled.
[18] ????The "trig_id" field contains (a) flag bits on the type of solution
that was found by the LVC pipeline processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G internal_flag LCV_Team_internal distribution(=1), Full (Priv Phase) LV-EM-Forum_sign-up distribution(=0)
1 G test_flag Test-type: 0=Real, 1=Test
2 G hardware_inj Is this a hardware injection event: 0=no, 1=yes
3 G vetted Has this event been vetted by a human: 0=no, 1=yes
4 G open_alert Is this event an open alert: 0=no, 1=yes
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 spare spare for furture use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description/definition of the quantity.
[19] ????The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 LHO LIGO-Handford Obs contribution flag (aka 'participated')
1 LLO LIGO-Livingston Obs contribution flag (aka 'participated')
2 Virgo Virgo Obs contribution flag (aka 'participated')
3 GEO600 GEO600 Obs contribution flag (aka 'participated')
4 KAGRA KAGRA Obs contribution flag (aka 'participated')
5 LIO LIGO-India Obs contribution flag (aka 'participated')
6 spare_inst1 TBD1 Obs contribution flag (aka 'participated')
7 spare_inst2 TBD2 Obs contribution flag (aka 'participated')
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-17 alpha_letter The first letter suffix ('a' in SYYMMDDa)
18 spare Spare bit within 'misc'.
19 Gnd_gen When this bit is a 1, then this Notice was ground-generated; else flight-generated.
Always 1 for Test Notices.
20-23 Letter The Letter prefix on the ID_number: 1="G", 2="T", 3="M", 4="Y", 5="H", 6="E", 7="K", 8="S" 9="GW", 10="TS", 11="TGW", 12="MS", 13="MGW".
24-31 serial LVC-generated serial number for message sequence in this trig_num.
????[20] The "ProbNS" field contains the probability that at least one object in the event
has a mass less than 3 solar masses. It is located in the upper 16 bits of the 32-bit quantity.
The "ProbRemnant" is in the lower 16 bits has the probability that there is matter in the surrounding central object.
Both quantities are in units of centi-percent (ie they have been multiplied by 100 and integerized).
It is present on only Initial and Update notice types (but not the Preliminary notice type).
Here is a snipet of C-code to show the proper extraction of the two probabilities in slot 20:
if((lbuf[23] & BIT05) == 0)
Prob_NS = ((lbuf[20]>>16) & 0xFFFF)/100.0;
//else
// Prob_NS VALUE NOT ASSIGNED!;
if((lbuf[23] & BIT06) == 0)
Prob_Remnant = (lbuf[20] & 0xFFFF)/100.0;
//else
// Prob_Remnant VALUE NOT ASSIGNED!;
????[21] The 2nd suffix letter (SYYMMDDab) in the IDname for the event (in bits 0-7).
The "Prob Mass Gap" value is the probability that one of the sources falls in the 3.0-5.0 Msolar range.
This is the 5th probability -- the other 4 are in slot 22).
The MassGap probability (on a scale of 0.0 to 1.0) is multiplied by 100 and then integerized
down to a single byte each (value 0 to 100). This byte is packed in the top 8 bits of slot 21.
The bit/byte packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 alpha2_letter 2nd suffix letter in IDname for the event ('b' in SYYMMDDab)
8-15 spare Spare 8 bits
16-23 spare Spare 8 bits
24-31 MassGap Probability that one of the masses is in the 3.0-5.0 Msolar band
if((lbuf[23] & BIT03) == 0)
PROB_MassGap = ((lbuf[21]>>24) & 0xFF)/100.0;
//else
// PROB_MassGap VALUE NOT ASSIGNED!;
????[22] The "Prob BNS,NSBH,BBH,Terrestrial" values are the probabilities of the given event/trigger
being due to: Binary Neutron Star system (BNS), Neutron Star - Black Hole system (NSBH),
Binary Black Hole system (BBH), and Terrestrial (not due to anything astrophysical). [The 5th
probability of this quintet (MassGap) is stored in slot 21 -- see above.]
The 4 probabilities (on a scale of 0.0 to 1.0) are each multiplied by 100 and then integerized
down to a single byte each (value 0 to 100). The 4 bytes are packeted together into a single
4-byte quantity with the BNS being the most significant byte, then NSBH, then BBH, and
Terrestrial being the least significant byte.
The bit/byte packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 Terrestrial Probability that this event/trigger is non-astrophysical
8-15 BBH Probability that it is due to Binary Back Hole system,
16-23 NSBH Probability that it is due to Neutron Star - Back Hole system,
24-31 BNS Probability that it is due to Binary Neutron Star system.
if((lbuf[23] & BIT00) == 0)
Prob_BNS = ((lbuf[22]>>24) & 0xFF)/100.0;
//else
// Prob_BNS VALUE NOT ASSIGNED!;
if((lbuf[23] & BIT01) == 0)
Prob_NSBH = ((lbuf[22]>>16) & 0xFF)/100.0;
//else
// Prob_NSBH VALUE NOT ASSIGNED!\n");
if((lbuf[23] & BIT02) == 0)
Prob_BBH = ((lbuf[22]>>8) & 0xFF)/100.0;
//else
// Prob_BBH VALUE NOT ASSIGNED!\n");
if((lbuf[23] & BIT04) == 0)
PROB_TERRES = ((lbuf[22] ) & 0xFF)/100.0;
//else
// PROB_TERRES VALUE NOT ASSIGNED!;
????[23] The "prob_invalid_flags" field contains bit_flags indicating which of the 7 probabilities
are invalid (ie were not included in the riginal message from LIGO-Virgo).
The bit packing is:
Bit_Number Item_name Description
---------- -------------- -----------
0 ProbNS_invalid Is the value invalid (1=Yes (do not use), 0=No)
1 ProbRem_invalid Is the value invalid (1=Yes (do not use), 0=No)
2 ProbBNS_invalid Is the value invalid (1=Yes (do not use), 0=No)
3 ProbNSBH_invalid Is the value invalid (1=Yes (do not use), 0=No)
4 ProbBBH_invalid Is the value invalid (1=Yes (do not use), 0=No)
5 ProbMassGap_invalid Is the value invalid (1=Yes (do not use), 0=No)
6 ProbTerr_invalid Is the value invalid (1=Yes (do not use), 0=No)
URL for the skymap:
The "url_c0-3" is the start of slot 29 for Types Preliminary/Initial/Update.
It is present in all 3 packet types Preliminary, Initial, and Update notices.
It is not defined for the Retraction Notice and Counterpart Notice types.
It is a string that looks like: S190419a/files/bayestar.fits.gz
(Sometimes the suffix can be 2 letters (ie "aa" instead of "a").
It needs to be combined with: https://gracedb.ligo.org/superevents/
to make the full url string: https://gracedb.ligo.org/api/superevents/S190814bv/files/bayestar.fits.gz
There are a total of 11 "spare" items in the packet (usually filled with zeros).
They are located at items 7-8, 15-17, and 24-28.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=164 PACKET CONTENTS:
The LVC Retraction packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 164 (Retraction):
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=164)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7-12 spare[6] integer 24 bytes for the future
long 13 trig_subsec [micro-sec] (int)(0 to 999999)
long 14-17 spare[4] integer 16 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 36 bytes for the future
[maybe even for a retraction]
quad_char 29-38 url[10] chars The URL for the skymap
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (for 164):
[0] The "pkt_type" is an integer with a value of 164 for the Retraction LVC types.
It tells which type of packet this is and therefore what the contents are
(the contents change somewhat between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
[5] The "trig_tjd" is the Truncated Julian Day of the LVC event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the LVC event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
LVC has higher precission for the actual trigger SOD, but this field is kept
for LVC to be uniform with all the other GCN Notice types. See slot 13
for the full 6 digits of precision (ie micro-sec) for the LVC Trigger SOD.
[13] The "trig_sod_usec" is the sub-seconds portion of the Trigger_SOD.
The units are [microsec].
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the LVC pipeline processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G internal_flag LCV_Team_internal distribution(=1), Full (Priv Phase) LV-EM-Forum_sign-up distribution(=0)
1 G test_flag Test-type: 0=Real, 1=Test
2 G hardware_inj Is this a hardware injection event: 0=no, 1=yes
3 G vetted Has this event been vetted by a human: 0=no, 1=yes
4 G open_alert Is this event an open alert: 0=no, 1=yes
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 spare spare for furture use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description/definition of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 LHO LIGO-Handford Obs contribution flag (aka 'participated')
1 LLO LIGO-Livingston Obs contribution flag (aka 'participated')
2 Virgo Virgo Obs contribution flag (aka 'participated')
3 GEO600 GEO600 Obs contribution flag (aka 'participated')
4 KAGRA KAGRA Obs contribution flag (aka 'participated')
5 LIO LIGO-India Obs contribution flag (aka 'participated')
6 spare_inst1 TBD1 Obs contribution flag (aka 'participated')
7 spare_inst2 TBD2 Obs contribution flag (aka 'participated')
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-18 spare Spare bits within 'misc'.
19 Gnd_gen When this bit is a 1, then this Notice was ground-generated; else flight-generated.
Always 1 for Test Notices.
20-23 Letter The Letter prefix on the ID_number: 1="G", 2="T", 3="M", 4="Y", 5="H", 6="E", 7="K", 8="S" 9="GW", 10="TS", 11="TGW", 12="MS", 13="MGW".
24-31 serial LVC-generated serial number for message sequence in this trig_num.
[29-38] The "url_c0-3" is the start of slot 29 for Type Retraction.
It is a string that looks like: S190219ab
It needs to be combined with: https://gracedb.ligo.org/superevents/
https://gracedb.ligo.org/apibasic/superevents/S190219ab/view
There are a total of 30 "spare" items in the packet (usually filled with zeros).
They are located at items 7-17 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=166 PACKET CONTENTS:
UNDER CONSTRUCTION!!!!! UNDER CONSTRUCTION!!!!! UNDER CONSTRUCTION!!!!!
The AMON_ICECUBE_CLUSTER Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 166
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=166)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_events [evts] Events [counts] (always 1)
long 10 spare integer 4 bytes for the future
long 11 evt_error50 [0.0001-deg] (int)(0.0 to 180.0 *10000) 50% Conf
long 12-15 spare[4] integer 16 bytes for the future
long 16 stream integer Which instrument/data source
long 17 spare integer 4 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 166, which tells that this packet
is of type AMON_ICECUBE_CLUSTER and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_num" is a uniquely identifying number for each event/trigger.
(See also 'run_num' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "n_events" field contains the number of events (ie neutrinos)
that occurred during the deltaT window. For ICECUBE_EHE type,
this number will always be 1 (ie one PeV neutrino). (Alway one, but this field
is still included in the EHE type to be symetric with the HESE and COINC types.)
[11] The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
????
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G role=test Received with role="test"
2-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-23 spare Spare bits within 'misc'.
24-31 sernum 8 bits containing the type of the EHE serial number(???)
There are a total of TBD "spare" items in the packet (usually filled
with zeros). They are located at items TBD-TBD.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=168 PACKET CONTENTS:
UNDER CONSTRUCTION!!!!! UNDER CONSTRUCTION!!!!! UNDER CONSTRUCTION!!!!!
The GWHEN_COINC packet contains spatial/temporal coincidence
between LVC GW events and ICECUBE HEN neutrino events.
The GWHEN_COINC Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 168:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=168)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 coinc_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 coinc_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 fluence [J/m2]] (int)(log10(fluence)*10000)
long 10 peak_freq [centi-Hz] (int)(Hz*100.0)
long 11 lvc_far [Hz] (int)(log10(lvc_far)*10000)
long 12 event_type bit_fields Search/Pipeline/Group index values
long 13 trig_subsec [micro-sec] (int)(0 to 999999)
long 14 duration [centi-sec] (int)(0 to NNN.NN *100)
long 15 eta [milli-dn] (int)(0.00 to 0.NN *1000)
long 16 chip_mass [0.0001-Mo] (int)(0.00 to 1.50 *10000)
long 17 max_distance [centi-Mpc] (int)(0.00 to 600.00 *100)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 hen_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 21 hen_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 22 hen_error [0.0001-deg] (int)(0.0 to +180.0 *10000)
//long 23 coinc_far [Hz] (int)(log10(coinc_far)*10000)
long 23 lvc_far [Hz] (int)(log10(lvc_far)*10000)
long 24-28 spare[5] integer 20 bytes for the future
//quad_char 29-38 url[10] chars The URL for the skymap
quad_char 29-38 coinc_url[10]chars The URL for the skymap
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (for 168):
[0] The "pkt_type" is an integer with a value of 168 for the GWHEN type.
It tells which type of packet this is and therefore what the contents are
(the contents change somewhat between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
[5] The "trig_tjd" is the Truncated Julian Day of the LVC event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the LVC event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
LVC has higher precission for the actual trigger SOD, but this field is kept
for LVC to be uniform with all the other GCN Notice types. See slot 13
for the full 6 digits of precision (ie micro-sec) for the LVC Trigger SOD.
[7-8] The "coinc_ra" and "dec" fields specify the RA,Dec location of the convolution
of the two probability maps (the LVC_INITIAL map and the HEN probability map)
(in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[9] The "fluence" is the estimated fluence of the GW burst signal. The units are [J/m2].
It is defined (ie filled) only for the 'burst' class of trigger events.
The quantity stored in slot 9 is the log10() of the fleunce value from LVC
multiplied by 10,000 and then integerized. To retrieve the fluence value at the
receiving end, call fluence=pow(10.0,slot[9]/10000.0).
[10] The "peak_freq" is peak frequency of the GW burst signal. The units are [Hz].
It is defined (ie filled) only for the 'burst' class of trigger events.
[11] The "lvc_far" is the false alarm rate. The units are [Hz].
The quantity stored in slot 11 is the log10() of the FAR value from LVC
multiplied by 10,000 and then integerized. To retrieve the FAR value at the
receiving end, call far=pow(10.0,slot[11]/10000.0).
[12] The "event_type" is a combination of the group-type, search-method and pipeline used.
The pipeline is packed in the bottom 8 bits (2^0 - 2^7), and the search-method is
packed into the next higher 8 bits (2^8 - 2^15), and group-type is packed
in the next higher 8 bits (2^16 - 2^23).
Pipeline:
0 undefined/illegal
1 MTBAOnline
2 CWB
3 CWB2G
4 GSTLAL
5 GSTLAL_Spiir
6 Hardware Injection
7 X
8 Q
9 Omega
10 Ringdown
11 LIB
12 Fermi
13 Swift
14 SNEWS
Search:
0 undefined/illegal
1 AllSky
2 LowMass
3 HighMass
4 GRB
5 Supernova
6 MockDataChallenge
Group:
0 undefined/illegal
1 CBC
2 Burst
[13] The "trig_sod_usec" is the sub-seconds portion of the Trigger_SOD.
The units are [microsec].
[14] The "duration" is duration of the GW burst signal. The units are [sec].
It is defined (ie filled) only for the 'burst' class of trigger events.
[15] The "Eta" is the ratio of the reduced mass to the total mass. The units are [dn].
It is defined (ie filled) only for the 'LowMass/CBC/inspiral' class of trigger events.
The quantity stored in slot 15 is the eta value multiplied by 1000 and then integerized.
[16] The "chirp_mass" is ((m1*m2)^3/5)/(m1+m2)^1/5. The units are [M_solar].
The chirp mass determines the leading-order amplitude and frequency evolution
of the gravitational-wave signal emitted by the binary during its inspiral.
It is defined (ie filled) only for the 'LowMass/CBC/inspiral' class of trigger events.
The units are 0.0001-solar_mass (ie the value was multiplied by 10,000 and then integerized).
[17] The "max_distance" is the maximum distance this could be detected. The units are [Mpc].
It is defined (ie filled) only for the 'LowMass/CBC/inspiral' class of trigger events.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the LVC pipeline processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G internal_flag LCV_internal distribution(=1), Full distribution(=0)
1 G test_flag Test-type: 0=Real, 1=Test
2-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 spare spare for furture use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0 LHO LIGO-Handford Obs contribution flag (aka 'participated')
1 LLO LIGO-Livingston Obs contribution flag (aka 'participated')
2 Virgo Virgo Obs contribution flag (aka 'participated')
3 GEO600 GEO600 Obs contribution flag (aka 'participated')
4 KAGRA KAGRA Obs contribution flag (aka 'participated')
5 LIO LIGO-India Obs contribution flag (aka 'participated')
6 spare_inst1 TBD1 Obs contribution flag (aka 'participated')
7 spare_inst2 TBD2 Obs contribution flag (aka 'participated')
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10 IceCube IceCube contribution flag (aka 'participated')
11 Antares Antares contribution flag (aka 'participated')
12 Auger Auger contribution flag (aka 'participated')
13-18 spare Spare bits within 'misc'.
19 Gnd_gen When this bit is a 1, then this Notice was ground-generated; else flight-generated.
Always 1 for Test Notices.
20-23 Letter The Letter prefix on the ID_number: 1='G', 2='T', 3='M', 4='Y', 5='H', 6='E', 7='K', 8='S'.
24-31 serial LVC-generated serial number for message sequence in this trig_num.
[20-21] The "hen_ra" and "dec" fields specify the RA,Dec location of the HEN neutrino(s)
(in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[22] The "hen_error" is the radius of the circle that will contain TBD%
of the correct direction of the HEN localizations.
The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
[23] The "hen_far" is the false alarm rate of just the HEN event. The units are [Hz].
The "coinc_far" is the false alarm rate of just the ??? event. The units are [Hz].
The "lvc_far" is the false alarm rate of just the LVC event. The units are [Hz].
The quantity stored in slot 11 is the log10() of the FAR value from LVC
multiplied by 10,000 and then integerized. To retrieve the FAR value at the
receiving end, call far=pow(10.0,slot[11]/10000.0).
[29-38] The "url_c0-3" is the start of slot 29 for Types I/U/T).
It is not defined for the Preliminary or Counterpart Notice types.
It is a string that looks like: M131119/files/lalinference_nest.fits.gz
It needs to be combined with:
https://gracedb.ligo.org/apibasic/events
[Note that prior to 24jul15, it was recommended that https://gracedb.ligo.org/events/
be used as the prefix string. But this is the x509-based url string, and x509
requires that the recipient have an x509 certificate, and be able to launch a java script,
and this was just too complicated. So LVC created a simplier web-based interface.]
to make the full URL:
https://gracedb.ligo.org/apibasic/events/M131119/files/lalinference_nest.fits.gz
For GWHEN there are a total of 11 "spare" items in the packet (usually filled
with zeros). They are located at items 7-8 and 30-38.
The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=169 PACKET CONTENTS:
NOTE: Type=169 packets (AMON_ICECUBE_EHE) are NO LONGER AVAILABLE.
They have been replaced by the 173/174 packets.
The AMON_ICECUBE_EHE Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 169
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=169)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_events [evts] Events [counts] (always 1)
long 10 spare integer 4 bytes for the future
long 11 evt_error50 [0.0001-deg] (int)(0.0 to 180.0 *10000) 50% Conf
long 12 spare integer 4 bytes for the future
long 13 deltaT [centi-sec] (int)(0.0 to 0.999999 *100)
long 14 sigmaT [centi?-sec] (int)(log10(sigmaT)*10000)
long 15 energy centi-TeV (int)(0.0 to EEE.E *100
long 16 stream integer Which instrument/data source
long 17 rev [dn] 0-N (revision/update serial number)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 spare integer 4 bytes for the future
long 21 charge [centi-pe] (int)(0.0 to NNNN.N *100
long 22 signalness [0.01-1.0] (int)(log10(signalness)*10000)
long 23 run_num [dn] Run number in which the Event was found
long 24 spare integer spare
long 25 sub_sec [micro-sec] (int)(0.sssssss *1e6)
long 26-38 spare[12] integer 52 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 169, which tells that this packet
is of type AMON_ICECUBE_EHE and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_num" is a uniquely identifying number for each event/trigger.
(See also 'run_num' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "n_events" field contains the number of events (ie neutrinos)
that occurred during the deltaT window. For ICECUBE_EHE type,
this number will always be 1 (ie one PeV neutrino). (Alway one, but this field
is still included in the EHE type to be symetric with the HESE and COINC types.)
[11] The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
[13] The "deltaT" field contains the Time window of the burst.
The units are centi-sec (ie the deltaT was multiplied by 100 and then integerized).
[14] The "sigmaT" field contains the Uncertainty of the time window.
The quantity stored in slot 14 is the log10() of the Sigma_T value from AMON
multiplied by 10,000 and then integerized. To retrieve the time_interval value at the
receiving end, call sigma_t=pow(10.0,slot[14]/10000.0).
[15] The "energy" field contains the lower bound energy estimate of the neutrino (in units of TeV).
The quantity stored in slot 15 is the log10() of the Energy value (in TeV)
multiplied by 10,000 and then integerized. To retrieve the time_interval value at the
receiving end, call energy=pow(10.0,slot[14]/10000.0).
[16] The "stream" field contains the index number identifying
which analysis stream produced this trigger. It ranges from 1 - NN.
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=abc, 3=def, ...
[17] The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
For AMON_EHE type notices, the changes are most likely due to the RA,Dec,Error
values changing.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G role=test Received with role="test"
2-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-23 spare Spare bits within 'misc'.
24-31 sernum 8 bits containing the type of the EHE serial number(???)
[21] The "charge" field contains the total neutrino event charge (in units of photo-electrons).
The quantity stored in slot 21 is the log10() of the charge value (photo-electronics)
multiplied by 10,000 and then integerized. To retrieve the Charge value at the
receiving end, call charge=pow(10.0,slot[21]/10000.0).
[Note that this is not the same packing method as 'charge' in the AMON_ICECUBE_HESE packet.]
[22] The "signalness" field contains the probability that the neutrino event was signal and track-like.
The range is 0.00001 to 1.0.
The quantity stored in slot 22 is the log10() of the Signalness value from AMON
multiplied by 10,000 and then integerized. To retrieve the Prob_value value at the
receiving end, call signalness=pow(10.0,slot[22]/10000.0).
[23] The 'run_num' is the 2nd of two parts ('event_num' is first part, see above)
that uniquely identifies this event.
[25] The "sub_sec" field contains the subseconds portion of the trigger_sod.
It contains the fractional-seconds portion to 6 significant digits;
0.123456*1e6 and then integerized.
There are a total of TBD "spare" items in the packet (usually filled
with zeros). They are located at items TBD-TBD.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=170 PACKET CONTENTS: [Terminated by AMON 08sep19]
The AMON_ANTARES_FERMILAT_COINC Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 170
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=170)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_events [evts] Events [counts] (always 1)
long 10 spare integer 4 bytes for the future
long 11 evt_error50 [0.0001-deg] (int)(0.0 to 180.0 *10000) 50% Conf
long 12 spare integer 4 bytes for the future
long 13 deltaT [centi-sec] (int)(0.0 to 0.999999 *100)
long 14 sigmaT [centi?-sec] (int)(log10(sigmaT)*10000)
long 15 energy centi-TeV (int)(0.0 to EEE.E *100
long 16 stream integer Which instrument/data source
long 17 rev [dn] 0-N (revision/update serial number)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 spare integer 4 bytes for the future
long 21 charge [centi-pe] (int)(0.0 to NNNN.N *100
long 22 signalness [0.01-1.0] (int)(log10(ssignalness)*10000)
long 23 run_num [dn] Run number in which the Event was found
long 24 spare integer spare
long 25 sub_sec [micro-sec] (int)(0.sssssss *1e6)
long 26-38 spare[12] integer 52 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 170, which tells that this packet
is of type AMON_ANTARES_FERMILAT_COINC and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_num" is a uniquely identifying number for each event/trigger.
(See also 'run_num' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] The "n_events" field contains the number of events (ie neutrinos)
that occurred during the deltaT window. For ICECUBE_EHE type,
this number will always be 1 (ie one PeV neutrino). (Alway one, but this field
is still included in the EHE type to be symetric with the HESE and COINC types.)
[11] The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
[13] The "deltaT" field contains the Time window of the burst.
The units are centi-sec (ie the deltaT was multiplied by 100 and then integerized).
[14] The "sigmaT" field contains the Uncertainty of the time window.
The quantity stored in slot 14 is the log10() of the Sigma_T value from AMON
multiplied by 10,000 and then integerized. To retrieve the time_interval value at the
receiving end, call sigma_t=pow(10.0,slot[14]/10000.0).
[15] The "energy" field contains the lower bound energy estimate of the neutrino (in units of TeV).
The quantity stored in slot 15 is the log10() of the Energy value (in TeV)
multiplied by 10,000 and then integerized. To retrieve the time_interval value at the
receiving end, call energy=pow(10.0,slot[14]/10000.0).
[16] The "stream" field contains the index number identifying
which analysis stream produced this trigger. It ranges from 1 - NN.
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=abc, 3=def, ...
[17] The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
For AMON_EHE type notices, the changes are most likely due to the RA,Dec,Error
values changing.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G role=test Received with role="test"
2-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-23 spare Spare bits within 'misc'.
24-31 sernum 8 bits containing the type of the EHE serial number(???)
[21] The "charge" field contains the total neutrino event charge (in units of photo-electrons).
The quantity stored in slot 21 is the log10() of the charge value (photo-electronics)
multiplied by 10,000 and then integerized. To retrieve the Charge value at the
receiving end, call charge=pow(10.0,slot[21]/10000.0).
[Note that this is not the same packing method as 'charge' in the AMON_ICECUBE_HESE packet.]
[22] The "signalness" field contains the probability that the neutrino event was signal and track-like.
The range is 0.00001 to 1.0.
The quantity stored in slot 22 is the log10() of the Signalness value from AMON
multiplied by 10,000 and then integerized. To retrieve the Prob_value value at the
receiving end, call signalness=pow(10.0,slot[22]/10000.0).
[23] The 'run_num' is the 2nd of two parts ('event_num' is first part, see above)
that uniquely identifies this event.
The "sub_sec" field contains the subseconds portion of the trigger_sod.
It contains the fractional-seconds portion to 6 significant digits;
0.123456*1e6 and then integerized.
There are a total of TBD "spare" items in the packet (usually filled
with zeros). They are located at items TBD-TBD.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=171 PACKET CONTENTS:
The HAWC_BURST_MONITOR Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 171
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=171)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integer 8 bytes for the future
long 11 evt_error [0.0001-deg] (int)(0.0 to 180.0 *10000) 68% Conf
long 12 FAR [# per yr] pow(10.0,slot[12]/10000.0)
long 13 deltaT [centi-sec] (int)(0.0 to NNNN.NN sec *100)
long 14 spare integer 4 bytes for the future
long 15 event_ID integer Event Triger/ID number
long 16 stream integer Which instrument/data source
long 17 rev [dn] 0-N (revision/update serial number)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 pvalue [0.0-1.0] Probability that is real astrophysical
long 21-22 spare[2] integer 16 bytes for the future
long 23 run_ID [dn] Run number in which the Event was found
long 24-28 spare[5] integer 20 bytes for the future
quad_char 29-38 url[10] chars The URL for the skymap
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 171, which tells that this packet
is of type HAWC_BURST_MONITOR and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_ID" is a uniquely identifying number for each event/trigger.
(See also 'run_num' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[11] The "event_error" is the radius of the circle that will contain on average
68% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
[12] The "FAR" (False Alarm Rate) is the occurance rate of non-astrophysical events
that are of the same intensity (significance) as the current event.
The quantity stored in slot 12 is the log10() of the rate
multiplied by 10,000 and then integerized. To retrieve the "FAR" value at the
receiving end, call FAR=pow(10.0,slot[12]/10000.0).
[13] The "deltaT" field contains the Time window durtion of the burst.
The units are centi-sec (ie the deltaT was multiplied by 100 and then integerized).
The deltaT values are 0.2, 1.0, 10,0, and 100 seconds.
[15] The "event_ID" is a uniquely identifying number for each event/trigger.
(See also 'run_ID' below.)
[16] The "stream" field contains the index number identifying
which analysis stream produced this trigger. It ranges from 1 - NN.
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=EHE, 3-6=tbd,
7 =HAWC_Burst, 8-23=tbd, 24=IceCube_Gold, 25=IceCube_Bronze, ...
[17] The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
For HAWK_BURST_MONITOR type notices, the changes are most likely due to the RA,Dec,Error
values changing. (TBR)
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G role=test Received with role="test"
2-4 - spare spare for future use
//5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction. Not now, but eventually.
6-27 - spare spare for future use
//28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
//8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-31 spare Spare bits within 'misc'.
[20] The "pvalue" field contains the post-trials probability value of the event.
The quantity stored in slot 20 is the log10() of the rate
multiplied by 10,000 and then integerized. To retrieve the "pvalue" value at the
receiving end, call pvalue=pow(10.0,slot[20]/10000.0).
[23] The 'run_ID' is the 2nd of two parts ('event_ID' is first part, see above)
that uniquely identifies this event.
[29-38] The "url" is just the filename portion of the skymap URL -- the leading path
for the full URL is "http://not.yet.defined/notices/" for thr AMON archive and
"http://gcn.gsfc.nasa.gov/gcn/not-yet-defined/(TBD)" for the GCN archive.
This item in the packet spans 10 longwords (ie 40 bytes, ie up to 40 character) and contains
the ASCII string of the filename portion of the URL. This string
can be up to 39 characters long, and will always be null-terminated.
The combined/full url will look like:
"http://not.yet.defined/not-yet-defined/
There are a total of 12 "spare" slots in the packet (usually filled
with zeros). They are located at items 9-10, 14, 21-22.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=172 PACKET CONTENTS:
The AMON_NU_EM_COINC Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 172
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=172)
long 1 pkt_sernum integer 1 thru 4 billion
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_events integer CONFIRM THIS
long 10 spare integer 4 bytes for the future
long 11 evt_error90 [0.0001-deg] (int)(0.0 to 180.0 *10000) 90% Conf
long 12 FAR [# per yr] pow(10.0,slot[12]/10000.0)
long 13 deltaT [centi-sec] (int)(0.0 to 0.999999 *100)
long 14-15 spare[2] integer 8 bytes for the future
long 16 stream integer Which instrument/data source
long 17 rev [dn] 0-N (revision/update serial number)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
//long 20 pvalue [0.0-1.0] Probability that is real astrophysical // NOT USED
long 21-22 spare[2] integer 8 bytes for the future
long 23 run_num [dn] Run number in which the Event was found
long 24 evt_error50 [0.0001-deg] (int)(0.0 to 180.0 *10000) 50% Conf
long 25 sub_sec integer Subsec portion of the event_sod trigger time
long 26-35 spare[10] integer 40 bytes for the future
quad_char 36-38 evt_date[3] chars The Event_Date Name for this event
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 172, which tells that this packet
is of type AMON_NU_EM_COINC and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_num" is a uniquely identifying number for each event/trigger.
(See also 'run_num' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] "n_events" ....
[11] The "event_error90" is the radius of the circle that will contain on average
90% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
[12] The "FAR" (False Alarm Rate) is the occurance rate of non-astrophysical events
that are of the same intensity (significance) as the current event.
The quantity stored in slot 12 is the log10() of the rate
multiplied by 10,000 and then integerized. To retrieve the "FAR" value at the
receiving end, call FAR=pow(10.0,slot[12]/10000.0).
[13] The "deltaT" field contains the Time window of the burst.
The units are centi-sec (ie the deltaT was multiplied by 100 and then integerized).
[16] The "stream" field contains the index number identifying
which analysis stream produced this trigger. It ranges from 1 - NN.
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=abc, 3=def, ...
[17] The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
For AMON_NU_EM_COINC type notices, the changes are most likely due to the ?????
values changing.
[18] The "trig_id" field contains (a) flag bits on the type of solution YET TO CHECK/REVISE!!!
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
//0 G private This is a private event (only to AMON Team) //NOT USED
1 G role=test Received with role="test"
2-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction. Not now, but eventually.
6-11 G coinc_pairs The instrument coinc pairs ID index (6 bits, 0-63) (See table below)
12-27 - spare spare for future use
//28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event ?????
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event ?????
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
Table of Coinc_Pair_Index values and the Instrument_Pair_Names:
0 "illegal value"
1 "IC-HAWC"
2 "IC-Swift"
3 "IC-HESE-EHE"
4 "IC-Fermi"
5 "OFU-Alerts"
6 "GFU-Alerts"
7 "HAWC-GRBlike-Alert"
8 "Antares-Fermi"
9 "IC-Gold-Bronze"
10 "Inst1-Inst2" // future
11 "Inst3-Inst4" // future
[19] The "misc" field contains various bit_flags. YET TO CHECK/REVISE!!!
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
//8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-31 spare Spare bits within 'misc'.
[20] The "pvalue" proability that this event is astrophysical real.
It has a dynamic range of 0.0 to 1.0. Currently is is not used.
The AMON team fills this slot with a value which is always 1.0.
The quantity stored in slot 15 is the log10() of the pvalue value (in ???)
multiplied by 10,000(TBC) and then integerized. To retrieve the pvalue value at the
receiving end, call pvalue=pow(10.0,slot[20]/10000.0(TBC)).
[23] The "run_num" is ... (vs "run_ID" as in Type 171)(TBD)
[24] The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains the statistical error and the systematic error(TBD).
[25] The "sub_sec" is the subseconds portion of the trigger time.
Take the 4 bytes (unsigned integer) and divide by 1,000,000.0
and add to the Trigger_SOD[6] to get the full Trigger_SOD value.
[36-38] The "evt_date" is date-based name for this event: YYYYMMDDa.
There are a total of 15 "spare" items in the packet (usually filled
with zeros). They are located at items 10, 14-15, 21-22, and 26-33.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=173 PACKET CONTENTS:
The ICECUBE_ASTROTRACK_GOLD Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 173
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=173)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integer 8 bytes for the future
long 11 evt_error90 [0.0001-deg] (int)(0.0 to 180.0 *10000) 90% Conf
long 12 event_ID integer Event Triger/ID number
long 13-14 spare[2] integer 8 bytes for the future
long 15 energy TeV Energy of the neutrino
long 16 stream integer Which instrument/data source
long 17 rev [dn] 0-N (revision/update serial number)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 FAR [N/yr] False Alerm Rate [N/yr]
long 21 spare integer 4 bytes for the future
long 22 signalness [0.01-1.0] (int)(log10(signalness)*10000)
long 23 run_ID [dn] Run number in which the Event was found
long 24 evt_error50 [0.0001-deg] (int)(0.0 to 180.0 *10000) 50% Conf
long 25-38 spare[14] integer 64 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 173, which tells that this packet
is of type ICECUBE_ASTROTRACK_GOLD and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_ID" is a uniquely identifying number for each event/trigger.
(See also 'run_ID' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[11] The "event_error90" is the radius of the circle that will contain on average
90% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
[12] The "event_ID" is the first part of the identification of the IceCube event.
[15] The "energy" field contains the lower bound energy estimate of the neutrino (in units of TeV).
The quantity stored in slot 15 is the log10() of the Energy value (in TeV)
multiplied by 10,000 and then integerized. To retrieve the energy value at the
receiving end, call energy=pow(10.0,slot[15]/10000.0).
[16] The "stream" field contains the index number identifying
which analysis stream produced this trigger. It ranges from 1 - NN.
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=EHE, 3-6=tbd,
7=HAWC_Burst, 8-23=tbd, 24=IceCube_Gold, 25=IceCube_Bronze, ...
[17] The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
For ICECUBE_ASTROTRACK_GOLD type notices, the changes are most likely due to the RA,Dec,Error
values changing.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G role=test Received with role="test"
2-4 - spare spare for future use
//5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction. Not now, but eventually.
6 G url_exist 0=No or 1=Yes. Do the two URL exist in this Notice?
7-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-23 spare Spare bits within 'misc'.
24-31 sernum 8 bits containing the type of the EHE serial number(???)
[20] The "FAR" (False Alarm Rate) field contains the rate of background events
that are "like this alert" that would be seen by IceCube per year.
The quantity stored in slot 20 is the log10() of the rate
multiplied by 10,000 and then integerized. To retrieve the "FAR" value at the
receiving end, call FAR=pow(10.0,slot[21]/10000.0).
[22] The "signalness" field contains the probability that the neutrino event was signal and track-like.
The range is 0.00001 to 1.0.
The quantity stored in slot 22 is the log10() of the Signalness value from AMON
multiplied by 10,000 and then integerized. To retrieve the Prob_value value at the
receiving end, call signalness=pow(10.0,slot[22]/10000.0).
[23] The 'run_ID' is the 2nd of two parts ('event_ID' is first part, see above)
that uniquely identifies this event.
[24] The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
There are a total of 19 "spare" slots in the packet (usually filled
with zeros). They are located at items 9-10, 13-14, 21, 25-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=174 PACKET CONTENTS:
The ICECUBE_ASTROTRACK_BRONZE Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 174
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=174)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9-10 spare[2] integer 8 bytes for the future
long 11 evt_error90 [0.0001-deg] (int)(0.0 to 180.0 *10000) 90% Conf
long 12 event_ID integer Event Triger/ID number
long 13-14 spare[2] integer 8 bytes for the future
long 15 energy TeV Energy of the neutrino
long 16 stream integer Which instrument/data source
long 17 rev [dn] 0-N (revision/update serial number)
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20 FAR [N/yr] False Alarm Rate [N/yr]
long 21 spare integer 4 bytes for the future
long 22 signalness [0.01-1.0] (int)(log10(signalness)*10000)
long 23 run_ID [dn] Run number in which the Event was found
long 24 evt_error50 [0.0001-deg] (int)(0.0 to 180.0 *10000) 50% Conf
long 25-38 spare[14] integer 56 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 174, which tells that this packet
is of type ICECUBE_ASTROTRACK_BRONZE and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "event_num" is a uniquely identifying number for each event/trigger.
(See also 'run_num' below.)
[5] The "trig_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[11] The "event_error90" is the radius of the circle that will contain on average
90% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
[12] The "event_ID" is the first part of the identification of the IceCube event.
[15] The "energy" field contains the lower bound energy estimate of the neutrino (in units of TeV).
The quantity stored in slot 15 is the log10() of the Energy value (in TeV)
multiplied by 10,000 and then integerized. To retrieve the energy value at the
receiving end, call energy=pow(10.0,slot[15]/10000.0).
[16] The "stream" field contains the index number identifying
which analysis stream produced this trigger. It ranges from 1 - NN.
The list of streams are: 0=undefined, 1=ICECUBE_HESE, 2=EHE, 3-6=tbd,
7=HAWC_Burst, 8-23=tbd, 24=IceCube_Gold, 25=IceCube_Bronze, ...
[17] The "rev" field contains the number of times this notice was revised (ie updated).
rev=0 means the first notice, 1 is the 1st revision, 2 is 2nd revision, etc.
For ICECUBE_ASTROTRACK_BRONZE type notices, the changes are most likely due to the RA,Dec,Error
values changing.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the AMON processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G role=test Received with role="test"
2-4 - spare spare for future use
//5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction. Not now, but eventually.
6 G url_exist 0=No or 1=Yes. Do the two URL exist in this Notice?
7-27 - spare spare for future use
28 G spatial_coinc 0=No or 1=Yes, there was a spatial coincidence with another event
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-7 spare Spare bits within 'misc'.
8-9 cite_type Citation type (0=undef,1=followup,2=supersedes,3=retraction)
10-23 spare Spare bits within 'misc'.
24-31 sernum 8 bits containing the type of the EHE serial number(???)
[20] The "FAR" (False Alarm Rate) field contains the rate of background events
that are "like this alert" that would be seen by IceCube per year.
The quantity stored in slot 20 is the log10() of the rate
multiplied by 10,000 and then integerized. To retrieve the "FAR" value at the
receiving end, call FAR=pow(10.0,slot[20]/10000.0).
[22] The "signalness" field contains the probability that the neutrino event was signal and track-like.
The range is 0.00001 to 1.0.
The quantity stored in slot 22 is the log10() of the Signalness value from AMON
multiplied by 10,000 and then integerized. To retrieve the Prob_value value at the
receiving end, call signalness=pow(10.0,slot[22]/10000.0).
[23] The 'run_ID' is the 2nd of two parts ('event_ID' is first part, see above)
that uniquely identifies this event.
[24] The "event_error50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
There are a total of 19 "spare" slots in the packet (usually filled
with zeros). They are located at items 9-10, 13-14, 21, 25-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=175 PACKET CONTENTS:
The SK_SN Event packets consist of 40 four-byte quantities.
SK_SN is SuperKamioconde SuperNova.
The order and contents are listed in the table below:
For Type = 175
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=175)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 event_num integer Event Trigger/ID number
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 event_ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 event_dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 n_events integer Num neutrinos in the event
long 10 spare integer 8 bytes for the future
long 11 evt_error68 [0.0001-deg] (int)(0.0 to 180.0 *10000) 68% Conf
long 12 spare integer 8 bytes for the future
long 13 distance_lo kpc Lower boundary on the distance
long 14 distance_hi kpc Upper boundary on the distance
long 15 evt_error90 [0.0001-deg] (int)(0.0 to 180.0 *10000) 90% Conf
long 16 evt_error95 [0.0001-deg] (int)(0.0 to 180.0 *10000) 95% Conf
long 17 spare integer 4 bytes for the future
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-38 spare[19] integer 76 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS:
[0] The "pkt_type" is an integer with a value of 175, which tells that this packet
is of type SK_SN and therefore indicates the contents and format
for the other 39 fields.
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
[4] The "event_num" is a uniquely identifying number for each event/trigger.
[5] The "event_tjd" is the Truncated Julian Day of the AMON event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "event_sod" is the UT seconds-of-day (SOD) of the AMON event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
[7-8] The "ra" and "dec" fields specify the RA,Dec location of the multiply detected
event (in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an integer quantity with units of 10^-4-degrees.
[9] "n_events" is the number of neutrinos that were in the event.
[11] The "event_error68" is the radius of the circle that will contain on average
68% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
[13] The "distance_lo" is the lower estimate of the distance to the Supernova.
The units are kpc.
[14] The "distance_hi" is the upper estimate of the distance to the Supernova.
The units are kpc.
[15] The "event_error90" is the radius of the circle that will contain on average
90% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
[16] The "event_error95" is the radius of the circle that will contain on average
95% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized).
It contains only the statistical error component; there is no systematic error component.
[18] The "trig_id" field contains (a) flag bits on the upernoave event, and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 - spare spare for future use
1 G test 1=Yes, a Test notice; =0 (not a test, it is real event)
2-4 - spare spare for future use
//5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction. Not used now, but maybe eventually.
6-31 - spare spare for future use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-31 spare Spare bits within 'misc'.
There are a total of 22 "spare" slots in the packet (usually filled
with zeros). They are located at items 10, 12, 17, 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=176 PACKET CONTENTS:
The AMON_ICECUBE_CASCADE Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 176:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=176)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 energy [centi-TeV] (int)(lowest_energy *100)
long 10 pos_error_50 [0.0001-deg] (int)(0 to 180.0 *10000) 50% Conf
long 11 pos_error_90 [0.0001-deg] (int)(0 to 180.0 *10000) 90% Conf
long 12 far [yr^-1] (int)(log10(far)*10000)
long 13-14 spare[2] integer 8 bytes for the future
long 15 event_id integer AMON Event_ID number
long 16 stream integer AMON Stream number
long 17 rev integer AMON version number
long 18 trig_id bits Trigger identification flags
long 19 misc bits Misc stuff packed in here
long 20-21 spare[2] integer 8 bytes for the future
long 22 signalness [0.01-1.0] (int)(log10(signalness)*10000)
long 23 run_num integer AMON Run Number (in the millions)
long 24-25 spare[2] chars 8 bytes for the future
quad_char 26-28 name[3] chars The common_name string for the event
quad_char 29-38 url[10] chars The URL for the skywatch_url
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (for 176):
[0] The "pkt_type" is an integer with a value of 176 for the AMON_ICECUBE_CASCADE type.
It tells which type of packet this is and therefore what the contents are
(the contents change somewhat between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num???" is a uniquely identifying number for each trigger.
[5] The "trig_tjd" is the Truncated Julian Day of the LVC event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the LVC event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
LVC has higher precission for the actual trigger SOD, but this field is kept
for LVC to be uniform with all the other GCN Notice types. See slot 13
for the full 6 digits of precision (ie micro-sec) for the LVC Trigger SOD.
[7-8] The "ra" and "dec" specifies the RA,Dec location where the neutrino came from
(in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[9] The "energy" is the emergy of the neutrino in units of TeV. It is accurate
to 5-10%. The units are 0.01-TeV (ie the fl.pt. energy was multiplied
by 100 and then integerized).
[10] The "pos_error_50" is the radius of the circle that will contain on average
50% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). It contains both the statistical error component and
the systematic error component combined.
[11] The "pos_error_90" is the radius of the circle that will contain on average
90% of the sources. The units are 0.0001-degrees (ie the fl.pt. error was multiplied
by 10000 and then integerized). It contains both the statistical error component and
the systematic error component combined.
[12] The "far" is the false alarm rate. The units are [1/yr].
The quantity stored in slot 12 is the log10() of the FAR value multiplied by 10,000
and then integerized. To retrieve the FAR value at the receiving end,
call far=pow(10.0,slot[12]/10000.0).
[15] The "event_id" is the Event_ID number assigned by AMON during the processing.
[16] The "stream" is the Stream number assigned by AMON during the processing.
[17] The "rev" is the version number assigned by AMON during the processing.
[18] The "trig_id" field contains (a) flag bits on the type of solution
that was found by the IceCube pipeline processing and
(b) flag bits that are assigned in the GCN ground-processing.
The bit packing of the "trig_id" entry in the packet is:
BitNum F-v-G Item_name Description
------ ---- --------- -----------
0 G internal_flag LCV_internal distribution(=1), Full distribution(=0)
1 G test_flag Test-type: 0=Real, 1=Test
2-4 - spare spare for future use
5 G retraction 0=No or 1=Yes, it is definitely not real, a Retraction
6-28 - spare spare for future use
29 G temporal_coinc 0=No or 1=Yes, there was a temporal coincidence with another event
30 test_submit 0=No or 1=Yes, this is a test submission (internal use only)
31 spare spare for furture use
The columns are: "BitNum" is the 2^N location within the 4-byte word;
"Item_name" is the short-description name of the quantity; and
"Description" is the longer description of the quantity.
[19] The "misc" field contains various bit_flags.
The bit packing is:
Bit_Number Item_name Description
---------- --------- -----------
0-18 spare Spare bits within 'misc'.
19 Gnd_gen When this bit is a 1, then this Notice was ground-generated; else flight-generated.
Always 1 for Test Notices.
20-31 spare Spare bits within 'misc'.
[22] The "signalness" field contains the probability that the neutrino event was signal and track-like.
The range is 0.00001 to 1.0.
The quantity stored in slot 22 is the log10() of the Signalness value from AMON
multiplied by 10,000 and then integerized. To retrieve the Prob_value value at the
receiving end, call signalness=pow(10.0,slot[22]/10000.0).
[23] The 'run_num' is the 2nd of two parts ('event_ID' is first part, see above)
that uniquely identifies this event.
[26-28] The common "name" for this event. Sorted in these 3 slots is the "YYMMDDa" part
of the "IceCubeCascade-YYMMDDa" name string.
[29-38] The "url_c0-3" is the start of slot 29 for ....
???It is not defined for the Preliminary or Counterpart Notice types.
It is a string that looks like: M131119/files/lalinference_nest.fits.gz
It needs to be combined with:
???https://gracedb.ligo.org/apibasic/events
???[Note that prior to 24jul15, it was recommended that https://gracedb.ligo.org/events/
???be used as the prefix string. But this is the x509-based url string, and x509
???requires that the recipient have an x509 certificate, and be able to launch a java script,
???and this was just too complicated. So LVC created a simplier web-based interface.]
???to make the full URL:
???https://gracedb.ligo.org/apibasic/events/M131119/files/lalinference_nest.fits.gz
For AMON_ICECUBE_CASCADE there are a total of ?? "spare" items in the packet (usually filled
with zeros). They are located at items ?-? and ??-??.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=188 PACKET CONTENTS:
The GECAM_FLT Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 188:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=188)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [num_per_sec] (long)0 to 2 billion
long 10 error [0.0001-deg] (long)(0.0 to 180.00 *10000)
long 11 class_type [integer] (long) Event type number
long 12 phi [0.01-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [0.01-deg] (int)(-90.0 to +90.0 *100)
long 14 burst_dur [sec] (int)(sss.sss *10000 *sec)
long 15 spare 4 bytes for the future
long 16 sc_lat
long 17 sc_long
long 18 soln_status Possible Test flag
long 19 misc
long 20 trigger_signif
long 21 trigger_dur
long 22 chan_lo
long 23 chan_hi
long 24 energy_lo
long 25 energy_hi
long 26 trigger_dets
long 27
long 28
long 29
long 30
long 31-38 spare[8] integer 32 bytes for the future
There are a total of 12 "spare" slots in the packet (usually filled
with zeros). They are located at items 27-38.
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (for 188):
[0] The "pkt_type" is an integer with a value of 188 for the GECAM_FLT type.
It tells which type of packet this is and therefore what the contents are
(the contents change somewhat between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
[5] The "trig_tjd" is the Truncated Julian Day of the LVC event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the LVC event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
LVC has higher precission for the actual trigger SOD, but this field is kept
for LVC to be uniform with all the other GCN Notice types. See slot 13
for the full 6 digits of precision (ie micro-sec) for the LVC Trigger SOD.
[7-8] The "ra" and "dec" specifies the RA,Dec location where the X-ray & gamma rays came from
(in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[9-26] NOT FINISHED YET
[27-38] SPARE
For GECAM_FLT there are a total of 12 "spare" items in the packet (usually filled
with zeros). They are located at items 15 and 27-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
TYPE=189 PACKET CONTENTS:
The GECAM_GND Event packets consist of 40 four-byte quantities.
The order and contents are listed in the table below:
For Type = 189:
Declaration Index Item Units Comments
Type Name
----------- ----- --------- ---------- ----------------
long 0 pkt_type integer Packet type number (=189)
long 1 pkt_sernum integer 1 thru infinity
long 2 pkt_hop_cnt integer Incremented by each node
long 3 pkt_sod [centi-sec] (int)(sssss.sss *100)
long 4 trig_num integer Trigger num
long 5 event_tjd [days] Truncated Julian Day
long 6 event_sod [centi-sec] (int)(sssss.sss *100)
long 7 ra [0.0001-deg] (int)(0.0 to 359.9999 *10000)
long 8 dec [0.0001-deg] (int)(-90.0 to +90.0 *10000)
long 9 burst_inten [num_per_sec] (long)0 to 2 billion
long 10 error [0.0001-deg] (long)(0.0 to 180.00 *10000)
long 11 class_type [integer] (long) Event type number
long 12 phi [0.01-deg] (int)(0.0 to 359.9999 *100)
long 13 theta [0.01-deg] (int)(-90.0 to +90.0 *100)
long 14 burst_dur [sec] (int)(sss.sss *10000 *sec)
long 15 spare 4 bytes for the future
long 16 sc_lat
long 17 sc_long
long 18 soln_status Possible Test flag
long 19 misc
long 20
long 21
long 22
long 23
long 24
long 25
long 26
long 27
long 28
long 29
long 30
long 31-38 spare[8] integer 32 bytes for the future
long 39 pkt_term integer Pkt Termination (always = \n)
PACKET ITEM DESCRIPTIONS (for 189):
[0] The "pkt_type" is an integer with a value of 189 for the GECAM_FLT type.
It tells which type of packet this is and therefore what the contents are
(the contents change somewhat between the various types).
[1] The "pkt_sernum" is the serial number for that packet type. Each packet type
has its own sequential serial numbering. They all start at 1
when the GCN program starts up.
[2] The "pkt_hop_cnt" is a sequential numbering scheme that is incremented by 1
for each machine that the packet passes through (starting from 0 on the
machine of origin -- sometimes PK and sometimes capella2). It is used
in checking the hand-shake processing through the PK, CC, and capella2 machines
within the GCN system. Since the loss of GRO (May 2000), and therefore
the elimination of the PK and CC front-end processors, this hopcount item
is defunct -- all packets start on capella2 with a hopcount value of 0.
[3] The "pkt_sod" is UT seconds-of-day when the packet was created/sent from
the GCN computer. Do not confuse this with the trig_sod (see below).
The value is multiplied by 100 and integerized (i.e. the units are centi-sec; 10 msec).
[4] The "trig_num" is a uniquely identifying number for each trigger.
[5] The "trig_tjd" is the Truncated Julian Day of the LVC event,
eg. TJD=14466 is 01 Jan 2008.
[6] The "trig_sod" is the UT seconds-of-day (SOD) of the LVC event.
The units are in centi-seconds (ie the fl.pt. seconds were multiplied by 100
and then integerized). The trigger time can be off by TBD msec.
LVC has higher precission for the actual trigger SOD, but this field is kept
for LVC to be uniform with all the other GCN Notice types. See slot 13
for the full 6 digits of precision (ie micro-sec) for the LVC Trigger SOD.
[7-8] The "ra" and "dec" specifies the RA,Dec location where the X-ray & gamma rays came from
(in J2000 epoch). These intrinsically floating point quantities
have been multiplied by 10,000 and then integerized to make
an 32-bit integer quantity with units of 10^-4-degrees.
[9-19] NOT FINISHED YET
[20-38] SPARE
For GECAM_GND there are a total of "spare" items in the packet (usually filled
with zeros). They are located at items 15 and 20-38.
[39] The "pkt_term" is the packet termination character. It is an ASCII
newline (decimal value 10) in the last byte of the last 4-byte long
in the packet. This highly specialized termination character was required
by the firewall machine at LLNL in the very early days of operation.
It has since become a permanent fixture as multiple sites are now operating,
and it is not wise to play with format/content changes. And it still
does function as a fixed-content termination value for validity checking.
================================================================================
COORDINATES EPOCH and QUANTIZATION COMPARISON:
The table below contains the epochs used for the various RA,Dec locations
given within the various packets within the entire GCN socket_packet process.
This table gives a rapid comparison, and allows the "pattern" of epoch-usage
to be seen (granted, there are two exceptions to this "pattern"). Current epoch
was used in the early days of operations when there was only the
BATSE-based Position Notices, and then when other sources came into existance
the Current epoch pattern was maintained for the "center locations".
But since some of these other sources also had other RA,Dec coordinate
information (notably the center of an IPN annulus), which were historically
reported in J2000 epoch, that precident was then followed. With the addition
of the Swift Notices, the J2000 convention has been maintained.
The table also contains the quantization factors for each set of coordinates
locations in the various packets (centers and corners, etc). The quantization
in the value in angular degrees in each integerized coordinate location
(i.e. the value in the packet is (int)(value/quant) ).
TYPE# SOURCE_TYPE CENTER_LOC CORNERS_LOC CENTER_LOC CORNERS_LOC
NUMBER TYPE EPOCH EPOCH QUANT QUANT
1 BATSE_ORIGINAL Current n/a 0.01 n/a
2 Test Current n/a 0.01 n/a
11 BATSE_MAXBC Current n/a 0.01 n/a
22 BATSE_FINAL Current n/a 0.01 n/a
24 BATSE_LOCBURST Current n/a 0.01 n/a
25 ALEXIS Current n/a 0.01 n/a
27 XTE-PCA Current n/a 0.0001 n/a
29 XTE-ASM Current J2000 0.0001 0.0001
30 COMPTEL J2000 (1) J2000 0.01 0.01
31 IPN_RAW J2000 J2000 0.0001 0.0001
32 IPN_SEGMENT J2000 (2) J2000 (3) 0.0001 0.0001
34 SAX-WFC Current n/a 0.0001 n/a
36 SAX-NFI Current n/a 0.0001 n/a
37 ASM_XTRANS Current J2000 0.0001 0.0001
38 testing Current n/a 0.0001 n/a
39 IPN_POSITION Current J2000 0.0001 0.0001
41 HETE_S/C_UPDATE Current J2000 0.0001 0.0001
42 HETE_S/C_LAST Current J2000 0.0001 0.0001
43 HETE_GNDANA Current J2000 0.0001 0.0001
44 HETE_Test Current J2000 0.0001 0.0001
45 GRB_COUNTERPART J2000 (4) n/a 0.0001 n/a
46 SWIFT_TOO_FOM J2000 (5) n/a 0.0001 n/a
66 SWIFT_TOO_SC_SLEW J2000 (5) n/a 0.0001 n/a
51 INTEGRAL_POINTDIR J2000 (8) n/a 0.0001 (8) n/a
53 INTEGRAL_WAKEUP Current n/a 0.0001 n/a
54 INTEGRAL_REFINED Current n/a 0.0001 n/a
55 INTEGRAL_OFFLINE Current n/a 0.0001 n/a
56 INTEGRAL_WEAK Current n/a 0.0001 n/a
57 AAVSO J2000 (4) n/a 0.0001 n/a
58 MILAGRO J2000 (4) n/a 0.0001 n/a
61 SWIFT_BAT_GRB_POS J2000 (5) n/a 0.0001 n/a
62 SWIFT_BAT_GRB_POS_NACK n/a n/a n/a n/a
63 SWIFT_BAT_GRB_LC J2000 (5) n/a 0.0001 n/a
64 SWIFT_BAT_SCALEDMAP J2000 (5) n/a 0.0001 n/a
65 SWIFT_FOM_OBS J2000 (5) n/a 0.0001 n/a
66 SWIFT_SC_SLEW J2000 (5) n/a 0.0001 n/a
67 SWIFT_XRT_POS J2000 (5) n/a 0.0001 n/a
68 SWIFT_XRT_SPEC J2000 (5) n/a 0.0001 n/a
69 SWIFT_XRT_IMAGE J2000 (5) n/a 0.0001 n/a
70 SWIFT_XRT_LC J2000 (5) n/a 0.0001 n/a
71 SWIFT_XRT_NACK_POS J2000 (5) n/a 0.0001 n/a
72 SWIFT_UVOT_IMAGE J2000 (5) n/a 0.0001 n/a
73 SWIFT_UVOT_SRCLIST J2000 (5) n/a 0.0001 n/a
76 SWIFT_BAT_GRB_PROC_LC J2000 (5) n/a 0.0001 n/a
77 SWIFT_XRT_PROC_SPEC J2000 (5) n/a 0.0001 n/a
78 SWIFT_XRT_PROC_IMAGE J2000 (5) n/a 0.0001 n/a
79 SWIFT_UVOT_PROC_IMAGE J2000 (5) n/a 0.0001 n/a
80 SWIFT_UVOT_PROC_SLIST J2000 (5) n/a 0.0001 n/a
81 SWIFT_UVOT_POS J2000 (5) n/a 0.0001 n/a
82 SWIFT_BAT_GRB_POS_TEST J2000 (5) n/a 0.0001 n/a
83 SWIFT_POINTDIR J2000 (5) n/a 0.0001 n/a
84 SWIFT_BAT_TRANS J2000 (5) n/a 0.0001 n/a
89 SWIFT_UVOT_POS_NACK J2000 (5) n/a 0.0001 n/a
98 SWIFT_BAT_QL_POS J2000 (5) n/a 0.0001 n/a
98 SWIFT_BAT_SUBTHRESH_POS J2000 (5) n/a 0.0001 n/a
99 SWIFT_BAT_SLEW_GRB_POS J2000 (5) n/a 0.0001 n/a
100 AGILE_GRB_POS_WAKEUP J2000 (5) n/a 0.0001 n/a
101 AGILE_GRB_POS_GROUND J2000 (5) n/a 0.0001 n/a
102 AGILE_GRB_POS_REFINED J2000 (5) n/a 0.0001 n/a
103 SWIFT_ACTUAL_POINTDIR J2000 (5) n/a 0.0001 n/a
107 AGILE_POINTDIR J2000 (6) n/a 0.0001 (9) n/a
109 AGILE_GRB_POS_TEST J2000 (5) n/a 0.0001 n/a
110 FERMI_GBM_ALERT J2000 (6) n/a 0.0001 n/a
111 FERMI_GBM_FLT_POS J2000 (6) n/a 0.0001 n/a
112 FERMI_GBM_GND_POS J2000 (6) n/a 0.0001 n/a
113 FERMI_GBM_LC J2000 (6) n/a 0.0001 n/a
114 FERMI_GBM_INTERNAL J2000 (6) n/a 0.0001 n/a
115 FERMI_GBM_FIN_POS J2000 (6) n/a 0.0001 n/a
116 FERMI_GBM_ALERT_INTERNAL J2000 (6) n/a 0.0001 n/a
117 FERMI_GBM_FLT_INTERNAL J2000 (6) n/a 0.0001 n/a
118 FERMI_GBM_TRANS J2000 (6) n/a 0.0001 n/a
119 FERMI_GBM_POS_TEST J2000 (6) n/a 0.0001 n/a
120 FERMI_LAT_GRB_POS_INI J2000 (6) n/a 0.0001 n/a
121 FERMI_LAT_GRB_POS_UPD J2000 (6) n/a 0.0001 n/a
122 FERMI_LAT_GRB_POS_DIAG J2000 (6) n/a 0.0001 n/a
123 FERMI_LAT_TRANS J2000 (6) n/a 0.0001 n/a
124 FERMI_LAT_GRB_POS_TEST J2000 (6) n/a 0.0001 n/a
125 FERMI_LAT_MONITOR J2000 (6) n/a 0.0001 n/a
126 FERMI_SC_SLEW J2000 (6) n/a 0.0001 n/a
127 FERMI_LAT_GND J2000 (6) n/a 0.0001 n/a
128 FERMI_LAT_OFFLINE J2000 (6) n/a 0.0001 n/a
129 FERMI_POINTDIR J2000 (6) n/a 0.0001 (7) n/a
130 SIMBAD/NED_RESULTS J2000 n/a 0.0001 n/a
131 FERMI_GBM_SUBTHRESHOLD J2000 (6) n/a 0.0001 n/a
133 SWIFT_BAT_MONITOR J2000 (5) n/a 0.0001 n/a
134 MAXI_UNKNOWN_SRC J2000 (6) n/a 0.0001 n/a
135 MAXI_KNOWN_SRC J2000 (6) n/a 0.0001 n/a
136 MAXI_TEST J2000 (6) n/a 0.0001 n/a
137 OGLE J2000 (6) n/a 0.0001 n/a
139 MOA J2000 (6) n/a 0.0001 n/a
140 SWIFT_BAT_SUB_SUB_THRESH J2000 (5) n/a 0.0001 n/a
141 SWIFT_BAT_KNOWN_SRC_POS J2000 (5) n/a 0.0001 n/a
144 FERMI_SC_SLEW_INTERNAL J2000 (6) n/a 0.0001 n/a
145 COINCIDENCE J2000 (6) n/a 0.0001 n/a
146 FERMI_GBM_FIN_POS_INT J2000 (6) n/a 0.0001 n/a
149 SNEWS J2000 n/a 0.0001 n/a
150 LVC_PRELIMINARY J2000 n/a n/a n/a
151 LVC_INITIAL J2000 n/a n/a n/a
152 LVC_UPDATE J2000 n/a n/a n/a
153 LVC_TEST J2000 n/a n/a n/a
154 LVC_COUNTERPART J2000 n/a 0.0001 n/a
157 AMON_ICECUBE_COINC J2000 n/a 0.0001 n/a
158 AMON_ICECUBE_HESE J2000 n/a 0.0001 n/a
159 AMON_ICECUBE_TEST J2000 n/a 0.0001 n/a
160 CALET_GBM_FLT_LC J2000 (10) n/a 0.0001 n/a Normal slots used
161 CALET_GBM_GND_LC J2000 (10) n/a 0.0001 n/a
163 LVC_EARLY_WARNING J2000 n/a n/a n/a
166 AMON_ICECUBE_CLUSTER J2000 n/a 0.0001 n/a
168 GWHEN J2000 n/a 0.0001 n/a
169 AMON_ICECUBE_EHE J2000 n/a 0.0001 n/a
170 AMON_ANTARES_FERMILAT J2000 n/a 0.0001 n/a [Terminated by AMON 08sep19]
171 HAWC_BURST_MONITOR J2000 n/a 0.0001 n/a
172 AMON_NU_EM_COINC J2000 n/a 0.0001 n/a
173 ICECUBE_ASTROTRACK_GOLD J2000 n/a 0.0001 n/a
174 ICECUBE_ASTROTRACK_BRONZE J2000 n/a 0.0001 n/a
175 SK_SN J2000 n/a 0.0001 n/a
176 AMON_ICECUBE_CASCADE J2000 n/a 0.0001 n/a
188 GECAM_FLT J2000 n/a 0.0001 n/a
189 GECAM_GND J2000 n/a 0.0001 n/a
Notes:
(1) J2000 is used for the "center" location which is in contradiction
to the rest of the packets in the system. This deviation from standard practice
was an oversight on my part.
(2) J2000 is used for both the "center of the IPN annulus" location
and for the "maximum probability" location. This "center of the annulus"
is not really the same kind of entity as the "center of burst" locations
in the rest of the GCN packets. However, the "max prob" is essentially
the same kind of entity as the "center of burst" locations
in the rest of the GCN packets. This deviation from standard practice
was an oversight on my part.
(3) J2000 is used for the "1,2,3-sigma" locations along the IPN segment
(which is the closest matchup to the "corners of a box" locations
of the other Notices types).
(4) J2000 is used for all the GRB_COUNTERPART, AAVSO and MILAGRO RA,Dec positions
because that is the new standard epoch being used. The switch from Current
to J2000 is being motivated by the Swift mission.
(5) J2000 is used for all the Swift and AGILE RA,Dec positions/pointings/etc
because that is the native epoch used by the mission, and if I converted it
back to Current epoch to be consistant with all the prior GCN packets contents
then the conversion would introduce errors comparable to the uncertainties
in the NFI-based positions (especially the UVOT positions which are 0.3arcsec).
(6) J2000 is used for all the AGILE, FERMI, MAXI, etc RA,Dec positions/pointings/etc,
because that is the new standard epoch being used within GCN, and it is the
native epoch used in those missions/instruments.
(7) The Initial/Starting RA,Dec Pointing Direction is quantized at 0.0001 deg,
but the 29 RA,Dec values into the future are quantized at 0.1 deg.
(8) The RA,Dec values for this s/c pointing direction are stored in slots 14 and 15;
not in the standard "center" locations of 7 and 8. The values are also J2000 epoch
which is non-standard for the source-position-containing INTEGRAL notice types
(which was Current epoch of that beginning era of GCN).
(9) The RA,Dec values for the current AGILE s/c pointing direction.
(10) The RA,Dec values for the current CALET s/c pointing direction.
Return to GCN/TAN homepage.
This file was last modified on 30-JAN-22.