Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Represents every hardware and software setting that can be changed at run-time, either for observations or for engineering tests.
  • Examples include analogue attenuations, channel selection, beamformer parameters, time/frequency averaging settings, whether data is being captured or not, etc.
  • Every setting has a desired state (what the user wanted it to be, at any particular time) and an actual state (what it was actually known to be at that time, or that the actual hardware state was unknown).
  • The reality of working with a ‘large N’ telescope means that the desired state of the telescope, as defined by the observing schedule, will never completely match the actual state.
  • The state (desired and actual) is stored in a PostgreSQL database, and every row in every table contains a time range (starttime and stoptime columns) for which that state entry applies.
  • The contents of the ‘desired state’ tables form the telescope schedule, defining what it should be, or should have been, doing at any given time.
  • One or more ‘observation controllers’ run continuously, reading the ‘desired state’ tables and communicating with all the hardware and software elements of the telescope to command them to change state as and when the schedule specifies.
  • The observation controller/s, along with other software monitoring the status of different elements, maintain another set of tables with the actual state of every element of the telescope, at all times.
  • Database constraints prevent entries in the past from being modified. For current observations  (if ‘starttime’ is in the past, and ‘stoptime’ is in the future) only the ‘stoptime’ column can be changed.

...