Remote Observing Manual


Any and all users of ARO computing facility will be required to submitted the IP address of the computer from which they plan to access the ARO telescopes. This IP must be communicated to the ARO staff prior to your observing dates to allow time to include the IP in our system.

If you do not know your IP address then you can determine it by going to this web site:

Please email your IP, along with your name and affiliation to


12 Meter Operator:   Info on the scheduling of remote test runs and account passwords.


Phone: 520-318-8670

10 Meter Operator: Info on the scheduling of remote test runs and account passwords.


Phone: 520-621-4328 x210

Software Engineer: Info on the Xremote software package and account passwords

Natalie Gandilo:


Phone: 520-621-3234

Observers can connect to the 12-m or SMT telescope computers and establish a remote data reduction session, see the on‑line "Status" screen, have a computer "Talk" session with the telescope operator, have a real‑time automatic display of incoming data, browse previously recorded data, see weather information, view receiver switched power and total power "chart recorder" output.

 The choice as to whether to observe remotely or on-site is largely the observers', although management may insist on local observing if the observations are deemed particularly complicated or if the observers are unfamiliar with the telescope.  Most importantly, observers should understand that remote observing is intended for experienced users who are very familiar with the facility, the observing modes, and the telescope personnel.  The principal assets of remote observing are convenience, access and making small blocks of telescope time accessible to observers who otherwise might be unable to travel.  We think it is most appropriate for short observing runs or for use by a collaborator who is not at the telescope but who wishes to participate in the observing.  Most programs benefit from the on-site presence of the observers: communication with the operator and other staff members is more fluid, access to staff advice and other observatory resources is easier, and the confluence of collaborators at the telescope may prove stimulating and beneficial to the scientific program.  The possibilities of remote observing are being tapped and a number of the traditional objections to it have been eliminated by technological advances.  Nonetheless, we are continuously enhancing remote observing capabilities to extend it to a wider audience and broaden its power and flexibility.  We welcome comments and suggestions from users.

Remote observing is designed for independent observer runs or in collaborative observing runs involving the same observing program. Multiple collaborative observers may use the package at the same time. But, be mindful that the package requires both computer cycles and network bandwidth and you should not be competing with other observers for these resources.  In addition, many observers may be (understandably) uncomfortable with their data being monitored by someone who is not part of their group. When you start the remote package the telescope operator receives a message on his monitor screen that a remote login has occurred. 

Observers should do trial logins before a remote observing run. Notify the operator when you are attempting a trial run.  Once you have performed the login and checked that all the tasks are working, you should exit as quickly as possible.  Simple courtesy and common sense will avoid any conflicts.

All observations to the ARO telescopes are performed using ssh. Using ssh provides the most secure type of communications to and from the telescopes.  Ssh also makes setting X display variables easier because it does all the work for us.

If your computer is behind a firewall or you use DHCP for obtaining IP addresses, then ssh will most likely be the only way remote observing will work for you.

Just make sure your instance of ssh is doing the X11 tunneling for you.

Observers are required to obtain and use ssh.

A free implementation of ssh for Windows is called putty and may be obtained at:

The latest version of Xming can be obtained at:

The latest version of openssh can be obtained at:

Most Linux distributions already supply ssh or openssh by default.

It is the policy of ARO not to give out passwords via email. All passwords must be obtained by calling the Telescope Operator or the Operations Manager (see Contact Info at the top of this page).

The following are required for successful remote observing:

  • Fully Compatible X Window system.
  • The ssh package.
  • The rshd daemon running on your home computer. ( For remote Printing )
  • A reasonably fast network connection.


The following systems are known to work with our Remote Observing Package:

  • Sun's OpenWindows.
  • Unix DECStations.
  • Silicon Graphics workstations.
  • Most X-Terminals.
  • All Linux systems.
  • Microsoft Windows using Xwin32, Xming or Hummingbird Xserver emulation software. 


NOTE: When setting up your Xserver it is helpful if you enable backing-store. This will reduce the amount of network traffic, from our computers to yours, by not requiring frequent repaints of screen displays.

N.B.  We recommend that you make a trial run well in advance of your observing time to ensure that you can successfully log in, start the various remote sessions, and produce graphics displays from the data reduction programs.  A trial session is particularly essential if you want to use an X Window environment other than Linux.  Sometimes problems arise with font libraries and the like, but solutions to these problems can usually be found given advance notice.  Contact the staff to arrange a time for your trial run.

It is imperative that you email the operator, at least 24 hours in advance, with a description of your planned observing run. This email should contain source names, receiver configuration along with frequencies, backend selections and the type of observing you expect to do. This information will be used by the operator to configure your observing ahead of time when possible.

Using the information on Contacts Page, telephone or email the Telescope Operator and have them create a data reduction subdirectory with your initials.  The operator will need the name of the principal observer, three initials from his name, and the project id of the program.


Observer = Thomas Folkers

Initials = twf

Project Id = f117

If you have your own catalog of sources you need to copy them to the telescope computers.

The only 'ftp' daemon we use is the "Secure File Transfer Protocol", sftp. This program is part of the ssh suite and is the only type we support.

Once a directory is established, you may sftp your source catalog to our computers by typing, (at your own system prompt):

For Kitt Peak 12 Meter:


For Mt. Graham 10 Meter:


Password: (See section 4 for our password policy)


Next, you must change to your observing directory:

sftp> cd "ini"

( Example:  cd twf )

where "ini" are your three observing initials. 

To place your catalog in your directory, type:

sftp> put

( Example: sftp> put )

NOTE:  Your catalog name must have the extension ".cat" when finished to be recognized by our system as a source catalog.

To end the sftp session, type

sftp> bye

Note that all source catalogs must be in the standard ARO format, for example

Ra DEC epoch name vel frame type
02:21:51.0 61:52:19.0 B1950.0 W3 -41.4 LSR RAD
02:23:17.0 61:38:54.0 B1950.0 W3(OH) -48.2 LSR RAD
03:44:52.4 32:44:28.0 B1950.0 B5 9.9 LSR RAD
04:38:38.0 25:35:45.0 B1950.0 TMC1 5.8 LSR RAD
05:32:47.0 -05:24:21.0 B1950.0 ORIONA 9.0 LSR RAD

Other coordinate and velocity frames are supported - Please see contact list above for more info about catalog options.

Examples of ARO catalog format can be found here.

Open a shell / xterm type window then type: (NOTE: the -X allows the required X11 Forwarding)

For Kitt Peak 12 Meter:

% ssh -X -l obs

For Mt. Graham 10 Meter:

% ssh -X -l obs

% Password:       (See Section 4 for our password policy)

[ lots of messages ]

% observer initials: (your initials, as established with the operator)

At the prompt you may start the remote observing package by typing:

% Xremote <cr>

The system will first check that your home machine has allowed our computers the permission to write to your display, and, if so, will print:

% OK




A control menu like the one shown below should, depending on the site, appear on your screen. The items that are "missing", from the Xremote control panel, are engineering processes that are available only from engineering login accounts.  These technical items are not of general interest to observers.

12 Meter XRemote SMT Xremote


Select All button. Pressing it will select all the standard processes.

Clear button. Pressing it will clear all the check boxes.

Start button. Pressing this will start all of the selected processes.

Stop button. Pressing this will stop all the selected processes.

Exit button. Pressing this will end your remote session. Any processes still running will also be terminated.

Page Operator button. Pressing this button will play a prerecorded message in the control room to alert the operator.

If you press the button, check marks will appear in all the default boxes except a few auxiliary processes which must be started explicitly.

Conversely, pressing the button removes all the check marks.   It is worth starting all the remote processes at least once to familiarize you with what is available.  You may find that you do not need all of the processes, in which case they can be shut down individually.  If the network throughput into your site is sluggish, you may also choose to shut down all but the most essential screens.

To start the processes identified by check marks in the boxes above, press the button.

If you want to stop some of the processes, first press the button to remove any remaining checks, then check the specific processes you want to stop, and press the button.

To stop the entire Xremote session, push the button, then log out of your original window by typing "<control-d>" or "logout."  Please remember to stop your remote session as soon as you are finished observing.

Depending on your choices, up to 17 windows will begin to appear on your screen. Some of these screens may appear different because of different features at each site.

Catalog Tool:

This will display the position of sources on various Az/El and time grids.  Source catalogs in your directory as well as the ARO standard catalogs are accessible.  You can use this tool to plan your observations and to display when sources are up. To bring up the control menu for this tool, move the mouse arrow to the interior of the window, hold down on the right button and pull to the desired menu selection.

Receiver Chart Display:

This is a digital representation of the switched power and total power chart recorders at the telescope.  To access the control panel for the display and the selection of channels to plot, move the mouse arrow to the interior of the window, hold down on the right mouse button and pull to the desired selection.  You can also use your mouse to resize the display as desired.

Condar Window:

This is just a terminal window for continuum data analysis.  You type "condar" in this window to start the UniPOPS CONDAR program. This program will start its own graphics window. This window shows a condar graphic window after reducing a five point observation.


This window presents a real‑time, automatic display of each observing scan within moments of the completion of the scan.  Both spectral line and continuum observations are displayed.  Utility observations, such as five‑points, focus checks, etc., are reduced automatically.  The results of the analysis are transmitted to the operator.  This window can be resized with the mouse.  When Dataserv starts, an additional icon will appear labeled OTF Gridder.  This icon will pop open to display on-the-fly images when that observing mode is in use.  Do not kill the OTF Gridder window even if you do not plan to make OTF maps; doing so will kill Dataserv altogether. This display is a view of the 12 Meter Dataserv reducing a pointing scan.


DataBrowse is an off-line version of Dataserv.  While Dataserv is always attached to the incoming data stream from the telescope, DataBrowse can be used to peruse previously recorded data.  It provides a very fast way to review the data on disk.  It is particularly useful in quick look displaying of spectral line OTF maps. DataBrowse does not provide publication grade results; you must use Line, Condar or Class for that. It is only a quick look tool. This shows the interface from the SMT.


This is just the interface portion of Databrowse (see above), that talks to the on-line Dataserv process. It allows adjustments to be made to Dataserv. (i.e. which filters back ends to use, which channels to integrate, etc). This is normally only used by the operator. This shows the interface from the 12 Meter.


This window is a display of the various disk drive capacities. The three rightmost gauges show the capacity of the data files. This display is only mildly useful to people doing intense OTF mapping.

Line / Class Window:

This is just a terminal window for spectral line analysis.  Within this window, type line to start the UniPOPS LINE program. Alternatively, you may type "class" in this window if you wish to use the GILDAS software package. Both packages will start their own graphics window. The UniPOPS line graphics window is shown at left.


This shows error and status messages seen by the operator. 

Operator Log:

This is a scrolling text file that gives a summary of observations with similar information to that recorded manually by the telescope operator on his log sheets.  Configuration information such as filter bank changes appears as single-line entries in the automated log.


This is the off line version of Rambo. It is useful for watching the setup screens that the operator is using. No telescope control can be achieved from this display. This window shows the Rambo display from the SMT.

Status Display:

This shows the on‑line status monitor (with telescope setup information) as seen on the screen at the telescope.

Weather Chart Display:

This shows the temperature, barometric pressure, and relative humidity on one screen, the zenith opacity of the 225 GHz tipping radiometer on a second screen, and wind speed, direction, and a rain marker on a third screen.  The display cycles automatically among the three screens or a specific screen can be displayed via a pull‑down menu button on the top of the window.  Results for the last 24 hours are presented.  This window can be resized with the mouse.  The pull‑down menu also allows the display of 4 satellite weather photos from the visual, IR, water vapor‑sensitive band, and a surface analysis weather map, which includes a radar precipitation summary.  You can kill these extra weather map image windows by hitting a "q" or the spacebar with the mouse arrow inside the weather map windows.


Program to show you results of pointing scans. Select 'AutoPoint.dat" and then press "Load File". This will load in all pointing results in the current archive. Next, select the receiver you are using by right-clicking on the receiver name button. All this does is set the frequency range for that receiver so the sorting process only retrieves the correct points. You may further refine the selection process by changing the date fields, time fields or frequency range. Once you are satisfied with the selection criteria, press the "Sort Data" button to select only those pointings. Xgpoint will then list the selected pointings in the right most list widgets. Under the "Plot Choice" frame, pressing the various plot formats will give graphic plots of the data. Pressing the "Hardcopy" button will pull up an additional window that allows you to pick where to send the Postscript output. Once properly filled out, press the "Print" button and then click the mouse on which window you want a hardcopy of. (As of this writing, Nov 09, 2005, only Az vs. El, and El vs. El works properly for hardcopies)


Use this to carry on an electronic conversation ("E-Chat") with the telescope operator.



If your network connection is very slow, than the very least you should run are the following programs:

  • Monitor:      Show any error messages.
  • Status:        Shows the status of your observations.
  • Xhchat:       Allows communications to the operator.
  • Analysis:     Allows you to reduce your data online.

After you have finished your remote observing session, please stop all the remote processes.

You have two options here.  You can press the button on the Xremote screen which will stop all processes and remove the control menu.

Alternatively, press the button, then press the button.  This will stop all the default remote windows, but leave the menu screen operative.  Please note that killing the Xremote window by itself using the window manager will not kill the other windows; they run as independent processes.   To conclude your remote observing session, type "exit" in the original window.

