 |
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass98/teubenp/
Дата изменения: Sat Jul 17 00:46:42 1999 Дата индексирования: Tue Oct 2 07:01:33 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п п п п п п п п п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п |
WASP and its front-end computer are fully mobile and can be taken to any suitable radio telescope. The front-end is typically connected via Ethernet to the actual observing computer at the telescope. We will also discuss a typical observing setup in such a loosely coupled environment.
A ruggedized Pentium-133 was acquired (replacing the previous 486-33 Lynx-OS-based setup) to which a standard NI GPIB card and Metrabyte PIO-12 DAQ card were added. RedHat 5.1 Linux was installed and modularized device drivers for the PIO-12 and GPIB cards were obtained from the Linux Lab project.
|
The WASP (Harris, Isaak, & Zmuidzinas 1998) signal feeds directly into the PIO-12 and is driven at 4.603 kHz by WASP. WASP is also controlled via the PIO-12 card as the i8255 based PIO-12 card contains 3 bytes, configurable in many I/O modes. We use PA to read, PB to write, PC(low nibble) to write and PC(high nibble) to read.
The GPIB card is connected to an HP8648C synthesizer for bandpass calibration, which in turn drives WASP in calibration mode, (see also Fig. 1).
Several cheap alternatives to increase performance and/or responsiveness are available on Linux:
qsched -t 10000 rmsobs
would run rmsobs in guaranteed timeslices of 10 seconds. This can of course (like many in these situations) hang the machine if not carefully used. We tried QNX scheduling and found it to be reliable for short observations, but lack of low level scheduling made it impossible to adopt it for complex tasks like the bandpass calibration.
Victor Yodaiken and collaborators at New Mexico Tech (Socorro) have recently made patches available to the Linux kernel which turns it into a good Real-Time operating system. This works by a user supplied kernel module, which takes over control of the computer. Only when this user module has determined there is time left will the kernel get time allotted and can do its usual things. Communications between these modules and user program occurs via special RT FIFO buffers. As usual in this business, programmers need to take special care not to produce situations that can lock up the computer.
We wrote an interrupt driven Real-Time module to guarantee that no data will be lost. Data are then read until a full ``lag-readout'' has been accumulated (192 bytes at a rate of 4.6kHz) and sent to a user program via a Real-Time FIFO. This turned out to work very reliably. The periodicity and nature of this signal also made it possible to accurately determine if data were missed.
Since WASP was designed to be mobile, a typical observing mode might consist of shipping the WASP box (the current prototype is a 1 cubic meter) together with the HP synthesizer and Linux box to a remote observatory where the IF mixed signal can be spectrum analyzed.
The Linux box will only be controlling the spectrometer itself and is normally part of a local network. The observing telescope computer will drive the telescope and send synchronized commands (in the form of remote shell scripts) to the Linux box to perform integrations, calibrate the signal, set the chopper, etc.
WASP2 is being planned, taking data at 50kHz instead of the current 5kHz rate. Our current P133 should be able to handle around 30-50kHz, a Pentium-II-266 should be able to handle a 150kHz interrupt rate.
 |
Harris, A. I., Isaak, K. G., & Zmuidzinas, J. 1998, in SPIE Proc., Vol. 3357, Advanced Technology MMW, Radio, and Terahertz Telescopes, ed. T. G. Phillips (Bellingham: SPIE), 384