User Tools

Site Tools


This is an old revision of the document!

ASKAP phones (since September 2012)

ASKAP extensions useful to VLBI are:

08 9923 7700 MSF - Gemma
08 9923 7750 MSF - Shaun Amy
08 9923 7766 MSF - Suzy Jackson
08 9923 7900 MRO - main site phone
08 9923 7961 MRO - control room
08 9923 7965 MRO - Electronics room
08 9923 7950 MRO - Manager
08 9923 7979 MRO - 1st Aid
08 9923 7929 MRO - Ant29 hut
08 9923 7970 MRO - old site hut?
08 9923 7973 MRO - Lunch hut?

From CSIRO phones replace prefix with just 99 and then the 4 digit extension.

Starting up

ASKAP ANT29 is run via a VNC session on the Curtin Recorder (cira10) housed in hut29 at the ASKAP site at MRO. The vlbi recorder is on a 1 Gbps link to the routed CSIRO network. It can now be accessed directly as, with both ssh or VNC from ATNF networks.

Running the antenna

To run the antenna for VLBI, the directory should be set to “askap/run” and commands can be run in separate xterms.

The driver task “askap_drv” needs to run first for communicating with the antenna, and then the other tasks are started. This can be done by:


  • “askap_drv 1” to get the antenna driver. Monitor the messages in that xterm.
  • “askap” to start the antenna gui. (Since June 2013 command now is “askap 1”)

OR (since June 2013:)

  • “askap 1” starts askap_drv and the gui in one step. It also displays the “askap_drv 1” session is a separate xterm to monitor messages.

For vlbi observing via the schedules you need:

  • “vlbi_drv” to run the vlbi schedule (a .psn file like Parkes).

The schedules are in sub-directory askap/sched.

  • N.B.: Since August 2013, please run “vlbi_drv_new” instead.

The main antenna control is run from the gui. Essential commands that can be typed in the command window are:

  • “update” to synch with the ntp server. This is essential if “clk err” is large. (usually is below 0.1 second). Must NOT exceed 0.5 sec. Can only be updated when antenna is not tracking (counter not incrementing).
    • IF the update does not work, it may imply ntp issues with cir10 (the vlbi observing computer.)
  • “stow” to stow the antenna. During stowing the “high-stow” block will show “driving” and finally “in”. Once stowed many red blocks will be reported on the gui.
  • “unstow” to get things moving. All red blocks should turn to yellow and the antenna would be ready to run.
  • “drive_off” to manually turn drives off (especially if there is a red bar after the unstow)
  • “drive_on” to manually turn drives on.

(Note: if the telescopes is having problem switching the drives, a sequence of drive_off and then drive_on often fixes things)

One can track a source from the gui e.g. for fringe checks.

  • in the “select” line, select “J2000” and type in the RA and DEC required. Then make sure that “track” is selected in the “action” line and click on “start obs”. You can use the “stop” button to stop.

* During tracking make sure that the “stack” button is decrementing from about 38 to 1 in cycles. You can also monitor this in the askap_drv window.

For debugging problems other useful commands are:

  • version - to give the firmware version
  • k4stat - use after a problem to check for error messages. It clears when a drive command is given.

Running a schedule (vlbi_drv)

The vlbi schedule for askap is a .psn file similar to Parkes. Normally this will have been already generated and copied to cira10. If you need to generate this from the vex file in the vlbi ftp area one needs to run “ -askap <vexfile>” and scp to cira10 in the area askap/sched. e.g.

  • -askap v252ab.vex > v252ab-ak.psn

in the v252ab area would create the .psn file, Note the _ak in the filename, so as to not confuse with the .psn for Parkes.

In another window in the askap/run area type “vlbi_drv”. It will ask for the schedule name. It should be provided by full path name e.g. “../sched/v272ab-ak.psn”. It should then run for the duration of the schedule and the telescope should slew and track at the appropriate times. If a source has set or has not risen the schedule will report “sleep” and will wait till the next scan.

  • N.B.: Since August 2013, please run “vlbi_drv_new” instead.

N.B. 1: If you stop vlbi_drv with ^C it can hang the gui and/or crash askap_drv. If you need to stop vlbi_drv best use the “q” command in that window. But q does not always work so ^C can be used if needed.

