1. Introduction

The MWA is capable of performing triggered observations. This facilitates automated and rapid follow-up of astronomical transients and other time-critical space-based events. It is possible to perform rapid-response observations using the standard MWAX correlator and the associated Voltage Capture System (VCS) and Voltage Buffer.

Two possible pathways access the back-end of the MWA triggering services, which schedule and perform the rapid-response observations. The user can directly send triggers to MWA (recommended when requiring the lowest latencies) or respond to public event streams using the TRACE-T web application. The back-end and original MWA triggering front-end system are described in Hancock et a. (2019).

Rapid-response observing requests sent to MWA will only override the schedule if the target is above the horizon. If the scheduled programs are interruptable, the trigger overrides the observing schedule for the requested length of observing time.

1.1 Triggering with the MWAX standard correlator

• All triggered observations are pointed observations (not drift scans). TRACE-T automatically requests that the observer-specified observation length be divided into snapshots of 120 seconds (this is the default for the ‘exptime’ parameter for MWAX standard correlator observations in the Triggering web services). This ensures the target stays near the centre of the primary beam.

• If the trigger occurs during the day, the MWA triggering service engages the Sun avoidance subroutine, which optimises for the best pointing direction that places the Sun into a primary beam null. Note that this can add up to 10 seconds to the telescope response time (see Hancock et al. 2019 for details).

1.2 Triggering with the Voltage Capture System

• For MWAX Voltage Capture System (VCS) triggers, TRACE-T automatically requests that the observer-specified observation length be divided into 5-minute files (this is the default for the ‘exptime’ parameter for MWAX VCS observations in the Triggering web services), which makes data processing more manageable.

1.3 Triggering with the Voltage Buffers

• The Voltage Buffers can provide up to 4 minutes of voltage data before the trigger from wherever the telescope was pointed during that period.

• The Voltage Buffer data is saved with the same observation ID(s) and project ID(s) as what was scheduled before the trigger.

• If the Voltage Buffer trigger is to be followed by further observations with the VCS, a second trigger request must be sent to the telescope simultaneously.

• Idle array configurations or shadowing for when the array is not in use can be requested in your observing proposal to give some control over the telescope pointing at the time of the buffer dump.

2. Getting Started

Step 1: Choose the triggering pathway

The next section outlines the two possible pathways. Choose one and set up the code.

Step 2: Act on events

Start a live instance of the chosen triggering pathway. Check if the code can listen to the correct alert streams and filter them correctly.

Most public alerts are sent via the General Coordinates Network (GCN), which is NASA’s Time Domain and Multimessenger Alert System. This service distributes transient alerts covering four different formats (JSON, VOEvent, Text, Binary) over the Kafka event streaming platform. NASA plans to migrate all alerts to JSON format, with all new facilities adopting this protocol. You can start streaming GCN Notices right now using this website.

Step 3: Set up a test account

Contact @Andrew Williams (Andrew.Williams@curtin.edu.au) to set up a test account, which enables the user to send real triggers to MWA without overriding the observing schedule. This will demonstrate how the telescope will respond to the triggering requests.

Step 4: Submit MWA proposal

Write an MWA proposal for the next observing semester. Make sure it outlines the science case for requiring rapid-response observations, including details on the interruptability of your program.

Step 5: Set up credentials

Once your proposal is approved by the TAC, you will be assigned a project code and password that will allow you to trigger rapid-response observations on MWA.

3. Triggering Pathways

3.1 Direct Triggering

Following the instructions on the Triggering web services page.

3.2 TRACE-T Web Application

TRACE-T is the Transient RApid-response using Coordinated Event Triggering software that enables MWA to trigger on General Coordiates Network (GCN) VOEvents (XML packets) sent over Kafka. It filters these alerts based on user-defined logic and then sends observation requests to MWA. Note that the future version of TRACE-T will also be able to ingest JSON packets as well as convert VOEvents to JSON format.

