RTML submission (in blue) to LT Phase 2 database and how it compares to other methods. © 2016 LT Group


Regular users of the Liverpool Telescope (LT) will be familiar with the standard method of setting up their observations, namely the Java-based Phase 2 User Interface or "Phase2UI".

This user interface, accessible only to registered users of the LT, enables them to manually define their observation details: the coordinates of their targets; the timing of their observations; the instruments and filters to be used; and the number and length of the exposures. The interface transmits this information directly to the telescope's Phase 2 database, which is polled by the robotic scheduler repeatedly through the night between observations to decide what to observe next — i.e. to match the best observation to current conditions.

If using the Phase2UI at night, the new or updated observation group will be considered by the scheduler as soon as it makes its next poll. So it could potentially be chosen and observed mere seconds after the "Submit" button is pressed.


What may not be so widely known is an alternative way an LT user can enter observation details, which in some cases is faster and more convenient. It uses the "Remote Telescope Markup Language" (RTML) protocol, which was invented in 1989 at the University of California at Berkely, USA. It's a special dialect of XML (Extensible Markup Language), and is used to remote-control telescopes, or to communicate with autonomous robotic telescopes.

We provide two different ways to use RTML to send your observation details to the LT. Like the Phase2UI, both of them insert the information straight into the phase 2 database. The advantage however is that they allow you to automate the Phase 2 process, particularly useful if you have a lot of targets or observation groups to enter. The two RTML interfaces are:

  • command-line tools:
    • one tool to generate the RTML, and another to send the RTML directly to the LT
    • can be incorporated into customised scripts and programs
    • example use: generating and entering many targets quickly
  • LT-specific RTML Application Programming Interface (API):
    • allows users to build their own customised GUI tools at their institutions
    • GUI makes use of API to generate RTML and send directly to LT

We have in the past provided a third interface: bespoke webpages created by us for users who do not want to program with the command-line tools or API. These restricted-access pages contained HTML forms tailored to a user's specific observing programme. They generated observation details in RTML and transmitted directly to the LT. These pages are now being phased out.

Rapid-response overrides

Both RTML interfaces can also talk directly to the Target of Opportunity Control Agent (TOCA), the system that triggers the LT's rapid-response capability to interrupt the current observation and immediately observe your target instead. The LT already performs completely autonomous instant overrides for Gamma-Ray Burst alerts via a different protocol from the NASA Gamma-ray Coordinates Network (see GCN in diagram above), but a similar end result is also possible via RTML/TOCA.

As you can imagine, overrides can be very disruptive. Therefore permission to have TOCA capability has to be requested at the Phase 1 stage and approved by the TAC.

RTML-capable instruments

RTML capability is being phased in across the LT's suite of instruments. IO:O and IO:I have been available for RTML response for some time, and now SPRAT has been added to the list. FRODOSpec and RISE are next, and we hope to have them available soon.

Applying for RTML capability

The RTML facility is available to all users who have TAC-awarded time allocations. Please contact us if this sounds interesting, and we will provide full user instructions.