Work in progress.
What do I have to do to join the GCN/TAN system? ...to get notified of a new GRB/Transient?
Go see the Open Invitation page.
Why did my Socket-method packet arrive at T+10sec when I was lead to believe that the GCN/TAN-system response time was 3.5-5.5 seconds?
explain the trig-to-enough (searching for enough initial counts) scanning. it looks for up to 10 sec after the trigger to find a 1-sec interval with enough source-counts above background to be able to make a meaningful calculation/solution.
the above was in the BATSE days. now we are in the Swift days; the delay interval can be as short as 7+1sec out to as long as 35+1 sec. with the typcical being 14or21+1 sec.
Why didn't I get a notice for GRB NNNNNN?
mention the various filters and how they reject certain notices to a given site. mention the source dis/enable flags/filters. also mention that one occaisions (rare occaisions) i have been know to make a mistake in the filtering coding or a mistake in the site's configuation (that is why it is important for them to check their configurations closely).
Why is there a newline character at the end of a Socket-method packet?
The "pkt_term" slot is the packet termination character for the (binary form of the) socket distribution method. 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 (the very first socket-based customer; early 1990's). 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 so it propogates to each new Notice Type added to GCN/TAN). And it still does function as a fixed-content termination value for validity checking.
Why do the socket-packet serial numbers start over from 0 evern now and then?
This in only noticable to the socket-based customers (ie their socket conenction breaks and restarts).
Because I'm installing a new version of the GCN software.
In the early-mid 90's this would happen every few days -- the softwsre was evolving quickly.
But since then, long stretches (5-20 days) go between software additions/enhancements.
I also restart the software to do a clean reloading of the sites config file
to handle sites/people's config changes..
About half of these instances, I do the kill/restart during times when HETE, or Swift, or Fermi is in the SAA (and they are not able to trigger on GRBs).
Why are the roundtrip travel times for GRB packets longer than those for the Imalive packets?
It is not real -- they have the same intrinsic travel times, it's just that the program is forced (due to minimizing the delay times for the e-mail recipients) to measure the times differently.
Where can I get the T90 times for bursts?
In the "Cmnt" column of the "Recent Triggers web page".
What is the purpose of the Test Notices?
Sites can exercise their systems/instruments (an end-to-end test). Their ops programs can treat these Test Notices exactly like real GRB notices (but they always have a Type ID that is distinguishable from the real notices and the locations and times are knowable).
Why are some Test Notices generated/treated differently?
Not all TestNotices have a different Type ID.
The INTEGRAL Test Notices have the same ID number as the real Notices.
This is because the INTEGRAL Team chose to generate their own Test Notices
(the Test Notice for all the other missions are generated within GCN).
The chose to keep the same ID number and use an internal flag to distinguish
Test from Real.
The SNEWS_EVENT Notices are so rare (many years apart), it was felt to keep
the same ID Number so that there would be absolutely no difference in the distribution
or processing a the recipient's end between the real and the test notices.
Given the rarity of the event, it would be unfortunate to discover a bug
in the processing of the real notices on the one time it was really needed.
What is the deal with different RA,Dec Epochs used the various pager formats?
Pager: The RA,Dec are Current epoch.
Short Pager: Epoch 1950.
Subject-only: Current Epoch.
SubjHHMM-only: J2000 Epoch.
These are the 4 "pager" formats. Unlike the full-email which has lots
of space (character count) to display all 3 epochs, the pager formats
are designed to fit the limited character counts of the pager-based technology (mid to late 1990's).
And there are 4 different pager formats because people used different service providers
that have different char-count limitations.
And as each new pager format was added (per specific new GCN/TAN client),
it was made with the epoch that new-client wanted.
And because character count was so precious (back then), there was not even space in the message to list which epoch was being communicated.
The recipinet just had to remember which epoch was for his particular pager format.
At the time, I thought about making the epoch a client-by-client selection (ie another column in the sites.cfg file), but that tripled the amount of scratch-files and (some factor of processing time, and some factor of human and testing coding time), so I decided not to impliment that particular flexibility. Now, the 4 formats are cast in concrete. And as the years passed, the smart-phones have essentially replaced the pagers, and smart phones do not have the char-count limitations of the pagers, so there is little current use of the pager-based formats.
Why does the e-mail come from a person called "vxw"?
The custom front-end computers that process the raw telemetry stream from CGRO mission
are programmed using the VxWorks Inc. software development product.
To use this product within the Goddard PACOR division,
it was necessary to create a psuedo-person account under the name of "vxw".
The programs must also be run under this account, hense all the e-mail comes from this "vxw" account.
As an attempt to let people know "who" this e-mail is actually from,
we added the string "(BACODINE)" to the Fullname field in the "vxw" entry in the
/etc/passwd file.
In the modern era, BACODINE has changed it's name to GCN/TAN
and the computer(s) have moved from the PACOR division to the LHEA division,
but the "vxw" psuedo-person account name was preserved
so as to not disrupt any email filering rules people may have set up
to auto-process these incoming emails.
Yes, BACODINE does have a sort of pharmaceutical sound to it. I was being pressed to give the project a name so that it could be written up in some Goddard-internal monthly status reports. When I listed the words "BATSE", "coordinates", "distribution", and then "network"; I realized that BCDN could not be pronounced because it had no vowels. So then I started out by doubling up the letters from BATSE (ie BACDN), but that still was not pronouncable. Then came a doubling from coordinates, and then it immediately leaped to using the first two letters from the four words that had some relation to what was actually going on in the project("BAtse COordinates DIstribution NEtwork"). I realize that this is not the standard convention for building an acronym, but I don' think that is important. ;-)
What does MAXBC stand for?
OLD BATSE THING: This is an acronym for the "MAXimum Burst Channels". The BATSE on-board flight software monitors the rates in the 8 LADs in the C1 DISCLA channel and the C2 and C3 DISCLA channels (C2 and C3 are the "burst channels") for up to 10 minutes after a trigger looking for and recording the maximum (peak) values. After the 10 minutes, these 16 rates are telemetered to the ground. GCN/TAN uses them to produce the MAXBC GRB locations.
What are the 16 numbers at the end of the MAXBC Notice?
Those are the peak count rates in a 64-msec interval for the 8 LADs in the lower C1 channel and the "burst channels".
Why does the MAXBC Intensity differ from the Original Notice Intensity?
OLD BATSE THING: Can be higher (because of the 64msec vs 1024msec sampling of the rates) and it can be lower because the Original Notice can be from two 1-sec samples instead of the normalized single 1-sec sample scale. And of course the Final Notices integrate the light curve up for 2-32 sec after the initial trigger, so they list a "fluence" instead of an "intensity".
Why does the Trigger_type Identification sometimes change between the type listed in the Original Notice and the Final Notice?
OLD BATSE THING: The algorithm used int he program to determine the trigger makes tests in a 5-dimensional phase space using the count rates available at the time of each notice. The counts rates (actually integrated fluences) are different for the Original and Final Notices, so the result of the tests can be different. The algorith is about 98% accurate so it will be wrong 2% of the time.