Transient Astronomy - VOEvent Receiver Operation and Testing

Once you have set up the VOEvent Receiver, simply starting it up will enable it. The Receiver requires the Scheduler to be running, but the dispatcher does not have to be enabled. Obviously, if the dispatcher isn't enabled, no observing resulting from incoming VOEvents can take place. Once configured and tested (see below), the recover and alerter are "hands-off" systems. Simply starting up the VOEvent Receiver is enough to enable all of the receiver and alerter functions.

Incoming Event Capture

The default configuration of the VOEvent Receiver specifies a "pre-patcher" script that isn't a pre-patcher; it saves copies of every VOEvent received, regardless of whether they are valid XML or have been passed by the interest filter. Every message that arrives from the VOEvent network goes to the pre-patcher, and this to this script. Again, this is the default setting for the Pre-Patcher in the receiver's configuration.

Saved VOEvent messages are put into a hierarchy of folders under My Documents\ACP Astronomy\VOEvent Archive. Below this, folders are created using the VOEvent message IVORN paths. This keeps the messages organized corresponding to the path part of the IVORN.

Using the Test Event Generators

The VOEvent Receiver has a Generate Test Event menu with which you can simulate the arrival of a VOEvent of the desired type). Using a test event template (which you can customize), a VOEvent message is generated and fed into the receiver, which acts just like it received a real VOEvent message of that type. Use this to verify that your observatory operates properly and acquires the data for the event.

If you have the Alerter enabled, completion of observing caused by a test event will cause a follow up VOEvent to be sent.

  While testing, be absolutely certain that you have the Alerter set to Disabled or Test mode, not Live mode! This prevents "live" VOEvents resulting from test VOEvent observations to be sent to the worldwide VOEvent network! Test mode is fine, no one (else) will pay attention to your outgoing test follow up events.

For each event type there are three timing choices:

• Now and observable: The message is time stamped for the current time, and the target is nearly at the meridian right now. This is the most common mode, as it allows your system to immediately start observing the target.
• Now but too low: The message is time stamped for the current time, but the target is 5 degrees below the minimum altitude considered "observable" by the Scheduler (which uses ACP's horizon settings). This tests the system's response to a VOEvent which may become observable soon.
• 2 hours old: The message is time stamped for a time 2 hours in the past, but the target is observable now. This tests the system's response to an "old" alert.