On 11. February 2009 we did our first visit to 1.23 at CAHA. Thanks to the great support of Ulli Thiele we got the basic info which is summarized further.

The telescope is ready to be used from within Solaris on its principal computer. All the remote observational commands are available as executable programs, which are non-blocking. There are three sets of these commands - telescope, CCD and filter wheel control. All these commands are very old and generally cannot be changed. Most of the control has been written by people who is retired or even dead and the source codes are not available.

Good news is that the telescope is not willing to self destroy if incorrectly commanded. The low limit of pointing is at altitude of 10deg.

The pointing accuracy of the telescope is of the order of 30“ and is expected to improve.

We discussed the possibility of installing our stuff on Solaris - it seems this would be the cleanest solution, This Solaris has a C and C++ compiler, but it may be painful to get all the libraries we need to use to run there. The extreme example case being the PSQL database. The obtained images are physically on this computer.

Another option would be to run RTS2 from antoher computer. The forementioned Solaris is accessible via SSH and therefore this computer could be practically anywhere in the world. Practically this would mean somewhere at CAHA. It is not certain how much support we may expect from the CAHA staff in this case - although the computer would most likely be of CAHA or officially provided by us as a support of the 1.23m telescope project.

This is, however, not a concern for the case of early testing.

Update 20.iii.2009:

We are definitively trying to get RTS2 working on Solaris ultra2.caha.es. I managed to compile astrometry after some minor struggle with it. So here we go:

