Download 5 General Requirements to the Software

Large Binocular Telescope
ARGOS
Advanced Rayleigh Ground layer adaptive Optics System
Software Preliminary Design
Doc. No.
Issue
Date
ARGOS PDR 012
1.0
2009/02/01
Prepared
W. Gaessler
Name
2009/02/01
Date
Approved
L. Busoni
Name
2009/01/03
Date
Released
S. Rabien
Name
2009/01/03
Date
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
2 of 65
TABLE OF CONTENTS
Change Record ................................................................................................................................................ 3
1
Scope ...................................................................................................................................................... 4
2
Applicable documents ............................................................................................................................ 4
3
References .............................................................................................................................................. 5
4
Introduction ............................................................................................................................................ 6
5
General Requirements to the Software ................................................................................................... 6
6
ARGOS in a nutshell .............................................................................................................................. 8
7
Use Cases.............................................................................................................................................. 11
7.1
Actors ........................................................................................................................................... 11
7.2
Observation Modes ...................................................................................................................... 12
7.3
Observation procedures ............................................................................................................... 13
7.4
Setup procedures .......................................................................................................................... 28
8
Operating Environment ........................................................................................................................ 32
8.1
Current Hardware layout of FLAO .............................................................................................. 32
8.2
Current SW layout of FLAO........................................................................................................ 32
8.3
Current interface to TCS .............................................................................................................. 33
9
Software Structure and Functional Specifications ................................................................................ 36
9.1
Common Software ....................................................................................................................... 38
9.2
Laser and Launch System Software (LLS) .................................................................................. 42
9.3
LGS Wavefront Sensor System Software (LGSW) ..................................................................... 44
9.4
Wavefront Data Handling System Software (WDHS)................................................................. 46
9.5
Tip Tilt and Truth (T3) Sensor Software ..................................................................................... 48
9.6
DM Diagnostic Software (DMD) ................................................................................................ 48
9.7
Real-time reconstructor software (RTR)...................................................................................... 49
9.8
PSF reconstruction software ........................................................................................................ 51
9.9
Observation Preparation Software ............................................................................................... 55
10 Computer Architecture ......................................................................................................................... 57
11 Network Architecture ........................................................................................................................... 59
APPENDIX (1): ............................................................................................................................................ 63
List of acronyms ............................................................................................................................................ 63
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
3 of 65
Change Record
Issue Date
Section/ Paragraph Affected
Reasons / Remarks
Name
0.1
2008/08/11
All
Created
gaessler
0.2
2008/11/24
All
Moved to new template
gaessler
0.3
2008/12/16
All
PDR refinement
gaessler
1.0
2009/02/01
All
PDR for approval
gaessler
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
4 of 65
1 Scope
This document presents the preliminary design of the software, including definition of computer hardware
and network architecture.
2 Applicable documents
No.
Title
AD 1
AD 2
AD 3
AD 4
AD 5
AD 6
AD 7
AD 8
AD 9
AD 10
AD 11
AD 12
AD 13
AD 14
AD 15
AD 16
AD 17
AD 18
AD 19
AD 20
AD 21
AD 22
AD 23
AD 24
AD 25
AD 26
AD 27
AD 28
AD 29
AD 30
AD 31
Number & Issue
LBT Laser Phase A study report
Executive Summary
Science Case Study
Management Plan
LBT Implementation Plan
ICD
System Design
Laser System Design
Launch System Design
Wavefront Sensor Design
Tip-Tilt Tracker Design
Software Design
Calibration Unit Design
Site Characterization Report
Upgrade Path Plan
LBT ASM Functional Description
FLAO Subsystem Functional Description
AOS Functional Description
FLAO WFS software
ASM Software Components
Integration of the AdOpt Software into TCS
AOS Functional Description
LN Common Software
LN Software Overview
LBTO-AO Software Architecture
ASM Basic Computational Unit Design Report
LBT AO Real Time Software
LBT Specifications
Skycat manual
LBT common software description
LBT software subsystem descritpion
© ARGOS Consortium
1.0
ARGOS-PDR-000
ARGOS-PDR-001
ARGOS-PDR-002
ARGOS-PDR-003
ARGOS-PDR-004
ARGOS-PDR-005
ARGOS-PDR-006
ARGOS-PDR-007
ARGOS-PDR-008
ARGOS-PDR-009
ARGOS-PDR-010
ARGOS-PDR-011
ARGOS-PDR-012
ARGOS-PDR-013
CAN-486f007a
LBT-AdOpt.001
CAN-486f006c
LBT-SW workshop 2006
LBT-SW workshop 2006
Soft-002, Version 1.2
AdOptSW.005, Version 2.1
LN-MPIA-SWDR-ICS-001, 1.1
LN-MPIA-SWDR-ICS-001, 2.1,
LBT-SW workshop 2006
CAN-640a009a
LBT AO meeting February 2005
LBT spec 1998
481s501a 1.0 July 13 2006
481s008a 1.0 July 13 2006
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
5 of 65
3 References
No.
Author, Year, Journal. Vol.,
Name
RD 1
Wilson 2002, MNRAS, 337,
SLODAR: measuring optical turbulence altitude with a
Shack -Hartmann wavefront sensor
RD 2
Britton 2006, PASP, 118,
The Anisoplanatic Point-Spread Function in Adaptive
Optics
RD 3
Gavel 2004, SPIE, 5490,
Tomography for multiconjugate adaptive optics systems
using laser guide stars
RD 4
Gendron 1994, A&A, 291,
Astonomical AO: I. Modal control optimization
RD 5
Gendron et al. 2006, A&A, 457,
New algorithms for adaptive optics point-spread function
reconstruction
RD 6
Jolissaint 2006, JOSA,
Analytical modeling of AO of the phase spatiial power
spectrum approach
RD 7 Jolissaint, submited,
OPERA , an automaitc PSF reconstruction software for
SH AO systems: application to Altair
RD 8 Peter 2008, PhD,
RD 9
Veran et al. 1997, JOSAA, 14,
Estimation of the adaptive optics long exposure pointspread function using control loop data
RD 10 Wilson 2002, MNRAS, 337,
SLODAR: measuring optical turbulence altitude with a
Shack- Hartmannwavefront sensor
RD 11 Whiteley 1998, ApOpt, 37,
Incorporating Higher-Order Modal Measurements in
Tilt Estimation: Natural and Laser Guide Star
Applications
RD 12 Whiteley et al.1998, JOSAA,15,
Temporal properties of the Zernike expansion
coefficients of turbulence- induced phase
aberrations for aperture and source motion
RD 13 Whiteley et al. 1998, JOSAA,15,
Optimal modal wave-front compensation for
anisoplanatism in adaptiveptics
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
6 of 65
4 Introduction
The software design and implementation lives from the requirement gathering. Therefore, we extended the
work of the Phase A study with more detailed procedures and functional specifications. After mentioning
the basic requirements for the software design in chapter 5 a short overview of the ARGOS system and
possible software component structure is given (chapter 6) – ARGOS for dummys, so to say. The real
desing starts with discussing the use cases in chapter 7. Here, we want to learn who wants to do what with
ARGOS and how this is sequenced in time. In chapter 8 we have a look at the environment and existing
software at LBT, which sets certain constraints to us, before we then define the software structure and
discuss the functional specification of software packages in detail in chapter 9. Finally we break down the
computer architecture and network architecture in chapter 10 and chapter 11, respectively.
All the section are constructed that they are selfconsistent. It is not an absolute must to follow the given
outline but it is helpful to do so. The idea of the chapter ‘ARGOS in a nutshell’ at the beginning is to give a
short summary and a glimps of where all will end already in the beginning.
5 General Requirements to the Software
Requirements and general rules are described, which are baseline to the following design description. The
code implementation should follow this rules in all software layers.
The software is divided into packages that consist of several modules providing certain functionalities. In
first order, a package reflects a hardware system, i.e. the wavefront sensor, the deformable mirror or the
laser launch system. Some packages are logical systems, unrelated to hardware, which are needed to
structure a task, i.e. a wavefront data handling system for extracting information from sensor data and
optimizing parameters. Each package should be able to run standalone, in parallel without interaction to
other packages or in parallel together interacting with other packages, therefore it has to fullfill following
requirements:
1. Independence – each package should be usable also if no other computer or package of
ARGOS is available. This capability is needed for testing and maintenance. Exception is the
common software that provides a common layer to all sub-system software. Any package
should be based on the common software.
2. Standalone - all devices and related SW services of a package should be under control of the
package itself. This needs to resolve all the hardware interferences and assign an unique
package to it from which it is operated only. The package must be able to start servers, switch
states and handle configuration on its own. All services such as configuration, logging,
sampling, scanning, storing, etc. have to be handled within this package on one computer or
distributed computers.
3. Efficiency – each package should use parallel command processing and device setup as much
as possible. It should also be able to execute commands in parallel with other packages without
interference.
4. Hierarchical control – The command structure has to be hierarchical. Commands can only go
top-down the hierarchy, never up. For each command status replies are sent back. Therefore
exception cases have to be defined if a sub-system fails and timeouts have to be handled and
defined. The hierarchical control is an exception since it only requests status and thus do not
change anything on a sub-system. To fulfill the independence and standalone requirement, a
possibility to interact with the sub-systems from engineering GUI or command line has also to
be allowed.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
7 of 65
5. Failure tolerant – Each package should be fault-tolerant to failures as much as possible. This
involves also recovery strategies and configurations to allow locking of broken hardware,
offline or simulation modes and using alarms as notification. So far safety allows, the program
should not be stopped. All communication has to be non blocking.
6. Transparency – The status should be available online and update asynchronously. Therefore
event channels can be used. Each server has to update its parameters at the latest after
execution of a command. Status information has to be provided also in a horizontal way
between sub-systems of the same software layer. Error messages have to be in such way that
the operator is able to undestand where the error happened and what failed.
7. Command safety – A GUI should provide separate command buttons to the selection of
components and values. Changes of parameters have to be activated through a separate button
executing the command. This does not allow having an entry widget that automatically starts a
command by changing the contents.
8. Automatization – All user interaction should be automated as much as possible to minimize
mistakes. Automatization should be done with scripts in a simple interpreter language. So they
are easy to understand and can be changed rapidly. However, it must also be possible to set
parameters interactively to a GUI and overrule automatic procedures. All automated
procedures should have a reasonable size and breaks. In case something fails it must be
possible to execute sub-sequences or only parts of the procedure.
9. Minimize Impact on existing systems – As the LGS system is implemented in an already
established environment and might use an already existing WFS for different purpose, the
impact on such systems have to be minimized and their current functionality only extended but
not removed or disturbed.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
8 of 65
6 ARGOS in a nutshell
The optomechanis of ARGOS can be divided into three major components, which are taken over as
component in the software structure:
 LLS: The laser launch system, which consist of the laser system and the launch optics.
 LGSW: The LGS wavefront sensor, which includes the dichroic.
 T3S: The tip tilt and truth sensor, which is based on the existing First light AO System (FLAO).
The deformable mirror diagnostics and the real-time reconstruction built an additional software component,
as the first is already one separate part in the existing FLAO and the latter is based in dedicated electronics.
Further we define a wavefront data handling system, which takes care of automatic optimization and offloading between different optical elements. Therefore, we have three further components:
 DMD: Deformable mirror diagnostics, which monitors the DM data and does the housekeeping
of the DM unit.
 RTR: The real-time reconstructor software.
 WDHS: The wavefront data handling system, which optimizes the AO loop and handles all the
off-loading and slow steering control loops of the system.
All these components have to interface with each other and the Telescope Control Software
(TCS) provided by an communication interface. The communication to the DM is defined by the ASM
interfaces from Microgate.
Figure 1: Component overview of ARGOS software.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
9 of 65
Figure 2: The scheme shows the control architecture with all interactions and the optical paths (ultra fine
dashed lines) for the LBT LGS GLAO system
The ARGOS system contains several control and off-loading loops as can be seen in Figure 2. The control
loops will be now shortly discussed separately.
Laser Launch control loops
Field control: The second mirror of the laser launch periscope controls the outgoing laser field positions
and differential initial settings for each laser separately. The position is measured with the field diagnostic
camera on a high sample rate.
Pupil control: The first mirror of the laser launch periscope controls the outgoing laser pupil position for
each laser separately. The position is measured with the pupil diagnostic camera on a low frame rate. The
optical entaglement of the two periscope mirrors on field position and pupil position is divided by the
different sampling rates of the field control and the pupil control.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
10 of 65
Launch stabilization: Accelerometers and off-loading from the WFS field stabilization will be taken as
input for the launch stabilization, which is done with the launch pupil mirror.
Focus control: The launch focus is controled with look up tables in feed forward using an objective on a
stage. Focus refinement can be done with help of the WFS data.
Laser Guide Star WFS control loops
LGSW field steering: A patrol camera in the WFS monitors and positions the laser on the LGSW initially.
The LGS WFS tip tilt is controlled with a periscope mirror system within each sensor path.
WFS pupil tracking: Evaluation of the outer subaperture intensities are used to set and track the pupil
position. A lens in front of the Pockels cells is moved compensating pupil flexure.
High order loop: The LGS WFS corrects the atmospheric turbulence with the Adaptive Secondary. Tip
Tilt modes are excluded.
Gating: The altitude and gating range is defined with the master clock and delay generators.
Tip Tilt control loop and Truth sensing
Natural Guide Star TT loop: The tip tilt measurement of the First Light AO (FLAO) system is sent to the
LGS WFS and added asynchroniously to the next LGS WFS command.
Truth sensor: The FLAO is used for truth sensing. Comparing LGS WFS measurement to NGS
measurements and refining slope offsets or calibrating modes.
Wavefront Data Handling System off-loading and arbitration
The WDHS collects all the WFS measurements of the LGS WFS and TT WFS/Truth Sensor. The offloading scheme can be summarized as follows:
 Long term atmospheric TT to hexapod.
 Tracking TT to mount.
 Telescope Flexure to hexapod.
 Launch Flexure to the entrance pupil mirror of the launch system (see launch stabilization above).
 Differential tip tilt at the WFS side to laser steering mirrors in launch.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