With TRACE-T, the user has full oversight of their event type of interest, the observing request sent to the target telescope (MWA), and whether or not the observing request was successful. TRACE-T can also send email, SMS and phone call alerts when an observation is triggered.

3.2.1 TRACE-T Version 1 - Current version

The code can be found at: https://github.com/ADACS-Australia/TraceT

The documentation can be found at: https://tracet.readthedocs.io/en/latest/

The current version of TRACE-T was written by the Australian Data and Computing Services (ADACS), which is based on the original front-end systems described in Hancock et al. (2019) and Anderson et al. (2021a). Please reference both publications if you use this software.

Functionality

The current TRACE-T functionality was implemented based on the interests of the MWA collaboration. It ingests VOEvents sent by the Neil Gehrels Swift Observatory, the Fermi Gamma-ray Space Telescope, LIGO-Virgo-Kagra (LVK) and Monitor of All-sky X-ray Image (MAXI) to perform triggered observations on gamma-ray bursts (GRBs), gravitational wave events (GWs), and flare stars. When setting up a triggering program, the user selects the transient class or event type (GRB, GW or flare star) and then chooses the event telescope (Swift, Fermi, LVK or MAXI). The specific GCN event filtering applied to the three transient classes are described in Section 3.2.2.

TRACE-T can send triggered observation requests to both the MWA and the Australia Telescope Compact Array (ATCA; see Anderson et al. 2021b). Both require an accepted proposal and access credentials supplied by the respective observatory.

Credentials

The Admin settings on the TRACE-T web application allow the user to set the password associated with the project ID that provides the necessary credentials for your specific observing program to override MWA.

Observational set-up

Once your TRACE-T web application is receiving transient alerts from GCN over Kafka, you can then set up your observations. On the TRACE-T webpage, you can select “New Proposal”. In this context, the proposal refers to your project observation set-up. In the drop-down boxes, you must make the following selections

• Your target source class and event telescope (Swift, Fermi, LVK or MAXI).

• Your target telescope (MWA or ATCA)

• Declination ranges of limits (up to two can be specified)

• Trigger timescales (dependent on the event telescope - see specific recommendations for Swift below).

• Select your project code, which you set up in the TRACE-T Admin settings described under Credentials.

• MWA-specific options will be displayed, including your observing frequency and integration time. These values should reflect your requests in your MWA observing proposal.

• Specify the minimum position offset that would trigger a repointing update. Repointing will only occur up until the maximum requested integration time.

Latencies

Important note: If running multiple triggering programs from your TRACE-T instance, each ingested transient event notice will be filtered by each program individually (in series) rather than simultaneously, taking 2-5 seconds each. Each triggering program allows you to specify a priority, which will ensure that those requiring the lowest latencies are processed first.

A detailed breakdown of the latencies associated with MWA triggering is provided in Section 3.1.1. of Hancock et al. (2019). The key latencies to be aware of are the following:

• The theoretical hardware minimum for a triggered MWA observation to begin is 8 seconds.

• The event filtering conducted by TRACE-T and web back-end systems provides an additional 2 seconds of latency.

• If the trigger occurs during the day, an additional 10 seconds of latency is accrued by the Sun-avoidance algorithm.

Latency updates that differ from Hancock et al. (2019) due to system upgrades and following the installation of MWAX include:

• If requesting a calibrator observation to take place following the trigger, the back-end now calculates the nearest calibrator after scheduling the triggered observation of the transient.

See Hancock et al. (2019), Anderson et al. (2021b), Tian et al. (2022a), Xu et al. (2025) for a breakdown of latencies associated with triggered observations of gamma-ray bursts (GRBs) with MWA. This demonstrates that in practice, the MWA response time is usually between 30-90 seconds. Note that most of these GRBs observations were triggered before the TRACE-T program prioritisation upgrade described above.

3.2.2 Object-specific filtering

Gamma-ray Bursts (GRBs)