• The astrometric registration script is /disk-a/obs12/jelinek/ast123. It contains no dark/flat correction as we still need to make clear how (and if) we are going to play with those things.
• rtopera2, the BOOTES astrometric package is in /disk-a/obs12/jelinek/rtopera2, no binary installation has been performed (programs must be called from within there.
• libnova is there, in /disk-a/obs12/kubanek/libnova-0.12.3/, it does not support Lunar computations yet, for there were some problems compiling the source.

The compilation problems against linux machines were the following:

• asprintf() does not exist: generally replaced with malloc(1024);sprintf(…
• sinl(). cosl() and similar are not present on Solaris - macros made
• round() call does not exist - enabled a windows macro.
• getopt_long() i did not find, header file #include <getopt.h> does not exist. getopt() may be used instead, losing the long options, however.
• to get support for socket & hostname lookup in programs, one must link against -lsocket -lnsl

There is a built-in focus/temperature self-correction to prevent frequent focusing during the operation. The focal offsets of various filters are not known and it is known that they are not treated within the existing solution. They are very likely to be small for the existing filter set, but may be of a concern if a custom filter is inserted.

There is a basic set of Bessel filters. Custom filters of 50x50mm may be inserted upon request.

We tested the focusing procedure, it's on ultra2:~/jelinek/focscr123, it works, produces images with columns of stars with different focuses. We have been told that within CAHA there is a program to tell the best focus out of such an image.

When running this script we get a Warning: interrupt in select function at the graphical screen. Weird.

The operation of RTS2 may, at present, appear chaotic to the responsible CAHA staff, especially in case of GRB alerts. We believe that care should be taken to inform people around about the actions the telescope is performing in a simple and accessible way.

CAHA maintains a database of all available information (meteo/ccd info/telescope info/etc.) Practically anything can be taken there. Most importantly the imaging CCD properties and conditions, which cannot be taken with any info command on the command line.

This is still a piece of magic for us. However, seemingly this may be the key to get a real grip to the telescope with RTS2. The calls provided to us for managing the CCD camera are in fact actually EPICS wrappers.

This section contains the control model rewritten from the sheet Ulli Thiele gave us during our first visit to CAHA. Plus some notes regarding various points which were not in the original text.

The telescope is controlled with the computer tecs12. To get the graphical interface go for

ssh tecs@tecs12

setenv DISPLAY ultra2:0.0 or another if the DISPLAY was created by ssh

start comes the famous window of tecs

there are 2 actions:

• start_tcs to restart the telescope control, normally not needed, but sometimes has to be tried more than once. If used, wait until the logging falling into the terminal ceases and then the other command may be run.
• start_gui: starts the GUI.

In GUI:

1. Make sure the REMOTE is in GREEN, if it is red, it may be really not remote or you may need to start_tcs of the previous step
2. Start the hydraulics with the button hydraulics, it may take up to one minute and it may fail and need another try.
3. Start the drives with drives, this is normally short amd makes no problems.
4. Manage the dome with the pull-down dome, auto means to follow the telescope.

The following scripting commands are executed at ultra2.

From what I have seen they are all scripts which can be studied (and not really used literally). The level of support of programs based on what has been found inside is, however, likely to be different than if we use them as they are. On the other hand, connecting rts2 to epics would bring a serious simplification.

They are generally blocking commands which end when the requested action is finished. They return a single numeric value on a line to determine the exit status. (We are missing examples of the output of each command at this moment.) The dome is entirely integrated with the telescope, there is no need to take care of it.

As I (mates) understood, this set of commands, although old as the others, has been recently revisited by Ulli Thiele when the telescope has been repaired and could, theoretically, be retouched if there are some issues. But we should not expect Ulli or anybody else do much effort here.

t_posit hh mm ss dd mm ss Eqx sends the telescope to the given coordinates, returns when the position is reached.

t_offset d_RA d_DEC sends the telescope the reqest for pointing offset. It is in units of 0.1arcsec. (note: is this is an image offset of a pointing offset? To move the given amount of pixels, should we or shouldn't we multiply by cos(\delta)?)

t_afocus focus_absolute value (mm) tried, works

t_dfocus focus_differential_value (mm) seem that it does not work

t_request is a query command - it returns alpha,delta,HA,AM,ST,UT,focus,casspos. tried, works

camera_chip1_hbin h_binning_factor

camera_chip1_vbin v_binning_factor

camera_chip1_x1 x_starting_pixel (min.=2)

camera_chip1_x2 x_end_pixel

camera_chip1_y1 y_starting_pixel

camera_chip1_y2 y_end_pixel

camera_dewar1_exptype dark/science/flat/focus

camera_expmode normal/test

camera_dewar1_exptime exposure_time (s)

camera_objectname object_name mandatory to set

camera_configfile filename where a predefined configuration may be stored

camera_dewar1_start wait Starts the exposure, waits for end of readout. The full CCD (2048×2048) readout takes about 3.5 minutes. The fits image obtained appears, with all appropriate header keywords filled, in the CAHA archive some 1 minute later. It can be accessed via FTP.

camera_chip1_rowshifts number_of_rows for focus exposures

camera_dewar1_f_loops number_of_loops for focus exposures

camera_reset1 reset the CCD electronics (i.e. to kill the ongiong exposure)

camera_readout There may be a command to invoke readout before finishing the exposure. UT is not sure.

Filter wheel commands are not known to us at this moment.

Define binning and readout window (can be set from a config file)

Define the exposure type: science/dark/flat

Define the exposure mode: normal or test (In test mode the file test0001.fits will be always owerwritten.)

Enter the exposure time

These actions need to be done only once, if nothing changes

Define the object name: This has to be done before each exposure.

Start exposure: camera_dewar1_start wait (The wait is necessary, otherwise the script would go on without waiting for the end of the exposure. How to find out that the exposure has finished if we do not give the wait?

Select exposure type as focus

Define the row shift (default is 50which is OK in most cases)

Define the number of focus loops (def: 7)

• Start the exposure: camera_dewar_start wait, wait for the end of exposure
• change focus
• start again etc. until all exposures are done
• after the last exposure the readout will start

Martin and Javier will go to CAHA (as soon as possible), see telescope, instruments, and bring back information:

• how are instruments connected. That is:
  • how are telescope motor interfaced
  • how is dome interfaced
  • how is CCD interfaced
  • if there is description of protocol used to communicate with the devices (and bring that description if there is one)

• If there is any available program which exploit telescope and devices functions, and for which we can get source code, so I can see how to communicate with the telescope.

After I get those information, I will start to write drivers. Most probably I will need a day for driver, if the interface is well defined.

After I return from NZ, I will drive to CAHA, stay there for some time, tests and finish drivers. After that, we will have the scope running, and can see how we can offer telescope time to other participants.

Dream case will be when we can get ssh out access to CAHA control computer, so I can test remotely from NZ (with Martin or Javier overseeing telescope operations - it is a bit though and dangerous beast, so I prefer to have somebody nearby to check for possible problems).

I expect that we will get telescope up and running with current RTS2 at mid March. We will see if till this time I will get interface for others to enter observations requests, but I hope I will have that ready.