This page is an overview of the real-time MWAX beamformer - for more technical details and development notes, etc, see:

Overview for users during testing and the 2026A semester

The MWAX beamformer runs instead of the MWAX correlator and voltage capture system, and rather than producing visibility files or raw voltage data from the entire array, it captures an (optional) incoherent beam as a ‘Stokes I Filterbank’ file for each coarse channel, as well as a few (less than 10, exact number to be determined) coherent voltage beams saved in VDIF format (one VDIF file and one header file, per beam, per observation, per coarse channel).

Each voltage beam can have its own RA/Dec coordinates on the sky, tracked through the entire observation, but as for any other MWA observation, the primary beam - the pointing direction of the analogue beamformers on each tile - stays fixed for the duration of each individual MWA observation. Each observation has a primary beam pointing chosen to put the desired target coordinates in the middle of the primary beam at the midpoint of the observation duration. This means the phase centre will drift towards, through, and away from the centre of the primary beam over the course of every observation. Usually, any observing times are split into ‘sub-observations’, typically 296 seconds long, so that each (sub-)observation has the phase centre close to the primary beam centre for the entire duration.

At the start of observing a new target (often involving a new set of coarse channels in the receiver, or a new analogue attenuation setting), around 4 seconds of data should be discarded, while the hardware was changing state. Any subsequent sub-observation doesn’t need many hardware changes - each will have its own ‘observation ID’ (start time in GPS seconds), and follow its predecessor without gaps in the data. As a user, what you will see is a short period of bad data at the start of each sub-observation, where the analogue beamformer is changing state to a new position on the sky, and the new voltage beam data will suddenly be from a different location in that primary beam (but at the same RA/Dec on the sky). This bad data can be avoided by flagging the first 0.1-0.3 seconds of data after each sub-observation start time (each ‘obsid’).

Voltage beams are currently all saved at 1.28 million samples per second, with no time or frequency averaging - more flexibility will be added in the future. At this stage, cross-polarisation terms in the output files are not being computed - this will also be added in the future.

When requesting real-time beamformer observations, it’s up to the user to decide:

• Whether they want an incoherent beam to be saved along with any coherent beams.

• Whether and how to use multiple coherent beams in each observation, or take separate observations of each target, each using a single voltage beam. This will depend on the size of the primary MWA beam at the desired coarse channels, the separation of the sources on the sky, and whether concurrent observations are needed to compare timing, for example. Note that the nominal ‘pointing direction’ of the telescope does NOT need to be the target of any coherent beams, you could pick a position mid-way between two target sources.

• Whether and how to split your total observation time on each target into sub-observations - this will be a trade-off between S/N loss when any of the voltage beam targets are near the edge of the primary beam, and any consequences from the repointing glitches. The more widely spaced multiple simultaneous beams are on the sky, the more often the primary beam will need to be repointed.

These decisions are in addition to the usual MWA observation settings that apply to the entire observation:

• Subset of tiles to be used (eg, p2_compact, p1-extended, p1+hexes, 256T, etc). At some point in the future, you will be able to define multiple beams in the same observation with different tile subsets, but at his point, all voltage beams in an observation must use the same tile set.

• Coarse channels to be used (24 contiguous channels, picked fence, etc).

• Any other constraints (dates, times, elevations, etc).

Scheduling

The current beamformer runs as an entirely different set of processes on the 24 MWAX boxes doing processing on site. Changing between critically sampled correlator, oversampled correlator, and voltage beamformer can be scheduled (with special ‘CORR_MODE_CHANGE’ observations), but each change involves 5-10 minutes of downtime during which time the telescope is unusable. This makes triggering beamformer observations impossible, as well as interrupting beamformer observations for a triggered correlator observation.

Future Plans

These features will (probably) not be available for the 2026A semester, but are currently in development:

• Instantaneous switching between correlator and beamformer observations.

• Simultaneous correlation and voltage beamforming - with a smaller number of available voltage beams due to limited GPU resources.

• Choice of tileset for each voltage beam, eg just compact tiles for a wider beam, and/or all tiles for a tight beam.

• Oversampled voltage beamforming - currently the code only handles critically sampled data.

• Individual time and frequency averaging settings for each beam.

• Multiple primary beam subarrays, each with one or more voltage beams, allowing widely separated targets to be taken in the same observation - eg, some tiles on a reference pulsar and the rest on a fainter target.