- Timestamp:
- 01/30/05 10:44:32 (20 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/MagicSoft/GRB-Proposal/Monitor.tex
r6120 r6123 86 86 \end{itemize} 87 87 88 At the moment {\it arehucas} informs the shift crew about the alert and undergo88 At the moment {\it arehucas} informs the shift crew about the alert and takes 89 89 further steps only in case of red alerts. In this case a pop-up window 90 90 appears with all the alert information received by the burst monitor. 91 91 The operator has to confirm the notice by closing the pop-up window. 92 92 He can decide to stop the current scheduled observation and to point the GRB. 93 A new button in the CC will be displayed and allows to point the t he telescope to93 A new button in the CC will be displayed and allows to point the telescope to 94 94 the GRB coordinates by pushing it. 95 95 96 96 \subsection{GRB archive and emails to the GRB-mailing list} 97 97 98 In case of an alert , even if it did not contain the necessary coordinates,the99 information s are translated into ''human language'' and stored intoASCII files.100 In the same time an e-mail is sendto the MAGIC GRB-mailing list.98 In case of an alert -- even if it did not contain the necessary coordinates -- the 99 information is translated into ''human language'' and stored in ASCII files. 100 At the same time an e-mail is sent to the MAGIC GRB-mailing list. 101 101 102 102 \subsection{The GRB web page} 103 103 104 The status of the GRB Alert System and relevant informations from the last105 alert are displayed on a separate web page. The page is hosted onthe web server in La Palma.104 The status of the GRB Alert System and relevant informations about the lastest 105 alerts are displayed on a separate web page. The page is hosted at the web server in La Palma. 106 106 The address is the following:\\ 107 107 108 108 \qquad \qquad http://www.magic.iac.es/site/grbm/\\ 109 109 110 The web page automatically updates itselfevery 10 seconds. In this way111 the status of the Burst Alarm System can be checked from everywhere.110 The web page updates itself automatically every 10 seconds. In this way 111 the status of the Burst Alarm System can be checked from outside. 112 112 113 113 \subsection{The acoustic alert} … … 119 119 will be noticed about the alert situation. The signal will be on as long as 120 120 {\it gspot} stays in alarm state, and in any case for a minimum of 1 minute. 121 This device will keep also a display where to fast check the status 122 of the system and of the alert. 121 This device will keep also a display to check the status of the system and the alert. 123 122 124 123 \subsection{Alerts received until now} 125 124 126 Since July, 15th 2004 {\it gspot} has been working stable. 127 It received from HETE-2 and INTEGRAL about 100 alerts, most of them without coordinates. 128 More precisely only 20 of them contained GRB's coordinates. Time delays 129 were in most cases very large - in the order of of several minutes or even 130 tens of minutes. In the beginning the Burst Monitor contained some bugs so that we can not 131 rely on the alerts until November last year. Since the bugs were fixed we got only one red alert. 132 This alert came from INTEGRAL with a delay of 71 seconds, it happened 133 on December 19th at 1:44 am and the GRB zenith angle was $\sim 60^\circ$. It is a pity that the weather 125 Since July, 15th 2004 {\it gspot} has been working stably at La Palma. 126 It received about 100 alerts from HETE-2 and INTEGRAL, out of which 127 only 20 contained GRB's coordinates. Time delays 128 were of very the order of of several minutes or even 129 tens of minutes in most cases. The Burst Monitor can be considered bug-free since 130 November 2004. Since all bugs were fixed we received only one red alert from INTEGRAL on December 19th at 1:44 am 131 with a delay of 71 seconds. The GRB had a zenith angle of $\sim 60^\circ$. It is a pity that the weather 134 132 conditions were very bad during this night. 135 133 136 137 \subsection{Tasks to be arranged} 134 \subsection{Procedure to be defined} 138 135 139 136 The Burst Alarm System is currently able to provide the minimum 140 features needed to point and to observe a GRB. Anywayseveral141 things must be defined in order to improve our efficiency137 features needed to point and to observe a GRB. However, several 138 procedures must be defined in order to improve our efficiency 142 139 to point and observe GRBs. 143 140 144 141 \begin{itemize} 145 142 \item {\bf Yellow Alarm strategy} 146 First of all the strategy to follow in case of a yellow 147 alarm, i.e. in case of a not observable GRB, is not defined yet. 143 The strategy to follow a {\bf Yellow Alarm} is not defined yet. 148 144 In such a case the CC does not undertake any steps, 149 145 except confirming the alarm notice to the Burst Monitor. We do not 150 146 calculate if and when the GRB will become observable. 151 147 It would make sense to check if during the period of 5 hours we could point to the burst. 152 Then the Alarm System would change to{\bf Red Alarm State}148 Then, the Alarm System would change to the {\bf Red Alarm State} 153 149 at that time and allow the observation. 154 150 155 \item {\bf sequence of alerts} 156 Another procedure that needs to be defined is how to deal with new alerts 157 that are distributed during the time that {\it gspot} stands 158 in alarm state. The status of the system now is that {\it gspot} 151 \item {\bf Sequence of alerts} 152 How to deal with new alerts that are distributed during the time 153 that {\it gspot} is in alarm state. Currently, {\it gspot} 159 154 locks its alert status until it exits 160 the alarm state. This feature was implemented in order not to 161 loose GRB informations due to nasty events. 162 Such situation can appear ONLY when the CC is switched off so 163 that it cannot receive the alert. Indeed such situation can 164 occur when more than one alert happens in the late afternoon or 165 in the 5 hours before the beginning of the night-shift. 155 the alarm state. 156 This feature was implemented in order not to 157 loose any GRB information. 158 Such a situation can occur when the CC is switched off and thus 159 cannot receive the alert and if more than one alert happens 160 in the late afternoon or in the 5 hours before the beginning 161 of the night-shift. 166 162 In such a case we propose 167 to implement into {\it gspot} a listin which every168 item is a GRB's alert thatexpires after:163 to implement a list of the available GRB alerts into {\it gspot} in which every 164 item expires after: 169 165 170 166 \begin{itemize} 171 \item having been noticed tothe CC;167 \item having been noticed by the CC; 172 168 \item the canonical 5 hours. 173 169 \end{itemize} 174 170 175 If more than one alert is present in the list then the program 176 gives a mark to the GRB based on the total time of observability 177 within the canonical 5 hours, on the intensity of the 178 burst itself and on the time to wait to get the GRB observable. 179 Such a mark should reflect our estimation in the chances that 180 we have to observe that GRB. 181 The GRB with the highest mark will be noticed to the Central Control. 171 If more than one alert is present in the list, the program 172 gives a marker to the prioritary GRB -- a decision based on the 173 total time of observability within the canonical 5 hours, 174 on the intensity of the burst and on the time until the GRB becomes observable. 175 Such a marker should reflect our estimation of the chances to observe the GRB. 176 The GRB with the highest marker will be noticed to the Central Control. 182 177 183 178 \end{itemize}
Note:
See TracChangeset
for help on using the changeset viewer.