Next: Real-Time Observing at Hat Creek
Previous: Superfast Photometry with MANIA Complex
Table of Contents --- Search ---
PS reprint
Rob Seaman
NOAO/IRAF
Bruce Bohannan
KPNO
These experiments were part of two new Internet-based observing services offered to KPNO observers beginning with the Fall 1995 semester: a remote observing station and an automatic FTP data queue. The remote observing station seeks to duplicate the KPNO IRAF/ICE observing environment on a workstation at the observer's home institution. The automatic FTP queue is intended to support those observing programs that require quick transport of data back to the home institution, for instance, for near real time reductions to aid in observing tactics. We also discuss the early operational results of these services.
The remote observing station seeks to duplicate the KPNO IRAF/ICE observing environment on a workstation at the observer's home institution. The remote window environment includes the ICE data acquisition window, IRAF data reduction window, and an ximtool quick look image display.
Audio and video connections are provided through the Internet MBONE clients nv and vat in point-to-point mode. The video client, nv, is available from ftp://parcftp.xerox.com/pub/net-research, and the audio client, vat (and also a whiteboard client, wb), is available from ftp://ftp.ee.lbl.gov/conferencing.
Other clients (such as the video client vic) were tested, and we judge these two to be the most robust and fully featured of those available at the present time. The video connection will allow access to the acquisition and guide TVs and to the VDU screen. Audio and video connections will provide valuable interaction and feedback between those on Kitt Peak and those eavesdropping from ``home''.
The MBONE session clients sd and mmcc were investigated for managing the entire set of audio, video, and whiteboard connections, but these seem to add more complexity to the simple KPNO configuration than warranted in point-to-point mode. Some method of managing coherent sessions will prove invaluable for three-way (or many-way) conferences, however.
A minimal remote setup includes an audio connection via a microphone and the built-in speaker in the observer's home workstation, and the nv and vat software. An Internet connection is required. NOAO provides a tar file containing the files needed to configure an observing account, but we cannot guarantee support for all computer platforms.
All long-distance telephone charges during the run between investigators on site and at the home institutions remain the responsibility of the observers, but the network audio link should make the phone unnecessary.
Under normal conditions, all observing runs using the alternative modes require at least one observer to be present at the telescope during night-time operations. The observer's home computer must be configured and tested for remote operations before the date of their observing run. Note, however, that the remote observing station is available as an option not just for observer's research colleagues, but for their students as well.
The bandwidth requirements for the audio and video links are both moderate and configurable. One audio channel requires about 70 kilobits per second if the default PCM2 encoding is used. The GCM encoding requires only about 14 kilobits/second and can theoretically be used over a modem connection.
The default video channel bandwidth is 128 kilobits per second and can be easily adjusted higher or lower using a slider control in the nv window interface. No more bandwidth than the specified maximum will be consumed. The frame refresh rate is automatically adjusted to compensate, but is typically about 4--5 frames per second at the default resolution of 320x240 pixels. The resolution can be either halved or doubled from this value and the video signal can be either color or grayscale. A 160x120 grayscale window is refreshed frequently enough to move quite naturally.
The video transfer algorithm is clever about minimizing the bandwidth requirements. Only non-stationary portions of the frame are sent, except for a low-frequency (every several seconds) refresh of the entire picture. Pixels that have not changed are not sent again. A coarser pixel resolution region update precedes the finer pixel-by-pixel updates.
The video signal can come from any of the normal sources in the dome via a Sun VideoPix frame buffer card, but can also come from an active screen capture option. The screen capture is active in the sense that changes to the selected region of the screen are automatically sent to the remote end---clocks will tick both locally and remotely, for instance, and ximtool redisplays will be automatically echoed---without an explicit command to the nv software.
This method of transmitting the ximtool view to the remote end is not intended to represent normal use, but may prove handy on occasion. The IRAF group is currently investigating compression options for the ximtool data stream. This may perhaps use a method similar to STScI's hcompress or the bit plane by bit plane variation of Percival and White. A more fundamental option for data display is to send the actual data to the remote end for redisplay and further analysis. This is discussed under below.
The point-to-point mode of the vat and nv audio/video clients provides a reliable connection for most remote operation scenarios. We are also proceeding with the network configuration needed to provide IP multicasting access into each dome. This will permit more that two sites to be connected simultaneously allowing the normal benefits of Internet based video-conferencing, but also perhaps proving of use to observing initiatives such as multiwavelength studies using simultaneous observations from multiple telescopes. (This segment of the multicasting Internet MBONE that is specific to telescope operations could perhaps be referred to as the ``T-bone''.)
Support for CU-SeeMe connections to Macintosh and PC class computers will be provided via reflector software that will run from our downtown Tucson headquarters as well as on Kitt Peak. CU-SeeMe is being developed at Cornell University and is available from ftp://cu-seeme.cornell.edu/pub/CU-SeeMe/. CU-SeeMe is an intrinsically unicasting protocol. Each participant in a conference connects separately to a reflector node, which copies all traffic to each of the other nodes. Each additional conference participant increases the network traffic.
The MBONE provides a mechanism for true routed multicasting---if the routers support it. In the absence of an installed base of multicast ready routers, router software such as mrouted can be executed on workstation nodes. In either case, once a packet arrives on a given subnet, it is available to all nodes on that subnet---all nodes, that is, that support a multicasting kernel. In this case, there is no increase in network traffic if more participants join on already connected subnets.
Note the distinction between the physical network infrastructure and the virtual multicasting network that is overlaid on top of it.
Security issues are addressed at the Internet level. Control of the data acquisition process is implemented via passworded rlogin or telnet sessions running the IRAF/ICE software. No direct access to the telescope control software is currently planned. The KPNO telescopes are not instrumented for robotic operation. Future audio security may be provided with the Diffie-Hellman public key encoding of the PGPfone software.
The automatic FTP queue is intended to support those observing programs that require quick transport of data back to the home institution, for instance for near real time reductions to aid in observing tactics.
After each exposure, each image is passed to a queue which automatically transfers it to the observer's home computer using FTP. This process operates in the background and does not affect the efficiency of observing.
The FITS data are automatically compressed using STScI's hcompress, which is available for UNIX and VMS systems. After sending the compressed FITS image over the network a semaphore ``ready'' file is sent as well. This provides a method for software on the remote end to recognize that the transfer is finished and to trigger an automatic response (such as decompressing the data).
The length of time needed for a complete queue transaction depends on the total time needed for the various steps---from the initial conversion into FITS format (if needed), through compression and the actual FTP transfer, and perhaps through a subsequent decompression. Each of these steps requires a fairly constant amount of time, except for the FTP transfer itself which depends on the available bandwidth between Kitt Peak and the observers' home institutions.
In many cases the bandwidth of about 40 kilobytes per second of the fractional T-1 link between Kitt Peak and Tucson will be the bottleneck. A 16 bit image from a 2048x2048 CCD is 8.5 megabytes uncompressed, which corresponds to 3.5 minutes per transfer. Compression will cut the size of a typical science frame by about a factor of two, reducing this to a bit under two minutes. FITS conversion requires about 30--45 seconds for a 2048 square image and the compression about another minute. Assuming that decompression requires about the same length of time on the remote computer, the total latency is about 4.5 minutes. This is quick enough to keep up with the demands of most observing programs, except perhaps during an extended sequence of calibration exposures. NOAO is investigating microwave and fiber options for upgrading the Kitt Peak-Tucson link to a higher bandwidth.
The FTP queue may be triggered manually or through the postprocessing command of the data acquisition software. Only the name of each image is provided to the queue, the actual data formatting and handling are the responsibility of the system level queue. This queue is implemented as a UNIX lpr queue with a short script filter that performs the actual operations.
White, R. L. 1992, High Performance Compression of Astronomical Images, STScI, hcompress is available from ftp://stsci.edu/software/hcompress
Zimmermann, P. R. 1995 PGPfone: Pretty Good Privacy Phone Owner's Manual, MIT, http://web.mit.edu/network/pgpfone/manual