N.B. 2: If schedule is started early and sources are below horizon, vlbi_drv behavior may be uncertain. Watch closely and restart schedule if necessary.

N.B. 3: Even when vlbi_drv is running, the telescope can be stopped from the gui. If you do that, it is not clear if the schedule picks up ok again. vlbi_drv may need to be restarted.

Recording data

Note that the system use “automount”. Currently it is configured with two data disks /mnt/raid_0 and /mnt/raid_1. You may need to “cd” into the directories before they seem visible.

Before recording data the directory should be created in /mnt/raid_0 e.g “mkdir v272ab” and then cd to that area before starting the recording program px14_record (similar to vsib_record). To run a quick check one can use e.g.

  • px14_record -v 12 -t 1m -f 1s which will record 1 minute of data in 1 second files.
    • if -t and -f are not specified the system records 60s of data in 1 file.
  • Note 1: Check the output lines in px14_record window. The “Stddev=x, y” line should report numbers around 1000-2000 and it is controlled by the “-v” flag.
  • Note 1a: One can inspect the recorded band with fauto e.g.
    • fauto -n 512 <filename.lba> – gives the averaged band in the file
    • fauto -n 512 -nint 32000 <filename.lba> – gives spectrum every 1s.
    • fauto -n 512 -tint 1 <filename.lba> – gives spectrum every 1s.


  • Note 2: The last number in the output record is the time difference in the sampler. It should be small (order 1). If it is very large (many 10s) then the system may NOT working, especially if this number is changing rapidly.(If stable then the system may be ok). Most likely culprit is ntp server on cira10.
  • Note 3: The ntp server on cira10 should be checked and/or restarted. Root access is necessary for restarts.
    • ntptime - gives the ntp status in the machine. The error should be microsecs. If it is hundreds of microsecs or millisecs then the ntp demon is not working properly.
    • to restart the ntp demon try “sudo /etc/init.d/ntp restart”.
    • the command “ntpdate -q” checks syste. “ntpdate” resyncs.
    • IF all else fails cira10 may need to be rebooted. Then the full VNC will need setting up again.
  • Note 4: To check correct timing of the sampler over longer periods, the .log file in the recording subdirectory can be plotted and inspected i.e.
    • -time -x 2 -c 9 *.log (or give the .log name you want). Maybe add “-line” option to connect the points in the graph. (Ignore PGPLOT::HANDLE error message).

Correct operation can be checked by running fauto with say “-n 512” on one of the recorded files.

Real-time fringe-checking is done for all LBA setups and will be the primary means of verifying correct operation. It is run centrally for all telescopes.

For production recording longer files should be run and an output name should be given e.g.

  • px14_record -o v272ab -v 12 -t 12h

will create the default 1 min length files for 12 hours.

  • For delayed start time add “-start dateTtime” e.g. “-start 2012-03-10T08:02:00”
  • N.B.: the “-invert” option should be used for inverted bands. Currently for the 1.6 GHz band.

NOTE 1: To stop px14_record it is recommended to use ESC rather than ^C.

NOTE 2: When restarting make sure you use all the correct parameters e.g. the “-invert” option. Best to use up-arrow and edit the previous line appropriately.

NOTE 3: The PX14400 kernel driver sometimes gives errors like “failed to allocate DMA buffer”, and needs to be restarted. This can only be done as root. The command then is “/etc/init.d/px14400 restart” (the available commands are: stop, start, restart).

The H-maser

The H-maser controls the timing for vlbi in the askap hut29. It is possible to monitor and control the H-maser via a VNC. Check with the vlbi group or Peter Mirtschin before attempting any adjustments on the H-maser.

The 1pps from the H-maser has glitched occasionally, most likely due to power cycling of the site, even though the H-maser is on 2 levels of UPS. If fringes are not found, the H-maser can be re-synched remotely.

The difference of the 1pps from the H-maser and the 1pps from the GPS (the ntp server in the main comms rack) can be monitored with a local timer-counter, but this can only be done manually.