The current version of TRACE-T can trigger on GRBs detected by The Neil Gehrels Swift Observatory and the Fermi Gamma-ray Space Telescope. If you would like to trigger on both Swift and Fermi GRBs then you will need to create two separate TRACE-T Proposals. You can use the same Project ID and password.

TRACE-T has inbuilt alert filtering on GRBs from both instruments. The web application logs and keeps track of all alerts associated with a given event ID from the event telescope (either Swift or Fermi). The classification of a GRB as “long” or “short” (Kouveliotou et al. 1993) is not provided as part of the alert notices due to the challenges associated with automated characterisation. However, both Swift and Fermi alerts provided the time in seconds it takes the gamma-ray signal to reach a triggering threshold of the instrument. TRACE-T allows the user to filter on this timescale.

The TRACE-T internal logic assumes that the most recent notice has the most up-to-date positional information, which may result in a telescope pointing update. This is specifically important for Fermi-detected GRBs as they can have pointing updates of tens to hundreds of degrees. TRACE-T repointing decisions also consider the alert type as only some subsequent alerts have higher positional reliability. The same alert type will cause a position update check but those of lower reliability cannot update positions previously generated from a higher priority alert. The specific Swift and Fermi alert type hierarchies are defined below (see also Hancock et al. 2019).

Swift alert hierarchy and filtering

For each Swift-detected GRB, TRACE-T makes decisions based on the following Swift VOEvent message alert types:

Initial Swift Burst Alert Telescope (BAT) GRB position: SWIFT_BAT_GRB_POS_ACK
Swift X-ray Telescope (XRT) position of the X-ray afterglow: SWIFT_XRT_POSITION
Swift Ultraviolet/Optical Telescope (UVOT) position of the optical afterglow: SWIFT_UVOT_POS

We ascribe a positional reliability hierarchy to these Swift alerts, with the highest to lowest reliability being: SWIFT_UVOT_POS > SWIFT_XRT_POSITION > SWIFT_BAT_GRB_POS_ACK.

The “Integ_Time” keyword in the SWIFT_BAT_GRB_POS_ACK notice is the length of time in seconds it takes the gamma-ray signal to reach the instrument threshold to register a new GRB detection. TRACE-T can use this value as a proxy for identifying those events more likely to be a short GRB, for which this value should always be <2 s.

If trying to filter for Swift-detected short GRBs, the best time range to filter for is:

If trying to filter for Swift-detection long GRBs, the best time range to filter for is:

Fermi alert triggering hierarchy and filtering

For each Fermi-detected GRB, TRACE-T makes decisions based on the following Fermi VOEvent message alert types:

Fermi Gamma-ray Burst Monitor (GBM) flight localisation and classification: FERMI_GBM_FLT_POS
Fermi GBM updated ground localisation: FERMI_GBM_GND_POS
Fermi GBM final localisation: FERMI_GBM_FIN_POS

TRACE-T will only consider those events provided the alert parameter “MOST_LIKELY” is >50% chance of being a GRB.

We ascribe a positional reliability hierarchy to these Fermi alerts, with the highest to lowest reliability being: FERMI_GBM_FIN_POS > FERMI_GBM_GND_POS > FERMI_GBM_FLT_POS.

See the above suggestions in the Swift alert filtering section for some ideas of how to filter for long vs short GRBs. Note that later Fermi alerts sometimes classify events as long/short under a “COMMENTS” keyword.

Gravitational Wave events (GWs)

TRACE-T currently has a bespoke set-up for targeting gravitational wave events due to the large positional uncertainty from LIGO-Virgo-KAGRA.

See Tian et al. (2023) for further details on the observing mode and strategy.

Flare Stars

Only this list of flare stars will be triggered on

In Progress

A more user-friendly version of TRACE-T is now being developed by ADACS. This next iteration will allow for more free-form triggering on any transient event broadcast via NASA GCN. Upgrades will include: