Is RTS2 an open standard?
Yes, it is. RTS2 defines TCP/IP interfaces between devices found at the observatory, services observatory shall provide, and central server, which registers devices and services and provides observatory-wide state propagation and blocking.
Who is using RTS2?
RTS2 is used on more than 20 observatories around the world, ranging in diameter from 10cm to almost 2m. RTS2 was selected by ESA in an open bid for environment to control its space monitoring telescopes.
Will RTS2 run on Windows?
Yes. If you don't want to change anything, please use cygwin environment and compile RTS2 in it. If you want native Windows interface, please consider providing Windows port or get in touch with us for negotiation details. We don't need Windows, and as long as nobody will pay us to provide direct support for Windows, Microsoft Windows (or any other closed source operation system) will remain unsupported.
Why there aren't precompiled binary packages?
Because we are not funded for providing binary packages. If you want them, please consider either providing them, or get in contact with us regarding funding necessary to have binary packages.
Why I should use RTS2 instead of ASCOM?
ASCOM is a standard tightly coupled with Windows closed source COM/DCOM model, now being depreciated by its backing company in favour of .NET and other marketing tricks. We are not interested in upgrading our environment every few years.
ASCOM has following bottlenecks, which makes its use at big observatories difficult:
* it is strictly typed, it is not possible to extend devices with additional information - consider switching on/off hydraulics, or various variables RTS2 image processor can output to signal current observation conditions
* it hardly scales over network
* it does not provide in our sense reasonable weather reaction subsystem - in RTS2, every device can signal bad weather and block operations of the observatory
How do I add and schedule a new target?
There is a MPEC howto. Entering target is very similar, just instead of MPEC one-line you put in target name (resolvable by SIMBAD):
rts2-newtarget 5004 M74 01:37:14+15:50:14
Which images consider rts2-imgproc as good and which as bad?
rts2-imgproc actually have three output scenarios for the images:
- bad, when imgproc is unable to read the image. This means that the image FITS header is screwed or that something else failed. Then this image is moved to bad directory in directory from which the image was taken
- trash, when image processing routine do not output string with astrometry informations to standard output.
- good, when image processing routine (defined in /etc/rts2/rts2.ini file) output string in format
%li %lf %lf (%lf,%lf)
for the scanf. The format is defined in src/plan/connimgprocess.cpp. First is image ID - and integer. Second and third are RA and DEC of image centre expressed in degrees (RA 0..360.0, DEC -90..90). In brackets are errors in RA and DEC, in arcminutes. Assuming your image centre is at RA DEC 12:00:00 05:00:00 and the telescope pointed to 12:01:00 05:01:00, the output string should be:
1 180.0 5.0 (.2499999990 .0166666666)
When is selector called to select next target?
Selector (rts2-selector) is process responsible for selecting new observational targets. It sends targets IDs using next command. You can imitate selector behavior by running rts2-mon, selecting EXEC component and typing: next 1000 to select target with id 1000. The selection is executed on the following occasions:
- When observatory is switched to ON state, so the executor knows what to observe
- during last exposure on last exposing camera in script, so the executor is keep updated what to observe as the next target
- every idle_select seconds, so new targets are selected even if some long script is running. The value of idle_select defaults to 300 seconds (=5 minutes). It can be changed by providing –idle-select parameter to rts2-selector (most probably in etc/rts2/services file).