BAIT Communication Protocol

The BAIT communication protocol was developed at the Astronomy Department at U.C. Berkeley for the Berkeley Automated Imaging Telescope (BAIT) project . The protocol uses messages over TCP/IP sockets. In this way the hardware control can be maintained in a modular fashion without regard to the operating system used on the client or the server. The basic command structure consists of ASCII messages similar to:

point ra=00:57:45 dec=35:12:55 nodome

Each message consists of one or more fields delimited by spaces. The terminator is a NULL (0) character. The first field contains the command. The other fields can contain keywords or keyword=value pairs. The replies are limited to the two forms: 

done point dist=.03 
  or
ERROR point power not on
The ordinary case reponds with the word, done followed by the name of the command followed by any optional keyword, keyword value pairs. The second ERROR form lists the command name and any error message. This message results from problems in either interpreting or executing the command.

Each command must have a help feature so that if the first keyword is help the command will report back immediately with a string showing the allowable options. (With optional keywords in [] brackets.) For example: 

point help
done point ra= dec= [equinox=] [nodome] [noapp] [nocorr]

Every server must have a help command which lists the commands that are available. This command is used by tserver to link up servers under one roof. For example one telescope server may have the following conversation. 

help
done help beep dome mirror move_sec offset point power slit temps track

There is an abort message which can be sent via UDP rather than TCP. Long loops should look for this message and terminate if it is received with an ERROR message.

Option Specification

The commands and options are case sensitive and are usually in lower case. There are different types of options that are specified in the following shorthand. Note: Babylonian or sexagesimal numbers must be specified with colons and not spaces delimiting the fields. The seconds field is not necessary, but the minutes one is. Personally, I hate this notation.

Multitasking

Each command is blocking i.e. it doesn't return until the task is completed. Therefore commands within one server can only be executed one at a time.

Commands sent to different servers may, however, be executed simultaneously. For example, if the filter wheel, telescope and CCD camera are all controlled by different servers, they may be operated simultaneously. To allow this the tx command allows multiple connections.

Aborting Operations

Commands may be aborted by sending an abort command on a UDP rather than TCP channel.

GENERIC PROTOCOLS

These protocols are templates and vary from installation to installation depending on the properties of the instrument. Here are how they are implemented at the RCT.

Binary Data Transmision

The ASCII protocol will bog down if large amounts of data are to be transmitted. We have therfore put in an additional option to the done/ERROR replies mentioned above. If the reply is of the form 

nbytes=xxx
where xxx is a number, the next transmission will consist of the specified number of bytes. This transmission will then be followed by the usual done message. The nbytes= are never transmitted without a request and usually they usually asked for with a nbytes= in part of the command.

The received bytes can be stored as uninterpreted bytes but the other following keywords can be used to help interpret the incoming bytes:

SEE ALSO

Program index