Pointing updates bug

[PaulHancock]

An issue was identified with trigger GCN575108474. The initial observations were interrupted with a new set of coordinates as further information became available. This is normal. The problem is that the new position information was so close to the original value that when the current observation was interrupted and replaced with a new one, the new observation was using the same sweet spot pointing and frequency. This is an unnecessary step, and has the downside of introducing gaps into the observations as the telescope stops one obs and starts another.

Recommend: When updating the pointing direction for an observation that is in progress, the update is ignored if it would not change the pointing direction by more than some given radius (~5deg or so).

[PaulHancock]

Andrews email about this trigger with more details:

The actual alert handler:

-Received the first alert at 08:21:35.155 UT (event
GBM_Flt_Pos_2019-03-24T08:21:09.63_575108474_49-361).

-triggered on the first alert at 08:21:36.599 UT at (RA 82.8333, Dec
9.05, err 23.9333). From timestamp in the event name, that seems to
imply a 25 second delay between the event time, and when we received the
alert?

-Generated observations starting at 08:21:50.0, which is a little under
15 seconds after the trigger was received, or 13 seconds after the
trigger was sent to the back-end handler.

-triggered with an updated position at 08:21:48.392 UT, replacing the
previously scheduled observations with the new coordinates of (RA
84.5167, Dec 14.15, err 8.1).

-triggered with an updated position at 08:21:58.771 UT, replacing the
previously scheduled observations with the new coordinates of (RA 79.77,
Dec 13.4, err 9.99).

-triggered with an updated position at 08:30:22.743, replacing the
previously scheduled observations with the new coordinates of (RA 81.03,
Dec 12.02, err 1.0).

It looks like everything worked exactly as designed, although in this
case, the original position was close enough to the final one that we
wouldn't have been too far off the target.

What I did notice was that the first re-pointing with an updated
position truncated the current observation to only 8 seconds long, then
generated new observations with an RA/Dec so close to the original that
it actually used the same sweet-spot pointing.

It might be an idea to increase the threshold a little bit, so that it
doesn't interrupt and re-generate observations unless the new pointing
is a little further away from the current one.