There are two options for routing UniPOPS hardcopies to your local site.  Approach 1 is easy but tedious if you are making a lot of hardcopies.  Approach 2 is automatic but requires some UNIX savvy, may open a security hole on your remote host, and it can tie up the unipops program while the graphics file is being printed.

Warning: This is for Postscript output only.

1. Unipops Remote Printing Approach 1 ( Easy but tedious if you are making a lot of hardcopies)

Before starting up line or condar set your popsprinter environment to be "capture".

% setenv popsprinter capture

After starting up line or condar, whenever you request a hardcopy (i.e. via GCOPY or TCOPY or LASER or OUTPUT) the postscript output that would otherwise get sent directly to a printer will be deposited in a file with each hardcopy request going into a new file (i.e. each time you type GCOPY, a new file is generated).

The name of the individual files will be capture.file.$$ where $$ will be expanded to a unique number for each file.  The name of each file will be echoed to your screen.

ftp or sftp each file from our machine to your remote host and print it out as you would any postscript file (this is the tedious part).

Delete the files on our machine once you've transferred them to your remote host.  You may wish to delete them on your remote host as well once they've been printed.  Postscript files can be large so you don't want to get in the habit of letting them pile up.


2. Unipops Remote Printing Approach 2 (Automatic but more involved)

N.B.      This method:

  • Requires some UNIX savvy.
  • It's a security issue for your remote host.
  • Can tie up the program while the graphics file is being printed.
  • May not work if you are behind a firewall.



At the telescope computer prompt, type:

setenv popsprinter remote

cp ~unipops/remote.print remote.print

Using your favorite editor, edit the copy of remote.print in your own obs/ini subdirectory. Here's what the unedited remote.print looks like:

#!/bin/csh ‑f

cat ‑ >$$


rsh ‑l username hostname lpr ‑Pprinter_name ‑r ‑s$$

/bin/rm ‑f$$


  • The first line merely indicates that the c‑shell is to be used.
  • The second line deposits the standard input into a file (this is what the popsprinter=capture does, using a different file name).  The standard input is already in postscript so no conversion to postscript is necessary.
  • The next line copies that file to the top level directory of username on hostname.
  • The fourth line remotely prints out the file that was just copied using the printer named "printer_name" and the  unix lpr command. The ‑r flag to lpr removes the file when printing is completed.
  • The final line removes the temporary file on our machine.


Modifications to the script you should make:

  • You need to change "username" to be your login name on the remote host (username appears twice in remote.print).
  • You need to change "hostname" to the full Internet host name for your remote host (e.g. would be an example of a hostname; hostname appears twice in remote.print).
  • You need to change "printer_name" to the name of the desired postscript printer on hostname (printer name appears once).
  • It is slightly possible you may need to change the syntax of the lpr command and flags on the fourth line although the above should work on most lpr capably machines.
  • On "hostname" (your remote host) you need to create (or modify if you already have one) a .rhosts file (notice the leading "dot" in the  name).  See the man page for rhosts as well as rsh for complete information. You must also have the rsh daemon running on your machine for this to work.
  • Entries in an .rhosts file signal the computer that logins from certain users on certain machines are "trusted" and no password is necessary.  This is what allows the rcp and rsh commands to work.  Without an appropriate .rhosts file, none of this will work.
  • Your .rhosts file should be in your default login directory on "hostname".  It should be readable/writable by you (the owner) and read‑only for everyone else.  Since you want to signal that the "obs" username on modelo or smtoast is "trusted", you want the following line in your .rhosts file:  obs

or obs


That should do it.  If everything works as planned you should get a hardcopy out of your remote postscript printer every time you issue a hardcopy request on UniPOPS.

Since EVERY observer uses the obs account on our machines, it should be obvious what a security risk this is.  Therefore, it is important that you remove the line you just entered in your .rhosts file whenever you don't need it (i.e. after each observing run).  Otherwise, anyone with access to the obs account on our machines will be able to log into your account (username) on your host (hostname).

Time:  The UniPOPS prompt will not come back until remote.print has finished. If the graphics file is large (and postscript files tend to be large to start with) and the data rate between our machines and your host is slow, this may be an unacceptably long time to wait for the UniPOPS prompt to come back.  You may opt for Approach 1 above since you can do the ftp'ing asynchronously (UniPOPS merely has to wait for the file to be copied to the capture file).  There is currently NO way to switch printers once the program has started.