Nightview for developer

A description

The nightview package is a server-client application. This means that, in principle, minimally two programs must run: The server program on computer with camera connected and some client program. We recommends use different computers for its due to increase efficiency during down-loading image over parallel port. Both server and client can run on the same machine, of course.

Our configuration on MonteBoo is an old P90 computer as server and (de)Celeron 433 as a platform for client. Both run the Debian. The server don't need massive hardware support. It run only server and a few operational system utilities. I believe that 386 with 8Megs of memory and 50M disc will be OK, but I recommends at least 486 with respect to the higher speeds of image downloading over parallel port. The more than P90, 16M memory and 100M disc is un-warranted luxury and it don't operate faster because limited by the parallel port and net speed. The server needn't extensive use of disc space. Only the clients saves images. The server-client framework is equipped to use in TCP/IP environment. Than the utility will be work for example over intranet with ethernet, serial or radio link. The Monte Boo camera operates on one ethernet segment of the Masaryk University, so the our camera is directly connected to Internet. Note, that server part not needs some expensive libraries except libsbig, cfitsio and standard system libraries.

The nightview package contains two kinds of clients: GUI for GTK+ and shell utilities. The GTK+ front-end is usable for interactive control of the CCD. It's useful for focusing, temperature regulation or telescope pointing.

The shell client are developed for non-interactive control of CCD. They are contains all functions of the GUI package and all functions of the CCD camera. With this utilities the camera is controled over a extremely slow communication lines (telephone) and for the batch processing. There is a shell front-end - night_control - for acquiring of image series with arbitrary combination of the exposure timeouts and filters.

In principle, there is no problem for implementation of clients on other platforms or in others languages or environments. So, the windows users can connect to server with fully transparency as the linux clients for example. Moreover, I suppose that the implementation of the on-line http server with full control of the camera will be developed in the near future.

GUI Configuration files

Both xnightview and xmove creates config files. Its names are .xnightviewrc and .xmoverc and lies in user's home directory. The format of the files is really simple. The text files contains options on separate lines are in the form:

key = value

It is possible (without doubt) edit the files by hand when its parent application doesn't run (these files are updated on exit).

Format of the xmove catalogue

The xmove stores its catalogue items in file $HOME/.xmove.stars as lines with format:

name alpha delta

where the values are separated by tabs. The equatorial coordinates alpha, delta are in degress (equinox is your matter). The file is usually created during observation when different objects are get from SIMBAD.

Moreover, the file may be created from any catalogue by some simple convertor. The file than can be used in xmove and loaded via File->Load menu item.

How to control home-made mount

The telescoped server is independent on your hardware solution of the mount. On the other side, this independence requires a site specific solution for slow of the telescope. This solution is build on a few low-level subroutines directly used to communication with mount engine.

A good example is a mount with axes driven by steeper motors. The steeper motor have 100 steps per revolution (for example), your gears provides 1:3600 ratio so the low-level subroutines may know that you have a 100 steps per degree. Moreover, this drivers may provide communication over some interface (hardware dependent again).

To use of the telescope mount controlel, we need to provide a few commands to do it. The commands must satisfy conventions described below. The utility names are mandatory.

The nightview package defines six general commands to control of the telescope. The telescope_hang, telescope_dekl, telescope_clock and telescope_stop controls the telescope. The telescope_domeinit and telescope_dome controls the dome. The table describe usage:

The telescope_hang command change Hour angle of the telescope for value given by first parameter. If current hour angle of the telescope is h, than telescope slew to a new coordinate h+Δh. All values are in degrees, positive and negative values for differnece are allowed. Second parameter is velocity for slew in degrees per second. The command should immediately print the number of seconds needs to moving as a machine readable float number. If any error is occurred the zero is printed and return value should by set to non-zero.

The telescope_dekl command change declination of the telescope for value given by first parameter. If current declination of the telescope is δ, than telescope slew to a new coordinate δ+Δδ. All values are in degrees, positive and negative values for differnece are allowed. Second parameter is velocity for slew in degrees per second. The command should immediately print the number of seconds needs to moving as a machine readable float number. If any error is occurred the zero is printed and return value should by set to non-zero.

The telescope_clock command switch on the clock of siderical time of the mount when parameter 1 (or any positive non-zero value) is supplied. If the zero (or negative or nothing) is specified, the clock is stopped. The float-number format can be used. The command should immediately print the number one (1) (may by a float number) when started and number zero (0) (may by a float number) when stopped the clocks. If any error is occurred the zero is printed and return value should by set to non-zero.

The telescope_stop command immediately stop all moving (clock included) motors. It's normally not used and is invoked when unconditional interrupt from user is occurred. The command line arguments are non-relevant and print the 0 (fail) or 1 (success).

The telescope_domeinit command initialise the dome (open the doors, spin to the telescope position for example) when firts parameter 1 (or any positive non-zero value) is supplied. If the zero (or negative or nothing) is specified, the dome is uninitialised (doors are closed, power is down). The float-number format can be used. The command should immediately print the number one (1) (may by a float number) when dome is initial and number zero (0) (may by a float number) when uninitialised the dome. If any error is occurred the zero is printed and return value should by set to non-zero.

The telescope_dome command change azimuth of the dome's (of the slit) for value given by first parameter. If current azimut of the dome is A, than dome slew to a new coordinate A+ΔA. All values are in degrees, positive and negative values for differnece are allowed. Second parameter is velocity for slew in degrees per second. The command should immediately print the number of seconds needs to moving as a machine readable float number. If any error is occurred the zero is printed and return value should by set to non-zero.

Warning. For correct behaviour of the telescoped server, all listed drivers are need. Otherwise, the server will be flood your syslog with warnings and control utilities will print confusing messages. If any function is not supported by your hardware (like dome) use a dummy script. For example, there is a telescope_dummy script for supply:

#!/bin/sh
#
# dummy telescope

echo -1
exit 0

To use it, make any approprite links on its.

How to code your own client?

There are two ways how to do it. First, simpler, is to use of the night_* utilities and call in your code as a some type of subprocess. xmove, xnightview or night_batch can show a way.

In case, that this is not appropriate, you can communicate directly to the server. An example of the needs will be a web client in an exotic language or an extremly portable utility.

The server can be connected directly to the comunication socket or to the web proxy. In both cases, the comunnication is command driven, eg. the client is asking of the server and the server is serving the client with an ansfer.

Last modification: 2009-01-22 16:06:42