Linux at the Arcetri Observatory Infrared Group

by Carlo Baffa

The Infrared group at Arcetri Observatory is finishing the debugging phase of Near Infrared Camera Spectrometer (NICS), an advanced instrument for imaging, spectroscopy and polarimetry in the near infrared wavelength range (1-2.6 \mu m). It will be one of the scientific instruments hosted at the Galileo National Telescope (TNG). NICS is an optical/infrared four-meter class telescope with active optics control, built by the Italian astronomical community in Canary island of La Palma (Spain).

Figure 1. Galileo National Telescope

Our Group

The Arcetri Infrared Group began in the late 1970s and is composed of scientists and technical personnel who design and build infrared instrumentation. The group has acquired experience in the fields of optical design, cryogenics, mechanics, electronic data acquisition, control software, user interface, data storage and archiving. Our group has operated in the framework of a CNR-OAA cooperation.

Figure 2. A View of the Instrument during Laboratory Testing

The NICS is composed of many small subsystems interacting together, to achieve very flexible observing capabilities. The optical, mechanical and detector parts are enclosed in an aluminum cryostat built by Infrared Labs, Tucson, Arizona. This enclosure maintains component temperature of 80 degrees Kelvin and a pressure well below 10<+>-3<+> mbar (see Figure 2). The cooling is achieved by a CTI cryocooler, a refrigerating machine working with high-pressure gaseous helium, while the low pressures required are attained by a three-stage pump and a chemical adsorption pump placed inside the cryostat. The mechanical assembly is complex and comprises seven stepper motors driving the mobile components inside the dewar and their reduction gears. The motors are mounted on the external surface of the cryostat and are driven by a commercial controller that receives commands from a RS-232 serial line. The flexibility of NICS was attained by means of a multiconfiguration optic. All reconfigurations are motorized and under remote control. The general layout is as follows:

  • The input assembly, comprised of the aperture wheel (eight slits and stops that limit the field of the instrument) and the collimator (a doublet of BaF2 -IRG2 with all spherical surfaces) that transforms the f/11 TNG beam into a 22mm parallel beam.

  • The filtering assembly, two wheels holding a set of 20 broad and narrow band filters that allow wavelength light selection while 16 prisms permit the spectrographic working modes to take place. Placed in the prism's wheel is also a double Wollaston prism for spectro-polarimetric observations.

  • The final camera section, which includes three cameras that focus the beam on the detector, act as a three position zoom and give three scales with different fields of view and resolutions. The focus position can be regulated by one of the stepper motors.

Electronics

The electronic system executes both acquisition and control operations under the management of an external computer. The head of the acquisition system is a 1024x1024 pixels array of the HAWAII series built by the Rockwell Science Center. The HAWAII (HgCdTe Astronomical Wide Area Array) detector is a ternary DRO (Direct Read Out) sensitive to radiation of wavelengths between 0.90 and 2.6 \mu m, and it is characterized by good values of dark current, efficiency and readout-noise. Particular attention has been paid to planning and building low noise analogic and ADC electronics to not limit array performance. Dealing with very faint objects that are detected by means of a few tens of e<+>-<+>, it is very important to reduce the electronics noise to the lowest possible level. To give an idea of how sensitive NICS is, we claim that it is capable of detecting the IR emission of a burning cigarette placed four times the distance of the Earth to the Moon. The architecture for the array controller grew on the project of the CCD Working Group of TNG, but it has been modified to fulfill the heavier requirements for higher readout speeds required for near-infrared observations. The controller is based on a DSP Motorola 56001 processor that generates the clock pattern to access and read the array multiplexer, and on a set of Transputer processors for commands and data handling. Transputers are old microprocessors that support parallel processing through on-chip hardware and can be connected by means of their fast serial links. We use them as the building blocks for complex parallel processing systems. The Transputer module interfaces with the host computer (a PC station) through a serial optic fiber link with a transfer rate of nearly 20MB/s. Because of the short typical integration times and the large quantity of data acquired (1024X1024X16 bits), some data preprocessing, such as subtraction of the frames in double-sampling mode, is done in the acquisition electronic by the transputers to limit the required bandwidth of the data transfer. Data is then sent to the host computer through the fiber link. Electronics include some other boards for general housekeeping, controlling the motors' movements and collecting the dewar system data such as pressure and temperature.

Computer

The instrument is controlled by a PC equipped with a Transtech TMB17 PCI bus interfacing with the transputer network. The PC architecture is based on a single AMD K6-2 300MHz processor with 128MB RAM running Linux. Our system has been configured using Slackware 3.6, the stable 2.0.36 kernel and XFree86 3.3.3.1. We decided to stay with this older kernel for driver compatibility. The system is cheap, quite robust and has a good computing capability. The last features are important because our system must be able to acquire and store large amounts of data and execute several concurrent cpu-consuming tasks,such as preprocessing and quick look.

Real Time

The crucial point of an acquisition system is the timing and the capability to respond in a predictable amount of time. In our system the hard real-time work is done at the hardware level by the DSP processor. From the controlling software and OS point of view, we cannot claim it is a true hard real-time system, but rather a system in real time, i.e., a system rapid enough to collect all data and to perform all operations in time. To achieve such behavior in reducing the response latencies, we have implemented some FIFO buffers in the hardware and software, to avoid data loss.

Software Architecture

The control software of the whole system is divided in two parts: low-level software called Transnix that performs the basic hardware operations, and high-level software, called Xnics that interfaces with the end user, handles data, talks with the telescope and performs all high-level tasks.

Low-Level Software

Transnix is aimed at the control of the different kinds of processors involved in the acquisition process. Due to the mixed architecture of the programming and control of the DSP processor and the transputers network, different programming languages have been used. The DSP routines are written in Assembler, while the different modules executed in parallel by the transputers are written in the OCCAM language and are loaded at startup in the network by Xnics, which directly controls the output link. At the PC level, a specific Linux driver originally developed by C. Niemann, Bochum University, and reworked by our group to implement PCI support, performs the basic control and I/O operations to the root transputer installed on the PC carrier board, interfaces it with the applicable software and performs a device single-allocation policy.

The High-Level Program

The experience acquired in our years as developers and users of astronomical instrument programs has given us the ability to define the characteristics of good software for astronomical observations. The global system (telescope + detector + electronics + acquisition computer) is quite complex, and its management may not be intuitive to the average observer. For this reason the user interface must be kept as simple as possible, easy to use and capable of implementing the automatization of the simplest and most repetitive observing procedures and of the data and system control. Therefore, a scripting language has been implemented that permits the building of a description file with the list of the observing tasks that the astronomer would like to execute. XNICS is an X11-based application containing the user interface to all NICS functionalities and, following the classic client/server network applications model, works as a server for an intermediate X11 client program (NICSgate), started during the program initialization. NICSgate represents a communication channel between the high- and low-level software and consists of several object-oriented processes, each controlling a special portion of the hardware functionality and all types of communications in real time.

Each process maintains its inner state and can be activated at anytime when an external event needs its special functions. Any high-level command given by the observer via the graphical interface is elaborated and coded in a specific protocol and sent through this soft-gate to the low-level hardware programs. Every message, telemetry value and raw data output are sent back to the main user program using the same protocol. The communications between the two X11-based applications are realized with bidirectional asynchronous sockets using the TCP/IP protocol.

The resulting user program structure is very flexible and permits complete remote control of the instrument. The remote control of different devices, including the telescope is also common, but it is often expensive because of the special hardware needed and is difficult if there are no broadband lines available. Despite this, it is important to implement such a feature inside a control program because there are many situations when remote observations are very desirable. For example, the telescopes are generally far from scientific centers, and sometimes the principal observer cannot be at the telescope site at the proper time. The network environment is drastically changing, and the chances of getting a full remote control will increase with the rising availability of high-bandwidth connections.

Figure 3. Main User Interface during Observation Process

Figure 4. Close-up of Facility during Observations

Figure 5. The Interface Showing Initialization and Observation Setting Submenus

The GUI

The graphical user interface represents a fundamental part of the program control because it is how the end observer interacts with the system. XNICS' main window, subdivided into three logically separated areas, has been organized in a simple way. All the command buttons that control the observing, re-initialization or setup procedures are on the left panel of the main window. The central zone deals with the measurement settings, while the system status is displayed on the right with icons changing appearance or color to reflect the system configuration (see Figure 3). The application control panel shows all the basic system operations and implements some options to guarantee a fast and simple way to verify the quality of images acquired (see Figure 4). Each independent task displays its own window with command buttons to stop or kill the process and with message labels and sliding bars showing the progress of different operations executed by the task (see Figure 5).

To keep things simple we used a 3-D variation of the Athena widget set to develop the graphical interface. The graphical objects created with this library are simple, if less attractive then those generated using other toolkits. We chose this option because the Xaw3D library is not too large, is efficient, is widely available and free. Furthermore, it permits us to maintain compatibility with our previous instruments' software.

Figure 6. The M15 Galaxy as Seen from Galileo National Telescope

Why Linux?

In the development of such a complex acquisition system we think the use of Linux was a natural choice. There are several reasons:

  • Linux offers a stable, flexible and solid environment that eases the development of efficient and robust applications.

  • Linux allows us to build a reliable acquisition system without hangs or crashes in a taxing operations environment.

  • Linux multitasking is rock-solid.

  • It's possible to introduce new hardware support by changing device drivers.

  • The implementation of the TCP/IP protocol gives support for network applications with the ability to develop distributed programs in order to control the system remotely. This represents an important feature for an acquisition system, especially in the astronomical field.

  • The XWindow system is an environment suited to develop graphic user-friendly applications that are platform-hardware independent.

Conclusion

This project is more proof that GNU/Linux is a stable and fruitful platform for data acquisition and instrument control. Our next project will involve still more, both as an embedded system OS and as a general control computer OS.

Load Disqus comments