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 ce