This document details 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.


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

When do you want your observations scheduled?

Day or night observations?

Commensal observing:

If your observations need to be scheduled around some other instrument (GMRT, Parkes, etc.), then your proposal needs to state:

Observation ordering

What order would you like individual observations (different sources, frequencies, etc.) taken in? Does it matter?

Suppose you want four hours, on each of 5 sources, at each of three frequencies, and there are 6 hours available per night. What ordering suits your science better for the 60 hours of observations? Eg:

Things to consider:

Frequency Channels

MWA observations use an arbitrary set of 24 ‘coarse channels’ numbered from 0-255, where each channel is 1.28 MHz wide. The centre frequency of each coarse channel is 1.28 MHz multiplied by the channel number. We carry out morning and evening calibrator observations every night, for eight commonly used channel sets:

Decide whether you can use one of these eight frequently-used channel sets for your observation Using one of the above channel sets means that:

If you’d prefer to use a unique channel set, mention that in the proposal. That way I won’t waste time by asking if you want to use a GLEAM band, for example. Also, if you need precise limits for frequency, mention that in the proposal, so they don’t get missed by rounding to the nearest 1.28 MHz wide channel, or better yet, specify the exact channel numbers you want.


What I need to see in part C, at a glance (ideally in a table):

What you need to remember: