Next: The VLT Real Time Display
Previous: The Gemini Data Handling System
Table of Contents --- Search ---
PS reprint
V. Gavryusev,1 C. Baffa
Osservatorio Astrofisico di Arcetri
E. Giani
Dipartamento di Astronomia, Università di Firenze
1Visiting Astronomer, Nuclear Physics Institute of Moscow State University, Moscow, Russia
ARNICA, an infrared CCD detector operating at a telescope (TIRGO, Gornergrat, Switzerland) was controlled by an observer from Firenze, Italy. Despite the rather slow Internet link available, we were able to perform the observations in quite an acceptable way. The user interface process (a widget based X11 client) was executed locally on a Sun workstation. All processes responsible for hardware support (initialization of devices and their dynamic control and data acquisition itself) were executed remotely under DESQview/X on a PC dedicated to the control of ARNICA. The traffic was reduced to a minimum due to the truly distributed software used. In normal conditions this is just an exchange of short primitives which describe the task to be performed and of informative messages. There is also the possibility of a continuous display of the obtained images, with flexible control of display parameters.
There are many situations when remote observations are very desirable. The telescopes are generally far from the scientific centers. The observers need to spend a lot of money and time for the travel. Sometimes the principal observer can not be at the telescope site at the proper time. Meanwhile the network environment is changing drastically with time. The Internet access to the world distributed databases is common now. The remote control of different devices including telescopes is common, too, but it is often very expensive because of the specially designed hardware that is needed.
Here we describe some solutions which could be of practical use in the organization of at least partially remote observations in a very inexpensive way.
X11 is now a de facto standard for remote processing. Hence, any program controlling the experiment (data acquisition, telescope, etc.) and designed as a X11 client can become a tool for the remote observations. But there is a practical problem which could stop at the very beginning any attempt to realize such an experiment. The crucial point is timing. The controlling software is a program always on-line and should work in real-time or near real-time. It should also have a well developed user interface, with menus, tools for data presentation and quick-look, and so on. The update of large windows across a network is a rather intensive task. In some cases it may be not a problem, if one is using a local high speed network with low traffic, for instance. If the link is world-extended, includes with high probability some low speed segments and some high speed segments which may be heavily loaded, the update of the windows could be terribly slow. Thus the simple realization of a remote observation may be far in the future, when links with significantly higher performance will be more widely available.
To fit in the current situation, the splitting of the software into two parts---user interface and hardware dependent processes---is a practical necessity (Gavryusev, Giani, & Baffa 1993, 1995). We have followed this scheme in the development of a data acquisition package for the Arcetri two-dimensional infrared instruments ARNICA (Lisi, Baffa, & Hunt 1993) and LONGSP (Gennari & Vanzi 1993).
Figure 1: Widget with Main menu during the initialization process.
The telescope and ARNICA electronics are checked. The controller for the filter
motor is not programmed yet. The test of the board for reading from the
CCD detector (PingPong) is not executed yet.
Figure 1: PS 529 Kb
The user interface is organized as a widget-based X11 client. Under the observer's control, this program starts/stops the hardware control processes locally or remotely, using the standard rsh or rexec commands, and establishes connections with them.
The interprocess communication uses standard stream sockets on top of TCP/IP. Currently the communication is asymmetric. It is asynchronous from the side of the user interface, which acts as a server, and it is synchronous blocked (request---response---actions---request) from the side of the hardware control processes acting as clients. This choice is due to some hardware constraints, while the asynchronous communication from both sides is preferable. The traffic is reduced to short primitives with environment and task descriptions and to informative messages. All restrictions on the timing are guaranteed by hardware support processes, executed on the local PC dedicated to data acquisition control. The information on the observed intensities is provided to the observer to allow a quick control of the data quality. ARNICA has a 256x256 pixels CCD detector. The whole image is optionally available for immediate inspection. To reduce the traffic we transmit 8 bit image intensities instead of 16 bit original CCD intensities: the image should be scaled to the available color index limits. Even with such a reduction the array is still huge and its transmission could create a long delay. To avoid this problem the user can easily reduce the size of the transmitted rectangle, change its position, or choose not to transmit the image at all.
The user is also provided the numerical values of the measured intensities. It could be 8x8 pixels, evenly distributed across the CCD detector, or 16x16 pixels from the square centered around the point chosen by the observer.
Figure 2: Widget for dynamic control of the acquired image.
The image corresponds to the ``dark current'' of the ARNICA (blend
acquisition without source). The small (16x16 pixels) rectangle
is shown as a zoomed
one in the upper right corner of the widget. The observer can choose the
center of this rectangle by clicking the left mouse button. Its position
and corresponding intensity (in original units) are shown in the
informative labels.
The re-newed
part of the image could be defined by press/drag/release of the
right mouse button.
Figure 2: PS 241 Kb
The whole package (user interface and hardware support processes) is executed normally on the same computer, a PC dedicated to the observations and controlled by DESQview/X.
There is no practical difference when the user interface is executed on a Sun workstation which is a node of the same ethernet segment at the telescope site (Gornergrat, Switzerland).
The situation changes when we control the observations
from Florence. The link now consists of many Internet segments
with heavy traffic. While a large part of the link consists of
high speed segments (usually T1, 
1.6 MBaud), there is one
low speed segment (64 KBaud) from Bern University to our telescope, TIRGO
(Telescopio InfraRosso del GOrnergrat). Hence, the conditions are
a common situation of the world-wide network.
The observed timing of the session is quite acceptable. We see a somewhat longer delay at the beginning of each task execution. The flow of the information during the task body execution seems, in a human time scale, practically the same as in the work on a stand-alone computer. The real problem appears when the observer wishes to control the image dynamically. Probably the best way to do this would be to get the whole image in the very beginning and then to reduce the re-newed part of it to a small rectangle in the place of interest.
While the remote observations under current conditions could be useful only in some cases, our experience shows that the available standard environment is almost ready for wider use.
We are grateful to R. Stanga and F. Lisi for useful discussions and to Prof. F. Pacini who invited one of us (VG) to Arcetri.
Gavryusev, V., Giani, E., & Baffa C. 1995, in Astronomical Data Analysis Software and Systems IV, ASP Conf. Ser., Vol. 77, eds. R. A. Shaw, H. E. Payne, & J. J. E. Hayes (San Francisco, ASP), p. , 25
Lisi, F., Baffa, C., & Hunt, L. K. 1993, SPIES's International Symposium on optical Engineering and Photonics in Aerospace and remote Sensing (Orlando, SPIE)
Gennari, S., & Vanzi, L. 1993, UCLA Conference
DESQview/X User Guide, 1993, Quarterdeck