This manual describes how to apply for observing time, make an observing schedule and carry out observations with the 64m CSIRO Parkes Radio Telescope (hereafter, called `Parkes’). This manual is a reference and you should not feel that you must read all of it in order to use Parkes. Chapter 1 describes the telescope system, including the characteristics of the available receivers and backends. This information can be used before proposing to use the telescope, the procedure for which is also detailed in this chapter. Chapter 2 can be read after being given observing time on Parkes, as this chapter focuses on preparations needed to observe with Parkes. Chapter 3 is dedicated to observing procedures and systems and details how to actually do your observations. Chapter 4 walks you through processes that occur once your observations are over, such as accessing your data and reporting your experiences.
In 2019 April there was a major overhaul of this manual: the presentation of the document on the web and in print was improved, and the content was significantly updated. Copies of this manual and other ATNF documentation can be obtained from the ATNF webpages.
If you find that any part of Parkes doesn't work as described
in any of our documentation, please email the Parkes Users Guide
editorial team at
Comments on documentation are especially welcomed.
- 20 Jun 2020: Updated information on accessing Medusa from outside the ATNF/CSIRO network.
- 1st May 2020: Updated Medusa search mode coherent dedispersion and DM parameters. These were based on a subband level, but are now configurable at the target (source) level.
- 21st Apr 2020: Updated DHAGU screenshots to tie in with removal of AzEl offsets. Added Scan, ScanMap examples. Medusa tab in DHAGU explained, and update on Medusa commensal modes. Added in receiver characterization.
- 6th Apr 2020: Addition of commensal observing modes in DHAGU.
- 9th Mar 2020: Updated DHAGU descriptions, including new ScanMap implementation.
- 22nd Nov 2019: Transfered over to Docbook format.
Computer system names, e.g. joffrey
Software packages, e.g. psrcat
Software program, e.g.
Command example, e.g. $ df -h
Filename, or file content, e.g.
Program option, e.g.
Single parameter name, e.g.
Astronomy-related acronym, e.g. USB (upper sideband)
Non-astronomy-related acronym, e.g. USB (universal serial bus)
List of potential commands or parameters, e.g.
disable|enable. These might also be wrapped in curly brackets, e.g.
Table of Contents
- 1. The CSIRO Parkes Radio Telescope
- 1.1. The Australia Telescope National Facility
- 1.2. Overview of Parkes
- 1.3. Design and Operation of Parkes
- 1.4. Receiver Fleet
- 1.5. Signal Paths
- 1.6. Sensitivity and System Temperature
- 1.7. Backends and bandwidths
- 1.8. Observing Strategies
- 1.9. Additional Observing Considerations
- 1.10. Submitting a Proposal
- 2. Preparing your observations
- 2.1. Calibration
- 2.2. Injected Calibration
- 2.3. Calibration Sources
- 2.4. Scheduling Observations
- 2.4.1. Preparing a Parameter Set
- 2.4.2. Viewing and Saving the Parameter Set
- 2.4.3. Loading Saved Parameter Sets
- 2.4.4. Example Pulsar FOLD Parameter Set
- 2.4.5. Example Pulsar SEARCH Parameter Set
- 2.4.6. Example CONTINUUM (Spectral-line) Parmameter Set
- 2.4.7. Example SCANMAP CONTINUUM (Spectral-line) Parmameter Set
- 2.4.8. Example SCAN Parmameter Set
- 3. Observing with Parkes
- 3.1. Observer Training
- 3.2. Observing
- 3.3. Telescope Monitoring
- 3.4. Unattended Observing
- 3.5. Key contact numbers
- 4. After your observations
The Australia Telescope National Facility (ATNF) is managed as a National Facility by the Commonwealth Scientific and Industrial Research Organisation (CSIRO). Formerly part of the CSIRO Division of Radiophysics, it became a separate division in January 1989. The ATNF became a National Facility in April 1990. In December 2009, ATNF became part of a new Division, CSIRO Astronomy and Space Science (CASS), together with NASA Operations (including the Canberra Deep Space Communication Complex), and CSIRO Space Sciences and Technology. The Australia Telescope continues as a National Facility, providing world-class observing facilities for astronomers at Australian and overseas institutions.
The majority of ATNF staff are located at the headquarters in Marsfield, a suburb of Sydney in New South Wales – although Marsfield is sometimes referred to as ‘Epping’, a larger, neighbouring suburb. A growing number of ATNF staff are also located in the Perth suburb of Kensington, Western Australia at the Australian Resources Research Centre (ARRC).
Besides the Parkes telescope, the ATNF operates the Australia Telescope Compact Array (ATCA) which is comprised of an array of six, 22-m antennas and is located in Narrabri, NSW. ATNF also is currently commissioning the Australian Square Kilometre Array Pathfinder (ASKAP). The telescope has been constructed by ATNF in Murchison, Western Australia, and is an array of thirty-six wide-field 12m antennas operating in the 0.7–1.8 GHz range. More details are available on the ASKAP project website. Additionally, the ATNF negotiates time with the CSIRO-administered 70-m and 34-m antennas at the Tidbinbilla Deep Space Tracking station outside Canberra. The ATNF telescopes are used together, in conjunction with the University of Tasmania telescopes at Hobart and Ceduna, as part of the Long Baseline Array for Very Long Baseline Interferometry (VLBI) observations.
The Parkes Observatory is located 415 m above sea level at Latitude -32.99839 South, Longitude 148.26352 East, 25 kilometres north of the town of Parkes which is approximately 365 kilometres west of Sydney. It is 6 kilometres off the Newell Highway, the main road from Parkes to Dubbo. The Shire has a population of 15,000 and the town a population of 10,000 and is in the middle of a rich sheep, wheat producing and mining area. Table 1.1 gives accurate site locations for Parkes in Cartesian coordinates and Table 1.2 lists Parkes’s geodetic coordinates in both WGS84 and AGD84/AHD systems. The Parkes position was derived from VLBI measurements on 2016-December-19. See the ATNF online appendix for more information on observatory coordinates and calculations.
Figure 1.1 shows a complete site overview of the CSIRO Parkes Radio Observatory. The Parkes site contains the 64-metre Radio Telescope, the 12-metre ASKAP prototype antenna, an administration building with offices, workshops and library, Visitors Discovery Centre and The Dish Cafe. In addition, there are numerous testing and monitoring facilities on site.
Table 1.1. Location of Parkes Radio Telescope in Cartesian coordinates.
|X(m)||e(X) (m/yr)||e(Y) (m/yr)||e(Y)||Z(m)||e(Z) (m/yr)|
Table 1.2. Geodetic coordinates of the Parkes Radio Telescope.
|Coordinate System||Longitude (deg)||Latitude (deg)||Longitude (DMS)||Latitude (DMS)||Spheroidal (m)|
|WGS84||148.2635101||-32.9984064||148 15 48.636||-32 59 54.263||410.80 m|
|AGD84||148.2623007||-32.9999629||391.52 m||148 15 44.283||-32 59 59.866|
Overview of the CSIRO Parkes Radio Observatory. The letters correspond to the following locations on site: a) Visitor car park b) Visitor Centre c) `The Dish’ cafe d) carpenter workshop e) welding hut and equipment shed f) mechanical and electrical workshop g) admin building (“Opera House”) h) generator hut i) receiver lab j) the tower k) staff and service road l) staff tea area and RFI lab (“the woolshed”) m) maser hut n) mobile interferometer (“kennedy antenna”) o) wind station and RFI reference (“Telstra tower”) p) 3.7m antenna q) RFI monitoring tower r) hot/cold testing s) 12m antenna (“ASKAP antenna”) t) Harold’s hut.
The observatory can be contacted at the following address:
Parkes Observatory 473 Telescope Road (or PO BOX 276) PARKES NSW 2870 Australia Switch:(02) 6861 1700 [International +61 2 6861 1700] Fax: (02) 6861 1730 [International +61 2 6861 1730]
Figure 1.2. Overview of the Parkes telescope tower. The letters correspond to the following: a) aerial/focus cabin b) feed legs c) lift leg d) vertex radiator e) counterweight f) azimuth track g) control tower.
The antenna has a paraboloid design with a 64-m diameter. The surface is high precision aluminium millimetre wavepanels to a diameter of 17-m (for operation to 43 GHz), then perforated aluminium plate out to 45-m, and rectangular galvanised steel 5/16-inch mesh for the remainder of the surface. The focal ratio is 0.41 for the full 64m surface, the focus being located 26-m above the centre.
The aerial cabin, which houses feeds and receiver equipment, is supported by a tripod. Access to the aerial cabin is either by the lift on one of the tripod legs (the “lift leg”) or by a ladder on one of the other legs. The feed platform translator, which can hold up to four receivers, at the base of the aerial cabin has up/down (focus), lateral and rotational movement. Figure 1.2 labels these and other commonly referenced parts of the telescope.
Further properties of the Radio Telescope are shown below.
Weight of counterweight: 475 tonnes Total weight of dish: 1,000 tonnes Surface area of reflecting mesh: 0.4 hectares (1 acre) Height of concrete tower: 10.7 m (35 ft) Height to centre of dish: 27.4 m (90 ft) Height to top of aerial cabin: 58.6 m (192 ft) Power of azimuth/zenith drives: 11kW (15 hp) Pointing accuracy: < arcsec Sky coverage: Az: 0-360 deg. El: 30.5 - 88.5 deg.
The dish may be operated between the Zenith angle software limits of 1.2 and 59.5 degrees. There are three hardware limits at Zenith angles less than 1.5 degrees, and also another three past 59.5 degrees. The dish can be “stowed” at a physical limit 30 minutes of arc beyond the Zenith. It is constrained in this position by a locking pin. Azimuth angle is measured as 0 degrees due north, increasing to the east.
The Ultra Wide-bandwidth Low (UWL) receiver system provides continuous frequency coverage from 704 - 4032 MHz. The feedhorn design is described in detail in Dunning et al. (2015), and the feed achieves a near constant beam width over a 6:1 bandwidth (note that the beam on the sky still scales with λ/D). Over the majority of the band, there is a system temperature of ~20 K and the system remains linear even in the presence of strong RFI.
For the first time at the Parkes telescope, the band is digitised in the focus cabin into three distinct bands (`low’, `mid’ and `high’). Each band is then passed to field programmable gate arrays (FPGAs) which are used to receive the digitised signal and produce a total of 26, 128 MHz subbands. The frequency range and corresponding sub-band number are given in Table 1.3 As of September 2019, the UWL filterbank is critically sampled, introducing roll-off at the edges of each sub-band. This will restrict the ability to study spectral lines +/- 5 MHz from the sub-band edges. This does not discount these frequencies, but observations will suffer lower than average sensitivity and there is the potential for aliasing if a source is particularly bright.
Table 1.3. Frequency coverage for each of the 26, 128-MHz sub-bands as processed by the FPGAs and referenced by the Medusa backend. The table also shows the breakdown into the three distinct digitised bands: low, mid and high.
|Low Band||Mid Band||High Band|
|Frequency Range (MHz)||Sub-band number||Frequency Range (MHz)||Sub-band number||Frequency Range (MHz)||Sub-band number|
Once the data has been packetised in the FPGAs, it is sent to the GPU correlator (or backend) called “Medusa”. At this point, Medusa carries out the astronomy processing including pulsar fold-mode (timing) observations, search mode and single-pulse observations as well as continuum/spectral line observations.
Table 1.4. Calibration information.
Normalized gain-elevation curves of the form:
For a complete description of the system installed on the Parkes telescope, as well as a summary of system temperature, beam efficiencies/FWHM and RFI across the observing band, see Hobbs et al. (2019).
The Parkes telescope is equipped with a sensitive 13 beam receiver operating at 20cm, and a 26 channel spectral line correlator (13 beams by 2 polarisations). The Multibeam system comprises 13 identical dual-linear feeds, each with cryogenically-cooled HEMT LNAs, covering a frequency range of 1230-1530 MHz. The FWHM of the center beam is 14.0 arcmin, beams 2-6 14.1 arcmin and beams 7-13 14.5 arcmin. The thirteen horns are disposed in a hexagonal pattern, with the inner and outer rings of beams having a radii 29.1 arcmin and 50.8 arcmin respectively. The receiver package has the ability to rotate to enable parallactic angle tracking. If rotated at an angle of 15 degrees to the scan direction, it presents a nearly uniformly spaced “comb” of beams spanning approximately 96 arcmins. Adjacent scans of 35 arcmins (0.583 degrees) thus have an approximately two- thirds overlap. The package can be rotated in feed angle up to -70 degrees and +83.75 from its neutral position; rotation is in a positive direction corresponds to increasing position angle on the sky, or anti-clockwise as shown below:
Further characterisation of the receiver can be found in the following: Calabretta, Staveley-Smith & Barnes (2014) Kalberla et al. (2010)
This is a dual package, with the upper frequncy range 12.0 - 12.8 GHz, and the lower 5.9 - 7.0 GHz. However, the upper frequency range is not operational. For the lower range, one of either of the LNAs is known to oscillate from time to time, but never both. This tends to settle down after the LNAs have been left on for some time.
Table 1.6. Calibration information.
Normalized gain-elevation curves of the form:
The following plots show the system and calibration temperature of the METH6 receiver (Kelvin). The Moon was used for the measurements, with correction for opacity, plus contributions from atmosphere and ground emission included.
This receiver has the capability to operate at S and X- band frequencies concurrently (2.2- 2.5 GHz and 8.1 - 8.9 GHz) or to solely observe at C-band (4.5 - 5.5 GHz). The C-band and X-band receivers in the AT Multi-band receivers also have quarter-wave plates ahead of the cal injection. This receiver is still scheduled on a needs basis for regular Parkes operation as well as for VLBI. The C band capabilities of this receiver are currently under investigation.
Table 1.8. Calibration information.
Normalized gain-elevation curves of the form:
The following plots show the system and calibration temperature of the ATPROTO receiver (Kelvin). The Moon was used for the measurements, with correction for opacity, plus contributions from atmosphere and ground emission included.
A receiver built to track NASA mars missions. The MARS (8.4 GHz; X–band) receiver has a built-in (non-removable) waveguide circular polariser also with cal injection between the polariser and OMT.
Table 1.10. Calibration information.
Normalized gain-elevation curves of the form:
The following plots show the system and calibration temperature of the MARS receiver (Kelvin). The Moon was used for the measurements, with correction for opacity, plus contributions from atmosphere and ground emission included.
A K-band receiver covering 16-26 GHz was delivered and commissioned in September 2008 and July 2009. The receiver has wider frequency coverage than the older K-band receiver and appears to have the anticipated ~threefold advantage in Tsys at 22 GHz over the older package. The receiver can be installed with either of two feeds: a narrow- band feed and quarter-wave plate providing dual orthogonal circular polarisation over the frequency range 21.0 to 22.3GHz, or the standard feed providing dual orthogonal linear polarization over the 16 to 26GHz range. The package has two independent conversion systems allowing simultaneous operation at any two arbitrarily-spaced frequencies within the band limits. The 13MM receiver also has an optional quarter-wave plate used with the narrow-band VLBI feed covering the 22 GHz water transition. The cal injection occurs after the polariser (between the polariser and the OMT). More information on the receiver is available here.
Table 1.12. Calibration information.
Normalized gain-elevation curves of the form:
The 50cm receiver in the 1050CM package injects a cal signal using a directional coupler after each LNA (strictly, after the 4-port hybrid used to combine the signal from each pair of opposing probes and LNAs). A splitter is used to generate two identical cal signals from the same noise source. Further information on the receiver can be found in Granet et al. (2005). This receiver is not normally scheduled for any regular Parkes nor VLBI observing as it has been superceded by the UWL.
Table 1.14. Calibration information.
Normalized gain-elevation curves of the form:
The H-OH receiver has an optional quarter-wave plate which can be inserted in the circular waveguide between the feedhorn and the Ortho-Mode Transducer to achieve circular polarisation on the sky. The quarter-wave plate is inserted before the cal injection so in this case the cal signal resembles a 100% circularly-polarised signal on the sky but the cal signal alone cannot be used to model the precise properties of the quarter-wave plate. This receiver is not normally scheduled for any regular Parkes nor VLBI observing as it has been superceded by the UWL.
Table 1.16. Calibration information.
The following plots show the system and calibration temperature of the H-OH receiver (Kelvin). The Moon was used for the measurements, with correction for opacity, plus contributions from atmosphere and ground emission included.
The overall outline of the Parkes observing system is shown in Figure 1.12.
Since February 2019, Medusa has become the dominant backend for all observations with the UWL. In the normal operation of the UWL in conjunction with Medusa, the full UWL band is digitised into three discrete bands in the focus cabin. Each of these bands is sent down to the control tower to a suite of FPGAs, where the data are broken into further sets of 128 MHz sub-bands. Data are then sent to the Medusa GPU cluster where it is processed according to the user-defined observing parameters (See Section 1.3 Observing Modes for full details on the capabilities of each mode).
The Parkes Conversion System (PCS) had been the main method of down-conversion for all single-pixel feed receivers until February 2019. As of September 2019, all receivers other than the UWL still require the use of the PCS before data before data can be sent to a designated backend. Single-beam spectral-line observations have back-end options using 8, 64, 128, 256, 512 or 1024 MHz bandpass capabilities of the 8-bit Digital Filterbank (DFB4), or patching in an ATCA-style bandpass filter to provide 4, 16 or 32 MHz bandpass capability. For Pulsar observations, it is possible to switch simultaneously record data on several back ends at once. An in-depth discussion of the PCS is available here (PDF file).
When preparing your observing proposal, you are required to estimate the expected brightness and sensitivity of your source for your particular correlator/receiver combinations. For spectral-line observations, sensitivity per bandwidth channel can be estimated from the following equations of line brightness and line flux respectively:
In the above, G is the main-beam gain (Jy/K) for a receiver defined from where and are the solid angles on the sky for the main beam and the total collecting are of the antenna, respectively. Also, npol is the number of polarisations (an average of two independent polarisation channels), BW is the bandwidth [MHz], nchan is the number of channels and is the on-source integration time in seconds. is the beam efficiency factor = 0.7. For continuum, we need to calculate the sensitivity over the whole bandwidth. The continuum line brightness and line flux respectively become:
For both the line and continuum flux, the source is assumed to fill the main beam which has efficiency G~0.7. The theoretical RMS noise estimates for line and continuum observations can be estimated using the on-line sensitivity calculator. A detailed analysis of the sensitivity calculator, with examples of Parkes data, is given here.
DFB4 supports all single-pixel feed receivers and the centre beam of the MB. It is possible to use DFB4 in conjunction with the Medusa backend; however this is not a typical observation configuration. Consult with local staff before attempting to record with both backends.
DFB4 can be used in four observing modes:
Pulsar folding mode
Pulsar search mode
Time binning mode (spectral-line/continuum observations at high time resolution)
Spectrometer mode (spectral-line/continuum observations at low time resolution).
For more information on DFB4 capabilities, see the Parkes Correlator Guide.
Spectra are folded on the pulsar period. Used to observe pulsars of known period. Relevant configuration parameters are:
The number of time-bins the folding period is divided in;
The number of frequency channels;
The bandwidth (BW).
The minimum folding time depends on the configuration. Examples are:
2k bins, 2k channels, 1024 MHz BW: 8.192 ms
2k bins, 512 channels, 1024 MHz BW: 2.048 ms
The maximum number of frequency channels is limited to 2048.
File format is "PSRFITS".
Configurations are of the type "pdfbX_YYY_BW_CH" where X = 4, YYY is the number of time-bins per folding period, BW the bandwidth (MHz), and CH the number of frequency channels.
Spectra are dumped to file unfolded and the output is the spectrum as a function of time. Used to search for new pulsars. Relevant configuration parameters are:
The number of time-bins the dump time is divided in;
The number of frequency channels;
The bandwidth (BW);
the number of bits (2, 4, or 8).
the number of polarizations (1, 2, or full Stokes).
Some of the major features are:
The minimum sampling rate depends on the configuration and the computing power required. A typical value is 100 μs.
The maximum number of frequency channels is 8192.
Configurations are of the type "srch_BW_CH" where BW is the bandwidth (MHz) and CH the number of frequency channels.
It is used for spectral line and continuum observations, especially when observations require scans or, more in general, sampling times of 4 sec or shorter. Spectra are integrated in time bins (sampling time). Data are dumped every time-cycle, which is a set of time-bins. Relevant configuration parameters are:
The time-cycle: 4-s or longer;
Number of time-bins in each time-cycle:
The minimum is 8;
The maximum depends on the configuration, but cannot exceed 2048 (e.g., with 4096 channels, the maximum number available is 32);
The number of frequency channels:
The minimum is 512
The maximum is 4096 for DFB4 for a bandwidth of 512 MHz or narrower (2048 for a BW of 1024 MHz);
File format is "RPFITS".
The program to run DFB4 in this mode is "sdfb4" on the computer "pkccc4".
It can be used for spectral line and continuum observations when sampling times of 4-s or longer are required. It is like the time-binning mode but with one time-bin a time-cycle. Relevant configuration parameters are:
The maximum is 8192 (each IF);
The minimum is 512.
The time-cycle: 4-s or longer;
The number of frequency channels:
File format is "RPFITS".
The program to run DFB4 in this mode is "sdfb4" on the computer "pkccc4" ("pkccc4").
Configurations are of the type "sdfbX_BW_CH" where X = 4, BW the bandwidth (MHz), and CH the number of frequency channels.
The Berkeley Parkes Swinburne Recorder (BPSR) is a high resolution digital filterbank data acquisition and processing system for the Parkes Multibeam receiver, developed in collaboration between Swinburne University of Technology and The University of California at Berkeley.
Thirteen Interconnect Break-out Boards (IBOB) perform analog-to-digital conversion of two dual-polarization signals, each with a bandwidth of 400 MHz. These signals are sub-divided into 1024 frequency channels using a polyphase filter bank programmed into the IBOB Field Programmable Gate Array (FPGA) logic blocks. The signals are then detected, integrated, decimated to 8 bits, and streamed to 13 server-class nodes.
For more information on BPSR, visit the instrumentation page of the Swinburne Pulsar Group.
Medusa a GPU-based signal processing unit that was specifically designed to support the UWL receiver. Integration with other receivers is possible, though users are strongly encouraged to collaborate with local Parkes support to discuss and facilitate any such use cases.
Medusa is capable of processing each of the 26, 128-MHz sub-bands of the whole UWL bandpass independently. The processing can involve forming full polarisation products, folding these signals in a mode typical of “fold mode” pulsar observations, creating products suitable for searching for transient events (akin to “pulsar search mode”), and/or producing high-frequency resolution data for use in spectral line or continuum emission studies.
Each of the 26 sub-bands can be configured independently in any of the observing modes (search, fold, continuum, etc). See Section 1.3 for a summary of each mode or Hobbs et al. (2019) for a complete summary of the backend modes.
The suite of backend instruments available at Parkes ensures that a diverse range of observations can be carried out. These are usually split into high time-resolution modes (e.g., pulsar observations) and high spectral-resolution modes (e.g., spectral line observations). In this section we describe the observing modes available for use with the Ultra-Wide-Low (UWL) receiver. The astronomy processing is initially carried out on a GPU cluster (known as “Medusa”) with subsequent processing on a CPU server (known as ``Euryale”).
If the pulsar astrometric, spin, dispersion measure and orbital parameters are known (from, e.g., a tempo2 timing solution) then the incoming data stream can be “folded” at the topocentric period of the pulsar. For each 128 MHz-wide sub-band, the data is coherently dedispersed and channelised. The data are then detected, polarisation products AA, BB, Real(A*B), Imag(A*B) formed and folded into pulsar phase bins. The data are output for every sub-integration. The data are output in a PSRFITS fold-mode data file. The switched calibration signal is not run during such observations; typically the calibration signal is recorded (using the same observing mode) prior to the pulsar observation.
Number of frequency channels/sub-band: between 64 and 4096 channels.
Number of pulsar phase bins: between 8 and 4096 bins
Sub-integration time: between 8 and 60 seconds
If a new pulsar is to be added to the folding catalogue, or the parameters for a particular pulsar requires updating then the following procedure should be followed (note that this will be simplified in the near future):
Log on to “joffrey” as pksobs (password required)
Create a new obs*.db file (or update an existing one for your project). Note that formatting required (this is not exactly the same format that gets output as a TEMPO2 parameter file).
Test that the parameters are correct for your updated or new pulsar using: psrcat -E -all <pulsar name>
Assuming correct then run:
To search for a new pulsar, transient event (such as a fast radio burst), or to study individual pulses from a known pulsar a “search mode” data set is produced. The incoming data stream is channelised and polarisation products formed. These are averaged to a specified sampling interval, normalised and re-quantised to 1, 2, 4 or 8 bit values.
Number of frequency channels/sub-band: between 8 and 4096 channels
Sampling interval: between 1us and 1sec
Polarisation products: (AA+BB), (AA,BB) or (AA, BB, Real(A*B), Imag(A*B))
Number of bits: 1, 2, 4 or 8
Whether coherent dedispersion is applied (if so, then the dispersion measure of a known pulsar or fast radio burst source is required).
Note that not all combinations of parameters are possible. A typical observation mode may have 32μs sampling, 8-bit samples, four polarisation products and 128 channels for each sub-band. This produces 400 MB/sec or 1.5 TB in a one hour observation.
High frequency resolution output can be produced in spectral line/continuum modes. The data are channelised with up to 221 (2097152) channels per sub-band giving 61Hz spectral resolution. The sampling rate is tunable from 0.262144 - 60s (where integer sampling time is supported, but it is best practice to use multiples of 0.262144 s). 1, 2 or 4 polarisation products can be formed and the output written out as SDHDF-format files with an integration time between 0.262144 and 60 seconds. The switched calibrator source can be run during spectral line/continuum observations. If running then the output data products also include cal-ON and cal-OFF spectra.
Number of frequency channels/sub-band: 2N values up to 2097152
Sampling interval: between 0.262144 and 60 sec
Polarisation products: (AA+BB), (AA,BB) or (AA, BB, Real(A*B), Imag(A*B))
Frequency, duty cycle and starting phase of an inject cal signal.
Min frequency: 0.01 Hz
Max frequency: 100 Hz
Bandwidth over which Tsys is calculated: 0.001953125 - 1 MHz
Currently zoom bands are not implemented. For now, the observer must observe with sufficient spectral resolution across the entire sub-band and use offline tools to extract the bands of interest.
Commensal observing modes have been implemented into DHAGU and Medusa, but are not officially offered in the current semester (2020APRS). With commensal modes, it is possible to observe with the following configurations:
- Continuum and Fold
- Continuum and Search
- Fold and Search
Please discuss usage of commensal modes with Jimi Green (James.Green[at]csiro.au).
The telescope is able to point at objects or positions -- not to be confused with determining a pointing solution. Parkes uses a pointing model which is receiver-specific, and so there is no global solution. Each receiver at Parkes sits within a specific location on the translator, which must be physically moved to place the chosen receiver on focus. For each receiver, an all-sky pointing solution is performed by staff, and for receivers up to 6 GHz, the goal RMS error in pointing offsets is 10% the receiver FWHM. For higher receivers, the goal RMS pointing error is 5% FWHM. For higher frequencies, poor weather may cause this error to be larger. It is currently not possible for observers to update the pointing in real time, but it is possible to run a SPOT observation with TCS and check the pointing. The SPOT observation performs orthogonal scans across a continuum source, and can be processed to obtain the RMS errors between the expected and measured positions of the source. A DHAGU controllable version of SPOT is not yet implemented. SPOT usage for pointing is only applicable to observers using high frequency receivers (and is otherwise an observatory role). SPOT-type observations are not yet implemented in DHAGU.
The telescope is able to point at a position in the sky and allow the celestial sphere to pass through ‘Drift mode’. The antenna is driven to a given Azimuth and Elevation and “tracked” at that position for a specified amount of time, with the source drifting through the receiver beam. Not yet implemented in DHAGU.
The telescope is able to form a grid of observations through ‘Grid mode’. This allows the antenna to create an l (1D) or l x m (2D) grid of positions, with an optional reference position (which can be inside or outside the grid as required) to be revisited every nth observation. Not yet implemented in DHAGU.
The telescope is able to scan between two selected endpoints, for a given duration. A series of scans can be merged together to create a map. DHAGU currently allows maps to be defined as on-the-fly (OTF), where scans are observed in turn, with the bandpass calibration is performed by using the scan data itself. There is also the option of performing referenced scanning. Here, a reference point outside the map region (presumably free of spectral-lines) is observed for a short time, then interleaved scans are observed before returning to the reference position. Please note scanning within 10 degrees of the upper Zenith limit is not recommended and should be avoided to reduce antenna structural stress.
Tracking mode allows the antenna to follow a source for a specified duration, in theory it is possible to do this from the source rising to setting with the elevation limit defined by 30.25 degrees.
Observers should avoid putting undue stress on the drive systems of the telescope by avoiding tracking a source through Zenith. A warning is sounded in FROG when an observation moves within 5 degrees of Zenith, but observers should take precautions to avoid tracking a source within a couple of degrees of zenith (sources with declinations of approximately -30 to -32). Not only does it put stress on the drive systems, but it will also likely result in poor data as the telescope struggles to maintain tracking lock. As such we request observers to be conscious of these limits and schedule sources appropriately. If only one source is being observed, and it tracks within a couple of degrees of Zenith, observers should stop observing, wait for the source to transit, and then restart observing.
All observers will need a CASS Unix account and password in order to access the various observing tools and utilities.
This is an essential element of Parkes remote observing.
If you do not have one already, then you can apply to get one here. It usually takes a week or two for the request to go through the system. Therefore, it is important that you put in your request for a Unix account at least a week before your scheduled observations. Similarly, if you have an account already, but it has lapsed, then you will need to send an email to firstname.lastname@example.org at least a week ahead of your observations to reset your password.
Various tools exist to help you plan your observations. A full list of tools can be found on the Parkes Observing Information web page (look under “Planning your observations”): here.
Below are some of the more useful tools.
The PORTAL includes information (under ‘alerts’) on any particular forecast RFI - this is typically at L band and may be unavoidable but should there be flexibility in the observing strategy, one mitigation is to observe at a different part of the band or with a different receiver (if for example a high frequency receiver is installed). This RFI has frequency peaks around 1265 and 1300-1310 MHz, and can have extremely high amplitudes. The RFI monitor (see below) can be used to see when mid-week RFI is present, as shown in Figure 1.13 Because of the strength of this RFI, it can often drive the front-end system into saturation; if this occurs, the data becomes unusable. We do now sometimes receive advanced warning on when this RFI may be present, and if this will affect observations, the notification will be made on the PORTAL and possible alernative arrangements, such as switching receivers and/or frequency can be made.
The Parkes Observatory has a real-time RFI monitoring antenna that is located on a tower, a few hundred metres to the East of the telescope. It is a log-periodic antenna and is used to measure and identify the many man-made signals that are produced by on-site and off-site sources. The antenna scans the site, completing a full circuit every 20 minutes. Every 20 seconds the data is updated and displayed on the web site linked below. It monitors the frequency range 700 - 3000 MHz with 2 MHz frequency resolution. The data is presented in three different format:
A power spectrum of the “latest spectra”. It is zoomable by moving the cursor over the spectrum.
The spectrum as a function of time in the form of a waterfall plot showing the last hour of data.
The spectrum as a function of azimuth.
The RFI Weathermap is avaliable here.
Many satellite constellations regularly transmit in our receiver observing bands. The best way to deal with them is to avoid them all together. On the sky plot of FROG (or DHAGU), you can display the satellite constellations that are known to transmit in your observing band and then avoid those parts of the sky populated by the satellites.
Figure 1.15. An example of the sky plot on FROG showing the GPS Satellite constellation (NAVSTAR) as blue crosses.
The UWL system and Medusa backend potentially allows for extensive data rates that can impact other observers and the ability to take further data. As such we ask that observers clearly stipulate their expected data rates on their observing proposals and maintain those for the actual observations. The scheduler will endeavour to ensure data intensive projects are not scheduled too close to one another, but this cannot be guaranteed.
In general to observe with Parkes you must submit a proposal to the ATNF Time Allocation Committee via the OPAL webpage (https://opal.atnf.csiro.au). There are exceptions to this (purchased contracted telescope time and targets of opportunity). A proposal consists of a cover sheet, a table of observations and a science case. Calls for proposals are made every 6 months (in approx. June and December), with meetings of the Time Allocation Committee thereafter (typically in July and February respectively). Proposals are allocated a project code on submission of the form of a ‘P’ followed by an iterative 4 digit number (previously 3 digits). Exceptions to this convention are contracted time (given a name for example ‘BL’ or a special code for example PX500 and PX501) and Target of Opportunity observations (also PX but with a 3 digit number much less than 500). Proposals are graded by the committee and then those with sufficient grades will be allocated some or all of their requested time (typically grades of at least 3.0 are required, and time will be scheduled in the subsequent semester, starting October or April respectively). Scheduling is a function of the proposal pressure and requested Local Sidereal Times, meaning that exact allocations, and grading cut-offs, vary from semester to semester. If you are unable to find your project code during the setup for your observations, use the code `PUNDEF’ and contact Parkes support after your observations to reassign the correct code do your data.
Parkes operates a model whereby each project should have a designated ‘Project Expert’. These individuals should be trained in the use of Parkes, qualified to observe remotely and available to assist the project with any scientific or observing strategy related queries. They are also expected to train their team members in any specifics to their projects (separate to the basic remote observer training provided by the national facility). If the proposal team does not include someone who is already qualified then the team must send someone to visit the ATNF and receive appropriate training (or recruit an expert to their team). The Project Expert is expected to be present with any first time observers to provide assistance as required. The Project Expert should be identified on the proposal cover sheet.
Successful proposals provide clear and succinct science cases that motivate the proposed observations. They identify why the observations should be carried out with the Parkes telescope (and not another facility) and demonstrate that the proposers have appropriately considered what is required to achieve their science goals. The OPAL proposal cover sheet allows for the selection of the preferred receiver and backend. The default receiver pairing is the UWL and the Multibeam. If another receiver from the fleet is required this should be clearly motivated and will require a substantial time request and high Time Allocation Committee grading to instigate a change of receivers from the default pairing. Alternatively observations with other receivers can be entertained if combined with the VLBI observations for the semester (for which proposers should liaise with the LBA System Scientist).
In addition to standard scheduled observations there are two types of observation that can override the schedule:
These are proposals of a non-claim-staking nature for a well-defined set of observations but requiring specific dates and times for observations that are not yet established. This is either because they are in response to a trigger which is unpredictable in time, or because they are a component of commensal observations with another facility with a different timeframe for allocation to that of ATNF proposals. The proposal is submitted to OPAL as usual, but identified as a Non-Apriori Assignable Proposal (NAPA) in the system. The proposal is then assessed by the Time Allocation Committee as usual, receiving a grade, but is only scheduled on the telescope when an event is triggered or commensal observations scheduled. If triggered they may displace any lower ranked proposal at the discretion of the scheduler.
These are unexpected astronomical events of extraordinary scientific interest for which observations on a short time scale are justified, and for which a NAPA was not possible (i.e. the request was unforeseen). To trigger such an observation requires an email to the scheduler and to the alert email address. Your email should include a scientific justification (of order half a page to one page) providing sufficient technical detail for the observations to be scheduled. These observations are allocated a number of the form of a ‘PX’ followed by 3 digits.
Time unallocated in the semester schedule, which is elsewhere often referred to as ‘Director’s Discretionary Time’, is referred to within the ATNF as ‘green time’ (due to the green hue in the graphical schedule, example below).
Traditionally this time would have been requested via an email to the ATNF Director, or Head of Science Operations, but is now through the PORTAL and an email to the scheduler. This should include information on the proposed observations, a rationale for the request, and any project codes that may be relevant (for example if you are asking for additional time for a scheduled project it would be allocated to the same project code).
The Parkes instrumentation enables various calibration strategies. The primary calibration goals are to:
- Ensure the telescope is pointing accurately
- Remove fluctuations and ripples in the bandpass
- Scale astronomical sources to flux density units
- Account for gain fluctuations throughout the observation
- Form calibrated Stokes parameters for the astronomical sources.
Pulsar astronomers generally observe a switched calibration signal prior to the pulsar observation. Spectral line/continuum observers have made use of a wider range of calibration strategies including position and/or frequency switching, pointing models, beam switching and calibration signals. Bandpass ripples also need to be accounted for during data processing.
We note that the fixed digitisation for the Parkes UWL receiver precludes frequency switching calibration systems for observations with that receiver.
Pointing solutions are obtained by observatory staff for the receivers when they are installed. However, at high frequencies further pointing calibration is required during observations.
The Parkes UWL receiver, the multibeam receiver and other legacy receivers within the fleet enable the injection of a switched noise source into the signal path. Typically this switched calibration system is used as follows:
- Pulsar fold-mode observations: the telescope is pointed a few beam-widths away from the source of interest and the switched calibrator run with a 50% duty cycle and a frequency of 11.123 Hz. A fold-mode observation is recorded (typically with the source name being <pulsarName>_R. The calibration signal is then switched off during the pulsar observation.
- Pulsar search-mode observations: traditionally, no calibration signal is applied for pulsar search observations. For studies of single pulses from known pulsars, then the calibration signal is switched (as above) prior to the start of the pulsar observation.
- Spectral line/continuum observations: the calibration signal can be applied continuously during the observation or for a specified short observation In this mode, the UWL backend instrument produces a cal-ON and a cal-OFF spectrum alongside the higher resolution astronomy spectrum. It is typically switched with a 50% duty cycle and a frequency of 100 Hz.
A characteristic small-scale ripple with a periodicity of 5.7 MHz arises from multiple reflections in the 26m space between the vertex at one end, and the focus and/or underside of the focus cabin at the other. Analysis of the Parkes UWL spectra also shows small-scale ripples on a range of periodicities and these are actively being studied with the goal of their removal. The primary 5.7 MHz ripple is usually mitigated in offline processing by baseline fitting, or position switching, but it is also possible to cycle the (high frequency) receivers up and down in the translator Y-axis to ‘smear out’ the ripple with amplitude 6.3mm peak-to-peak and a period of 60 seconds. This technique is available for use with higher-frequency receivers only and proposers should contact Parkes Operations, ATNF-Parkes-Remobs[at]csiro.au before submitting proposals.
Flux calibration sources in the Southern Hemisphere can be identified from the ATCA calibrator database. Flux density calibrators that are commonly used are listed below:
Table 2.1. Standard Calibrators.
|Source name||J2000 Right Ascention (hh:mm:ss)||J2000 Declination (dd:mm:ss)||Notes|
|PKS 1934-638||19:39:25.026||-63:42:45.63||4.8 - 4.928 GHz: V/I = 2.5x10^-4 +/- 0.5x10^-4 (Rayner et al. 2000) Stokes I flux model: Reynolds (1994); Partridge et al (2015)|
|Hydra A (3C 218)||09:18:05.7||-12:05:44||Has been used by the pulsar community for decades, but not suitable above ~3.5 GHz.|
|PKS 0407-658||04:08:20.380||-65:45:09.08||ATNF Standard flux calibrator.|
|PKS 0823-500||08:25:26.869||-50:10:38.49||ATNF Standard flux calibrator.|
|PKS 1921-293||19:24:51.056||-29:14:30.12||Variable, can be tied to ATCA flux.|
Most observing projects obtain their own flux calibration solutions. However, the switched calibrator source is relatively stable for the UWL and multibeam receivers and so flux density calibration solutions taken within weeks or months of a particular observation are generally sufficient for use (assuming that the switched calibration signal is used).
Cross coupling in the feed is a major issue for the multibeam receiver. In Figure 2.1 below (to be published in Kerr et al.) we show, for different receivers, the ellipticities of the receiver system and as well as the orientation of receptor 1 with respect to receptor 0 (). In brief, the co-axial 40/50 cm and 10 cm systems are close to the ideal feed assumption over most of the band. The 20cm multibeam system shows substantial non-orthogonality and cross-polarisation, while the 20cm H-OH feed is also close to ideal.
The the UWL system the measured receptor ellipticities are close to 0 degrees across the whole band, indicating that the degree of mixing between linear and circular polarisation is low. The non-orthogonality of the receptors is also very low. At higher frequencies, the reference signal produced by the artificial noise source deviates from 100\% linearly polarised. Up to ~30\% circular polarisation has been observed at ~4 GHz and this must be accounted for in the offline processing.
The P737 observing project carries out rise-to-set tracks of the bright, millisecond pulsar, PSR J0437-4715 approximately once per semester with the multibeam receiver and/or the UWL. These observations can be used to track any changes in the cross-coupling parameters within the receiver system.
The basic requirement of scheduling an observation with DHAGU is the Parameter Set. This is a list of key/value pairs which configure the TOS (antenna) and Medusa (recording) subsystems. Once a Parameter Set is created, it can be submitted to TOS, which then creates a Scheduling Block. A Scheduling Block is an atomic entity and contains all the information on the requested observations. The TOS system logs and system state, observer comments, commensal projects and status of the observation are all associated with a Scheduling Block, which has a unique number that is assigned when submitted to TOS.
There are several ways to import a Parameter Set into DHAGU. From the Editor tab shown below in Figure 2.2, you have:
- ability for direct entry of sources via the editor table, and configure Medusa manually.
- ability to upload a Comma-Separated Values (CSV) source list, and configure Medusa manually.
- ability to upload TOS/Medusa key/value pairs, and populate all inputs automatically.
Before you start entering sources manually, you must first select the configuration you wish to use. From the Select template... dropdown menu as shown below in Figure 2.3. When the selected option is clicked on, this will result in a modal popup requiring you to configure the calibration waveform and Medusa backend, if available. The Track, Scan and ScanMap options do not have a Medusa configuration, which is useful if you want DHAGU to drive the antenna and calibration waveform, but drive Medusa manually. If you select a ScanMap* option, you will also need to define the map parameters (widths, spacing, etc...). Note the ScanMap otions will auto-populate scanning positions in the Editor table based on the input map parameters. Once you are happy with the selected configuration, click the Save button.
You can now add sources into the Editor table, or in the case of ScanMap configurations, edit if required. Also note if you have selected a reference position in a ScanMap configuration, it will only have the tracked position, whereas the scanning rows will have a start and end position.
To add sources to the Editor table, click on the Add row button. For the source input, a typeahead exists which is linked to static versions of PSRCAT and ICRF J2000 catalogues. These present the observer with a list of matching sources (maximum 10 listed) to select from as shown below. When a source is selected, the Name, Epoch (J2000), RA, DEC, LST Rise/Set and (current) Visibility fields are populated automatically.
You can add or remove rows, or clear the table. Note that clear does not touch the calibration waveform or Medusa configuration. To clear these, simply reselect the template from the dropdown menu, and click the Reset button on the modal popup.
It is also possible to auto-populate rows using the Table Global Change section, as shown above in Figure 2.5. By clicking Add row, the observer can add (say) 10 rows to the table, then in the Table Global Change section, enter their PSRCAT or ICRF J2000 source only once, and click Go! All rows, whether every row, of the nth row of the table (n < 10), should now be populated with the chosen source. Similarly, if the observer wishes to populate the on-source duration (seconds) or toggle the calibration waveform, it can be done here. Note it is not currently possible to pass names to an external query database like Simbad, but this may be added in the future.
Currently, TOS accepts coordinates in J2000 or AZEL only. However, DHAGU allows J2000, AZEL and GALACTIC. When the Display/Save Parameter Set buttons are pressed, the coordinates are converted to J2000 if GALACTIC is selected. If you need accounting of Galactic coordinates in some way, use the longitude/latitude in the name of the position, ie., G200-2.5.
You can order sources by using click+drag on the first column to its destination. It is only possible to order by clicking on the ID column of the table. You can reorder sources with more flexibility when loading the saved Parameter Set into the Scheduler tool. Once done adding sources, you can save the table as a Parameter Set by clicking Save.
By clicking the Upload CSV button, you can select and import a CSV file. The resulting popup is shown below. You must define the observation import template of the CSV file, which currently is Scan or Track modes only. By clicking on the Select menu, your OS will present a finder window, which will allow you to select a CSV file to upload. Once you have selected a file, the filename will be present in the entry box adjacent to the Select button. By clicking the Import button, the process of uploading and parsing the file will begin. Note that in the event of errors in parsing the CSV file, only the first five (5) error messages will be displayed.
The format of the import is defined by a header in your CSV file, which must be present. For TRACK, the full header list is as follows:
Here, x and y are source coordinates determined by epoch, where GALACTIC implies x = longitude (degrees) and y = latitude (degrees). Note the offsets parameter was removed in DHAGU, version 0.7.0 (15th April 2020).
For SCAN observations, the full header list is as follows:
Here, the name, x, y, epoch, duration and cal keywords have the same meaning as for Track observations. The scan_length paramter allows the scan length to be determined (degrees), orientated at angle scan_rotation (degrees). The rotation angle is positive for a clockwise rotation. A rotation angle of 0 degrees implies the scan will proceed from North to South. You can change the direction of the scan by specifying a negative direction.
If the object name is contained in the Pulsar PSRCAT or ICRF databases, the import process will generate the J2000 coordinates and auto-populate these in the table. Therefore if you are using sources from these catalogues, the minimum set required for Track is name and duration, and name, scan_length, scan_rotation and duration for Scan. Keywords can be in any order, but must match the header. If your sources are not in PSRCAT or ICRF catalogues, you will need to supply the x/y coordinates and epoch, or the source will be skipped during the import process. Note the import process will attempt to minimum match source names to PSRCAT and ICRF sources if the coordinates are not present. An example Track CSV file is shown below:
name,x,y,epoch,duration,cal J0437-4715_R,04:37:16,-47:00:00,J2000,30,true J0437-4715,,,,180,false
The first source is a provided reference position; note the _R extension, but this is not mandatory, only historical for denoting a reference position. The reference is located to the North of the given Pulsar position, with the calibration waveform switched on for 30 seconds. The second source is the catalogue Pulsar position proper, and the calibration waveform switched off and integrating for 180 seconds.
An example Scan CSV file is shown below:
name,x,y,epoch,scan_length,scan_rotation,duration,cal 1934-638,,,,1,0,600,false 1934-638,19:39:25.026661,-63:42:45.62554,J2000,1,135,600,false
The first line defines the header. The second line is a one degree scan across 1934-638 with a rotation angle of 0 degrees, resulting in a North-South scan. The coordinates for 1934-638 will be populated via DHAGU. The next line is again 1934-638, with coordinates defined and another one-degree scan but at a rotation angle of 135 degrees, clockwise from North. For more information, see the Scan example in Section 2.4.8.
It is possible to import the full TOS/Medusa key/value pairs (the Parameter Set) into the Editor table. By clicking the Import TOS button above the editor table, the resultant popup is shown below.
You must define the observation import template of the TOS file. These essentially define antenna and Medusa modes, but currently only the Track* and Scan* configurations are directly importable. Regarding the Scan* configurations, it is assumed there are defined start and end positions for each scan. There is no currently way to define a scan length or rotation through TOS parameters. If you require this functionality, use the CSV import tool for scans, as described in Section 126.96.36.199. Also, note that if you import Scan* TOS parameters and then press the Clear Table button, the table format will revert back to scan format as described in Section 2.4.8.
By clicking on the Select button, your OS will present a finder window, which will allow you to select the text file to upload. Once you have selected a file, the filename will be present in the entry box adjacent to the Select menu. By clicking the Import button, the process of loading and parsing the file will begin. The difference between using the TOS import tool over CSV is that you can import both TOS and Medusa key/value pairs, whereas the CSV import allows source parameters only. Examples of Track and Scan key/value pairs are shown below.
Track with Search parameters (recording all subbands)
cal.duty_cycle = 50 cal.frequency = 11.123 common.target.src1.cal_signal = false common.target.src1.duration = 3600 common.target.src1.field_direction = [04:37:16,-47:15:08.64,J2000] common.target.src1.field_name = J0437-4715 common.target.src1.field_offset = [0,0] common.target.src1.search_co_dedisp = false common.target.src1.search_custom_dm = -1 common.targets = [src1] medusa.common.cal.tsys_avg_time = 5 medusa.common.cal.tsys_freq_res = 1 medusa.common.fcm_configuration = medusa.uwl medusa.common.subband%d.adaptive_filter_epsilon = 0.1 medusa.common.subband%d.adaptive_filter_nchan = 1024 medusa.common.subband%d.adaptive_filter_nsample = 1024 medusa.common.subband%d.enable_adaptive_filter = false medusa.search.subband%d.active = true medusa.search.subband%d.output_nbit = 8 medusa.search.subband%d.output_nchan = 1024 medusa.search.subband%d.output_stokes = 3 medusa.search.subband%d.output_tsamp = 128 medusa.search.subband%d.output_tsubint = 30
Scan with Continuum parameters (recording subband5 HI only)
cal.frequency = 100 cal.duty_cycle = 50 cal.phase = 20 common.target.src1.field_name = 0407-658 common.target.src1.field_direction = [04:08:20,-64:45:09,J2000] common.target.src1.end_direction = [04:08:20,-66:45:09,J2000] common.target.src1.duration = 300 common.target.src1.cal_signal = true common.target.src2.field_name = 0407-658 common.target.src2.field_direction = [04:08:20,-66:45:09,J2000] common.target.src2.end_direction = [04:08:20,-64:45:09,J2000] common.target.src2.duration = 300 common.target.src2.cal_signal = true common.targets = [src1,src2] medusa.common.cal.tsys_avg_time = 5 medusa.common.cal.tsys_freq_res = 1 medusa.common.fcm_configuration = medusa.uwl medusa.common.subband%d.adaptive_filter_epsilon = 0.1 medusa.common.subband%d.adaptive_filter_nchan = 1024 medusa.common.subband%d.adaptive_filter_nsample = 1024 medusa.common.subband%d.enable_adaptive_filter = false medusa.common.subbands = 26 medusa.continuum.subband%d.active = false medusa.continuum.subband%d.output_nchan = 32768 medusa.continuum.subband%d.output_stokes = 3 medusa.continuum.subband%d.output_tsamp = 1 medusa.continuum.subband%d.output_tsubint = 10 medusa.continuum.subband5.active = true medusa.continuum.subband5.output_nchan = 32768 medusa.continuum.subband5.output_stokes = 3 medusa.continuum.subband5.output_tsamp = 1 medusa.continuum.subband5.output_tsubint = 10
When you click the Import button, DHAGU will parse the file, and if successful will change the the selected configurations dropdown to the chosen option. For the above example, if you selected the TrackFold configuration at the import stage, DHAGU will report there is no Medusa configuration but still load the source list into the Editor table. If you are wanting a Track-only option, you will need to switch the dropdown menu from TrackFold to Track. This will ask for confirmation on changing, where you click OK and the configuration modal will present itself.
The Medusa parameters below outline a FOLD mode observation, with all 26 subbands at the same settings for nchan,
nsamps, etc can be added to the TOS parameters above. Full stokes is specified by
medusa.fold.output_stokes = 3 and represents [AA,BB,Re(AB*),Im(AB*)] recorded for
medusa.common.cal.tsys_avg_time = 5 medusa.common.fcm_configuration = medusa.uwl medusa.common.subband%d.adaptive_filter_epsilon = 0.1 medusa.common.subband%d.adaptive_filter_nchan = 1024 medusa.common.subband%d.adaptive_filter_nsample = 1024 medusa.common.subband%d.enable_adaptive_filter = false medusa.common.subbands = 26 medusa.fold.append_output = true medusa.fold.custom_period = -1 medusa.fold.output_nbin = 1024 medusa.fold.output_stokes = 3 medusa.fold.output_tsubint = 30 medusa.fold.subband%d.active = true medusa.fold.subband%d.custom_dm = -1 medusa.fold.subband%d.enable_sk = false medusa.fold.subband%d.output_nchan = 128 medusa.fold.subband%d.sk_nsamps = 1024 medusa.fold.subband%d.sk_threshold = 3
The Medusa parameters (if present in the uploaded file) will auto-fill the Medusa configuration, which is accessible by clicking the select dropdown menu. It is important that any changes to the Medusa configuration be propagated by pressing the Save button, available from the modal popup when selecting a configuration from the dropdown menu.
To configure the required Medusa mode (Fold/Search/Continuum/...), select the required configuration from the dropdown select menu. For the TrackFold selection, we see the following modal popup appearing as in Figure 2.8, with top-level options expanded:
The Medusa configuration tool uses hierarchical keywords to display options for each mode. A truncated hierarchy for Fold mode is shown below:
Medusa Fold -> common -> subbands -> fcm_configuration -> cal -> tsys_avg_time -> tsys_freq_resolution -> fold -> output_nbin -> output_tsubint -> overrides
common menu contains values that apply to all Medusa subbands, and “fold”
distinguishes this mode (via key/value parameters) from other Medusa modes. The “overrides” section allows
different settings to be applied for each 26 Medusa subbands, other than the assigned defaults. For example,
the observer may want to only
observe a Pulsar in Fold mode for only one subband, so they would disable all sub bands, but use the overrides
section to configure (say) subband 5, which has a central frequency of 1408 MHz (127 MHz bandwidth.) Only
subband 5 would be recorded in this example. Similarly, a spectral-line observer would only select subband 5
if only interested in Galactic HI, subband 7 for the Hydroxyl (OH) transitions at 1612, 1665, 1667 and 1720
MHz, or subbands 0, 19 and 20 to observe all transitions of Methylidyne (CH) at 701, 704, 722, 724, 3263, 3335
and 3348 MHz.
The observer clicks on the > buttons to expose settings that may need to be configured. The provided defaults for all modes configure Medusa to display data across all subbands and provide a good starting point for refinement, according to project specifications.
Once the observer is satisfied Medusa is configured as required, the Save button assigns that configuration to all sources. Basic type and range checking is performed before saving, with any errors listed. The saved configuration remains in place until cleared, another configuration selected, or you log out of DHAGU.
Once the source and Medusa parameters have been set, the observer can display the entire Parameter Set before saving, as shown in the example below. Parameters in green are TOS, and those in blue are Medusa. Once the parameters look fine, dismiss the popup and select (if not already) the project to associate the parameter set with, but using the Project button, then click on Save. A secondary popup will prompt for an alias, which is a alpha-numeric string, something to distinguish this Parameter Set from others. You can view the saved parameter set from the Manager tab, or (re)load it into the same table or via the Scheduler tab.
Once you have saved Parameter Sets in DHAGU, you can easily load them back into the Editor table. First, select the project the Parameter Set was saved to, using the Project... button above the editor table. Next, click on the Load button, and a list of saved Parmeter Sets should be diplayed. The table columns are sortable by clicking on the column headers. The table (example below) shows the ID of the Parameter Sets, the template (TrackFold, TrackContinuumSearch, ...) and a history with a dropdown menu showing who made changes and when (UTC timestamp.) Note there is no revistion control in DHAGU. By clicking on a row, the selected Parameter Set will be loaded into the Editor table, where it can be altered and either saved as a new Parameter Set (define a new alias when saving), or overwrite the existing one.
An existing TCS FOLD mode observation with the UWL receiver and PDFB4 may look like the following, which utilised the low (768MHz; CASPSR) and high bands (>3100MHz; PDFB4) of the UWL (note this would all be on one line to be read by TCS):
J0835-4510_R; P 08:35:00 -40:00:00; d4_cfg pdfb4_1024_1024_1024; d4_frq 3100.0; d4_tcyc 10; d4_tsub 30; rcvr UWL; tobs 120; mode levcal; cal freq; cfrq 11.123; fdmode FA; fdang 0.0; MED_PROC FOLD128; MED_SUB 30; MED_BIN 1024; MED_CHN 1024; CA_PROC dspsr.50cmsktoo; CA_FRQ 724.0; CA_BW 64;
The above TCS schedule equates to TOS/Medusa Parameter Set as below. Whilst more verbose, fine-grained control of subbands is possible via TOS, but not TCS. As we are selecting specific subbands, we disable all subbands first (using medusa.fold.subband%d.active) and specify those we want. For Medusa, subband0 equates to 768 MHz / 127 MHz bandwidth (equivalent of CASPSR), and subbands 13-20 cover the 3100 MHz, 1024 MHz bandwidth used with PDFB4. In the example, Kurtosis RFI Mitigation is on for subband1 only; it can only be on or off per Scheduling Block.
cal.frequency = 100 cal.duty_cycle = 50 common.target.src1.cal_signal = true common.target.src1.duration = 30 common.target.src1.field_direction = [08:35:00,-40:00:00,J2000] common.target.src1.field_name = J0835-4510_R common.target.src2.cal_signal = false common.target.src2.duration = 120 common.target.src2.field_direction = [08:35:20.61149,-45:10:34.8751,J2000] common.target.src2.field_name = J0835-4510 common.targets = [src1,src2] medusa.common.fcm_configuration = medusa.uwl medusa.fold.subband%d.enable_sk = false medusa.fold.subband%d.output_nchan = 1024 medusa.fold.subband0.enable_sk = true medusa.fold.subband%d.active = false medusa.fold.subband0.active = true medusa.fold.subband13.active = true medusa.fold.subband14.active = true medusa.fold.subband15.active = true medusa.fold.subband16.active = true medusa.fold.subband17.active = true medusa.fold.subband18.active = true medusa.fold.subband19.active = true medusa.fold.subband20.active = true medusa.fold.subband21.active = true
Note specifying the DM or period is not required here. Medusa will scan the source, and if in PSRCAT, will apply those parameters from there. For a new Pulsar that is not in PSRCAT refer to medusacat in Section 188.8.131.52.
An existing TCS Search mode observation with the UWL receiver and PDFB4 may look like the following, with Stokes I (AA+BB) only (note this should all be on one line to be read by TCS):
J1227-6230; P 12:27:39.96 -62:30:19.2; mode srch; tobs 3600; SR4_FTMX 900; pid P860; MED_PROC SRCH; MED_POL 1; MED_CHN 128; MED_BIT 8; MED_SMP 128; MED_DM 100.0; MED_SUB 15;
The corresponding TOS Parameter Set is:
cal.duty_cycle = 50 cal.frequency = 11.123 common.target.src1.cal_signal = false common.target.src1.duration = 3600 common.target.src1.field_direction = [12:27:39.96 -62:30:19.2, J2000] common.target.src1.field_name = J1227-6230 common.target.src1.search_co_dedisp = true common.target.src1.search_custom_dm = 100.0 common.targets = [src1] medusa.common.cal.tsys_avg_time = 5 medusa.common.fcm_configuration = medusa.uwl medusa.common.subbands = 26 medusa.search.subband%d.active = true medusa.search.subband%d.output_nbit = 8 medusa.search.subband%d.output_nchan = 128 medusa.search.subband%d.output_stokes = 1 medusa.search.subband%d.output_tsamp = 128 medusa.search.subband%d.output_tsubint = 15
Note specifying the DM or period is not required here. Medusa will scan the source, and if in PSRCAT, will apply those parameters from there.
In this example, we show a Parameter Set for position switching on the HII region, W51, with selected subbands. We will record full Stokes [AA,BB,Re(AB*),Im(AB*)] for the spectral-lines in the table below. We will observe a reference position 2 degrees South of W51 for 300 seconds, then on-source, for 300 seconds. For each subband, Medusa will dump spectra every 5 seconds (output_tsamp) and the number of dumps per file is set to 30 (output_tsubint).
|Subband||Center Freq (MHz)||Range (MHz)||Line||nchan||Resolution (km/s)|
Note the CH 3263MHz line is close to the boundary of Medusa subband 20, with ~ 0.2 MHz (~ 20 km/s) separation between line and band edge. As there is no doppler tracking, if the source velocity is unknown or is expected to be broad, then the best solution is to select both subbands 20 and 21 for this line. The full Parameter Set is below.
cal.duty_cycle = 50 cal.frequency = 100 common.target.src1.cal_signal = true common.target.src1.duration = 300 common.target.src1.field_direction = [19:23:36,+16:30:00,J2000] common.target.src1.field_name = W51_R common.target.src2.cal_signal = true common.target.src2.duration = 300 common.target.src2.field_direction = [19:23:36.0,+14:30:00,J2000] common.target.src2.field_name = W51 common.targets = [src1,src2] medusa.common.cal.tsys_avg_time = 5 medusa.common.fcm_configuration = medusa.uwl medusa.common.subbands = 26 medusa.continuum.subband%d.active = false medusa.continuum.subband%d.output_nchan = 262144 medusa.continuum.subband%d.output_stokes = 3 medusa.continuum.subband%d.output_tsamp = 5 medusa.continuum.subband%d.output_tsubint = 30 medusa.continuum.subband5.active = true medusa.continuum.subband5.output_nchan = 262144 medusa.continuum.subband5.output_stokes = 3 medusa.continuum.subband5.output_tsamp = 5 medusa.continuum.subband5.output_tsubint = 30 medusa.continuum.subband7.active = true medusa.continuum.subband7.output_nchan = 262144 medusa.continuum.subband7.output_stokes = 3 medusa.continuum.subband7.output_tsamp = 5 medusa.continuum.subband7.output_tsubint = 30 medusa.continuum.subband19.active = true medusa.continuum.subband19.output_nchan = 131072 medusa.continuum.subband19.output_stokes = 3 medusa.continuum.subband19.output_tsamp = 5 medusa.continuum.subband19.output_tsubint = 30 medusa.continuum.subband20.active = true medusa.continuum.subband20.output_nchan = 131072 medusa.continuum.subband20.output_stokes = 3 medusa.continuum.subband20.output_tsamp = 5 medusa.continuum.subband20.output_tsubint = 30
In this example, we show a Parameter Set for an on-the-fly (OTF) map of the HII region, W51, with selected subbands the same as in the previous example. We will create a 2 degree map of the region done with RA scans (scanning in lines of constant Declination), with a reference position located away from the HII region, which will provide bandpass calibration. We will revisit the referenced position after 5 scans are completed. Whilst orthogonal scanning is possible (i.e., RA and Declination), only RA scans are shown in this example, but you should aim to "basket weave" your maps (perform orthogonal RA and Declination scans) to gain better signal-to-noise, plus remove possible stripping when gridding. If you perform mapping in one direction only, you can oversample the row spacing between scans to account for stripping.
The Nyquist row sampling for our RA scans should not be larger than (Equations 8,9; Mangum 2007), where D is the antenna aperture at the observing wavelength. However, depending on your region size and time constraints, it is perfectly acceptable to oversample the row spacing as mentioned above. For each scan, the 2 degree length will be done in 2 minutes, equating to a scanning rate of 1 degree/min. At this rate, beam smearing is not a factor when scanning away from Zenith (~ 10 degrees), or the South Celestial Pole, where parallactification can produce poor baselines; W51 is to the North and low on the Parkes horizon, so these effects are not in consideration anyway. In general, scanning rates should not be more than 3 degrees/min. For this example, we should note the beam FWHM is different for each Medusa subband as shown in Figure 2.11, with subband5 (1408 MHz) having a FWHM 15 arcmin, and subband20 (3328 MHz) about 6 arcmin. In order to satisfy the Nyquist spacing condition, we use the smallest beam (subband20) to define our row spacing to be 2.5 arcmin using the equation above, but also note this will oversample the lower subband (subband5) by a factor 2.4.
For each subband, Medusa will dump spectra every 5 seconds (output_tsamp) and the number of dumps per file is set to 30 (output_tsubint). Using the determined Nyquist row spacing above, you can define a scanning rate using the following (in arcsec/sec), (Equation 10; Mangum 2007). For the example here, a 1-degree/min rate has the oversampling factor about 1. Having larger values for implies better signal-to-noise, but without frequent observations of the reference position between scans, drifts in the system (atmosphere, pointing and sky rotation) may mean your baseline subtraction may not be effective.
Now we input our parmeters into DHAGU, as shown below. Under the "Editor" tab, select the ScanMapContinuum option from the select menu, and the configuration tool as shown below in Figure 2.12 appears. Here we are generating a square 2x2 degree map, with no rotation. Once the parmeters are entered, click on Generate and the editor table will auto-populate with both tracked reference and scanning positions.
The result is 59 entries, with 10 of those the referenced track positions. Configuring Medusa is the same as per other examples above, and is left as an exercise.
By clicking on the Show parmeters button, the (abbreviated) Parameter Set is shown below.
cal.frequency = 100 cal.duty_cycle = 50 cal.phase = 20 common.target.src1.field_name = W51_R common.target.src1.field_direction = [19:23:36,+12:30:00.00,J2000] common.target.src1.duration = 60 common.target.src1.cal_signal = true common.target.src2.field_name = W51_ROW-24 common.target.src2.field_direction = [19:19:18,+15:30:00.00,J2000] common.target.src2.end_direction = [19:27:44,+15:30:00.00,J2000] common.target.src2.duration = 120 common.target.src2.cal_signal = true common.target.src3.field_name = W51_ROW-23 common.target.src3.field_direction = [19:27:54,+15:27:30.05,J2000] common.target.src3.end_direction = [19:19:28,+15:27:30.05,J2000] common.target.src3.duration = 120 common.target.src3.cal_signal = true . . .
In a future release, it will be possible to display Parameter Sets of region(s), with DS9 and/or KVIS annotation files also produced. The example below shows the generated RA scans overlaid on a 5x5 degree IRAS 100 micron image using KVIS and the DHAGU-generated annotation file. The reference position is shown as a circle to the South.
In this example, a Parameter Set for scans across the standard flux calibrator, B1934-638 is outlined. By scanning across this source, we can determine the frequency-dependant beamshape, plus also obtain flux calibration for other data. In this example, B1934-638 will be scanned across in 1-degree strips, with scan angles 0, 45, 90 and 135 degrees. A positive angle corresponds to a clockwise rotation, with North = 0 degrees. A 0-degree angle corresponds to a scan in the North-South direction.
There is no Medusa configuration associarted with this Scan example; this may be useful if Medusa is to be configured manually. By selecting Scan mode, we see a popup asking what calibration waveform configuration we wish to define. By clicking on the Save button, scans can be added as show in Figure 2.15.
The orientation of the scans about B1934-638 is shown in Figure 2.16. The pixel data is from the SUMMS 843 MHz Survey. The orange circles determine the start of the scan. We can reverse the direction of the scan by defining the length as a negative number. In this situation, the starting position of the scan is identified by the white circles. If you wanted to do a scan across a source in an East->West direction and then the (reverse) scan from West->East, you would simply define the East->West with a positive length, and West->East as negative.
In order to become a qualified remote observer, you must complete the remote observer training. This is undertaken with a CASS staff member, via a Skype session, and typically takes about two hours to complete. The purpose of this training is not to instruct you on how to do an observation, but rather to acquaint you with the procedures and protocols of remote observing. Only people who have completed this training can carry out Parkes observations.
All observers will need a CASS Unix account and password. If you do not have one already, then you will need to organise an account and password before the training session begins. An application for a CASS Unix account can be made online, here.
It usually takes a week for the request to go through the system, so you should apply as soon as possible. Once the account has been organised, then you should request a Parkes remote observer training by sending an email to: email@example.com. A date and time will be agreed on and the Skype addresses exchanged.
Following the training, you must then perform an observing session with a more experienced, qualified colleague, where you will be shown how to perform the specific observations related to your project.
Only when you have completed the remote observer training AND observed with an experienced colleague, will you be considered to be fully qualified.
All observing is considered to be remote observing since, regardless of where you observe from, whether you’re in the Parkes control room or on the other side of the world, the same software is used.
To perform remote observing, you need three essential tools – the PORTAL which allows you to communicate with other observers; the FROG which provides you with situational awareness of the telescope through audio and visual feedback; and two VNCs in which the observing software is run and the various observing backends are controlled. NOTE: A fourth tool is now also available that allows observing to be conducted, with the UWL receiver, via a browser based system - DHAGU, Section 184.108.40.206.
Ideally, we recommend that three separate screens be used to allow easy visual monitoring of the observation. In one screen we display the first VNC in which the observing software is run. On another screen we have the second VNC in which we run the correlator and other related software. Finally, in the third screen we have the PORTAL and FROG running in browsers. Since these two provide audio feedback, they should operate on machines that have a sound card with the volume turned up.
Figure 3.1. A typical setup for Remote Parkes Observing. L-R: Screen 1 with VNC2 running the correlator software; Screen 2 with VNC1 running the primary observing software; Screen 3 with the PORTAL and FROG. NOTE: This three screen setup is not essential, but it does allow for easy visual monitoring of the observation. Also to note for UWL observations, the first screen would be replaced with an additional web browser window containing DHAGU and the second would show the VNC1 desktop but with the UWL GUI for LNA control and OPERFCC for receiver translation.
In order to begin observing, you will need a CSIRO Unix account and password. If you do not have one, then please arrange to obtain one at least 2 weeks before you begin the observing session.
It is important to ensure that you have audio enabled.
If you are taking over as the designated observer, firstly, alert the current observer to begin the hand-over process by typing a message in the chat window of the PORTAL. Then click on the Observer-in-Charge button and register; further details below.
ssh -NfL 5901:joffrey.atnf.csiro.au:5901 firstname.lastname@example.org
In another xterm, type the following for joffrey:2
ssh -NfL 5902:joffrey.atnf.csiro.au:5902 email@example.com
If you want to monitor Medusa directly, via the SPIP page:
ssh -NfL 8000:medusa-srv0.atnf.csiro.au:8081 firstname.lastname@example.org
NOTE: ident is your CASS Unix account (NOT your NEXUS account). If you have trouble accessing orion.atnf.csiro.au, you can also try venice.atnf.csiro.au .
Start the VNC client on your local computer and connect to 127.0.0.1:5901, which is the VNC1 window.
Start another VNC client on your local computer and connect to 127.0.0.1:5902, which is the VNC2 window.
To access Medusa, point your web browser to https://localhost:8000/spip/ NOTE: If you see an error stating the connection is not secure, it is because the security certicifcate is only valid for addresses *.atnf.csiro.au and not localhost. It is left to the observer to determine the risks associated with continuing on or not. If in doubt, contact your IT department. Also, the SPIP page does NOT automatically load current status automatically. To do this, simply click on the required tab at the top of the SPIP page..
You will need to login with the VNC password. This password will change at the beginning of every observing semester, so be sure to get the new password if you are observing for the first time in a semester. Visit this site for instructions on how to get the new password here. When observing from within CSIRO (either from an onsite computer or through a VPN), open an xterm on the computer you are using for the remote observing and start the vncviewers for joffrey.
For VNC:1, open an xterm and type;
vncviewer joffrey:1 -shared
For VNC:2, open another xterm and type;
vncviewer joffrey:2 -shared
If you are wanting to access Medusa directly, use the following URL: https://medusa-srv0.atnf.csiro.au/spip/
The PORTAL allows the observer to communicate with other observers, to hand-over observing from one observer to the next, to troubleshoot, book observing sessions and generally setup and register as the current observer. It also allows the observer to post fault reports and find information and observing documentation.
The PORTAL can be accessed via a browser from this web address. Be sure to bookmark the address so that you can access it with ease, at a later time.
You will need a CASS Unix account and password to access the PORTAL. NOTE: Your CASS account is unique to you and it allows us to identify you and to determine if you are qualified to observe or not.
When an observer logs in, the alerts are first displayed in a message window. Alerts are issues that may cause problems during an observation. It is important to read these alerts every time you log into the PORTAL, since they are updated frequently. Take note of the alerts, and follow the instructions (if any) on how to avoid or mitigate the problems or issues. Once they have been read, click outside the alerts window to continue to the PORTAL’s main page. If the alerts were missed, then they can be accessed again by clicking on the “Show Alerts” button.
Alerts that are for your information only, are displayed in blue. Warning alerts, such as impending severe weather and RFI, are displayed in orange, and critical alerts, which will cause you to lose observing time, will be displayed in red. Note that for critical alerts, they are also emailed to any observers that have booked on the PORTAL. To cater for weekends, any critical alerts posted on a Friday are sent to all observers booked within the next 72 hours, or 48 hours if the issue occurs on a Saturday. The default is four hours, which is the same time use for weather-based (warning) alerts.
Once logged in, the times are displayed at the top of the PORTAL. The Parkes observing schedule is in Australian Eastern Standard Time (AEST), which is UTC+10 hours. It is important to note the time difference between AEST and the observer’s local time, so that a start time or finish is not missed - you don't want to be late for an observing session and lose that time.
Modes of operation:
There are three modes of telescope operation – Observing Mode, Verification Mode and Maintenance Mode.
When the telescope is in observing mode, the mode is displayed in green with a green background and normal observations can proceed. The VNCs will be enabled and the observer can register as the Observer-in-Charge (OiC).
When the telescope is in maintenance or verification mode, the mode is displayed in red with a red background. The VNCs are disabled from outside access. Verification mode is intended for use by science operations staff to conduct post maintenance tests prior to hand over to observing. To note, you can't register as the OiC while in either of these modes. These precautions are necessary to prevent any off-site observer from inadvertently accessing the VNCs and taking control of the telescope and moving it about when maintenance is being undertaken. Staff may be on the dish surface, in the focus cabin, or elsewhere on the telescope. Moving the dish, or any other equipment, while work is being done on them could cause the staff members to be seriously injured or the telescope and equipment damaged. Only when the staff member who is responsible for the maintenance is satisfied that it is safe to resume observing, is the operating mode switched back to Observing Mode and normal observing resumed.
NOTE: Sometimes the maintenance runs overtime, or finishes earlier than planned. It is important to check the chat utility for notifications on when the observing will resume, to avoid missing an early start or arriving un-necessarily early if maintenance runs overtime.
On the left, is the Chat Utility. An observer types a message in the text box at the bottom and the message is then displayed in the box above it. The observer’s name, with the date and time that the message was posted, is displayed so that other observers know who they are communicating with. The OiC’s initials are displayed in green circles, while all other users are in blue circles.
Registering as the Observer-in-Charge (OiC):
It is important to register as the OiC as soon as possible after you take over. If there is no OiC registered, then the observing team is alerted via email and asked to immediately arrange an observer to register and do the observation. This is a security issue, since we don't want the telescope to be unattended and capable of being moved about with nobody in charge. There must always be someone in charge and looking after the observations. It also means that we can check that the person who has registered as the OiC, has undergone the Remote Observer Training and is certified as a qualified observer.
To register as the OiC, click on the Observer in Charge button. You will be presented with a pop up window in which you have to enter your contact telephone number. Select from one of the options in the pull down window. The contact telephone number for that location will be displayed, except for the “Other” option. If you are observing from a location that is not listed, select “other” and enter the telephone number manually. Be sure to include the country code and area code along with the telephone number. For example, +61268611755 is the number for the Parkes Control Room (+61 is the Australian country code, 2 is the area code, and the 68611755 is the control room telephone number).
Your name will then be displayed under the OBSERVER IN CHARGE heading on the RHS. For privacy reasons, the telephone number displayed (+61268611750), is a re-direct number to the telephone number you entered when you registered as the OiC.
If the observer is not certified, operations staff will be notified and appropriate action taken. NOTE: The observer’s CASS Unix username uniquely identifies the observer.
Emergency Contact Person:
Every day, a Parkes staff member is rostered on to be the emergency contact person (ECP) in case anything should go wrong with the telescope. For privacy reasons, only the mobile phone number of the ECP is displayed.
The booking tab is where the observing schedule for the current semester is presented and where observers can book their observing sessions.
The next seven days of the schedule is displayed when you first open this tab. Clicking on the “left” and “right” arrows on the top left hand side of the schedule, allows you to move forward and back through the schedule.
The scheduled time is shown as coloured blocks.
- Grey: Grey blocks are observing times that have not yet been booked by any observers.
- Light Turquoise: These are the maintenance times. Observers can not book to observe in these times.
- Dark Turquoise: These are observing times that have already been booked.
- Yellow: These are reconfigs when receivers are either installed or removed from the focus cabin.
- Green: Green time is observing time that has not been assigned to any project. Observers can request to use this time by emailing the scheduler. See below.
The times default to UTC, but this can be changed to your local time, by clicking on the timezone button. This makes it easier for you to schedule your observations to match your individual work schedules. NOTE: The local time is taken from the clock setting on your local computer or laptop.
To book an observation, first click on the settings button and enter the location and telephone number of the place you intend to perform the observation from. Then move through the schedule to the date that you want to observe. In the grey project block, put the cursor at the start time of your booking and drag the cursor to the end time. A popup menu will appear showing the start and end times you just selected. If these are not quite correct, then they can be corrected by manually edited the dates and times, before submitting them. Your name then appears in the block for the range of times you selected.
Observers can request Green Time by simply booking the Green Time as per the normal booking procedure above. Your request will then be emailed to the scheduler for approval, see Section 220.127.116.11.
It is important to book an observation because it allows the system to determine that a new observer needs to be trained beforehand. It also allows the PI to know that observers have signed up to perform the observations. Two weeks before the scheduled start of the observation, the system will check to see if anyone has booked the time. If not, the PI will be alerted by email that no observers have booked the time. The PI should then have sufficient time to organise experienced observers or to arrange new observers to be trained. The two weeks gives the PI enough time to organise the CASS Unix accounts and training, if required.
The FROG provides the observer with situational awareness of the telescope through audio and visual feedback. When the Parkes version was developed, it was decided to give it a similar name to TOAD (Telescope Operator Alerting Display) which is in use at the Mopra observatory; since Mopra had TOAD, Parkes was given a FROG.
The FROG is a combination of some old observing tools, such as showtel and winds, plus a few new features that provide greater situational awareness for remote observers.
Like the PORTAL, the FROG can be accessed from a browser at the web address linked below. Also like the PORTAL, you will need a CASS Unix account and password to access it.
The Synoptic page on the FROG utility.
Left-Hand-Side: This is the region that shows you what the telescope is doing. It displays the coordinates of the position it is pointing at, what receivers are installed and which one is currently on the focus and being used.
Centre: A webcam image of the telescope is displayed here. It is updated every five seconds. It shows, in a single glance, the state of the telescope, that is, whether it is stowed or tipped over; whether it is day or night; whether it is clear or stormy etc.
Below this is the plot of the wind situation in the previous one hour. Every 20 seconds, the winds program looks back over the previous two minutes of wind data. It determines what the maximum wind speed was in that two minutes and also calculates the average wind speed in that two minutes, it then plots the data. The solid blue line is the maximum wind speed and the shaded blue region is the average wind speed. The coloured regions are:
White: As long as the winds stay in the white area of the plot, from 0 to 35 kph, then all is fine.
Yellow: When the winds are in the yellow region, between 35 to 45 kph, then there is a high likelihood of the dish being wind parked at some point.
Orange: If the wind is in the orange region, between 45 to 50 kph, then you will very likely be wind parked.
Red: If the wind is in the red region, then it may be some time before you can resume the observations. You just have to wait for the winds to drop sufficiently for it to be safe enough to resume.
Right-Hand-Side: This is the sky plot visible from Parkes. The centre of the concentric circles is the zenith and the outer circle is the true horizon. They are in 10 degree increments. The red, inner circle is the telescope’s 30-degree elevation horizon. Your sources must be within this circle in order for them to be observable at the time.
The solid blue line extending from the centre to the edge, is the azimuth the telescope is pointing. The hollow red circle on this line is the position the telescope is pointing on the sky. The small solid, red circle is the position of the source on the sky and the red line extending to the left, is its future track, with the remaining tracking hours marked on it.
Behind the dish are two dashed, blue lines, creating a 60-degree segment (30 degrees either side of the back of the dish). It is important to avoid having the wind in this direction if the winds are high, since the wind will tend to push the dish down, creating a high likelihood of a wind park.
The blue arrow head jumping around the inner edge of the outer circle, is the wind direction. It grows in length as the winds pick up. When the arrow head reaches the centre of the circles (the zenith), the telescope will be wind parked. The cloud of orange dots around the arrow head are the average wind directions over the past hour. The darker the dots, then the more recent were the average wind directions.
The orange solid circle is the position of the Sun, and the grey solid circle, is the Moon. It’s good to know where these two are, in case you happen to be pointing at them and wondering why you can’t detect your source. FROG will issue an audio alert if you are within one degree of these objects.
Around the outer circle is a green curve with a cut-in. This is the wrap limit of the telescope. The telescope cannot simply turn round and round forever, in azimuth. At some point it will need to stop and go around the other way. The two wrap limits are at the 205 degree and 295 degree azimuth positions. The active limit is shown as a cut-in. You cannot cross these limits. When slewing from one source to another, the control system will slew the telescope in the appropriate direction to avoid crossing the active limit. However, when it passes the crossover point at 68 degrees azimuth, the green curve will flip and the cut-in will be shown at the new active limit.
As the telescope slews from one source to the next, a yellow progress bar will appear on the outer edge of the horizon circle. The slew time and time remaining will also be displayed.
Just above the sky plot is a settings icon. Clicking on this will bring up a menu. You can select additional items to display such as the planets, the galactic plane and various satellite constellations. Certain satellite constellations could have transmissions in your observing band. By knowing where they are on the sky, you can better avoid them to minimise RFI. With the Solar scatter lobes option, you can display the scattering cones of the three feedlegs of the antenna. When a strong source (such as the Sun) lies within one of these scattering cones, radiation will be reflected off the feedlegs, and into the receiver. This option is useful to help minimise Solar ripple in data during daytime observing.
Figure 3.4. The TPS display in the control room. This can be accessed by the ECP to remotely resolve the issues and problems.
The Telescope Protection System (TPS), is a device that monitors hundreds of data points on the telescope. If it detects an issue that might be a major problem or concern, then the Emergency Contact Person (ECP) is alerted via SMS and various other alarms. The ECP can log into the system to see what the problem is and if needed can be at the telescope within minutes to resolve the issue and make the telescope safe. The TPS page on the FROG displays the various monitoring points. If one or more of these is red, the observer can see what the issue is by clicking on the link. A popdown menu will appear showing a summary of the issues. This display is only for information only. It cannot control the TPS. The ECP however, is able to log into the TPS to remotely resolve the issues and problems.
The TPS display in the control room. This can be accessed by the ECP to remotely resolve the issues and problems.
Note that Grafana may soon be replacing FROG. Currently, the Grafana instance is only accessible from within the CSIRO network and the FROG page can be accessed here.
For TOS/Medusa observing, you will need to log into DHAGU.
Whilst it is possible to login at any time to create Parameter Sets and manage Scheduling Blocks, you will need to register as the Observer in Charge via the PORTAL to submit Scheduling Blocks to the Observing Queue. The current Observer in Charge is displayed under the Queue tab in DHAGU. Note that when you register as Observer in Charge, you then have the ability to remove any Scheduling Blocks that are queued from the previous observing team.
Handover between observers is done via the PORTAL. Observers should login prior to the start of their allocated time and open a line of communication with the current observer. Ideally this is done at least 5 mins prior to the hand over and allows for the current observer to cleanly finish their observations. The expectation is that the current observer finishes in time to hand over at the allocated time unless an agreement has been made between the two sets of observers (for example if the current observer needs an additional few minutes to complete the current scan and the next observer is not time critical). If the current observer is unresponsive on the portal the new observer should allow a period of up to 5 minutes grace before taking over control.
If the handover is between local staff from a maintenance session to remote observers then the same PORTAL process is followed, but is subject to the completion of any maintenance activities. This exchange will also involve the switching from ‘maintenance mode’ to ‘observing mode’, done by the observatory staff.
The current number one golden rule for changing receivers is to only do so when the telescope is either parked or stowed - this is to reduce stresses on the telescope infrastructure. Please use the FROG interface to determine when the Dish is parked or stowed.
When it is parked/stowed you can translate the receiver so that the UWL is on axis. In the joffrey:1 VNC window, find the ‘OPERFCC’ GUI. Ensure that the UWL radio button is selected and then click on the yellow box “place selected receiver on axis”. Wait until all the “status” lights near the top are green (takes a couple of minutes).
Once the UWL is on axis, you may need to power on the low noise amplifiers (LNAs). The control for the UWL LNAs is located on the second screen in joffrey:1 VNC. The GUI is titled ‘CS-Studio GUI’. Select the ON button in order to turn all the LNAs on. If all of the LNAs don’t turn green, select the ON button again. Note that DHAGU/TOS will automatically turn the LNAs to the ON position when a Scheduling Block is submitted.
If you cannot find the GUI on any of the joffrey:1 VNC virtual desktops, you can restart the GUI by opening a terminal in joffrey and typing the following:
> cd UWB > /askap/default/bin/CSS uwb_obs.opi
This tab gives the observer a general overview. The left panel shows the Queue Status section, and the current state of the Observing Queue and current Observer in Charge. In the center panel, a synoptic view of the antenna. The right panel shows health status for various TPS monitoring points. Clicking on a section will zoom in and clicking on the central circle allows you to zoom out. Presently, there are no monitoring points associated with the UWL receiver, or Medusa.
The circular donut is a graphical representation of the Observing Queue. When a Scheduling Block is running, information about the Scheduling Block is presented therein (Scheduling Block number, scan number, …). The arc will increment until the Scheduling Block completes. When the Observing Queue is running, the donut should be green. When stopped or aborted, the donut will be red. When a Scheduling Block is running, the countdown will be shown as a blue overlay, incrementing until the Scheduling Block completes. The Observing Queue runs Scheduling Blocks in time mode, where the Scheduling Block ‘scheduler.time’ variable is used to determine the order, with the closest to the current time run first. There is a FIFO (First In, First Out) mode, but this mode is currently not in use.
The synoptic view is essentially the same as that in FROG. However, there are a few minor differences in that the display is an Orthographic projection, whereas FROG was a flipped Stereographic projection. Currently, only satellites, planets and the Galactic Plane are options, available from the cog menu.
The Health indicator shows TPS monitoring points for various subsystems- Antenna, Comms, Config, Cryo, Power, Temps and Weather. Beneath these, are individual monitoring points. You can view these points by clicking on any top-level panel. To zoom out, click on the central circle. If any individual point is in an alarming state, it will turn from green (status = ONLINE), to red (status = OFFLINE). As a result, the parent panel, will also turn red, to indicate there is an issue. Presently, there are no audio alarms associated with an OFFLINE state. Also, there is no monitoring of the UWL receiver, or Medusa, but these will be added when available.
This section shows the current Observer in Charge, plus status of the Observing Queue. If a Scheduling Block is currently executing, the parameters are displayed, along with the progress meter.
The Executive controls are also presented here. In order to submit Scheduling Blocks to the Observing Queue, you must be the Observer in Charge, currently set via the Observing PORTAL. Under Queue Control, the START, STOP and ABORT buttons allow the observer to control the state of the Observing Queue. The START button initiates the Observing Queue, allowing Scheduling Blocks to be submitted. The STOP button allows the observer to STOP the Observing Queue after completion of the current Scheduling Block. The ABORT button stops the Executive, and errors the currently Executing Scheduling Block. The Facilities Configuration Manager (FCM) shows TOS and Medusa “system variables”. By clicking on the FCM button, they are provided as a table with search facility, and provided for debugging purposes.
This table shows Scheduling Blocks that are currently awaiting execution in the Observing Queue. For each, the unSchedule button allows the observer to select, and remove multiple Scheduling Blocks from the Observing Queue. When this is done, they transition from SCHEDULED to SUBMITTED (these can be viewed under the Manager tab). This process is useful, especially if you are taking over from another project and wish to remove their Scheduling Blocks from the Observing Queue before starting. Only the current Observer in Charge can unSchedule via this table.
The log from TOS is displayed here. Along with the progress of the Scheduling Block, errors will be also presented. The table is searchable. Messages are colour-codes according to status, with red highlighting an ERROR, and normal messages in blue and warnings in yellow. Note the table will only display 500 messages, then reset. The full logging associated with a Scheduling Block can be viewed from the Manager tab.
It is anticipated that once Parameter Sets are loaded, the bulk of submitting Scheduling Blocks will be done from the Scheduler tab, as shown above. To load in a Parameter Set, click on the Load button, select your project, and a list of all Parameter Sets will be displayed, as shown below.
Click on the required Parameter Set to load. Once the Parameter Set is loaded in, you can view the Parameter Set by clicking on the Show parameters button.
To initiate an observation, simply select sources you wish to submit to the Observing Queue, then press the Schedule button. Note the Scheduler table allows multiple column sorting, to help identify sources which are visible. For example, you can order the visibility column by clicking the ordering button next to the column title, and then, while holding the SHIFT key, click on another column ordering button such as Azimuth. This allows you to order the table by visibility (true/false) and increasing/decreasing Azimuth. To reset the ordering, simply click on the ordering button in another column.
Once sources are selected and the Schedule button is clicked, the Scheduling Block(s) with the sources selected will be created, with state changes from DRAFT to SCHEDULED. If there are no Scheduling Blocks in the Observing Queue, the transition will go from SCHEDULED to EXECUTING. Monitoring of the observation can take place from the Observation Status tab.
A limited number of scheduling options are currently supported. These are accessible by clicking on the Options button.
- Auto refresh?: This will update the rise, set and visibility parameters of sources automatically, every 10 seconds.
- Hide Scheduled Sources: Selected sources are removed from the table when scheduled. You can click the Reload button to display all sources in the Parameter Set. Note that removing sources from the table is not propogated to other users using DHAGU.
The position of sources in the loaded Parameter Set will be presented on the skyglobe in blue if currently visible (also check the table for visibility), and red if below the antenna horizon. You can click and drag the skyglobe to change the view. It is also possible to zoom in using pinch for mobile devices, or mousewheel; this is useful for crowded sources. The position of planets, Sun and Moon are also shown. The thin vertical line represents the current LST at Parkes. You can press the Refresh ephemeris button to update both the positions on the skyglobe and Azimuth, Elevation, visibility and rise/set parameters on the table.
The Manager tab provides the (experienced) user with fine grain control over parameters sets (editing/retiring), adding comments to Scheduling Blocks, assigning multiple projects to a Scheduling Block (commensal projects), transitioning Scheduling Blocks to other states, submitting Jira tickets and viewing comments for problems associated with the Scheduling Block and more.
Available Parameter Sets
By selecting a project from Available Parameter Sets, a list becomes visible. The observer can click on any to view, edit or retire via buttons, as shown below. Note that retiring a Parameter set means it will no longer be visible or selectable from DHAGU.
Scheduling Block Status / Management
The colours of Scheduling Blocks map to their state:
- DRAFT: Orange
- SUBMITTED: Yellow
- SCHEDULED: Blue
- OBSERVED: Green
- ERRORED: Red
For each Scheduling Block, there is a link associated with the ID. Clicking on this link brings up the Scheduling Block Management Tool.
These are Annotations associated with the Scheduling Block. In the example below, the details associated with the creation of the Scheduling Block are shown.
Obs User Params
This represents the parameter set of the Scheduling Block. It is not possible to edit the parameter set from here.
The Log tab presents the observer with execution logs. If there are errors associated with a Scheduling Block, here is where to look (and put in a Jira ticket?)
The State Transition tab allows the observer to transition a Scheduling Block. This may be useful, for example if the Scheduling Block was currently in the ERRORED state because of an incorrect parameter set, you can transition to RETIRED. Another example is when a Scheduling Block is in the ERRORED state, but the error was caused by the antenna reaching the horizon limit. If the data are good, you can transition the Scheduling Block to OBSERVED. The New state select widget will display allowed transition states for the current Scheduling Block (see here). Note a comment on the reason behind the transitioning is required.
You can assign other projects to the selected Scheduling Block. Simply check those projects which might have a common interest and click the Save button. Note when searching for Scheduling Blocks in other sections of the UI, if the project being searched for is tagged as a commensal project in a Scheduling Block, it will appear. For example, by selecting P455 and P743 for the example Scheduling Block above, despite it belonging to the Testing project, searches for P455 and P743 will return this Scheduling Block in the results.
It is possible to add comments to the Scheduling Block by clicking on the Comment button. A text entry field appears and comments can be entered and saved. This is useful for projects to keep a central record of any observing, processing or general comments relating to the Scheduling Block. Comments are saved as an annotation.
If there is an issue associated with a Scheduling Block, the observer can submit a Jira ticket. If a Jira ticket exists, a link to it will be provided. Currently a CSIRO NEXUS account is needed to login to Jira to view the ticket, but eventually comments entered directly into the Jira ticket could be shown here instead of just a link.
This tab provides an in-built alternative to the Medusa SPIP webpage, which requires either access from the CSIRO internal network, or SSH tunnelling (see Section 18.104.22.168). On the top left, there is an panel with options to stop and start the DHAGU image service. If you notice plots have not been updating (they should every 10 seconds), then try restarting the service; this is not associated with Medusa, but an internal process within DHAGU to retrieve plots and information from Medusa.
Below the image server control, is the Observational Parmameters panel. This contains information about the source currently being observed. The next panel relates to the Medusa GPU status. If you notice the disk usage is high (85%+), you may have to stop observing briefly, to allow the data to be transferred from Medusa, to the data staging server (Euryale).
On the right are tabs for each Medusa mode, Continuum, Fold and Search. Whichever is currenty active is identified with a green arrow; in the example above, only the Continuum mode is in operation. Clicking on any tab will show plots associated with that mode. For Continuum, this is a bandpass plot for each of the selected subbands. Note with commensal modes, at most any two tabs will be indicated as active.
The telescope is stowed for maintenance and following weather events such as strong winds. To stow the telescope manually, when using DHAGU, the observer must go to the VNC session and locate the UWL 'CSS' gui window for the UWL receiver. On this window is a button to stow the telescope. If the UWL gui is not running, it can be restarted from the tools on the bottom bar of the VNC window. The status of the stow/unstow can be seen on FROG, or the CS-Studio GUI.
When the telescope is parked, it is possible that it can drift into the ‘dead zone’. This is the Zenith angle currently defined by the range 0.95 to 1.15 degrees- the antenna park position is 1.2 degrees. If the antenna falls within this zone (check FROG), you will hear an audible alarm from FROG. In order to exit this zone, you can hope the wind will push the antenna back out, or manually stow and then unstow the antenna.
There are two main weather phenomena that could cause you to lose observing time - high winds and lightning (on rare occasions extreme heat may also affect the ability to observe with given receivers). In the case of heat stows, directions will be posted on the PORTAL.
A good source of weather information is the Weatherzone site for Parkes.
Wind Parks: The dish has a large surface area, and under high winds it can experience forces that can render the dish unsafe for continued observing. For safety, whenever the winds pick up to levels that are considered unsafe, the control system will automatically take control and drive the dish to the Zenith (the safe position). This is referred to as a wind park. This will usually occur whenever the winds are around 40 to 45 kph. But, it does depend on other factors such as tip angle, wind direction and motor currents. For a full description of wind parks, see Section 3.3.3
Storm Stows: The Observatory has three sources of power - mains power, backup generator and UPS (batteries). Whenever there is a storm, there is often a high likelihood of lightning, too. The lightning can cause a disruption to the supply authority mains power. Normally, whenever we lose mains power, the generator should start automatically and provide power until the mains returns. If the generator fails to start however, then the drive UPS has sufficient power to allow you to drive the dish to the zenith and fully stow it. In this position the dish is guaranteed to be safe.
With the advent of remote observing, we have adopted a very conservative approach to lightning. We don’t ever want the situation arising of having the dish tipped over in a storm with high winds, and no power to stow it and make it safe. So, whenever lightning is detected, and while we still have power, the control system automatically takes control to stow the dish and make it safe. This is referred to as a Storm Stow. The dish remains stowed until the storm passes and the lightning levels drop to zero. The dish is then released and normal observing resumed.
FROG will produce audible alarms if a TPS monitoring point’s alarm state transitions to true. The popup will inform the observer what the issue is. Depending on the severity, the TPS may take control of the antenna and stow. The observer has the ability to mute alarms, but note that if the TPS issues the alarm again, the mute will need to be redone.
An Alerta system is being developed, which will provide an audible alarm when any telescope subsystem transitions from a status of OKAY. As with FROG, a message indicating the problem (and possible solution), along with the severity of the issue will be indicated. It will be possible for the observer (and staff) to “shelve” the alarm, thereby removing it from the list. It will also be possible to click on a link, which points to a Grafana monitoring page, to allow people to drill down into the nature of the problem.
The status of the Medusa backend can be monitored in three ways:
Once you have initiated your observations, check that your parset has been successfully interpreted by Medusa. You can check this either under the `Medusa’ tab on DHAGU or on the Medusa webpages. In the latter case, the page headers should read either “Idle” or “Recording” followed by your observation type (i.e. `Fold’, `Search’, or `Continuum’).
Note the “recording” status (it will be “idle” if Medusa is not recording) and check the UTC_START. This is the start time of the observation and the archived data files will have a name based on this date and time.
Note that a set of plots are given for each sub-band. At the start of each observing file, it is also good to confirm that the plots are updating correctly. It is possible for the observation header to update, but the plots do not. If the plots seem stalled, or are associated with previous observations, try stopping and starting the instrument.
Look carefully for mis-configured parameters:
If you see `Misconfigured’ at the top of your observing page header, there is something wrong with your Parameter Set. Stop your observations, check your Parameter Set, and resubmit in order for Medusa to configure itself properly.
The status of the GPU workload can be seen on the MEDUSA tab of the DHAGU webpage. If the `Disk’ and/or ‘Load’ status bars are red, consider stopping your experiment until the nodes have caught up with your observing load. If your observations will produce extremely-high data volumes (>100 GB/hour), be sure to have discussed your observing plan with Medusa and Euryale experts to be sure the system can support your data rate.
The same status icons listed above can also be monitored on the Medusa webpages underneath the `Status’ tab. This page has the added bonus that you can also monitor the Shared Memory Ring Buffer statuses. Red SMRB indicate that you may be dropping packets and have incomplete data.
On the Medusa Controls Page, which can be accessed by selecting the `Controls’ tab from any Medusa webpage, it is possible to monitor any issues within the server controls of each of the GPUs. There are also global buttons near the top of the page that allow you to stop or start the Medusa backend.
If the circles on the control page are gray, or you believe that the Medusa system has stopped working (plots are not updating etc.) then click on “Stop Instrument” at the top of the webpage. Wait at least 60 seconds. All the lights should now be red. Then click “Start instrument” and again wait at least 60 seconds. If that fails then contact local staff.
When starting Medusa, all the Individual Server Controls must be OFF (red or grey). Click the Start Instrument button once and wait for the all the controls to change from OFF (red/grey) to ON (green).
When stopping Medusa, all the Individual Server Controls must be on (green). Click the Stop Instrument button once and wait for all the controls to change from ON (green) to OFF (red/grey).
Killing Medusa, should only be used if the Stop Medusa function fails to shutdown Medusa within the allotted 120s timeout. Click the Kill Instrument button once and wait at least 30 seconds for the controls to change to OFF (red/grey). When they are all red/grey you may click Start Instrument.
The SERVO computer monitors the speed and direction of the wind from the (default) paddock sensor, and will stow the dish automatically above limits (defined in the table below) to ensure the safety of the antenna. Winds can be monitored with FROG.
Table 3.1. Wind Stow Limits
|Anemometer||Peak (km/h)||Gust (km/h)||Average (km/h)|
|Ane #1 (Az front)||58||54||42|
|Ane #1 (Az back)||46||42||35|
|Ane #2 (Az front)||66||62||48|
|Ane #2 (Az back)||53||48||40|
During an automated wind park, the antenna drives to an Azimuth that has the wind at least 60-degrees away from the back of the dish without driving into an Azimuth limit. If you are observing near one of the limits and there is an easterly wind this could involve driving up to 100 or so degrees. In addition, the antenna will drive to a (software limit) Zenith angle of 1.2 degrees.
Important If the wind is particularly high, the antenna can be driven into the Zenith hardware limit past 1.2 degrees. You will need to exit the limit by stowing and then unstow the antenna using the unstow button on the CS-Studio GUI (Figure 3.6) which usually runs on the joffrey:1 VNC.
The Peak (2 consecutive readings), Gust (5 readings in the last 180), and Average (15 readings in the last 20) values (in km/hr) must be satisfied for a wind park to occur. The ``Az back’’ for each Anemometer are for winds within Azimuths 150 degrees < Az < 210 degrees (ie, winds within 30 degrees of the back of the antenna). The ``Az front’’ values are for the remaining 300 degrees ``front-on’‘sector. A wind park holds the antenna at the software limit (Ze ~ 1.2 deg.) limit for 10 minutes until the countdown expires. At the end of this period the antenna is free to obey any pending or new programlistings.
Warning Once an automatic wind park has occurred, the antenna must not be moved until permissible conditions have prevailed for at least 10 minutes. If conditions are poor, the antenna must be fully stowed.
The telescope Protection System will automatically stow the telescope in the event of significant lightning strikes. There are three radii: Far (20-56km); Near (10-19km); and overhead (less than 10km). The numbers of strikes are weighted with those ‘far’, ‘near’ and ‘overhead’ respectively as x1, x10 and x45. The number of weighted strikes are summed and if the total is: 22 - 52, a storm warning is given; 52 - 102, a suggestion is made to start generators; 102 - 202, generators are started automatically; > 202, telescope is stowed automatically. The stow is released (and generators turned off) once levels drop below the thresholds.
We realise that observers are busy people who cannot always be in front of their observing computer for the entire duration of their experiment. The observatory can be operated in “unattended” mode when it is convenient to do so. This section describes how best to observe in this way, and what is expected from you during your experiment.
When we talk about “unattended observing”, we mean any period during your experiment where you are not immediately aware of the state of the telescope. You may be any distance away from your observing computer, or asleep, or otherwise engaged in another activity, but you are listed as the “observer in charge” on the PORTAL and can be reached in an emergency through your designated contact number.
The observatory does not require you to be responsible for the safety of the telescope equipment or of personnel. We have sophisticated systems and procedures which should handle any unsafe situation that might arise during a normal observation. For example, the automated systems (TPS described in the preceding section) will turn on the generators when a storm is approaching, and turn them off when it passes. It will also automatically handle stowing in periods of high wind, or when there is a high chance of lightning strike.
We do however expect that you are solely responsible for monitoring the quality of your data, and we do expect to be able to contact you via the phone number you supplied when you registered as the observer in charge. You should consider how often you need to check your data quality, given how much time you could lose if something goes wrong.
Telescope safety resides with the National Facility and is intended to be automated. However this does not preclude the potential for unforeseen events.
To request Remote Observer Training, email atnf-parkes-remobs[at]csiro.au
Issues related to data archiving or data access, email Lawrence Toomey: Lawrence.Toomey[at]csiro.au
The Emergency Contact Person (ECP), phone: +61 427 001 583
The Observer-in-Charge (OiC) re-direct phone number: +61 2 6861 1750
The Project Expert: All projects will have a nominated project expert. This is a person assigned by the PI of the project to be the “go to” person for members of the team whenever a problem arises during an observation. It should be someone who is sufficiently knowledgeable and experienced to troubleshoot any problems that may arise.
To submit a fault report, email parkes.support[at]csiro.au with as much detail on the nature of the problem as possible.
High time resolution data sets are available from CSIRO’s data archive (the Data Access Portal, DAP, https://data.csiro.au) and high frequency resolution data from the Australia Telescope Online Archive (ATOA, https://atoa.atnf.csiro.au).
The standard procedure is that the raw data sets from all Parkes observations are publically available after an 18 month embargo period (from the date of the observation), or in the case of a Target of Opportunity, within a week. Any deviation from this procedure, for example a longer embargo period, has to be through agreement with the CASS Director and with approval from the ATNF Steering Committee (or through contracted telescope time).
Data is archived as soon as possible following observations. This archiving process is contingent on projects adhering to the data rates that they proposed in their OPAL proposals. If the data rate is exceeded in the observations (with the use of additional unrequested modes or capabilities) the data archiving may be interupted, and in extreme circumstances may need to be deleted to allow other scheduled projects to proceed.
To calculate data volumes with the UWL:
- Pulsar Search: File size [bytes] = Nchan x Npol x Nbit/8 x Tobs/Tsamp
- Pulsar Fold: File size [bytes] = Nchan x Npol x Nbin x 16/8 x Nsub
- Spectral line mode: File size [bytes] = Nc_sb x Nsb x Npol x Ndump x 32/8
- Voltage Capture (non-standard): File size per zoom band [bytes] = Nbit/8 x BW x 1e6 x 2 x Tobs x 2
- Nc_sb = number of channels per subband
- Nsb = number of subbands (normally 26 for the UWL)
- Nsub = number of subintegrations in pulsar fold mode
- Nchan = total number of channels = Nc_sb * Nsb
- Npol = number of polarisation states (1, 2 or 4)
- Nbit = number of bits/sample (1, 2, 8, 16 or 32)
- Tobs = observation time (seconds)
- Tsamp = sampling time (seconds)
- Ndump = number of spectral dumps (the total integration divided by the spectral dump time (seconds))
- BW = bandwidth in MHz
Noting that the total data volume will be a few percent larger than that given by the equation because of the need to store meta-data information.
High time resolution data sets are stored in PSRFITS fold and search files. Within 2 weeks of observation they are available for access from https://data.csiro.au. Various access mechanisms are possible including:
- Web download from https://data.csiro.au using OPAL or NEXUS account for sign in
- Access from CSIRO high performance computing systems
- Searching using VO tools such as TOPCAT (http://www.star.bris.ac.uk/~mbt/topcat)
For more general DAP information and assistance:
- Contact Research Data Support at email@example.com or phone: +61 2 4960 6086
Information on data access for CSIRO computer (and HPC) account holders can be found on:
For non-CSIRO users, information on data access can be found on: https://bitbucket.csiro.au/projects/CPDA/repos/pks_data_access_docs/browse
Standard meta-data are stored within each PSRFITS file (as defined in https://www.atnf.csiro.au/research/pulsar/psrfits_definition/PsrfitsDocumentation.html). Currently all o bservations with the UWL are assumed to be tracking observations of a given source. The meta-data therefore only contains the right ascension and declination of the source at the start of the observation.
Pulsar fold-mode observations (and related calibration files) can be processed using the PSRCHIVE (http://psrchive.sourceforge.net/) and pfits software suites.
Calibration solutions that enable both polarisation and flux calibration are available for download from https://doi.org/10.25919/5ce76bf409bcf (and described in Hobbs et al., submitted to PASA). Typical processing commands would be:
- Use pfits_zapUWL for automated RFI flagging
- Use pfits_zapProfile on the output for any final manual flagging required
- Use psrsh for calibration with a script similar to:
load <filename> install par <best parameter file> cal load hybrid <alfile> <pcm calibration file> cal cal frontend cal load <flux cal file> cal flux
Then further processing tasks (such as selecting specific bands of interest, or frequency and time averaging) can be carried out.
Pulsar search mode observations can be processed using DSPSR (http://dspsr.sourceforge.net/) to fold the data at the period of a known pulsar and to extract individual pulses. The output is then a fold-mode profile which can be processed as described above. To search for new pulsars then PRESTO (https://www.cv.nrao.edu/~sransom/presto/) or the SIXPROC (https://github.com/SixByNine/sigproc) version of SIGPROC can be used (note that default SIGPROC can not process PSRFITS search mode files).
The spectral line and continuum data sets are stored in the Australia Telescope Online Archive (ATOA; https://atoa.atnf.csiro.au). For the wide-band receiver, each observation is recorded in Single Dish Hierarchical Data Format (SDHDF). Details on the SDHDF format are available from: https://bitbucket.csiro.au/projects/CPDA/repos/sdhdf_docs/browse
Web download is the only access method for the SDHDF data files. Meta-data stored within each SDHDF file is obtained from two sources: (1) the starting positions and parameters for the observation and (2) information that gets updated throughout the observation (such as the current telescope position for scanning observations).
The SDHDF data sets can be loaded using standard HDF5 reading tools (that exist within packages like Python). However, we do not yet have a well-tested suite of software for processing these data. We have test versions (currently available from local staff) of software to:
Visualise spectra: in C and in python (https://bitbucket.csiro.au/projects/CPDA/repos/sdhdf_tools/browse) Convert the HDF5 format files to SDFITS. Apply a basic flux, bandpass and polarisation calibration assuming that the switched calibration signal was run throughout the observations.
All papers that make use of the Parkes telescope or the online archives requires the inclusion of the acknowledgements listed on https://www.atnf.csiro.au/research/publications/Acknowledgements.html. Specifically:
“The Parkes radio telescope is part of the Australia Telescope National Facility which is funded by the Australian Government for operation as a National Facility managed by CSIRO.”
And if appropriate:
Observations with the UWL should reference Hobbs et al. 2020 for the receiver and observations with the MB should reference Staveley-Smith et al. 1996.
If you make use of CSIRO’s high performance computers for data processing, ensure that you acknowledge Scientific Computing as per https://confluence.csiro.au/display/SC/Conditions+of+Use with:
“This project was supported by resources and expertise provided by CSIRO IMT Scientific Computing.”
- BPSR, BPSR
- ATOA, High frequency resolution data sets (Spectral line), Publishing results
- DAP, Publishing results
- data access, Access your data and data analysis
- pulsar data, High time resolution data sets (Pulsar)
- spectral-line data, High frequency resolution data sets (Spectral line)
- DFB4, DFB4
- commensal modes, Commensal Observing Modes
- continuum/spectral-line mode, Spectral-line / Continuum Modes
- fold mode, Pulsar Fold Mode
- frequency range, Ultra Wide-bandwidth Low (UWL)
- introducing, Medusa
- medusacat, Pulsar Fold Mode
- search mode, Pulsar Search and Single Pulsar Modes
- voltage capture, Voltage Capture Modes
- zooms, Zoom Modes
- Parameter Set, Viewing and Saving the Parameter Set
- continuum/spectral-line mode, Example CONTINUUM (Spectral-line) Parmameter Set
- fold mode, Example Pulsar FOLD Parameter Set
- scan mode, Example SCAN Parmameter Set
- scanmap continuum/spectral-line mode, Example SCANMAP CONTINUUM (Spectral-line) Parmameter Set
- search mode, Example Pulsar SEARCH Parameter Set
- Project Expert
- Receivers, Receiver Fleet
- Remote Observing, Observer Training
- RFI, Interference & Avoiding RFI