ARECIBO COORDINATED TIMING INSTRUCTION MANUAL

ASP

• Open three or four windows on asp@aspmaster.naic.edu (via remote.naic.edu) (Tip: title them ASP1, ASP2, ASP3, e.g. xterm -T ASP1)
• In some window (call it window #1):
  • "cd config"
  • "cp P2016/xxxx.xml config.xml", where xxxx.xml is an appropriate-looking config file. Lately we have been using "2ds" (2 data server) files.
  • make sure that "cal_scan" is set to "0"
  • set "observer" to your own initials
  • make sure n_dump will give you a reasonable number of integrations (usually 30)
  • node11 has been flaky lately, so make sure the config.xml file does not use it.
  • "rms" You'll see a list of the rms of each channel. In the usable part of the band this should be about 0. If it's not, go to Receiver IF/LO Control, and then to Advanced IF Power Ctrl. Change "Atten (cmd)" to equal "Atten(act)". Subtract or add db as necessary to make rms 0. Note that the 4th column corresponds to the left-hand ASP column and the 3rd column corresponds to the right. The sense of the shift is the following: if the numbers in "rms" are negative then you want to decrement dB. Note that this needs to be done first, before you are running any other machine.
  • "stat_msg" (to monitor status messages)
• In another window (call it window #2):
  • "cd runtime"
  • "makepoly aaaa+aa bbbb ccc dddd.d 3 eee" where
    aaaa+aa is the pulsar,
    bbbb is the frequency (430, 1408),
    ccc is the bandwidth (must include zapped channels, i.e, always use 64 MHz when operating two data servers),
    dddd.d is the MJD now, or a few minutes ago (integer and fractional part)
    3 is the observatory code (always 3 for arecibo)
    eee is the max number of hours of observation. might as well make this big, like 6.
    
• In another window (call it window #3):
  • "cd data/P2178" (this is where the data will be written)
  • "start_asp" (this starts the data-taking!!)
• And back somewhere else (window #2, say):
  • "stat_asp" (for graphical display of pulsar)
• At the end of the scan, start_asp and stat_asp will end automatically. You will need to abort stat_msg by control-c. At the end of the observing session, you may need to manually kill the pgplot windows.

HOW TO TAKE A CAL SCAN:

• turn cal on on cima (if not already done)
• edit "config.xml" to change "cal_scan" to "1"
• run a scan as above.

HOW TO ABORT:

• use control-c to kill start_asp, stat_msg, and stat_asp

WHAT TO WATCH OUT FOR:

• In stat_msg window make sure starting MJD of both DSs are identical. If not, ctrl-c out of obs. Do stop_asp. Wait a minute. Start again. It shouldn't happen twice in a row.

SYSTEM DIAGNOSTICS:

HOW TO RUN:

• Open a window onto mark4@naic.edu (log in from remote.naic.edu)
• "su -" (don't forget the dash)
• "e4"
• Answer the questions about source name frequency, etc. when it asks "resent internal attenuators?", answer "y" the first time you are observing a given source at a given frequency, otherwise answer "n"
• Data-taking commences when you answer "y" in reply to "Accept choices?". You can safely control-c out of "e4" at any time before this point.

HOW TO TAKE A CAL SCAN:

• turn cal on on cima (if not already done)
• "e4"
• Answer "y" when it asks whether it is a cal scan

HOW TO ABORT:

• Open another window onto mark4
• "op k"
• In case of emergency, use control-c.

WHAT TO WATCH OUT FOR:

• "Adjusting ground currents" When you switch between low frequency and high frequency, it will run a quick fake data scan, which will take 15-20 seconds. This is normal.
• "Disk space available" This number is unreliable due to disk fragmentation issues.
• "Trouble converging" Attenuators are set through an iterative process. This message indicates problems setting the levels. If asked to try again, usually you should just answer "yes". If trouble continues: (i) if the levels / attenuator settings are bouncing around at the level of a few tenths of a db, don't worry about it. (ii) if the levels look bad (NaN's, negative infinity, zero, etc.) this usually means that mark4 is not getting IF power
• Screen output

HOW TO MONITOR:

• Approximately once a second a line is written to the screen. The number on the first column is the number of data records written. There are approximately ten records written per second. (Technically, a request for a "1 minute" observation produces 570 data records and runs for 570*1024*1024*1e-7=59.8 seconds.)

• Before first observation on any given day, ask operator to say ctrl-c, y, off, on, slave. This forces the pc to get time off the network.
• open a window as dtusr@observer2
• "cd /share/abpp/writ"
• "source ./setupxxxx" where xxx is observing frequency 329, 432, 1410, 2350. do this before each observation (but not before the cal), even if not switching bands
• "../runit/gui_obs_abpp". answer the questions. Use only 7 digits in the psrname. Use 4 polarizations for 327/430 MHz, 2 polarizations for 1410/2350 MHz.
• Many messages are written to the screen.
• When it writes a line starting with "dataloop", it is taking data.
• When it is done, it returns to the prompt.

HOW TO TAKE A CAL SCAN:

• turn cal on on cima (if not already done)
• "../runit/gui_setup_cal". answer the questions. it takes two 30 second scans.

HOW TO END AFTER CURRENT SCAN:

• "/share/abpp/runit/gui_scanend"

HOW TO ABORT:

• "/share/abpp/runit/gui_abort"

HOW TO LOOK AT DATA:

• "cd /share/abpp/data"
• find a recent data file (for example "c026937.dat")
• "../bin/cplot xxx" where 'xxx" is the numerical part of the file name ("026937").

WHAT TO WATCH OUT FOR:

• In another ABPP window say "tail -f /share/abpp/writ/abpp.log". After you start an observation you should see the last line say: "05Apr17 14:13:12 LST 23:29:25 integrate: 2317+14 27299 " If you don't see this line, the ABPP probably got stuck, and needs to have the "ctrl-c, y, off, on, slave" thing done to it again. Another way to tell the same thing is to see if it recently wrote data to /share/abpp/data.

• hit 'start monitor'
• if levels are not close to 1., hit xxxx
• hit 'stop observation' stop level-setting mode
• hit 'start observation' to take data

HOW TO TAKE A CAL SCAN:

• turn cal on on cima (if not already done)
• change the dump time to 10 seconds in each of WAPP1, WAPP2, WAPP4 by pressing the buttons that say WAPP1, etc., and entering the new time as 'Save folded data interval (secs)'.
• change the scan time, 'Set run time (secs)', to 30 seconds
• uncheck polyco and check "fixed f0" (should be 25 Hz, DM 0).
• hit 'start observation'

HOW TO ABORT:

• hit 'stop observation'

WHAT TO WATCH OUT FOR:

• overflow errors (messages giving next.total and tcount values) indicate that the WAPP is not keeping up with the incoming data. this means either (i) there is something wrong with the configuration, such as requesting too many lags or too short a sample time, or (ii) someone is running something else on the wapp computers, so that not enough cpu cycles are available to fold the incoming data. To check for the latter problem, log on to wapp (or wapp2 or wapp4) and run "top".

CONFIGURATION INFORMATION:

• All frequencies: scan time 1800 seconds. integration time 32 usec. folding mode. 3-level 2 polarization mode (NOT summed). use polyco file (polyco.dat). save lags (not spectra). 60 sec dumps. WAPPs 1, 2, 4 turned on; WAPP 3 turned off.
• At 1410 MHz: 50 MHz bandwidth, 192 lags, centers at 1145, 1195, 1500 Mhz
• At 2350 MHz: 100 MHz bandwidth, 96 lags, centers at 2650, 2750, 2850 Mhz
• At 327 and 430 MHz: Don't run the WAPPs.