Remote Observing Manual

This manual documents the remote observing operations of Shared Skies. It covers the basic elements of all of the telescopes available remotely, and provides links to information about robotic observing and data archives. Other shorter pages are available as well. Please check the index for those.

Overview

System Architecture

Each telescope, its instruments, and its enclosure are controlled by a single computer system connected to the hardware. There also are other network components at the observatory that have tasks such as controlling power switching, managing live video, delivering weather information, and handling the flow of image data. The telescope operator and the observers do not have to be on site because all of these components are accessible remotely, either through the Internet by secure login and encrypted transmission, or through servers that limit functionality while insuring safe reliable, largely robotic, operation from off site.

Robotic Operation

As you might expect, in fully robotic operation the system runs itself. A day of work for the system might go like this:

Consult a list of requests for data and identify the targets that are accessible during the coming night.

Put the targets into a queue in an efficient order based on their location in the sky, the Moon that night, and the duration of the exposures needed.

Make a decision about whether the weather is suitable for astronomy.

When it is time and conditions are right open the dome and power up the telescope and its instruments. Send an email message to the observatory manager so that they will be aware the telescope is open and in use.

Acquire data all night long if needed, but monitor the environment for dew or frost, the sky for clouds or rain, and shut down if undesirable conditions arise.

Stream data to a server where they would be subsequently processed.

Park the telescope at dawn, turn off the camera and other instruments, close the dome, and send the observatory manager an email that all is well.

Before settling down to ponder the next observing cycle, start the batch processing of this night's data on the remote server to dark subtract, flat field, add celestial coordinates, make entries in the management database, and do any photometric processing requested. The server would complete these tasks and notify the observers that their data are available.

We do not have this capability yet, but we are working on it. While many of these tasks can be reliably done by the computers alone, it is still sometimes helpful for an observer to be virtually present during operation if decisions have to be made during the night. In some cases, a remote observer may be accompanied by a telescope operator who is on site or is also running the instruments remotely.

Remote Observing

For remote users to have full control of the facilities they need secure access to the observatory network usually either through a Secure Shell (SSH) connection, or in a more limited way through a web server that acts as a communication hub for the remote user to autonomous software at the observatory. Videoconferencing telepresence is available between the observatories as well as to some campus locations to assist observers and operators. Skype with video also enables real-time interaction between remote observers and the observatory operator.

Software

A telescope and its instruments are devices on a local Instrument Neutral Distributed Interface (INDI) network that communicates with clients through a flexible instrumentation server protocol that accommodates several devices and clients simultaneously. In this way a robotic system may manage many components, while observers also have control of the telescope as needed. The servers and the observers may make use of

indiserver: a hub that talks to devices and to clients

xephem: an astronomical ephemeris, interactive sky map, and instrumentation interface used by a telescope operator and observers

xmtel: a telescope control panel

xmccd: a camera and filter wheel control panel

ds9: interactive image display spawned by xmccd

imagej: an image display and processing Java program that runs on any operating system

alsvid: a package of image processing programs usually run on the data server

xmguide: an autoguider controlpanel

xmdome: a dome rotation and shutter control panel

The INDI system is also accessible on the command line with getINDI and setINDI issued on a system which has network access to the port which indiserver uses. With these commands scripted utilities handle routine tasks on the servers such as starting the observations or running a sequential queue of images.

Network Connections

For complete control of all processes, an observer must have an account on the computer system that runs the telescope, and must be working through a network enabling a Secure Shell (SSH) connection also with access to the network devices. It is not necessary for the operator to be physically present at the observatory although in most cases the operator will at least be working within the university network because the external firewalls block access to most ports.

A Virtual Private Network (VPN) account may enable this access from outside the universities because VPN users appear to our systems as being on campus originating from a specific range of known IP addresses. Note that the firewalls of both the University of Louisville and the University of Southern Queensland do not offer unlimited connectivity between campuses. For example, an operator at USQ who wants to run a telescope at Moore Observatory must have access to the remote observatory's INDI port, such as through a server on the USQ network at Mt. Kent. For this reason, remote observing between Australia and the US is best done from a campus or observatory location.

With those constraints, a command line to connect to CDK20S and enable trusted X11 forwarding is

ssh -Y user@crux.mko.usq.edu.au

which responds with a request for a password. Similarly, to connect to CDK20N the command would be

ssh -Y user@pegasus.astro.louisville.edu

Passwordless Login

Secure Shell (SSH) permits secure passwordless login with public/private key encryption. Once set, this feature remains available until some change in the computer systems alters the keys. Assuming you are using a computer that has a full implementation of Secure Shell installed as is common in most Linux distributions, the command line

ssh-keygen -t dsa

generates two files in $HOME/.ssh

-rw------- id_dsa -rw-r--r-- id_dsa.pub

id_dsa is the private key and id_dsa.pub is the public key. Note the differences in the default permissions.

To permit passwordless login copy and append id_dsa.pub from your computer to

$HOME/.ssh/authorized_keys

on the remote computer. You should copy only the public key to the remote system.

This copy and append operation is more simply done using the ssh-copy-id command on your system

ssh-copy-id user@remote_host

For reciprocal passwordless login, do this on both machines.

Tunneling with SSH

Secure Shell permits tunneling through the firewalls to pass ports securely from one system to another.

The vncserver for example uses ports 5901 and up. To tunnel it through ssh, initiate a passwordless session from the client to the server with this command line:

ssh -L 5901:localhost:5901 user@remoteserver

TightVNC has a built-in menu for port forwarding. Note that VNC ports do not currently forward properly when the remote host is running on a subnet of the SSH server.