...

This document describe how to plan and describe the technical aspects of an MWA observing proposal ('Part C'), as written by the person who schedules your observations. It does not describe the science justification needed to get your proposal accepted, only the technical requirements that need to be included so we can schedule your observations and get the results you want, if it ends up being accepted.

Triggered observations (eg, from VOEvents)

The MWA uses a two-level triggering system for real-time events that can interrupt current observations and schedule new ones to catch a transient with low (~10-20 second) latency. The triggering system is described detail in Hancock et. al, 2019. The observations generated in response to a trigger can be of any duration, but anything longer than 30 minutes will need strong justification in your proposal. Both normal correlator and voltage-capture observations can be generated by a trigger. Your code can also request that a calibrator observation be scheduled immediately after the target observations, and the calibrator can be specified, or chosen automatically. If the trigger occurs during the day, your code can request that the primary beam direction be automatically offset slightly, to put the target location slightly off-center, but with the Sun in a primary beam null, to keep it out of the side-lobes. Your event handler code can also interrupt observations that it has generated for a previous event - for example, if a new VOEvent arrives with an updated source position, you can interrupt your first triggered observation/s and replace them with ones with the updated position. 

If you're interested in a project that involves triggering MWA observations in real time, contact Andrew Williams for more details, including a template for the VOEvent handler function you'll need to write, to parse incoming VOEvents and send them to the telescope. The MWA can also trigger via pathways other than VOEvents from 4PiSky, but this would require whatever network configuration is required to allow the messages to be delivered to site (or generated by hardware on site), as well as custom code to handle the incoming message.

Plan for at least a few months of testing and parameter tuning before any new trigger handler goes 'live' and actually interrupts the telescope.

Sources

Make it VERY clear what your sources are, and where they are in the sky:

...