11 of 65
7 Use Cases
In this chapter we define the overall instrument use cases. This requires first to understand the users, in
software slang Actors. After that we define the observation modes and describe the sequences one has to
follow to get the instrument into operation. .
7.1 Actors
There are three different actors identified, which will use or operate the LGS system.
7.1.1 Astronomer
The astronomer is the actor requesting the use of the LGS system either in advance through her/his
observation proposal or at the site interactively because of promising conditions to use the system. She/he
might not be operating the system on his own.
The astronomer needs software to prepare his observation and define observation relevant parameters in
advance and at the site.
7.1.2 Operator
The operator is the actor running the LGS system. She/he starts the hardware and software and then handles
the system - mainly through GUI. In cases of simple errors she/he is allowed to take the action to recover.
Therefore the operator should have a good knowledge of the system in order to be able to carry out these
tasks. In case of errors, which are not easy to recover she/he should be able to identify and contact the right
engineer to fix the system. The operator, as defined here, should not be confused with telescope or
instrument operator. It can be the telescope or instrument operator but it could also be i.e. a support
astronomer, visiting astronomer or any other person fulfilling the profile above.
The operator needs software to handle and control the system like status GUI and command GUI as well as
scripts and servers to run the overall system. He must also be able to take over the pre-prepared observation
defined by the astronomer.
7.1.3 Engineer
The engineer is the actor who must be able to run the system on all levels. She/he needs ability to control
single hardware components standalone, as well as the possibility to change the debugging and logging
levels to evaluate the individual parts and the overall system. She/he is also the only one allowed to install
and remove the software and parts of it.
The engineer needs software to communicate with the hardware even on lowest level and over command
line. She/he needs evaluation and debugging tools on all system levels.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
12 of 65
7.2 Observation Modes
In principle, one would distinguish observation modes in spectroscopy, imaging, etc. However, the LGS
system is more integrated with the telescope than with the instrument. It will be used with LUCIFER just
with one side or with both sides together. Maybe in the future there will be further sensors on other
instruments making use of GLAO. The system provides a nearly homogeneous PSF over the field and
behaves as seeing reducer. In such case it might be irrelevant to the astronomer to know if it is running or
not, as the scientific data outcome looks close to one obtained w/o GLAO but under better atmospheric
conditions. Therefore, the observation modes of LGS-GLAO system define themselves less from the view
of spectroscopy or imaging but from the way how the system is operated: with or without preparation, with
or without TT-star, etc. Therefore we define following observation modes.
7.2.1 Pre-prepared
The astronomer has prepared the observation in advance by defining LGS and instrument relevant
parameters like the reference TT star, constraints on atmospheric conditions, etc. Depending on the Target
the observation can be with or w/o TT star.
7.2.2 Interactive
The astronomer decides on the spot to turn on the LGS system to improve the current seeing condition. The
TT-star is selected interactively through a selection GUI if one is available within the FoV.
Figure 3: Use case diagram1 of the ARGOS observation modes.
The two modes have different requirements to the software design, while the Pre-prepared demands an
Observation Preparation Software (OPS) the interactive modes demands GUIs which allow for simple and
fast interaction with the system.In the following we will support both ways with no further mentioning the
two different modes explicitely.
Further design drivers due to the mode analysis:
Observation Preparation Software for pre-prepared mode, which can be used at home and at site.
Graphical User Interface to select TT guide star interactively.
1
For all who are not so familar with Use case diagrams: An ‘extend’ is a form of interaction, the relationship indicates
that the behavior of the extension use case may be inserted in the extended use case under some conditions. The
‘include’ is another form of interaction, the given use case may include another. The first use case often depends
on the outcome of the included use case.. (Courtesy to Wikipedia for wording inspiration.)
© ARGOS Consortium
Doc:
Issue
Date
Page
Software Preliminary Design
ARGOS PDR 012
1.0
2009/02/01
13 of 65
7.3 Observation procedures
The observation procedures define the tasks to be done with an observation. In non-optimal case they are
expanded by setup procedures to optimize the telescope and wave front sensor performance. Two major
procedures could be identified. The first one is preset the telescope and the second one is offset over a large
or a small distance, nodding or dithering respectively. Depending on the distance the procedure will use
different hardware. Each observation procedures should be automated and parallized as much as possible
but also splitted in sub-procedures in such way, that not everything has to be repeated in case of an error.
Figure 4: Use Case Diagram of the ARGOS observation procedures.
7.3.1 Preset
The preset procedure acquires the observation target and gets the telescope and GLAO system in a state
such that the instrument can start the observation.
The preset is divided into the Telescope, Launch, LGSW and T3WFS parts of the preset which are
following in sequence. The expected maximal and average duration of each part and the sum for the full
preset is given in Table 1 for the different observation modes. Details on the calculation can be found in the
following description of each part of the preset. The maximal execution time is estimated to be less than
15min (interactive mode), while the shortest execution time is estimated with 4min (Preselected mode).
Table 1: Estimation of the maximal and averge execution time for the preset in different observation modes. The light
green adds to usual AO observations as LGS overhead.
Preset
Telescope
Launch
LGSW
T3WFS
Sum
LGS overhead
Preselected Max.
380s
60s
80s
100s
10.3 min/620s
140s
Preselected Av.
130s
17s
43s
50s
4min/240s
60s
© ARGOS Consortium
Interactive Max.
380s
60s
80s
340s
14.3min/860s
140s
Interactive Av.
130s
17s
43s
170s
6min/360s
60s
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
14 of 65
7.3.1.1 Telescope
The goal within this part of the preset is to point the telescope and start the tracking. All mechanical units
which have long moving times should be set to their nominal start positions so all further actions will not
be delayed too much. The telescope preset is common to all observation modes but stated here to verify the
complience with the existing implementation.
Preconditions: The selection of the instrument is done in advance and with that the Tertiary mirror is set to
the required angle. The instrument hardware is switched on and ready to use (state: online). The target must
be cleared from space command. A launch delay should be considered.
Procedure: The Preset moves the telescope to the object positon and starts tracking. Therefore, the
telescope slews in azimuth and elevation until the object coordinates are reached. In parallel, also the
rotator angle of the instrument and AGW Unit is set. In case a TT star is pre-selected, the sensor moves to
the corresponding position. If not already in, the ARGOS dichroic is moved into position.The Primary
shape and Secondary shape is applied according to the collimation table parameters for the given target
position and ambient temperature. After arrivial at the target position the telescope starts open loop
tracking. Refinement of the collimation is not performed as this is done in closed loop with permanent offload to the mount control and primary control. The defined open loop tracking requirements of [AD 28] are
sufficient to setup the system further, therefore, no guiding is needed before closing the AO loops.
Figure 5: Activity diagram descsibing the tasks during telescope preset.
Time Estimate: The time dominating part will be the setting of the elevation and azimuthal drives. From the
telescope slew rate of 1.5deg/s [AD 28] the preset is expected to take not longer than 380s.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
15 of 65
Action
Set azimuth
Set elevation
Set primary
Set secondary
Set rotator
Set TT-stages
Set dichroic
Start tracking
Procedure Max/Avg.
Maximal time
Error scenarios
Telescope doesn’t reach target position:
 Coordinates out of range
 Telescope HW problem
Resolving
If the target coordinates are out of range, i.e. below horizon, the
observation has to be stopped. To avoid such error the
coordinates should be checked for consistency before sending to
the telescope.
In the case of HW problems, the HW has to be fixed or set in
simulation by interacting directly through the telescope interface
not through the LGS software. After the problem is resolved the
Preset has to be started from the beginning.
As the rotator has more than 360 degree rotation capability it is
either a software or a hardware problem of the rotator but not a
problem of beeing not able to reach the position at all. This
problem has to be resolved directly through the rotator interface.
After the problem is solved the rotator can be set manually and
the sequence can continue
The LGS system can be operated without TT star with paying the
expenses in performance degradation.
The dichroic must be in place for LGS operation. The problem
must be manually solved in engineering mode.
Such error is recognized by making an image with the science
camera. This might reduce efficency, especially in the case of
spectroscopy when slits have to be moved.
Alternatively the FLAO acquisition camera could be used. This
camera is always available, but the FLAO has to be set properly
and a position calibration between WFS and instrument is
required.
After the pointing mismatch is measured an offset with the
correct size is applied to the telescope.
Depending on the reason, the feedback is either through the
command reply or the error is recogniced with an image of the
science camera or the acquisition camera of the WFS (exposure
time ~1s). Start tracking manually after the reason is resolved.
TBD unsufficient.
Resolve mirror problem manually with direct interaction. After
that continue sequence
Resolve mirror problem manually with direct interaction. After
that continue sequence.
TBD unsufficient
Rotator doesn’t reach target angle
TT stages do not reach position
Dichroic does not reach position
Pointing off target position
Tracking doesn’t start
Tracking performance unsufficient
Primary mirror fails
Secondary mirror fails
Collimation unsufficient
Expected average time Counted
120s
x
64s parallel
13s parallel
13s parallel
120s parallel
60s parallel
60s parallel
< 20s
10s
x
380s
130s
< 360s
< 127s parallel
< 25s parallel
< 25s parallel
< 360s parallel
< 120s parallel
< 120s parallel
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
16 of 65
7.3.1.2 Laser Launch
The laser is projected on sky. The launch position is set to a nominal value and stabilized.
Preconditions: Before launch of the laser, the telescope has to be on position and the target has to be
cleared by space command. Aircraft spotters or an aircraft avoidance system can hold the launch at any
time. The lasers are switched on in the beginning of the night to bring them to temparture.
Procedure: With launch, the laser status goes from “Online” to “Working” (description of these states in
chapter 9.1.1) and the internal laser shutter opens. The gating range is pre-defined by the clocking but can
be changed at any time. The pupil control starts and stabelizes the pupil by moving the launch periscope.
The field control starts setting the individual laser spots to each other on the proper sky position using the
launch periscope. Focus position gets adjusted with help of a LUT (temperature dependent). The field
stabilization starts to reduce the LGS common jitter on sky, using the launch pupil mirror. This loop gets
fed with accellerometer measurements and WFS off-loads and defines the relative position of all three LGS
to the telescope pointing.
Figure 6: Activity Diagram showing the launch procedure.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
17 of 65
Time Estimate: So far this tasks can be fully automated the execution time should be quite fast. However,
error cases of certain sub-tasks and manual interactions might extend the execution time. The tasks which
go into the preset time calclulation are opening the shutter and setting the various components to the
nominal positions.
Action
Open shutter
Set nominal positions
Keep positions
(until loops are stable)
Procedure Max/Avg.
Maximal time
Error scenarios
Laser fails
Resolving
The system must be tolerant against individual laser failures. It
must inform all other systems about the individual laser failures
but should not stop the launch at all. It must be possible to resolve
individual laser failures manually and restart the laser loops
separately. It must also be possible that the system runs with an
incomplete number of lasers. This requires simulation modes in
several levels.
Similar to laser failures individual treatment for each shutter must
be possible.
Such failure could be a following error of a shutter failure or
result from rejected clearance or interlocks. The different sources
must be made transparent.
 Shutter failuers can be resolved manually and after that
the launch restarted.
 In case of clearence failure it must be easily possible to
get the information if and when clearence is given for the
object.
 In case of an interlock failure it must be possible to find
the blocking interlock. Depending on the reason the
interlock should be kept, released or overwritten.
This might be related to harware failure or the camera is powered
off. It must be possible to resolve the problem manually and start
the pupil tracking loop individually without restart from
beginning.
This might lead to oscillations at the periscope mirrors. It must be
possible to reset the pupil position.
This might be related to hardware failures or wrong parameters. It
must be possible to change gain of the loop and the pupil
position. It must be possible to restart the pupil tracking loop
individullay without starting the launch from beginning.
This might be related to hardware failure or the camera is
powered off. It must be possible to resolve the problem manually
and start the position tracking loop individually without starting
the launch from beginning.
This might lead to oscillations at the periscope mirrors. It must be
Laser shutter fails
Laser shutter not open
Laser pupil camera read fails
Laser pupil position wrong
Laser pupil loop fails
Laser field camera read fails
Laser field position wrong
< 20s
< 20s
< 20s
60s
© ARGOS Consortium
Expected average time Counted
3s
x
7s
x
7s
x
17s
Software Preliminary Design
Laser field loop fails
Launch focus movement fails
Launch focus movement wrong
position
Launch field stabilization fails
Launch field stabilization unsufficient
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
18 of 65
possible to reset the pupil position.
This might be related to hardware failures or wrong parameters. It
must be possible to change gain of the loop and the field position.
It must be possible to restart the field tracking loop individually
without starting the launch from beginning
This might be related to hardware failure or limitation in range.
The first problem has to solved manually. The latter problem
would involve a reset of the focus position on sky. This has also
to be communicated to the WFS, as the pockle cell delay might
need to change.
This can only be seen on the WFS. A procedure to get the proper
focus position is needed. It must be possible to run this procedure
separately. A new set point must be the result and the focus has to
move to the new position.
This might due to hardware failure or wrong parameters. It must
be possible to check the accelerometer measurements. The
problem has to be solved manually and the loop is started
individually.
TBD unsufficient. Such error can be only understood with help of
the WFS. It must be possible to change gain and set points of the
stabilization loop.
7.3.1.3 LGS Wavefront Sensor
The LGS is acquired and the loop is closed. The LGS high order loop is closed before the TT loop.
Preconditions: Before closing the loop the telescope preset must be finished and the laser must be
launched. The dichroic must be in place. The WFS sensor and the ASM is switched on in the beginning of
the night and running in open loop.
Procedure: The WFS Tip Tilt steering mirrors are set to their nominal positions. The common mispointing
of all laser launch positions are refined with feed forward of the WFS patrol camera field diagnostics and
WFS tilt measurements to the launch pupil mirror. Individual mispointings will be compensated with the
WFS Tip Tilt steering mirrors. The steering loop of the WFS Tip Tilt mirrors are closed with help of the
patrol camera to compensate for remaining sensor flexure and launch flexure, the TT signal of the LGS
WFS is used for the fast launch steering. The WFS pupil tracking loop is closed with use of the ShackHartman pattern. The LGS-WFS parameters like modes, gain, frame rate, etc. are set depending on the
results of open loop measurements. The WFS focus is set. The loop gets closed and continiously optimized.
Any launch interrupt will stop the loops or the loops end with finishing the observation. .
Time Estimate: Starting the LGS WFS will be dominated by the iterations, which are needed of each step
to converge to an optimized situation. Also errors and repeates because of wrong parameters (bad slope
offsets, etc.) might extend the LGS WFS startup tremendously. In the normal case most of the actions have
similar impact on the overall execution time.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
19 of 65
Figure 7: Activity Diagram showing the LGS WFS preset.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
20 of 65
Action
Set steering mirrors
Set pupil
Start steering loop
Start pupil tracking
Set loop parameters
Set LGS WFS focus
Start LGS loop
Procedure Max/Avg.
Maximal time
Error scenarios
WFS patrol camera fails
Resolving
This might be related to harware failure or the camera is powered
off. In case the camera can be fixed a procedure should exist to
do the acquisition without the patrol camera using only the WFS
detector.
The launch steering mirror can be used to get the LGS into the
patrol field. Than the usual procedure can be followed.
The launch power has to be checked and increased or the patrol
camera has to extend the exposure time.
Due to temperature and focus the platescale can vary. TBD
TBD unsufficient. Such error might increase the spot size in the
WFS.
If the hardware cannot be fixed a slope offset can be applied,
which is compensating in case of de-focus.
A separate focus routine must exist to measure the WFS focus
and reset the position.
There must be a possibility to create BCU parameter files and
upload them fom command line.
The BCU must be reconfigured. The current configuration of the
BCU must be transparent and visual to the operator.
It must be possible to create a new reconstruction matrix on the
fly, either from existing measurements or new measurements on
sky or with a calibration source. Tools for visualization and
comparison of reconstruction parameters should be available.
Same as for reconstruction matrix.
The current image quality should be available in Zernike or other
modes. Depending on the amplitudes and modes optical elements
will be reconfigured in position or shape.
It must be possible to set the gain manually overwritning the
automatic optimization.
It must be possible to set the gain manually, overwriting the
automatic optimization.
The laser power must be increased or exposure time extended.
Reajustment of optical elements to compensate.
Laser not in the patrol field
Not enough flux for detection
Platescale mismatch
WFS Steering loop unsufficient
WFS focus motor fails
Wrong WFS focus position
Parameter upload to BCU fails
Switch BCU misconfigured
Bad reconstruction matrix
Bad slope offsets
Bad collimation
Gain to low
Gain to high
Not enough flux for detection
Wrong platescale
< 20s
< 20s parallel
< 20s
< 20s parallel
< 10s
< 20s
< 20s
80s
© ARGOS Consortium
Expected average time Counted
10s
x
10s parallel
10s
x
10s parallel
3s
x
10s
x
10s
x
43s
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
21 of 65
7.3.1.4 Tip Tilt and Truth (T3) Sensor
The TT sensor is acquired and the the TT loop is closed. The TT sensing requires binning of the CCD. For
truth sensing also higher order information is provided, if requested. After substitution of the current FLAO
CCD with a L3CCD [AD 11] one could do permanently higher order truth sensing without readout penalty
and its resulting decrease in sky coverage.
Preconditions: The sensor must be switched on in the beginning of the night. Before closing the T3 loop
the telescope preset must be finished. The LGS WFS loop should be closed, but there should also be the
possibility to close the T3 loop without LGS WFS loop closed. Open loop read of wavefront aberrations
should be possible at any time.
Procedure: It must be possible that if no T3 star is available the LGS system runs without TT corrections.
In case the T3 star is not preselected and given with the preset it must be possible to interactively select a
T3 star from a user interface. Such interface has to visiualize the available stars with their magnitude from
a guide star catalog. It must also be possible to show an acquisition image of the T3 WFS acquisition
camera together with the guide star catalog data, similar to the functionality of the skycat tool [AD 29].
Figure 8: Activity Diagram showing the T3 WFS preset.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
22 of 65
The T3 sensor re-rotator is started, in the interactive mode after the T3 WFS is set to position or in preselected mode immediately with start of the T3 WFS part of the procedure. Than the WFS position can be
refined interactively or automatically with the help of the acquisition camera. In parallel the pyramid
modulation starts and the loop parameter like modes, gain, frame rate, etc set. Now the TT loop closes until
the observation is finished sending a signal to stop the T3 loop. The telescope focus can be refined with the
AO TT data if necessary.
Time Estimate: Starting the LGS WFS will be dominated by the iterations, which are needed of each step
to converge to an optimized situation. Also errors and repeates because of wrong parameters (bad slope
offsets, etc.) might extend the LGS WFS startup tremendously. In the normal case most of the actions have
similar impact on the overall execution time.
Action
[Select from catalog]
[Set T3 WFS]
Start re-rotation
Refine acquistion
Start modulation
Set T3 loop parameters
Start T3 loop
Procedure Max/Avg.
Maximal time
Error scenarios
Re-rotator fails
Resolving
If it is a hardware problem, which can not be fixed the system
might not suffer if the change in parallactic angle is small over
the observation time. In addition one could imagine to follow the
star with the T3 WFS support stages and re-rotate the pupil in
software.
TBD unsufficient.
No interactive acquisition is possible and the refinement has to be
done with the pyramid directly using tilt signals. Manual
interaction using the pyramid pupil images and the T3 support
stages.
An algorithem is needed to catch the star.
Switch to interactive mode and select different T3 guide star. If
no suffient bright star is available run the system without T3 star.
It was demonstrated, that the pyramid system could in princip run
with natural seeing without modulation [RD 8].
TBD unsufficient.
There must be a possibility to create BCU parameter files and
upload them from command line.
The system is run without TT correction.
It must be possible to create a new reconstruction matrix on the
fly, either from existing measurements or new measurements on
sky or with a calibration source. Tools for visualization and
comparison of reconstruction paramters should be available.
Same as for reconstruciton matrix.
It must be possible to set the gain manually overwriting the
automatic optimization.
Rerotation unsufficient
T3 acquisition camera fails
T3 guide star out of field
T3 guide star to faint
Pyramid modulation fails
Pyramid modulation unsufficient
Parameter upload to BCU fails
TT signal does not arrive to LGSW
Bad reconstruction matrix TT
Bad slope offsets TT
Gain to low
Expected average time Counted
[60s]
[x]
[60s]
[x]
10s
x
30s
x
10s parallel
3s parallel
<20s
10s
x
100s [340s]
50s [170s]
[<120s]
[<120s]
<20s
<60s
<20s parallel
<10s parallel
© ARGOS Consortium
Software Preliminary Design
Gain to high
Not enough flux for detection
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
23 of 65
It must be possible to set the gain manually overwriting the
automatic optimization
Reacquire new T3 star with sufficient brightness interactively or
run the system without TT correction.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
24 of 65
7.3.2 Offset
The background in the NIR is varying over time. The technique to reduce later on such background
fluctuations is to move the target on the science detector from one to another exposure. Depending on the
target, smaller or larger offsets are needed. On the other hand depending on the offset size different
schemes are needed to do such movements. We divide the offsets in two classes. Offsets up to 2” are called
dithering and offsets larger than 2” are called nodding. The division at 2” is due to limits of the ASM Tip
Tilt range.
7.3.2.1 Dithering – offset ≤ 2”
Dithering moves the field of observation up to 2” on sky. In such case the telescope mount is not moved at
all but the ASM is used to do such offset.
Dithering with TT star:
Preconditions: The observation is using a TT guide star for correction. The LGSW and the T3WFS loops
are closed and stable.
Figure 9: Action diagram showing the dithering sequence using the T3WFS to drag the ASM.
Procedure: After it is acknowledged that the last science exposure is done and no new one is started, the
gains of the LGSW loop and the T3WFS loop are reduced and fixed, means no optimization during
dithering. This is done for safety reasons to avoid overreaction of the control system. Than the T3WFS
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
25 of 65
sensor is moved with a speed slower than 1”/s to the offset position, which leads to an even slower reaction
of the ASM because of the loop gains. The goal is to move the target with about 0.2”/s. The slow speed
gives the controller enough time to react to the changes without to much disturbance. The movement drags
the ASM with it and introduces an offset in the science image and a tilt on the LGSW system. The flexure
compensation loops of the LGSW system will counteract this tilt and remove it. After the control systems
are stabelized the next science exposure can start.
Time Estimate: This is the fastest offset possible. It will take in worst case a bit more than one minute. All
actions need similar fractions of time on the full amount.
Action
Reduce gain LGSW
Reduce gain T3WFS
Drag T3WFS
Increase gain LGWS
Increase gain T2WFS
Procedure Max/Avg.
Maximal time
Expected average time Counted
10s
x
10s parallel
<30s
15s
x
<20s
10s
x
10s parallel
<70s
35s
<20s
<20s parallel
<20s parallel
Dithering without TT star:
Preconditions: The observation is not using a TT guide star for correction. The LGSW loop is closed.
Figure 10: Action diagram showing the dithering sequence using no TT star and moving the ASM directly.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
26 of 65
Procedure: After it is acknowledged that the last science exposure is done and no new one is started the
gain of the LGSW loop is reduced and fixed, means no optimization during dithering. This is done for
safety reasons to avoid overreaction of the control system. Than the ASM is tilted with 0.2”/s. The tilt can
be introduced through the LGSW sensor. The small steps give the LGSW system and launch system time to
react to the tilts. The LGSW field stabilization loop and the Launch field stabilization loop will correct for
the tilts with the periscope Tip Tilt mirrors. After the control systems are stabelized the next science
exposure can start.
Time Estimate: The time estimate is the same as for the mode with TT star.
Action
Reduce gain LGSW
Drag ASM
Increase gain LGWS
Procedure Max/Avg.
7.3.2.2
Maximal time
<20s
<30s
<20s
<70s
Expected average time Counted
10s
x
15s
x
10s
x
35s
Nodding – offset > 2”
Nodding moves the field of observation when the offset is larger than 2” on sky. In such case the telescope
mount is moved and loops must be opened.
Preconditions: The observation might use a TT guide star for correction. The LGSW loop is closed and
the T3WFS might be used.
Procedure: If the observation is without TT star the part of the T3WFS can be skipped. The LGSW loops
and the T3WFS loop will be stoped for safety. The T3WFS support stage will be moved and the telescope
will move, both of the offset amount. The LGSW acquisition and the T3WFS acquisition will be refined
automatically. In case of the LGSW the field diagnostic camera is used and for the T3WFS the acquisition
camera is used for this task. In case the automatic refinement is not sufficient an manual refinment can be
added. The LGSW loops are started again and after they are running stable the T3WFS loops are started.
The next science exposure can start.
Time Estimate: The estimated execution time for nodding is 1min in average and up to 4min in case of the
interactive mode. In the case of interactive mode the refinement will be sequential, what increases the
execution time tremendously.
Action
Stop T3WFS loop
Stop LGSW loop
Move T3WFS
Move telescope
Refine LGSW acquisition
[Manuel refinement LGWS]
Start LGSW
Refine T3WFS acquisition
[Manuel refinement T3WFS]
Start T3WFS loop
Procedure Max/Avg.
Maximal time
<10s
<10s parallel
<20s parallel
<30s
<40s
[60s]
<20s
<40s parallel
[<60s]
<20s
120s [240s]
© ARGOS Consortium
Expected average time Counted
5s
x
5s parallel
10s parallel
15s
x
20s
x
[30s]
[x]
10s
x
20s parallel
[30s]
[x]
10s
x
60s [120s]
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
27 of 65
Figure 11: Activity diagram showing the nodding procedure.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
28 of 65
7.4 Setup procedures
Setup procedures define the tasks to be done to get the telescope and ARGOS system ready for operation or
optimize its performance.
Figure 12: Use Case Diagram of the ARGOS Setup Procedures.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
29 of 65
7.4.1 Startup
It must be possible to startup all the systems individually and independent.
7.4.1.1 Select instrument
There must be a procedure to select the instrument. Such operation includes the setting of the tertiary,
which selects intrinsically the focus. The focus has to be locked.
7.4.1.2 Start-up T3WFS
The Start-up TT-WFS procedure powers the TT-WFS on and initializes all motors and devices.
More atomic actions, which one should be able to execute individually are:
 Read acquistion camera
 Read open loop data
7.4.1.3 Start-up LGSW
The Start-up LGS-WFS procedure powers on the LGS-WFS and initializes all motors and devices.
More atomic actions, which one should be able to execute individually are:
 Switch on the power
 Move Dichroic in and out
 Set ADM switch BCU to the LGSW
 Read diagnostic cameras
 Read open loop data
7.4.1.4 Start-up LLS
The Start-up LLS procedure powers on the laser and laser launch system and initializes all motors and
devices. More atomic actions, which one should be able to execute individually are:
 Power on Lasers for heat up.
 Read diagnostic cameras of the launch system.
7.4.2 Measure laser position
Such procedure needs the lasers and the diagnostic cameras switched on. The pupil and the field position
are measured for a certain elevation and the set points for the pupil and field position are defined.
7.4.3 Measure focus
There are several foci to adjust in the ARGOS system, the T3WFS focus, the LGSW focus and the focus of
the Laser on sky. All the measurements can be made independently.
7.4.3.1 Measure T3WFS focus
The Focus T3WFS runs a focus routine for the T3WFS. Therefore, the T3WFS has to run and a guide star
must be acquired beforehand or an artificial source is inserted into the light path. Several images at
different focus positions are made and the minimum FWHM is determined in the WFS acquisition unit.
Alternative or in parallel to the observation the focus term can be measured with the WFS at the different
focus positions and the position of the minimal focus term can be calculated. Finally the sensor is set to the
optimum focus position taking slope offsets into account.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
30 of 65
7.4.3.2 Measure LGSW focus
The laser must be launched or an artificial light source inserted into the light path. The LGSW sensor must
be switched on. The focus of the LGS-WFS is determined by moving the focus unit of the sensor. The
focus term from the WFS open loop measurement is calculated. The focus unit is set to the optimum
position taking slope offsets into account.
7.4.3.3 Measure LLS focus
The laser must be launched and the LGSW sensor must be switched on. The LGSW has to be set first. The
spot size on the LGSW is measured and the focus unit of the launch system moved. The smallest FWHM
defines the optimal LLS focus. The focus unit is set to the optimum position.
7.4.4 Measure slope offset
Slope offsets correct for static aberrations within the common and non-common optical paths between
sensor and instrument. The slope offsets are measured to optimize the delivered image quality on the
science detector. Therefore the shape of the DM is changed until the best image PSF is achieved on the
science detector. After that the shape is stored and subtracted in closed loop from the nominal mirror shape.
The strategy to measure non common path abberations between the systems is detailed in [AD 13] but can
be summarized here as follow:
a. Optimize the on-axis position and image quality on the science detector
b. Measure non common path aberrations on the T3WFS and the LGSW
c. Minimize aberrations in T3WFS and LGSW by using non common path optics
d. Set slope offsets of T3WFS and LGSW
7.4.4.1 Measure PSF on science detector
Before measuring the non-common path abberations in the WFS the image on the science detector should
be optimized. This can be done with a bright star on sky or with an artificial light source.
The science case must be turned on and ready to take imags. A sky source must be acquired or the artificial
light source must be inserted and switched on. The spot on the science detector is measured and optimized
using phase diversity or focal plane reconstruction techniques. The shape of the ASM is changed to
optimize the spot on the sience detector.
7.4.4.2 Measure slope offset T3WFS
A bright point source on sky must be acquired or the artifical light source must be inserted and switched on.
The image quality on the science detector must be optimized. The wavefront abberations on the T3WFS is
measured in open loop. Non common path optics of the T3WFS is operated to reduce the measured
abberations. The remaining abberations are stored as slope offsets, defining the new set point of the sensor.
7.4.4.3 Measure slope offset LGS-WFS
The laser must be launched on sky or the artifical light sources for off-axis calibration must be inserted and
switched on. The image quality on the science detector must be optimized. The wavefront abberations on
the LGSW is measured in open loop. Non common path optics of the LGSW is operated to reduce the
measured abberations. The remaining abberations are stored as slope offsets, defining the new set point of
the sensor.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
31 of 65
7.4.5 Measure interaction
To create a reconstruction matrix, which is needed to close the loop, the influence of the mirror on the WFS
have to be measured. The reconstruction is finally done with one matrix and one slope vector, which
consist of the high order LGSW measurement and asynchroiously added TT information from the T3WFS.
However, the measurement on both sensors to get the interaction can be done separately.
7.4.5.1 Measure T3WFS interaction
The Create TT-WFS control matrix procedure measures the influence of the DM on the wavefront sensors.
Therefore, the calibration unit has to be inserted and started. Then the mode to be measured is applied to
the DM and the influence of the WFS is recorded. This is repeated for each mode. After measuring the
modes the matrix is inverted, i.e. with a SVD algorithm, and the control matrix is calculated. Finally the
control matrix is loaded to the wavefront reconstruction computer. In the case of the TT-WFS this will be
only a few modes (less than 10). There can be further schemes to create the control matrix on sky.
7.4.5.2 Measure LGSW interaction
The Create LGS-WFS control matrix procedure measures the influence of the DM on the wavefront
sensors. Therefore, the calibration unit has to be inserted and started. Then a mode to be measured is
applied to the DM and the influence of the WFS is recorded. This is repeated for each mode. After
measuring the modes the matrix is inverted, i.e. with a SVD algorithm and the control matrix is calculated.
Finally the control matrix is loaded to the wavefront reconstruction computer. There can be further schemes
to create the control matrix on sky.
7.4.6 Measure background
The detector background is a sum of bias and dark counts. The background is measured in the beginning
and than from time to time on a low frequency.
7.4.6.1 Measure T3WFS background
The T3WFS detector has to be switched on. The other sensor components are not needed but could be
switched on. It has to be dark or the shutter, if existend, must be closed. Several exposures are taken and an
average background for each pixel is then calculated.
7.4.6.2 Measure LGSW background
The LGSW detector has to be switched on. The other sensor components are not needed but could be
switched on. It has to be dark or the shutter, if existend, must be closed. Several exposures are taken and an
average background for each pixel is then calculated for each pixel.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
32 of 65
8 Operating Environment
The software has to work within the LBT software and computer environment. Further the First Light AO
system (FLAO) is used as TT WFS and Truth sensor (T3WFS). Already existing software and computer
environment should be re-used as much as possible and all existing operation modes should not be
impacted by the ARGOS implementation.
8.1 Current Hardware layout of FLAO
The FLAO system hardware consists of the WFS unit and the DM electronics. The DM electronics is a
self-contained extendable system based on BCU boards. The BCU boards are doing all the calculations
necessary to control the actuators and are able to run in parallel the reconstruction of the AO system. A
specialized BCU board is used to acquire the sensor images and calculate the slopes for the effective data.
This all happens on the ASM network (blue line in Figure 13).
Figure 13 shows the FLAO WFS unit. All the hardware devices are commanded through RS232 serial lines
on the usual telescope network (red). There are filters, position stages, pupil re-rotation and CCD
controller. All this, including the data of the acquisition camera might be used as it is for the TT-star.
Figure 13: Current hardware layout of the FLAO WFS unit. There are several controller for motors, CCD, etc., which
are commanded through RS232 (green) on the usual telescope network (red). But there is in addition a dedicated
communication line to the ASM (blue) for real-time reconstruction.
8.2 Current SW layout of FLAO
The AO supervisor software consists of two main parts: the WFS software and the DM diagnostic software.
All the reconstruction is done within the DM electronics and excluded from this software.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
33 of 65
The WFS software takes care of all the hardware devices of the WFS (motors, CCD controllers, etc.),
monitors temperature in the WFS unit and provides data to the acquisition camera. The WFS arbitrator
receives commands from outside through the AO arbitrator and dispatches them within the WFS software.
The DM diagnostics software does housekeeping, fast diagnostics and sets mirror parameters through an
IDL controller. The housekeeping includes monitoring the status of the DM electronic on-board of each
card. It has access to data like voltages and currents of the power supplies, temperatures, air pressure and
humidity. The fast diagnostic software monitors the status of the shell, provides warnings/alarms and react
in case of necessity automatically. It has access to data like actuator position or forces and provides them
to GUI and high level applications. The IDL controller can calculate the value of parameters, i.e.
reconstruction matrix, of the ASM and load it then to the DSP in the DM electronic. IDL scripts sequence
the setup of the DM.
The WFS software and DM diagnostics software is coordinated on the AO supervisor side by the AO
arbitrator. The AO arbitrator receives requests from the TCS through the AOS subsystem of the TCS. The
AOS subsystem acts as a bridge between TCS and the AO supervisor. It listens to the commands from
other TCS subsystems and sends the appropriate request to the AOA. More detailed information can be
found in [AD 16], [AD 17], [AD 18], [AD 19] and [AD 20].
Figure 14: Current FLAO software overview. The AOSupervisor consist of two main packages: WFS software and
ASM software. Both are coordinated by the AOArbitrator, which is talking to the AOS a TCS subsystem listening to
the other TCS modules for requests to the AO system.
8.3 Current interface to TCS
LBT TCS software and AO supervisor software are using different middleware to communicate between
their processes. Both software have built their own IPC libraries. LBT TCS software is using a XML RPC
version [AD 30] and the AO supervisor is using a message system directly based on sockets. The
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
34 of 65
interaction between the AO supervisor software and the TCS is by means of communication protocol,
which is implemented in the AOS subsystem of the TCS following [AD 31].
As defined in [AD 18] the AOS provides following states:




Standalone, when the AO system is operational but will neither request nor accept interaction with
the TCS.
Engineering, when the system is performing calibration or maintencance function,and requires
services from the TCS (to operate telescope devices or to point asuitable reference star).
Ready, when the system has successfullly completed the automatic bootstrap preocedure waitin for
TCS requests or direct interaction.
Observation, when the AO system is supporting an observation
The AOS functional description [AD 18] defines a set of commands, which the AO system accepts from
the TCS for further action. The list of commands is shown in Table 2.
Command
StartObs
PresetFlat
Preset AO
AcquireRefAO
GetSnap
RefineAO
StartAO
OffsetXY
OffsetZ
CorrectModes
Stop
Pause
Resume
Terminate
User Panic
State
Ready
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Observation
Engineering
Ready
Description
Start an observation
Preset AO System for seeing limited operation.
Preset AO System for adaptive operation.
Acquire the reference star and become ready for closing the AO loop.
Get a snapthot image of the AO field of view.
Modify some AO loop parameter.
Start the AO mode (i.e. close the AI loop.
Offset AO pointing.
Offset AO focus.
Apply mirror shape correction.
Stop current operation.
Temporarily suspend current operation.
Resume suspended operation.
Terminate an observation.
Emergency shutdown request.
Table 2: List of commands AOS accepts from the TCS.
But the AO system must also be able to send commands to the TCS. Such commands are mainly necessary
for engineering and notification. Three subsets of commands are defined, which can be send from the AO
supervisor to the TCS through the AOS. The first subset includes housekeeping commands as listed in
Table 3.
Command
RequestService
EndOfService
LogItem
Stop
State
Description
Engineering Request exclusive service from TCS,
Engineering Notifies to the TCS that the AO ystem has finished with AO
engineering operations, and releases the telescope.
Engineering Requests to log some information into the TCS Logging system.
Observation
Engineering Terminate current operation.
© ARGOS Consortium
Software Preliminary Design
Warning
Error
Panic
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
35 of 65
Engineering Notify warning condition.
Observation
Engineering Notify erro condition.
Observation
Engineering Notify some AO System panic condition.
Observation
Table 3: List of commands issued from the AO supervisor to the TCS. Subset I – Housekeeping commands.
The second set of commands, listed in Table 4, are used when the AO System is performing engineering
operations which do not require pointing and tracking in the sky. In this mode of operation the AO System
may need to directly control devices susch as the hexapod or the rotartor
Command
SetAltAz
SetHexapod
SetRotator
SetTertiary
State
Engineering
Engineering
Engineering
Engineering
Description
Set telecope postion (alt-azimuth, not tarcking).
Set hexapod position.
Set rotator angle.
Set tertiary position.
Table 4: List of commands issued from the AO supervisor to the TCS. Subset II – Low level commands.
The third subset of commands, listed in Table 5, are used when the AO System is performing engineering
operations, which require pointing on sky and tracking. In this case the AO supervisor must be able to
control devices such as the hexapod or the primary because they are under the control of PCS.
Command
ActivatePreset
PointTelescope
OffsetPointing
OffloadModes
State
Engineering
Engineering
Engineering
Engineering
Description
Activate telescope preset.GUI.
Point telescope and start tracking.
Request a pointing offset to the telescope.
Offload accumulated aberrations.
Table 5: List of commands issued from the AO supervisor to the TCS. Subset III – Pointing commands.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
36 of 65
9 Software Structure and Functional Specifications
We now define the software structure concluding on the investigation of the use cases in chapter 7 and
taking the current implementation of the First Light AO (FLAO) into account, as described in chapter 8.
After presenting the software structure we describe the functional specification of each software package.
The software for the right and left arm are identical, just different instances of the same software, as it must
be necessary to run both arms independently. A synchronization of the right and left arm is not planned on
software level. The only synchronization needed is for gating the lasers, which is done electronically
through a master clock. Further software dependencies would create more failure cases and wait situations
and therefore make the system less efficient. Any co-ordination needed, between right and left, can be
handled on the highest level by GUI or scripts and should involve also the science instruments.
Following the general requirements of chapter 5, especially the requirement stand alone, a natural choice of
software packages should follow the optomechanical systems of ARGOS. The optomechanics can be
divided into three major components, which are taken over as component into the software structure:
 LLS: The laser launch system, which consist of the laser system and the launch optics.
 LGSW: The LGS wavefront sensor, which includes the dichroic.
 T3S: The tip tilt and truth sensor, which is based on the existing FLAO system.
The deformable mirror diagnostics and the real-time reconstruction built an additional software component,
as the first is already one separate part in the existing FLAO and the latter is based in dedicated electronics.
Further we define a wavefront data handling system, which takes care of automatic optimization and offloading between different optical elements. Therefore, we have three further components:



DMD: Deformable mirror diagnostics, which monitors the DM data and does the houskeeping
of the DM unit in the FLAO system.
RTR: The real-time reconstructer software, placed on the slope BCU of the LGSW.
WDHS: The wavefront data handling system, which optimizes the AO loop and handles all the
off-loading and slow steering control loops of the system.
All these components have to interface with each other and the Telescope Control Software
(TCS) provided by an communication interface. The communication to the DM is defined by the ASM
interfaces from Microgate. For the other communication we have to define the interfaces depending on how
close such system have to work together. Following considerations are taken into account:




The Launch system has to interact closely via SW with the LGS sensor for the launch stabilization.
The WDHS requires close interaction with all diagnostic systems of each component.
After intermediate steps, the Offset requires several times synchronization between the LGS and
the TT sensor. A close entanglement of both systems is required.
The AOS interface of the FLAO provides all required functionality, which is needed also in case of
the LGS operation.
Due to the close interaction between LLS and LGSW and WDHS it makes sense to implement them
embedded into a common software layer, which is able to handle asynchronious command exchange and
has a scalable distributed data base system. Minimizing the number of interfaces we propose to use only
one interface to the AO arbitrator to handle the communication with the TCS and sequence the T3S and
LGSW. The AOS provides all functionallity needed for the LGSW as well as the T3S and the AO
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
37 of 65
arbitrator already now sequences the FLAO system during operation. The proposed structure is shown in
Figure 15 including all communication paths envisioned.
Two additional packages are defined, which are supporting the astronomer in the preparation of the
observation and later in the reduction of the data.


PSFR: The Point Spread Function Reconstruction software, which should provide the PSF at
any position of the field.
OPS: The Observation Preparation Software, which shold support the astronomer to prepare his
observation.
Figure 15: Package diagram of ARGOS.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
38 of 65
9.1 Common Software
As a common middle ware for the ARGOS software packages we propose to use the MPIA inhouse
development for LINC-NIRVANA, which consist of two parts:


TwiceAsNice, a communication layer and distributed database [Reference]
BASDA, a generic device driver library for hardware [Reference]
This software is based on ICE an object oriented communication software. The advantage of this choice is
that this software provides asynchronous communication, database and easy to implement server and client
architecture in a completely distributed system.
9.1.1 TwiceAsNice
TwiceAsNice provides the communication layer and a database. The database is distributed and has a tree
hierarchy, which can dynamically attach new structures. Tree branches are accessable over network to
other clients and parameteres get automatically updated based on an event system.
Figure 16: Client server architecure of TwiceAsNice.
The principe of the TwiceAsNice server client architecture is illustrated in Figure 16. There are four major
components within this scheme:




Properties are container objects, which are able to keep data of complex data types like vectors,
matrices.
Tree Joints represent nodes of the data tree structure, which defines the hierarchical path to a data
object (Property).
Bridges do connect two or more Properties of the same data type. They manage the data
synchronization between connected Properties.
Actors are objects, which can be attached to a Property. The processing function of the Actor is
called before actually setting the data. Within the processing function user defined actions can take
place.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
39 of 65
Any application, which will be built based on this software will have four major states, which it inherits
from the base classes. Automatically also a property interface is provided, which can be loaded from ASCII
configuration files. The schematic of Figure 17 shows the basic interfaces and state machine any service
based on TwiceAsNice will have.
Figure 17: Schematic of the basic state machine and interfaces of an application based on TwiceAsNice.
An additional feature of this software package is a generic GUI application, which displays any parameter
of the distributed database. Simple engineering interfaces to monitor data or interface with any hardware
can be built by configuring the database. An example screenshot is shown in Figure 18.
9.1.2 Basic Devise Driver Application (BASDA)
BASDA provides an generic library to built hardware services based on TwiceAsNice. It has four layers:




Assemblies: This is the real hardware and its delivered driver libraries.
Devices: The device layer interfaces the hardware to the generic BASDA Service layer.
Services: This layer makes the hardware distributor independend. Four type of Services are
identified. Any software above the Service layer has not to be changed, when i.e. a different motor
controller is used.
Applications: This layer contains the instrument specific software. An application programmer has
no more to think about how to communicate with a certain hardware from a certain vendor. I.e. for
a motor the interface is always the same doesn’t matter what kind of controller is used.
Altogether four device types have been identified and implemented so far. This might extend with time.




Vino, contains all types of cameras and readout electronics.
Mocca, supports all kind of motor controller and devices.
I/O, collects I/O devices like D/A boards etc.
Tempo, implements monitoring devices like temperature sensor controller, etc.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
40 of 65
Figure 18: Example screenshot of the generic database interface of TwiceAsNice, Dr. Greenthumb.
Figure 19: Structure of the BASDA software layer.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
41 of 65
9.1.3 Status and GUI
Each module should include an engineering GUI to control the modules functionality. Each package should
have a GUI to operate the important subsystem tasks. Details on status and GUI will be described deeper in
the next phase of the project. At the current stage it is too early to show prototypes. However to get an
impression of the style and kind of GUI one can expect we refer to [AD 24].
All parameter, which are public or configurable are normally available through the common software to
everyone. The update on the parameters should be asynchronous to avoid heavy network load through
polling. Status displays should provide the essential information.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
42 of 65
9.2 Laser and Launch System Software (LLS)
The LLS software will have two sub-packages: the laser system and the launch system; each of them
consisting of several modules.
9.2.1 Laser system modules (LAS)
The LAS controls the components of the laser system. The class diagram in Figure 20 shows the outline of
the structure. The functionalities of the modules are described in the following paragraphs
Figure 20: Class diagram of the Laser System.
Laser ctrl (LASCTRL): The laser control module takes care of switching the laser on and off, adjusts the
power remotely and moves the shutter in and out. There will be one instance of this module for each eye.
Master clock (LASCLK): The master clock synchronizes the laser gating. This is done electronically. The
delay time and frequency of the pulse signal can be defined. The master clock can be switched off but in
this case it still must be possible to take images with the WFS CCD for engineering purposes. Therefore the
Pockels cells must be set in a way that the light can pass and is not blocked. There will be only one instance
of this module for both eyes.
9.2.2 Launch system modules (LAN)
The LAM controls the components of the launch telescope. The class diagram in Figure 21 shows the
outline of the structure. The functionalities of the modules are described in the following paragraphs
Launch ctrl (LANCTRL): The launch control will coordinate the hardware of the launch system on a
higher level. It will receive the commands and dispatch them to the corresponding modules.
Polarization (LANPOL): Each laser has one L/2 plate and one L/4 plate in front. After commissioning the
polarizer should only be moved rarely for re-adjustment. It might be necessary to use them to compensate
flexure introduced polarization changes. The stages have to be moved relatively to previous positions.
Direction and amount of movement is related to the return flux measured on WFS detector. There is no
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
43 of 65
automation planned. The stages are moved via GUI, while measuring the return flux with the WFS.
Therefore the WFS display should show the average flux of an image. There will be one instance for each
polarizer rotation stage, altogether 6 per eye.
Periscope (LANPTT): The separation of the lasers and their individual position to each other can be
steered via two tip tilt mirrors. Input from the field and pupil imager is used to tilt the mirrors correctly.
The stages have to be moved relatively to their current position. The adjustment should be automatic and in
closed loop but with low frequency to compensate flexure or initial setup. LANPTT does only receive
move commands and will have no calculation algorithms included. The measurement and calculation for
this closed loop will be handled in the field diagnostic module (LANFLD). The separation of the lasers is
set with the preset command or defined interactively by the TO, if it differs from some default value.
There are 6 instances of the module per eye.
Launch pupil mirror (LANPUM): The launch pupil mirror can change the position on sky of all lasers of
one side together. It will get the information off-loaded from the WFS. The stage will only move relative to
the current position. There is one instance of the module per eye.
Focus (LANFOC): The focus unit adjusts the altitude on sky. The laser focus has to be conjugated to the
image plane of the WFS. Therefore input from the WFS is needed. The same focus distance has a different
altitude when changing elevation. The altitude should be adjusted for each new pointing and during very
long observations on the same target. Input on the elevation is needed as well as coordination with the
WFS. All this should not happen during an exposure but in-between. This thus requires knowing if the
instrument is currently taking an exposure. All this coordination and intelligence could be in the
LANCTRL module. The focus module would just receive relative movement commands. There is one
instance of the module per eye.
Figure 21: Class diagram of the launch system.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
44 of 65
Pupil diagnostic (LANPUP): The pupil diagnostics consist of a CCD on which the pupils of the laser
guide stars are re-imaged. The pupil diagnostic is needed during assembly and just for monitoring during
operations. There is no feedback and interaction with other modules or packages needed. A display to look
at the images with some buttons to change exposure time and start/stop exposure should be enough. There
is one instance per telescope eye.
Field diagnostic (LANFLD): The field diagnostic consists of a CCD where all the laser guide stars of one
eye are re-imaged. It will be used to adjust the individual separation of the laser guide stars as already
described with the periscope module. The LANFLD will just take the images and send them to the
LANCTRL, which then evaluates them and defines the new actions. Simple interfaces to browse images
and set camera parameters are needed. There will be one instance of the module per eye.
Alignment source (LANCAL): The alignment source is used during assembly of the launch system and
later to check the alignment. It consists of one stage which might later also be used to feed the system with
an on-axis sodium laser. The stage has to move to a named position and the source has to be switched on
and off. There will be one instance of this module per eye.
9.3 LGS Wavefront Sensor System Software (LGSW)
The LGSW runs the components of the LGS wavefront sensor. The class diagram in Figure 22 shows the
outline of the structure. The functionalities of the modules are described in the following paragraphs.
Figure 22: Class diagram of the LGSW.
Wavefront sensor ctrl (LGSWCTRL): The WFS control will coordinate all modules and hardware
devices of the LGS WFS sensor. It will receive commands from a higher level and dispatch them to the
corresponding modules of the WFS. There is one instance of this module per eye.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
45 of 65
Detector ctrl (LGSWDET): The detector control module controls the WFS detector. Images can be
displayed; binning and exposure time can be defined. In closed loop the readout is externally triggered by
the master clock. There is one instance of this module per eye.
Pockels cell (LGSWPOC): The Pockels cells are driven by the master clock, which defines when light
might pass or is blocked. Within the module the voltage range can be set and the cells can be switched on
and off. In engineering mode it must be possible to overwrite the master clock and create a non-blocking
condition in which the detector gets light independent of the master clock. There are three instances of this
module per eye.
Field lens (LGSWFLE): The field lens adjusts the pupil position of each laser return on the lenslet array.
The lens has to be moved within the focal plane - XY movement. The movement is relative to the current
position, but it must also be possible to set the lens to an absolute position. The LGSWFLE does only
receive move commands and will have no calculation algorithms included. A closed loop is established
with the LANCTRL, which calculates the relative offset from monitoring the intensity of the outer subapertures of the LGSWDET image. There will be three instances of the module per eye
Focus (LGSWFOC): The focus stage adjusts the image on the WFS detector. It is necessary to be able to
move relative to the current position, but also to move to an absolute position. The module gets
commanded either by a higher-level module or through a GUI by the operator. There is one instance of this
module per eye.
Periscope (LGSWTT): A periscope system of two folding mirrors is used for field selection. The tilt
measured on the LGS-WFS detector is feed back through a serial line into this module and then applied to
the folding mirrors to compensate for fast image motion. The slow image motion due to flexure is feed
back from the patraol camera. There is one instance of the module per laser, altogether three per eye.
Patrol Camera (LGSWPCAM): The patrol camera consists of a CCD where the laser guide star return of
is re-imaged. There will be for each LGS one patrol camera. The cameras will be used to adjust the postiton
of the laser guide stars as already described with the periscope module. The LGSWPCAM will just take the
images and send them to the LGSWCTRL, which then evaluates them and defines the new actions. Simple
interfaces to browse images and set camera parameters are needed. There will be three instances of the
module per eye.
BCU ctrl (LGSWBCU): The BCU computes the slopes and sends them to the ASM. This local control
unit has an electrical interface to the LGSW detector from where it gets the images to extract the slopes.
The LGSWBCU is a module to control the configuration of the BCU. It loads the configuration, which
consists of the control matrix, the slope offsets, gain parameters, subaperture mapping and detector
parameters like size, pixel mapping, etc. There will be one instance of the module per eye.
Dichroic (LGSWDIC): The dichroic feeds the LGSW with light when inserted. It must be possible to
move the dichroic to an absolute position, in and out. The module gets commanded either by a higher-level
module or through a GUI by the operator. The dichroic is in the common path with the science instrument.
This requires, that it must be possible to command this component even all other software is not running
and the sensor is off.
Internal WFS calibration unit
There will be a calibration unit providing a DM and a calibration source to test the LGSW standalone. This
unit will not be permanently mounted, but used in the laboratory for testing or at the telescope for
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
46 of 65
maintenance and troubleshooting. Therefore, the software is not integrated closely into the LGSW package
and does not appear in the class diagram in Figure 22.
DM ctrl (LGSWCDM): This deformable mirror is a MEMS based one.It will need an electronical
interface to the BCU for running in closed loop. Additional software in this case will contain some
diagnostics and power switch functionalities.
Calibration source (LGSWCSRC): The calibration source will simply be a laser fiber fed to the focal
plane. The software for this device will only need power switch functionality. It might have some remote
dimming capability.
9.4 Wavefront Data Handling System Software (WDHS)
The Wavefront Data Handling System software takes care of the automatic system optimization and
wavefront data handling. The class diagram in Figure 23 shows the outline of the structure. The
functionalities of the modules are described in the following paragraphs. The major tasks are:








Data dump to disk for post evaluation
Display of residual errors
Display of corrected modes
Display of slope vectors
PSF evaluation
Gain optimization
Control Matrix calculation
Offloading
The task list shows how versatile this software has to be. In the final operation scheme most of the
functions have to be automated but it must also be possible to overwrite or execute tasks manually.
Data dump (WDHSDATA): The WDHSDATA gathers the wavefront data for post processing and non
real-time but online reduction. The frames of the wavefront detector, the slopes and the applied voltages of
each measurement are stored. In addition the current slope offset, control matrix, gains, background and
flatfield is added. Time stamps built the relation between the data types and avoid duplication. With this the
loop behaviour and calculations can be reproduced at any time and post-evaluated. The transfer of
diagnostic data from the ASM can happen in lager packages as no hard real-time is needed. However, the
transfer has to be secured and no package should be lost or block the other tasks. The diagnostic datarates
are calculated in chapter 11 and the storage space needed is calculated in chapter 10.
Display (WDHSDISP): The WDHS display should display all the information needed to evaluate the
behaviour of the reconstruction process. Arrows with according length and direction for each sub-aperture
visualize the measured slopes. A histogram shows the measured and corrected modes. A switch between
Zonal, Zernike, KL or other modes should be possible independent of the mode set used in the
reconstruction. A plot with the remaining residual as difference between measured slopes and corrected
slopes over time gives an impression of the performance. The display of the average residual over the
science exposure time or the average performance since start of the science exposure, respectively, could
be shown in addition as number. This would require a feedback from the instrument with time
synchronization. Alternatively one could show the average performance since start of the loop or over a
fixed time period. Remaining average tip and tilt for a fixed period of time (~60s) should be displayed in an
RA and DEC plot. Such plot is very useful to evaluate flexure effects. The sensor images with the SH plots
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
47 of 65
should be displayed to have an online feedback on the sensor behaviour. Displaying the data does not
require the full datarate. The upper limit is defined by the typical TV update rate of 25Hz but might be
much less. Experience from other systems show that 5-10Hz might be sufficient. However, the display rate
should be easily adjustable by the user to adapt to his purpose.
Figure 23: Class diagram of the WDHS system.
Offload (WDHSOFF): The WDHSOFF evaluates data collected from the individual systems and decides
to offload to other components.
 Up summing large strokes of atmospheric tilt applied to the ASM should be offloaded to the
hexapod. Such tip tilt is only seen by the natural TT wavefront sensor and saturates the ASM.
 Tracking tip tilt should be offloaded to the mount. The tip tilt is seen in the launch as well as in the
LGS and the TT path.
 Flexure of the incoming path should be compensated by the hexapod. Such effect produces a tilt
signal in the LGSW and TTW but not in the launch path.
 Flexure in the launch path should be offloaded to the exit pupil mirror of the launch system. The
TT is measured by the LGSW as common tilt.
 Differential tip tilt between the incoming laser beams leading to saturation of the TT steering
mirrors in front of the LGSW should be offloaded to the field steering mirrors in the launch path.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
48 of 65
Gain optimization (WDHSOPT): The robustness and performance of the loop is strongly depending on
the actual atmospheric condition, guide star magnitude and the noise behaviour of the system. The gain of
the control loop is the parameter to adjust the system to these conditions. The gain should be selected in a
way to keep the loop stable but to give an optimum performance. It should be possible to set the gain
interactively, from a lookup table or to calculate it from WFS data as e.g. described in [RD 4]. The
WDHSGAIN module provides automatic gain control. Therefore it needs the WFS data and command
access to the control loop. The gain has to be adjusted in a time base of minutes.
PSF evaluation (WDHSPSF): The PSF online evaluation from WFS data is still a subject of research but
was identified as very valuable. Several publications, [RD 6], [RD 7], [RD 5] and [RD 2], discuss recent
development in this field and possible schemes to implement. In chapter 9.8 we present a study of on the
available methods and developed scheme how to extract the PSF from wavefront sensor data with support
of additional information from other facilities like the DIMM. While that software will be provided for post
processing at home a similer approach can be implemented for quick look This way, the astronomer has an
immediate feedback of what can be expect from the data just taken.
Control Matrix calculation (WDHSCM): The control matrix is the essential part of the control loop in
an AO system. The control matrix reflexes how the DM has to respond to the measurement in the sensor.
The possibility how to create an influence matrix, which is the base for a control matrix, is discussed in
document [AD 13 Calibration Unit Design”. For some of the schemes the WFS data during closed loop
is used, for others not. However, the sequence is the same:
a.
b.
c.
d.
Peak and poke the deformable mirror actuators in a modal or zonal way
Measure sensor response and save the measurement
Create Interaction matrix
Invert the matrix -> create control matrix
In the case a calibration unit is used and the measurement is not done on sky some coordination with the
calibration unit has to be implemented on a higher level. The matrix inversion could be done, e.g. offline
with the script language IDL, which already has a SVD algorithm implemented. An interface to the DM to
apply the peak and pokes is needed.
9.5 Tip Tilt and Truth (T3) Sensor Software
The current AO system consists of two packages as described in section 8.2. The TTW corresponds to the
package Wavefront Sensor of the FLAO software and will be used as it is. All functionalities provided and
described in [AD 19] and [AD 25] are sufficient. Coordination with the LGSW will be handles through the
AO Arbitrator. An interface to the AO arbitrator has to be built and the AO Arbitrator has to be
extended in such way that the LGSW is included for LGS operation. A detailed design of the
implementation will be provided with FDR. As for ARGOS FDR the FLAO system should be under
commissioning, we also hope, that at that time the AO arbitrator is more stable and documented as now.
9.6 DM Diagnostic Software (DMD)
The current AO system consists of two packages as described in section 8.2. The DMD corresponds to the
package Adaptive Secondary Mirror of the FLAO software and will be left untouched. As described in
document [AD 16] the software has three modules: housekeeping, IDLController and FastDiagnostic. In
the case of the LGS operations functionality of the IDLController and FastDiagnostics might be dublicated
in the WDHS system.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
49 of 65
9.7 Real-time reconstructor software (RTR)
The real-time reconstruction software is located in the Basic Computational Units (BCU) of the ASM [AD
26]. The BCU use Digital Signal Processors (DSP) as processor unit. Dedicated firmware is installed on the
BCU, which can be re-configured by uploading configuration parameters. The firmware has already control
algorithms implemented which support modal control and filtering for different type of sensors. The
implementation for a pyramid sesnor is described in [AD 26] and [AD 27] depicts the control algorithm for
a SH sensor with LGS, tested at the LBT.
For the initial implementation we target on a modal integrator reconstructing the modes of each sensor
separately and averaging the signals in modal space. Such approach has less cross error propagation within
the reconstruction process as averaging the signals already in the slope space. It also allows for spatial
filtering, individal modal gains and mode projection calculated into the command matrix in advance and
updated time by time to optimize the loop performance.
The individual tasks of the closed loop are performed in a pipline. The computational needs and datarates
between the tasks will be calculated and shown in a table at the end of the chapter. The pipline constists of
following tasks:
 Readout
 Background
 Flatfield
 Slope calculation
 Reconstruction
 Set DM
Readout: After readout the raw frame is provided. With Frametransfere CCDs the readout is done parallel
during the exposure of the next frame and is therefore limited in length by the exposure time, or framerate
repectively, but can be often much short. The readout has no calculations but starts the pipline process. The
timing of the readout is the clock of the laser. Latencies between laser and CCD clocks have to be
synchronized by the delay cards.
Background: For each pixel a background is subtracted. The background is either defined by a fixed
background matrix created with dark images in advance or dynamically defined through an average of the
overscan region. Summarized in an equation with I the intensity and B the background of the pixel:
 pixel i: I i ,bacl  I i ,raw  Bi
The algorithm has one operation for all pixels in a subapertur leading to 43.2KFLOP for three sensors with
15x15 subapetures and 8x8 pixel per subaperture.
Flatfield: Each pixel gets divide by proportional factor equal to its linearity to normalize the pixel to pixel
variations. The flatfield is defined in advance from images with different illumination of the CCD. This is
done once in the laboratory and can only be repeted by dismounting the CCD from the sensor. The sensor
has no flatfield calibratoin capabilities implemented. Summarized in an equation with I the instensity and F
te background of the pixel:
 pixel i: I i , flat  I i ,back / Fi
The algorithm has one operation for all pixels in a subapertur leading to 43.2KFLOP for three sensors with
15x15 subapetures and 8x8 pixel per subaperture.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
50 of 65
Centroid: For each sub-aperture the individual slope in x and y direction has to be calculated. The slopes
will be the input to the reconstruction of the deformable mirror shape to be applied. Each sub-aperture will
have an 8x8 pixel. As initial implementation we will use a Threshold Weighted Pixel Average (TWPA)
algorithm, which was shown to be stable and sufficient [Error! Reference source not found.]. An
alternative could be the weighted weighted pixel average (WWPA) algorithm, which weights the each pixel
with ist poisson noise. The TWPA algorithm neglects all pixels at position r with intensity I lower than a
threshold for the calculation, as summariezed in following equation:
 sub-apertures a: I  I thres  I  0
 rI

I
N
than
ra
i
N
n n
Correction TBD: For all pixel Ii and ri,Ii
n
i
The thresholding is approximated with one Operation for a pixel of a subaperture leading to 43.2.KFLOP.
With three sensors, each 15x15 subapertures and 8x8 pixel per subapterture, the centroiding will need
about 86.4.8KFLOP.
Slope calculation: The slopes of each sub-aperture has to be calculated for each LGS separately in the
following way, with s the slope, r the position and x the zero position:
 sub-apertures a: sx ,a  rx ,a  x0,a , s y ,a  ry ,a  y0,a
The slope calculation will need two operation per subapertur leading to 1.35kFLOP for three sensors with
15x15 subapertures.
Reconstruction: The controller is a simple Modal Integrator reconstructing each sensor seperately and
then summing the modes. Time filters and space filters can be added and are already implemented in the
firmware. The reconstruction can be done with one matrix multiplication, where R is the reconstruction
matrix and s is the slope vector containing the x and y slopes of all three sensors in a row. The slope offset
F is removed in modal space as seen in the following equations, where the calculation from modes m to the
final correction Δp to be applied is separated:
mt  RM st  FM ,time mt 1  FM , space
pt  Rz mt
TBD: remove temporal filter!
The implementation is one matrix multiplication with a slope vector of three sensors, each two times 225
slopes resulting into the command vector of 672 actuators. This leads to 1.81MFLOP.
Set DM: After applying the new DM commands it will still take some time until the actuators are settled at
the requested position. This has to be taken into account into the control approach.
The real-time reconstruction constraints can be summarized as shown in . The loop frequency is 1kHz. The
allocated time allows for a one cycle calculation time lag and an additional for the actuator settling.
Task
Input Data
FLOP
Output
© ARGOS Consortium
Datarate
Time
Software Preliminary Design
Readout
264x264/16bit
Background
Flatfield
Centroid
Slope calculation
Reconstruction
Datatransfere
3x15x15x8x8pix /16bit
3x15x15x8x8pix/16bit
3x15x15x8x8/16bit
3x15x15/16bit
1350B/16bit
672 actuator
Doc:
Issue
Date
Page
data
1.12Mbits
140kB
43.2k/1OP
43.2kB
43.2k/1OP
43.2kB
129.6k/3OP
1350B
1.35k
1350B
1.81M
1344B
-
-
ARGOS PDR 012
1.0
2009/02/01
51 of 65
1.12Gbit/s
140MB/s
380MFLOP/s
with one BCU
(217.35kFLOP)
With 12 BCU
1Gbit/s
1000μs
572μs
~400μs
11μs
Table 6: Summary of the RTR requirements.
9.8 PSF reconstruction software
The reconstruction of the PSF at any location of the field was considered as very important for the ARGOS
science cases. As such task is still a research field in progress we can not provide a detailed design at this
stage but present a study we made evaluating available literature to this top. The result and a first layout
what we envision is presented now.
Author: D. Peter
9.8.1 Introduction
Post processing of astronomical data is an important task to optimize the image quality. In this context
PSF-reconstruction is the tool to improve the resolution of the image produced by an AO-system. This
means the knowledge of the spatial variation of the PSF over the entire field of view is desired. With this
knowledge one can then deconvolve the image with the spatially variable PSF and remove, at least
partially, the speckles which are present in any image produced with an AO system. Thus the structure of
the targets on the image is revealed more clearly.
One classical example where this method is used are double stars or multiple systems where the
companion(s) sit on the PSF of the primary maybe even closer than the diffraction limit of the telescope. So
they cannot be seen directly on the image but after a PSF deconvolution the multiple nature of the target is
revealed.
Two basic ingredients are needed for the reconstruction:


A reference PSF at one position of the image. This reference can be e.g. a bright star close to the
target
A method to transfere the PSF from the reference to the posistions of the other targets on the
image. Classically this is done by the so called isoplanatic transfere function (see e.g. Britton
2006).
There are three basic approaches to find the reference PSF for the reconstruction. One, as mentioned above,
uses a reference star close to the target (see e.g RD 2). The second one uses a speckle holography method.
For this approach one needs the short exposure images which add up to the final image. Due to the usual
faintness of the targets and the fact that IR-detectors have a large read noise this method is much less
performand. The third and last approach uses wavefront sensor data to reconstruct the reference PSF ([RD
9], [RD 5]). Due to the fact that we have three wavefront sensors and potentially not three bright reference
stars in the field the second method will probably turn out to be the default process.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
52 of 65
We also cannot just copy the approaches cited above as our system has several features which are not
covered within the studies found in the literature. These are:




We use three guide stars.
The position of the TT-star and the laser guide stars for the high order correction differ.
We use lasers, which show cone effect.
We only correct the lower layers of the atmosphere.
These points need some additional measurement and calculation. In the following we will first shortly
sketch the classical methods of PSF-reconstruction and then adress each of the additional points just
mentioned. The final goal is to provide the observer with three files per image: The original image, a PSF
map and a deconvolved image. Thus the observer can start with the reconstructed image provided by the
observatory or do his own deconvolution. In addition it would be desireable to provide a data basis with the
sets of wave front sensor data of each night. The data should be marked such that one can easily assign
WFS data and image. these WFS data should also be available on request. So the observer can construct his
own PSF map if wanted.
9.8.2 Classical PSF Reconstruction
In this chapter the two parts of the classical approaches of PSF-reconstruction will be explained. These are:


the reconstruction of the on-axis PSF from WFS data and
the reconstruction of the off-axis PSF from the on-axis PSF
9.8.2.1 On-axis PSF-reconstruction from WFS data
The reconstruction of the on-axis PSF has been described by [RD 9] and the algorithm has been improved
later by [RD 5]. This improvement has, however, not changed the basic principle. So in the following we
will just sketch the Veran paper.
The basic approach is to write the OTF of the system as a product of the measured OTF, B║, the OTF of the
wave front orthogonal to the measured one, B┴, and the OTF of the static non-common-path aberrations, Bs.
Bs can be measured with a calibration source so in the following we will only adress the measurement of
B║ and B┴.
In a first step one derives the noise transfer function Hn(g,f) from the modal gains g [RD 4]. Together with
the noise on the gradients one can deduce the noise on the wave front. Then, one uses the measurements of
the atmospheric turbulence (Cn2) to model the atmosphere either analytically or numerically. This model
then provides the statistics of the high order modes not measured by the WFS. Together with the
reconstruction matrix this yields the aliasing measured on the WFS. The only missing parameter is the
scale factor (D/r0)5/3. This factor can be derived iteratively using the noise on the wave front, the aliasing
and the mirror shape. Thee algorithm is as follows:




Start with D/r0=0.
Compute σ2rr from Crr=Crr(D/r0=1),with σ2rr the mean square due to aliasing, Crr(D/r0=1) the
covariance matrix of the aliasing at the position of D/r0 =1.
Compute σ2a=σ2m-σ2r-σ2n∫df |Hn(g,f)|2, with σ2a the mean square of the true wave front ,σ2m the
mean square of the mirror shape, σ2n the mean square of the wave front noise.
Compute D/r0 by (D/r0)5/3 = σ2a/Kii for every mode i, with Kii the contribution of the mode to the
wave front from Kolmogorov statistics (or statistics derived on the site).
© ARGOS Consortium
Software Preliminary Design

Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
53 of 65
Take the value of D/r0 and start again until convergency.
Now we have the contribution of noise, the contribution of aliasing and the high order contribution not
mesured by the WFS i.e. B┴. The last contribution comes fom the measured wave front error σ2w. Then
using the covariances Cww, Cnn and Crr, one can compute the estimate of the true wave front covariance Ctt
as Ctt=Cww-Cnn+Crr. From this one can compute B║. Putting B║, B┴, and Bs together one gets the science
OTF and via FFT the PSF. The algorithm is illustrated schmatically in Figure 24.
Figure 24: Classical scheme of PSF reconstruction from WFS data.
9.8.2.2 Off-axis PSF from on-axis PSF - the isoplanatic transfer function
This chapter follows the paper by Britton 2006 paragraph 2. A classical AO-system measures (and corrects)
a major part of the (off-axis) guide star wavefront which will be denoted by φ(r)=φa(r) +δφ(r) . Here φa(r)
denotes the corrected wave front and δφ(r) denotes the residual error, r is the coordinate in the pupil plane.
Thus the wave front φb of the target star is changed to the residual Δφ(r)=φb(r)-φa(r)+δφ(r). Now we
calculate the structure function of the residual phase:
Dδφ(r1,r2)=Dapl(r1,r2)+Dδφ(r1,r2)+2<[φ(r1)δφ(r1)+φ(r2)δφ(r2)-φ(r2)δφ(r1)-φ(r1)δφ(r2)]>
The cross terms at the end are negligible. From the above expression we can calculate the OTF:
OTF(r)=exp[-½Dapl(r)] x ∫ds exp(-½Dδφ(s,r+s))W(s)W(r+s)
with W(r) the pupil function i.e. a step function with value 1 inside and 0 outside the pupil. The integral
term is the OTF of the guide star. So any OTF can be calculated by multiplying the guide star OTF with the
isoplanatic transfer function. This transfer function can be calculated using:
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
54 of 65
Dapl(r1,r2)=2 Ξk2D5/3 x ∫ 0∞dz Cn2(z){|Ωab|5/3+2 x |2/D(r1-r2)|5/3-|2/D(r1-r2)+Ωab|5/3-|2/D(r1-r2)+Ωab|5/3}
with Cn2(z) the turbulence profile of the atmosphere, Ωab = (2z/D)θab the angle between the guide star and
the target scaled by (2z/D), Ξ=0.458986, D the telescope diameter and k the wave number. Thus it is
possible to calculate the OTF and thus the PSF of the off axis target by knowing the on-axis OTF, the
turbulence profile and the angle between the target and the guide star.
9.8.3 PSF reconstruction for ARGOS
As already mentioned in the introduction, in our case there are some additional challenges to solve. In the
following we will do this one by one and in the end show the resulting scheme of the PSF reconstruction.
As reminder we list again the four issues, which differ to the classical schemes:




Finite height of laser: The system measures only the abberation in the lower atmosphere.
Different angle of view for TT and HO: LGS and TTS are not measured in the same direction.
Number of guide stars: Three guide stars are used for the reconstruction instead of one.
Cone effect: The LGS suffer cone effects, which must be taken into account for the reconstruction.
9.8.3.1 Finite height of Laser
The problem to solve is to get information on the unmeasured higher layer of the atmoshpere. If one wants
to evaluate the wavefront from WFS data as stated in section 9.8.2.1 one has to split the wavefront in the
part which is measured by the WFS, i.e. the modes which have been calibrated, and the part orthogonal to
it. However, in the case of the laser we do not fully measure the disturbance of the atmosphere for any
mode. The way to account for the turbulence not measured in the WFS is similar as in the case of a natural
guide star. The only difference is how to get the missing information on the Cn2 profile.
The question which must be placed at this point is: Up to which height and with how many layers do we
measure the atmosphere. The answer strongly depends on the controller we use. If the approach is to use a
mere averaging of the three wavefront measurements, then we can only estimate the mean height of the
ground layer we correct. The part of the atmosphere, which is not corrected, starts at about the height where
the laser footprints do no longer cover the entire target beam. The volume of the corrected atmosphere can
be extended in height with a controller using pupil extension [RD 3].
The remaining missing contribution of the higher atmospheric layers, which are not measured, must be
extracted somewhere else. DIMM data or the FLAO as truth sensor can give the information over the full
atmoshpere. The lower atmosphere is extracted from the three LGS measurements using the SLODAR [RD
10] technique. A comparison between the two measurements then yields the r0 of the higher layers and that
of the lower ones. With an atmospheric model we then can derive the contribution of the high atmosphere
in the same way as it is done for the high order modes in the classical approach.
9.8.3.2 Different angle of view for TT and HO
The problem here is that the TT mode and the high order modes are not measured in the same direction.
The different angle of view makes the scheme more complex than the standard one. However, due to a
correlation between Zernike modes for different directions on sky, one can project the wavefront from any
direction into the science direction [see e.g. [RD 13]. There are several schemes for such calculation. The
approach yielding the least error seems to be the on which projects first all three laser measurements and
the TT measurements into the science direction. Then we combine the TT measurement and high order
measurement following the similiar approach as above in section 9.8.3.1. Thus we have knowledge of the
full atmosphere above the target.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
55 of 65
9.8.3.3 Three wave front references
In the case of ARGOS we have three LGS not only one. This increases the number of calculations. The
projection of all three lasers can be done simultaneously. Suppose we correct in the single guide star case N
Zernike modes, then the measured wavefront x is a vector with length N, as is the applied wavefront y. So
the projector is a N x N matrix with y=Px. In the case of three guide stars the measured wavefront is a
vector of length 3N and thus the projector is a N x 3N matrix. Still the equation to derive the best estimate
of the wavefront reads y=Px.
9.8.3.4 Cone effect
Finally, in the case of LGS one has to include the cone effect, which does not appear in the NGS case of the
standard scheme. The cone effect is accounted for in the calculation of the layer height from the C n2 profile.
This is done in two steps:


During the calculation of the correlations using the SLODAR technique, the (measured) wavefront
is stretched with height, in order to account for the projection by a spherical wave and also for the
change in footprint.
Then, the wavefront derived will be weighted to account for the corrected height of the
atmospheric layer.
The weighting is strongly related to the correction hight, which depends on design of the system and the
controller chosen. Figure 25 shows the PSF-reconstruction scheme as planned for ARGOS.
Figure 25: PSF-reconstruction scheme as proposed for ARGOS.
9.9 Observation Preparation Software
For the observation preparation software following tasks have been identified:
© ARGOS Consortium
Software Preliminary Design


Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
56 of 65
TT star selection
Performance estimation
The TT star selection will need some interaction to guide star cataloges. Such capabilities are provided in
available tools like skycat [AD 29].
For the performance estimator we goal on an analytical approch similar to the one proposed for LINCNIRVANA [AD 24].
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
57 of 65
10 Computer Architecture
The software is built in such way, that it runs on one machine or distributed on many. The computer
architecture follows the requirement of independent and standalone systems. Therefore each of the systems,
Laser Launch System and LGS Wavefront Sensor, has its own workstation to host the related software.
This is duplicated, one set for each side of the LBT. With such layout each individual system can be
assembled or taken to or from the telescope without interfering with the others. The T3 Sensor will use the
existing AO supervising computer of the FLAO. All the workstations are located in the computer room.
The real-time reconstruction runs on the dedicated Basic Computational Units (BCU) of the ASM located
at the DM. The slope calculation is done in a a special LGS BCU close to the WFS.
Figure 26: Layout of the computer deployment for the LBT LGS GLAO system of one eye.
All workstations run a standard LINUX distibution as Operating system. The middleware and the dedicated
software packages do not imply special requirements. In case of workstations LBTO suggests to use Altus
server from Penguin Computing. An outline of the workstation deployment and a summary of the
requirements can be found in Figure 26 and in Table 7, respectively.
Table 7: Summary of computers and their minmal needs.
Workstation CPU Clock
LLS-WS
≥1
≥1GHz
LGSW-WS
2
RAM Cache Storage
≥16GB ≥4MB ≥200GB
≥1.9GHz ≥32GB ≥8MB ≥4.1TB
Datarates
<100MB/s
<190MB/s
© ARGOS Consortium
Interfaces
2x PCI (diagnostics)
1x PCI (Master Clock)
1x Ethernet
2x Ethernet
1x PCI (diagnostics)
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
58 of 65
Table 8: Overview of computer equipment, rackspace and power consumptions of the LGS system for one side.
Unit
LLS-WS
LGSW-WS
Raid system
KVM switch
Network switch
Sum one side/two sides
Type
Relion 1650/2650
Relion 1650/2650
Xyratex F5412E
Raritan MCIP 8
Cisco 2960/8
Power
600W
600W
300W
20W
20W
1540W/3080W
Dimension
2U
2U
2U
1U
1U
8U/16U
LLS Workstation: The LLS Software has medium computational demands and no real-time requirements.
One PCI slot is needed for the master clock and two PCI slots are needed for the diagnostic cameras in case
of a Camera Link interface, which could also be substituted with an Ethernet interface. The datarate is
expected to be less than 100MB/s (see chapter 11 Network Architecture). With 10 operations per incoming
Byte the CPU clock should be 1GHz or more. The data is expected to sustain up to 10 seconds in the
RAM. All this leads to a RAM larger than 10GB, usual next size is 16GB which also suggests a cache of
minimal 4MB. Permanent storage of diagnostic data is not required. We assume that command data of one
night and maybe diagnostic data of up to one hour full rate might be stored. This would result in about
<30GB command data for an 8 hour night using an upper limit of 1MB/s on the command rate. The
diagnostic data is less thant 150GB per hour. We therefore specify 200GB harddisk space as lower limit.
LGSW Workstation: The LGSW workstation will host the LGSW control software and the WDHS
Software. It is better to distribute this to different CPU. One PCI slot is needed for the diagnostic camera in
case of the Camera Link interface. An alternative is via Ethernet. An additional dedicated Ethernet
interface for the ASM diagnostics is required. The datarate will not exeed 50MB/s for the LGSW software
and will be arround 140MB/s for the ASM diagnostics (see chapter 11 Network Architecture for details).
This puts some demand on the internal bus system of the workstation but not unusal high for a state of the
art server system. With 10 operations per incoming Byte the CPU clock should be 1.9GHz or more. The
data is expected to sustain up to 10 seconds in the RAM. All this leads to a RAM larger than 19GB, usual
next size is 32GB which also suggests a cach of minimal 8MB. We assume that command data of one night
and maybe diagnostic of the WFS field data of up to one hour full rate might be stored. This would result in
about <30GB command data for an 8 hour night using an upper limit of 1MB/s on the command rate. The
WFS field diagnostic data is less than 75GB per hour. The system should be capable to store the ASM
diagnostic data of one night, requiring around 4TB. We therefore specify 4.1TB harddisk space as lower
limit.
BCU (Real-time computer): The real-time reconstruction is done on the BCU boards of the ASM. As the
reconstruction is done in modal space separately for each sensor the demand on computational power is
three times larger than for the FLAO. One BCU has the computational performance of 380 Mega FLOPS
[AD 26]. The raw data processing and slope calculation needs 217.35kFLOP as shown in chapter 9.7 and
will/can be done one BCU. The matrix calculation will be done on the BCU at the adaptive secondary and
demands 12 BCU for reconstruction to keep the one cycle time lag requirement.
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
59 of 65
11 Network Architecture
The network connects the computers in the control room and the devices and local computers at the
telescope. Most communication within the ARGOS system has no constrains on latency, in some cases
there is a quite high datarate and finally we have the real-time demands of the ASM. Therefore, we define
three categories of network connection:



Gigabit Ethernet for low to medium throughput with no demands on latency.
Gigabit Ethernet with Quality of Service (QoS) for high throughput with no demands on latency.
QoS assures the bandwidth of a domain.
Dedicated Network or fiber connection for very high throughput or for communication with low
latency demands.
All the devices on the telescope should be remotely accessible. Most devices provide either an Ethernet
connection or a Seriell connection, which gets accessed through a terminal server. A possible solution for
the terminal server is the one from MOXA [Error! Reference source not found.]. Table 9, Table 10 and
Table 11 show the devices of the LLS, LGSW and Cal Unit, respectively.
Table 9 List of devices for the Laser and Launch System.
Device
Laser
Laser focus stage
Laser polarizer rotation stages
Laser periscope TT Stages
Laser diagnostic cameras
Laser upgrade stage
Laser shutter
Launch TT stage
Launch focus stage
Launch TT fold mirror
Launch shutter fold mirror
Launch exit shutter
Laser master clock
Laser delay generator right-left
Number
3
3
3
6
2
1
1
1
1
1
1
1
1 for both sides
1 for both sides
Connection
Ethernet (direct or Terminal Server)
Ethernet
Ethernet
Ethernet
Camara Link (dedicated fiber) or Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Local PC or Terminal Server
Local PC or Terminal Server
Table 10: List of devices for the LGS wavefront sensor.
Device
LGSW dichroic stage
LGSW field diagnostic
LGSW TT periscope
LGSW focus Stage
LGSW pockels cells
LGSW Delay generator
LGWS WFS detector
BCU
Number
1
3
3
1
3
1
1
1
Connection
Ethernet
Camara Link (dedicated fiber) or Ethernet
Ethernet
Ethernet
Terminal Server
Local PC or Terminal Server
AIA to BCU and Terminal Server or dedicated fiber
Ethernet + Dedicates diagnostic Ethernet
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
60 of 65
Table 11: List of devices for the CalUnit.
Device
White light source on-axis
White light source cal unit
Laser source off-axis
PSD source
PSD controller
Swing arm motor
Number
1
1 for both sides
1
1
1
1
Connection
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
The estimated data rate is collected in Table 12. The most data is produced with ASM diagnostics which
results in up to 140.6MB/s, when all requested data is transferred in 1kHz. The diagnostic data does not
demand real-time constraints but should be available timely, means seconds, and without data loss. We do
not consider, that frames could be skipped. However, the frequency of 1kHz might be reduced in case of
bandwidth problems.
For the LLS and LGSW the diagnostic images are the largest contributer. The frequency of 10Hz for the
launch and WFS diagnostics gives an upper limit and might be slowed down after understanding the
flexure of the system better. Altogether we reach a data rate of 130.18MB/s per eye. Therefore we propose
to have for each eye or the LBT separate networks and also split the LLS and LGSW in two separate
domains.
Table 12: Data rate estimation.
Data rate of ASM diagnostics network
Frame
Slopes
Applied Modes
Actuator Position
Accelerometers
Number
256x264
2x 672
672
672
6
Data rate in telescope network
Launch pupil diagnostic
Launch field diagnostic
WFS field diagnostic
WFS images display
Devices
Number
2048x2048
2048x2048
2048x2048
256x264
42.5
Sum one side/two sides
Sum
~135kB
~3kB
1.3kB
1.3kB
0.001kB
140.6kB x 1kHz = 140.6 MB/s
Sum
4.2MB x10Hz
= 42MB/s
4.2MB x10Hz
= 42MB/s
4.2MB x10Hz
= 42MB/s
135kB x25Hz
=3375 kB/s
42.5x19kB/s
= 807.5kB/s
(100 messages of 100 Byte forth and back)
130.18/260.37 MB/s
The outline of the ARGOS network architecture is shown in Figure 27. The system will have four class C
networks. From the telescope to the computer room this will be virtual networks. The networks are divided
as following:


Network 1: LGSW network commanding the WFS and taking care of the WFS diagnostics. The
network has no real-time requirements and the datarate is midium with less than 50MB/s. A fiber
connection from the SCP to the LGSW cabinet is required.
Network 2: ASM diagnostic network with high data throughput but no stringened real-time
requirements. This network requires QoS. The ASM diagnostic network should be already installed
for FLAO.
© ARGOS Consortium
Software Preliminary Design


Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
61 of 65
Network 3: The LLS network commanding the lasers and the launch telescope. The network has
no real-time requirements but a high datarate with up to 85MB/s. Therefore, we would also require
QoS for this network. At the telescope the devices of this network are distributed over the telescope
at the C-Ring and the Laser Platform. From both places fiber connections to the SCP are required.
Network 4: The existing FLAO network to command the T3 WFS.
The bandwidth of running ARGOS on both sides in parallel results in 4.33 Gb/s. Currently the connection
between telescope and computer room allows for 6Gb/s. Therefore, we conclude the existing network
capabilities are sufficient. The selected switches within the LBT network environment allow for QoS.
Figure 27: ARGOS network architecture scheme
© ARGOS Consortium
Software Preliminary Design
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
62 of 65
The real-time communication from the slope BCU to the ASM will have a dedicated fiber. The sensor will
be selected with the switch BCU placed close to the ASM (not shown in Figure 27). A dedicated serial line
from the FLAO BCU to the LGS BCU is needed for the asynchronious TT command.
Table 13: Summary of the requirements to LBT.
Domains
Domain-IP
LGSW domain SX
LGSW domain DX
LLS domain SX
LLS domain DX
T3 domain SX
T3 domain DX
ASM diagnostic domain SX
ASM diagnostic domain DX
TBD by LBT
TBD by LBT
TBD by LBT
TBD by LBT
TBD by LBT
TBD by LBT
TBD by LBT
TBD by LBT
Band
width
1GB/s
1GB/s
1GB/s
1GB/s
1GB/s
1GB/s
1GB/s
1GB/s
#port Dedicated fibres
Comments
1
1
2
2
1
1
1
1
QoS
QoS
From FLAO
From FLAO
From FLAO
From FLAO
Possible up to 2 (=1 pairs)
Possible up to 2 (=1 pairs)
Possible up to 4 (=1 pairs)
Possible up to 4 (=1 pairs)
none
none
none
none
© ARGOS Consortium
Software Preliminary Design
APPENDIX (1):
List of acronyms
AGN
AGW
AIA
AIP
AIT
AIV
ALFA
AOA
AOS
APD
ARIES
ASM
BCU
BH
BLINC
CAAO
CAHA
CAOS
CCD
CONICA
CSW
CUS
CW
DIMM
DIQ
DM
DMD
DSP
ECSS
E-ELT
EMCCD
ESO
FAA
FLAO
FOROT
FOV
FPGA
FTE
FWHM
GLAO
GLAS
GS
GSAOI
HLL
HST
HVR
ICD
IDL
IEC
Active Galactic Nuclei
Acquisition Guiding and Wavefront sensing
Automated Imaging Association
Astrophysical Institute Potsdam
Assembly, Integration and Testing
Assembly, Integration and Verification
Adaptive optics with a Laser For Astronomy
Adaptive Optics Arbitrator
Adaptive Optics System
Avalanche Photo Diode
Arizona infraRed Imager and Echelle Spectrograph
Adaptive Secondary Mirror
Basic Computational Unit
Black Hole
Bracewell Infrared Nulling Cryostat
Center for Astronomical Adaptive Optics
Centro Astronómico Hispano Alemán
Code for Adaptive Optics Systems
Charged Coupled Device
COudé Near Infrared CAmera
Common SoftWare
Calibration Unit Software
Contiunious Wave
Differantial Image Motion
Delivered Image Quality
Deformable Mirror
Deformable Mirror Diagnostics
Digital Signal Processor
European Coorperation on Space Standardization
European - Extremely Large Telescope
Electron Multiplied CCD
European Southern Observatory
Federal Aviation Administration
First Light Adaptive Optics
Forecast Optical Turbulence
Field of View
Field Programalbe Gate Array
Full Time Equivalent
Full Width Half Maximum
Ground Layer Adaptive Optics
Ground layer Laser Adaptive optics System
Guide Star
Gemini South Adaptive Optics Imager
HalbLeiterLabor, Max-Planck-Institute semiconductor laboratory
Hubble Space Telescope
High Vertical Resolution
Interface Control Document
Interactive Data Language
International Electrotechnical Commission
© ARGOS Consortium
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
63 of 65
Software Preliminary Design
IIF
ILT
IMF
INAF
ING
IPC
IR
IRCAL
ISAAC
LBC
LBT
LBTB
LBTC
LBTI
LBTO
LCSW
LCU
LGS
LGSF
LGSW
LINC
LL
LLNL
LLS
LLT
LMC
LSW
LUCIFER
MAD
MAIT
MCAO
MIRAC
MIT
MMT
MODS
MOU
MPE
MPG
MPI
MPIA
NACO
NAOS
NGS
NICMOS
NIF
NIFS
NIR
NIRI
NIRSPEC
NIRVANA
NOAO
OSIRIS
PA
PAH
PCI
PHL
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
64 of 65
Instrument InterFace
Instrument Level Test
Initial Mass Function
Istituto Nazionale di Astrofisica
Isaac Newton Group
Inter Process Communication
InfraRed
IR Camera for Adaptive optics at Lick
Infrared Spectrometer And Array Camera
LBT Camera
Large Binocular Telescope
LBT Beteiligungsgesellschaft
Large Binocular Telescope Corporation
LBT Interferometer
LBT Observatory
LGS Common SoftWare+B112
Local Computational Unit
Laser Guide Star
LGS Facility
LGS Wavefront Sensor
LBT Interferometric beam Combiner
Laser Launch
Lawrence Livermore National Laboratory
Laser Launch System
Laser Launch Telescope
Large Magellanic Cloude
LandesSternWarte
LBT Near Infrared Spectroscopic Utility with Camera and Integral Field Unit for Extragalactic Research
Multi conjugated Adaptive optics Demonstrator
Manufacturing, Assembly, Integration and Testing
Multi Conjugated Adaptive Optics
Mid-Infrared Array Camera for Astronomy
Massachusetts Institute of Technology
Multi Mirror Telescope
Multi-Object Double Spectrograph
Memorandum of Understanding
Max-Planck Institute for Extraterrestric
Max-Planck Gesellschaft
Max-Planck Institute
Max-Planck Intitute for Astronomy
NAOS CONICA
Nasmyth Adaptive Optics System
Natural Guide Star
Near Infrared Camera and Multi-Object Spectrometer
Near-Infrared Integral-Field Spectrograph
Near InfraRed
Near InfraRed Imager
Near Infrared Spectrograph
Near-IR / Visible Adaptive INterferometer for Astronomy.
National Optical Astronomy Observatory
OH-Suppressing InfraRed Imaging Spectrograph
Product Assurance
Polycyclic Aromatic Hydrocarbons
Peripheral Component Interconnect
Preliminary Hazard List
© ARGOS Consortium
Software Preliminary Design
PID
pnCCD
PO
PSF
PW
PXI
QA
QSO
RCO
RLGS
RMS
RON
RPC
RTC
SAM
SCAO
SCIDAR
SDSS
SDT
SFR
SH
SINFONI
SMBH
SMT
SNR
SOAR
SOR
SR
STIS
STScI
SVD
TBC
TBD
TCS
TMT
TRE
TT
TTW
UA
UKIDSS
UMAC
UNISIS
VATT
VLT
WDHS
WFS
WHT
WIYN
Proportional, Integral and Differential
the very fast high-resolution radiation detector of the HLL
Project Office
Point Spread Function
Pulsed Wave
PCI eXtensions for Instrumentation
Quality Assurance
Quasi Stellar Object
Radiation Control Office
Rayleigh Laser Guide Star
Root Mean Square
Read Out Noise
Remote Procedure Call
Real Time Control
SOAR Adaptive Module
Single Conjugated Adaptive Optics
SCIntillation Detection And Ranging
Sloan Digital Sky Survey
Science Demonstration Time
Star Formation Rate
Shack Hartmann
Spectrograph for INtegral Field Observations in the Near Infrared
Super Massive Black Hole
Sub Millimeter Telescope
Signal to Noise Ratio
Southern Astrophysical Research
Starfire Optical Range
Strehl Ratio
Space Telescope Imaging Spectrograph
Space Telescope Science Institute
Single Value Decomposition
To Be Confirmed
To Be Defined
Telescope Control Software
Thiry Meter Telescope
Test Review Europe
Tip Tilt
Tip Tilt Wavefront sensor
University of Arizona
United Kingdom Infrared Deep Sky Survey
Universal Motion and Automation Controller
University of Illinois Seeing Improvement System.
Vatican Advanced Technology Telescope
Very Large Telescope
Wavefront Data Handling
WaveFront Sensor
William Herschel Telescope
Wisconsin Indiana Yale & NOAO
End of document
© ARGOS Consortium
Doc:
Issue
Date
Page
ARGOS PDR 012
1.0
2009/02/01
65 of 65