Starting and Monitoring an LBA Observation

The examples below assume Katherine running v252ai.

If you are stopping the previous schedule early (e.g. finishing a Fringe Check schedule ahead of time), use halt to stop the schedule and then make sure the disk has stopped recording:

halt
disk_record=off

Now make sure you have the correct Mark5 module selected. Type

mk5=vsn?

and check the serial number against what you think it should be. For the March LBA session, a list of modules agains experiments is given in the Observing Roster page. If you need to change modules use the mk5=bank_set command. e.g. to change to Bank B:

mk5=bank_set=b

, then run

mk5=dot?

to check.

If time permits, make a recording test before starting and check the bit stats and autocorrelations (note this won't work from a fringe-checking schedule):

From the Field System:

proc=v252aike
setup01
disk_record=on
(wait ~10 sec)
disk_record=off
scan_check
postob

Now start the schedule

schedule=v252aike,#1

See these sections for notes on known problems, things to watch out for etc:

• Current Issues
• See the “Other things to watch out for” on the Starting and Monitoring IVS sessions page.

During the run, make sure that:

• Antenna: drives OK
  Check the antenna status display in the system monitor window for the antenna. If Drive Status is green then all is well.
• Antenna: Time OK (i.e. SNTP server OK)
  Check the Controller Clock status display in the system monitor window for the antenna. If it's green and “OK” then the controller knows the time. If not, the antenna probably doesn't know where its pointing, there's a problem. Check the HMI display on the time[hb|ke|yg] VNC session for more information. If HMI isn't running or you want to restart it here are some notes on Starting HMI.
• Antenna: on source and tracking
  In the field system, type onsource and check the antenna is tracking, which it should be provided a new source command hasn't recently been issued.
• Data: LO Locked
  In the System monitor, in the RF section, check that the LO Status is Locked. If not, no valid data will be recorded.
• Data: Autocorrelations OK
  At the end of every scan, the postob procedure will run a script to extract some Mark5 data and plot the autocorrections and show the bit statistics.
• Time: delays OK, stable and within 1us (clkoff, maserdelay)
  In the eRemoteControl, issue the commands clkoff and maserdelay. These values should be within 0.5 microsecond of each other and stable (i.e. similar results if you issue the commands again). If not, see this entry in the common Problems section for a remedy.
• Time: Maser status OK
  Check the “Standard VCH-1005A Manager” display on the Windows PC (to view it, start a VNC session to time[hb|ke|yg]). Green numbers are good, red are bad. Here's an example of how it should look:
  
  Report any red numbers to Brett ASAP. if you see mention of 'Battery', the maser has lost mains power and is running on it's UPS. If so, tell Brett immediately.
• Mark5: mk5=vsn? correct\\Verify you're recording to the correct module with a mk5=vsn? command
• Mark5: mk5=mode? correct
  Check mode with this command in the field system: mk5=mode?. The result should agree with the procedure file setting in setup01
• Mark5: mk5=dot? response nominal
  This is a check of the Mark5 decoder time. Check the time offset in the formatter with this command in the field system:mk5=dot?. Make sure it reports a small offset (~<10ms) as the final value, that syncerr_eq_0 and that FHG_on or FHG_off depending on whether it is currently recording or not. If not, fmset may need to be run.

To do this, open a terminal on pcfs[hb|ke|yg], and type

fmset

Only run fmset when the mk5 is not recording; therefore, halt the schedule with halt and stop recording with disk_record=off; check with mk5=dot?

When the interface appears, type

s

then confirm with a

y

Following this, the clocks should all be synchronised and agree with UT. Press the [Esc] key to exit fmset. Then check the times again:

mk5=dot?

you can continue the schedule with cont

• Mark5: disk_pos OK
  The command disk_pos in the field system should report three values - the current number of btyes recorded, bytes at start of previous scan and bytes at start of current scan. If not currently recording, the first and third values should agree.
• Meteorology: Weather (wth) being logged
  Look through recent messages in the field system log for output from the wth command, which will look like this:\\/#wx#/16.1,1007.9,58.6
  
• Systemp readings are nominal (Tsys readings are kludged in. If the experiment is recording a single polarisation both tsysS and tsysX will report whatever that is. For dual pol, tsysS is RCP and tsysX is LCP)
• System: Any problems or concerns logged
  If there are any other issues or unusual behaviour, report it in the log by typing a comment in the field system. All comments should start with double quotes.

One difference from IVS observing is that the postob procedure will also pop up a window listing the bit statistics of the recorded data. The observer should check this regularly to make sure it stays at near to the nominal 18/32/32/18 distribution (±2%).

If monitoring from Mt. Pleasant, use pmSTALMke.sh to monitor the alarms. If you want the station alarms to go off when there’s an error (rather than playing a sound through the speakers), use pmSTALMke.newsmerd.sh. I’d recommend changing the title of the terminal window to make it clear which alarms are from which station