The ATDC computer provides a station clock. It is synched to the GPS and the 5 MHz reference from the H-maser. It counts its own 1pps and this can be used to synch the samplers. This clock is displayed on the station and the tick-phase is monitored and logged.
BUT it has been playing up recently (March 2012) and it should be checked out before used.

LO setups

Sampler reference clock

The sampler in the VLBI computer expects a 64 MHz IF at 288 MHz (256-320 MHz. It uses a 128 MHz sampling clock provided by a SML 01 synthesiser (output level at 5 dBm), locked to a 10 MHz external reference from the H-maser. Make sure that “ext ref” is showing.


The LO for the L-band is provided by an Agilent at the antenna pedestal. This is locked to a 10 MHz external reference from the H-maser. Output RF level needed is 11 dBm. Again “ext ref” MUST be showing.

  • For 21 cm we use a 1240-1500 MHz filter (1370MHz, 260 MHZ BW).
    • e.g. for 1400, we set the LO to 1400-288 = 1112 MHz. “Low LO == non-inverted band”
  • For 18cm we use a wider filter 1.13 -1.83 MHz (1480/T700)
    • e.g. for 1665 MHz, we use 1665+288=1953 MHz. “High LO == inverted band”
    • e.g. for 1660 MHz, we use 1660+288=1948 MHz. “High LO == inverted band” (e.g. RadioAstron)

These filters are inside the conversion box and cannot be easily swapped. If both 18cm and 21cm are used in one session, the wide filter MUST be used.


The X-band Rx has a fixed 1st LO at 7.1 GHz, locked to a 100 MHz reference signal for the H-maser. This is housed in the Rx box with the feed.

  • N.B. Make sure that the 100 MHz reference signal is connected after receiver changes.

The 2nd LO is provided by the L-band system conversion equipment, as detailed above.

  • e.g for 8425 MHz, we get 8425-7100=1325 MHz IF, and need 1325-288=1037 MHz L-band LO. “All LOs are low == non-inverted band.”
  • For 8441 MHz, we have: 8441-7100=1341 MHz IF, need 1341-288=1053 MHZ L-band LO.

The Agilent providing the L-band LO is setup to remember its last state and recover to that on power-up.

Remote LO control --

The Agilent synthesiser can be controlled via Ethernet. It required the installation of a local ethernet switch at the antenna pedestal and the use of an ethernet-to-GPIB dongle.

The software to control the synthesiser is called and takes options on the command line i.e.

  • -status – Report the status of the Agilent
  • -lo=f – Setup the LO to f MHZ directly (see earlier discussion)
  • -lfreq=f – Setup LO to give sky frequency of f MHz (at L-band)
  • -xfreq=f – Setup LO to give sky frequency of f MHz (at X-band)
  • -power=level – Setup LO power to level e.g +11 dBm for the LO.
  • -rfon – Turn RF ON
  • -rfoff – Turn RF OFF
  • -help – get a list of commands and syntax

The -lfreq and -xfreq commands report the LO that has been setup and also if the band is inverted or not. The only inverted band at present is when lfreq is around 1.6 GHz. If the band is inverted do not forget to set the -invert option in px14_record.

It is prudent to sent a “status” command every time setup changes are made.

Other options are:

  • -reset – Reset Agilent if in pathological case.

These should be used with CAUTION.

Monitoring via Monica --

The antenna status can be monitored via Monica, running at the ATCA.

  • “” starts the generation of local monitoring from an xterm. The monitoring strings are displayed on this xterm.

To get to Monica, an ssh tunnel is needed, from within a screen session, logged on as vlbi. The command for the tunnel (e.g from hydra) is:

ssh -R 8051:monhost-nar:8051 vlbi@cira10

To setup (or reconnect) to the screen session run the following

ssh vlbi@hydra
screen -ls

If no sockets are found then run

ssh -R 8051:monhost-nar:8051 vlbi@cira10
^a d  (Control-a d) 

this leaves the screen session detached so you can log off and leave it.

If the output of screen -ls lists one (or more) sessions then you can reattach using

screen -r

if, for example, the ssh tunnel has closed you need to restart. Detach with “^a d” when done

Monica also enables monitoring via the LBA web monitoring page at

lbaops/askapnotes.1386074913.txt.gz · Last modified: 2015/12/18 16:38 (external edit)