ICD 2.3/4.3. Wavefront Correction Control System to Data Handling System

Transcription

1 ICD 2.3/4.3 Wavefront Correction Control System to Data Handling System Version: Issued By: Erik Johansson, Keith Cummings, Kit Richards, Luke Johnson Draft 19 December 2014 Wavefront Correction Group Approved By: Lead Engineer (2.3) Lead Engineer (4.3) Date: Systems Engineer

2 Revision Control 1. Revision Version: Draft Date: 19 December 2014 Revised by: Erik Johansson Reason for / items changed: Initial creation. ICD 2.3/4.3 Page 2 of 11

3 1. Description This document specifies the public software interface between the Wavefront Correction Control System (WCCS) and the Data Handling System (DHS), in particular the Bulk Data Transport (BDT). Although the BDT already has a public API specified in SPEC-0151, Data Handling System Bulk Data Transport API, this document is required to provide a configuration controlled specification for the data published to the BDT by the WCCS and its subsystems that are available for use by other observatory systems, including the instruments. The WCCS is the top-level control system for the Wavefront Correction System (WFC), which is comprised of the High Order AO System (HOAO), Low Order Wavefront Sensor (LOWFS), Context Viewer (CV), active Optics Engine (ao), and Limb Tracker (LT) subsystems. In the remainder of this document, the WCCS is considered to include all of these subsystems and represents the entire WFC. The WCCS publishes data to the BDT in a number of places: The HOAO publishes high-speed telemetry to the BDT for use by the Visible Broadband Imager (VBI) during its real-time speckle processing and to be saved to the DHS for use in further data reduction and analysis. The Context Viewer publishes image data to the BDT for use by the OCS for target selection and adaptive optics (AO) lock point selection. This data may also be saved to the DHS, but only for engineering purposes for the WFC. The HOAO and LOWFS use the BDT for transmission of image data and processed telemetry data for use and display on the WFC Engineering GUI. The first two of these applications represent the public interface between the WCCS and DHS. That is, the data published in these applications is intended for use by systems outside of the WFC. The last application represents the private interface between the WCCS and the DHS, which is for internal use by the WCCS. Only the public interface is discussed in this document. The details of the private use of the DHS by the WCCS subsystems may be found in the specific subsystem CDDs. This document defines the structure and content of the data and meta-data published by the WCCS subsystems to the DHS. The DHS is a service of the DKIST Common Services Framework (CSF). The CSF is described in detail in the CSF reference manual (SPEC-0022). The description of the interface to the Bulk Data Transport is found in the BDT API (SPEC-0151). Since there are no mechanical, optical, electrical, or thermal connections between these two systems, this document contains only the software interface. The interface defined in this document is inclusive of all public operations performed between the two systems; no commands, events, or other functional operations may be performed that are not defined herein. Moreover, no other BDT data products produced by the WCCS may be used by other systems unless they are defined herein. 2. Reference Documents [1] SPEC-0016, Data Handling System Specifications [2] TN-0065, Data Handling System Reference Design Study and Analysis [3] SPEC-0151, Data Handling System Bulk Data Transport API [4] SPEC-0022, Common Services Framework Reference Manual [5] SPEC-0026, Wavefront Correction Control System Design Requirements Document [6] SPEC-0058, Wavefront Correction System Specifications Document [7] SPEC-0142, Low Order Wavefront Sensor Critical Design Document ICD 2.3/4.3 Page 3 of 11

4 [8] SPEC-0147, High Order Adaptive Optics Critical Design Document [9] SPEC-0180, Wavefront Correction Context Viewer Critical Design Document [10] SPEC-0063, Inteconnects & Services Specifications, Section Physical System Interfaces N/A 3.1. Mechanical Interface N/A 3.2. Optical Interface N/A 3.3. Electronic Interface All software communications described in this document between the WCCS and the DHS shall take place over the DKIST Bulk Data Transport. The WCCS interface to the BDT is implemented using a Gigabit Ethernet as defined by IEEE-802.3z The interface is found in SPEC-0063, Inteconnects & Services Specifications, Section The BDT is implemented as defined in SPEC-0016, Data Handling System Specifications, SPEC-0151, Data Handling System Bulk Data Transport API, and TN-0065, Data Handling System Reference Design Study and Analysis Mass/Balance Interface N/A 3.5. Thermal Interface N/A 4. Software/Control Interfaces The following software interfaces exist between the WCCS and the BDT: The HOAO publishes high speed telemetry from the WFC Real Time Controller The Context Viewer publishes real-time image data These interfaces are discussed in detail in the sections that follow Overview of Wavefront Correction Control System Functionality This section gives a brief overview of the WCCS. The WCCS is responsible for managing all aspects of the operation of the Wavefront Correction System, which consists of the following subsystems: High Order Adaptive Optics System Low Order Wavefront Sensor ICD 2.3/4.3 Page 4 of 11

5 AO Context Viewer imaging system Active Optics Engine Limb Tracker The WFC is responsible for sensing and correcting wavefront and alignment errors in the light beam delivered to the instruments caused by atmospheric turbulence, thermal and gravitational fluctuations in the telescope optics and telescope vibration. These errors are sensed by the High Order Wavefront Sensor (HOWFS), Low Order Wavefront Sensor (LOWFS), Context Viewer (CV) and Limb Tracker (LT) subsystems of the WFC. The corrections are computed by the High Order Adaptive Optics (HOAO) system to directly control the positions of the M5 fast tip-tilt mirror and the M10 deformable mirror, and by the Context Viewer, Active Optics Engine and Limb Tracker subsystems to send correction information to the other telescope mirror control systems for quasi-static wavefront correction and pupil stabilization. The WCCS also provides telemetry information for the TCS, OCS and the instruments for use in target selection, AO lock point selection and instrument data reduction. The telemetry data is published to the DHS BDT. Finally, the WCCS also records and logs pertinent data used for performance optimization and system calibration. A context diagram for the WCCS is shown below in Figure 1. M5 & M10 HOAO ICD 2.3/4.4 LOWFS TCS WCCS CV Limb Tracker ao Engine ICD 2.3/4.3 DHS BDT ICD 2.3/4.4 ICD 2.3/4.4 ICD 1.3/2.5 M1CS Figure ICD 1.2/2.3 TEOACS M2 Position ICD 1.3/2.3 FOCS M3/M6 Tip Tilt ICD 1.5/2.3 TCS Pointing (TTM Offload) TCS Pointing Map, Limb Finding TEOACS M2 Tip Tilt Figure 1: A context diagram of the Wavefront Correction Control System. ICD 2.3/4.3 Page 5 of 11

6 4.2. BDT Data Published by the WCCS This section describes the data published by the WCCS or its subsystems to the BDT that is of interest to any other observatory subsystems, including the instruments. Currently, only the HOAO and CV subsystems publish data to the BDT that may be used outside of the WCCS. Other WCCS/WFC subsystems may use the BDT for intra-wfc data communications, but that data is not available in the public interface BDT Data Published by the HOAO The HOAO publishes three streams of telemetry data to the BDT: HOWFS shift vectors, residual wavefront error expressed in DM and TTM actuator space, and DM and TT actuator commands. The remainder of this section describes the details of these data streams, starting with an explanation of the optical geometry of the HOWFS HOWFS Geometry In order to interpret the HOAO telemetry data properly, the geometric orientation of the HOWFS subapertures and their associated shift vectors with respect to the DM actuators must be understood. The HOWFS uses what is referred to as the Fried geometry, in which the projection of the DM actuators onto the lenslet array subapertures is aligned such that each actuator is surrounded by four subapertures (alternatively, each subaperture is surrounded by four actuators). An illustration of the Fried geometry for the HOWFS is shown below in Figure 2. ICD 2.3/4.3 Page 6 of 11

7 Figure 2: An illustration of the orientation of DM actuators and lenslet subapertures for the HOWFS. The squares are subaperture lenslets and the x s are DM actuators. The red squares highlight the numbered subapertures shown in the diagram. There are a total of 1600 actuators on the DM, numbered in raster order from left to right starting at the top left corner, with numbers from 1 to This assumes you are looking at the face of the mirror. The subapertures processed by the Real Time Controller (RTC) form a 48 x 48 grid about the optical axis. There are 43 subapertures across the diameter of the illuminated pupil. The geometry shown in Figure 2 includes only those subapertures that are surrounded by three or more actuators on the DM. These subapertures are also numbered in raster order, from 1 to The HOWFS detector data includes many subapertures that lie outside of the pupil that are not illuminated, whose corresponding shift measurements are random due to detector noise (these are not used to calculate wavefront corrections). Because of the high frame rate of the HOWFS camera it is important that this useless data is not published to the BDT, as doing so will reduce available BDT bandwidth as well as impact the storage capacity of the DHS. ICD 2.3/4.3 Page 7 of 11

8 There are 48 x 48 = 2304 total subapertures processed by the RTC, but only 1561 subapertures in the immediate vicinity of the pupil. Hence there are 743 subapertures that are never used. Each subaperture shift vector is transmitted using 2 bytes, so the unused subapertures represent 1486 bytes. At the nominal HOWFS frame rate of 2 khz, that is MB/s of data, which is significant. Hence, we publish only the shift data for the 1561 subapertures illustrated above. It is important to note that the numbering scheme described above exists solely for the purpose of limiting the amount of data transmitted to the BDT and is not directly related to the specific subapertures used in the wavefront reconstruction process. The subapertures used in the wavefront reconstruction are determined by the structure of the reconstruction matrix used by the RTC BDT Overhead The original intent for the WFC telemetry was to publish on a per-frame basis, which means at a rate of 2 khz. However, the BDT is designed for the transmission of large amounts of image data and has an overhead associated with each transmission. The table below shows the impact of overhead based on the payload size (reproduced from TN-0065, Data Handling System Reference Design Study and Analysis): Data Size Max Frames/second Max MB/second 128K 3, K 1, MB MB MB 33 1,056 64MB The throughput at the maximum frame rates is about 50% of the maximum throughput available. The size of a single frame of WFC telemetry is approximately 9.6 kb plus meta-data, or ~10 kb. At 2 khz, that is 20 MB per second. However, the data cannot be combined, as each stream must be saved so that it can be read as separate FITS images using standard FITS reader software. This means there are three separate streams of approximately 3.2 kb (residual wavefront error), 3.2 kb (DM/TT actuator commands) and 3.1 kb (shift vectors). The BDT overhead and effective throughput associated with publishing the combination of these three streams at 2 khz is unknown. As a result, we plan to buffer the data and publish it periodically at a rate slower than 2 khz, with all three streams buffered to contain the same number of frames. The VBI requires the WFC BDT telemetry data within 100 ms of the receipt of the actual data by the camera, so this bounds the problem to some extent: we can buffer from 50 to 75 ms (100 to 150 frames) and still have 25 ms for BDT transmission overhead to meet the VBI requirement. We plan to experiment with this buffering strategy in the laboratory during initial system integration to determine the optimal number of frames to buffer HOWFS Shift Vectors A shift vector consists of a pair of x and y shift values for each subaperture. There are 1561 shift vectors in each frame for a total of 3122 values. The values are stored in the following order: [{S1 x, S1 y}, {S2 x, S2 y}, {S3 x, S3 y},, {S1559 x, S1559 y}, {S1560 x, S1560 y}, {S1561 x, S1561 y}] Each value is encoded as an 8 bit signed integer, with the number representing 50 times the actual measured shift in pixels on the HOWFS detector. The shift in arc-seconds may be determined as follows: ICD 2.3/4.3 Page 8 of 11

9 S as = ps ( S 50 ), Where S is the encoded shift value and ps is the plate scale of the HOWFS camera in arc-seconds per pixel. The HOWFS plate scale will be accessible as a WCCS property from the CSF Property Data Base. It is up to the user of the telemetry data to scale the shift values from pixels into arc-seconds. The HOWFS shift vectors will be published using the BDT topic name howfsshiftvectors and will be accompanied by the following meta-data: Name Type Value howfsshiftvectors dhs.qas.xdim Int The number of shift values per frame (2*1561) dhs.qas.ydim Int The number of frames in the BDT buffer (TBD) dhs.qas.bitpix Int the number of bits per value (8) BSCALE Real 1.0 (preserves the raw value) BZERO Real 0.0 BUNIT String Raw WFSCALE Real 0.02 (converts from raw to pixels) WFZERO Real 0.0 WFUNIT String Pixels The BSCALE and BZERO values are set such that they will not modify the data values when automatically applied by a FITS reader. The WFSCALE, WFZERO and WFUNIT attributes must be saved as custom FITS keywords and used to interpret the data. WFSCALE will convert the raw shift values into pixel units, which must then be multiplied by the HOWFS plate scale by the user to convert to units of arc-sec on the sky. The size of the HOWFS shift vector data will be N frames * 2 * 1561 bytes Residual Wavefront Error The residual wavefront error is the uncorrected wavefront error sensed by the HOWFS expressed in DM actuator space for a single frame of HOWFS camera data. In addition there are two values appended at the end for the x and y tip-tilt error. The values in the residual wavefront error vector are equal to the current HOWFS shift vectors multiplied by the HOAO reconstruction matrix. There are = 1602 values for each frame of residual wavefront error data. Each value is encoded as a 16 bit signed integer, with a range of to The data must be multiplied by a scale factor to convert to nm of wavefront error. Separate scale factors are required to convert the DM data to nm of wavefront and Tip-Tilt data to arc-sec of tilt. The residual wavefront error will be published using the BDT topic name hoaoresidualwfe and will be accompanied by the following meta-data: Name Type Value howfsresidualwfe dhs.qas.xdim Int The number of wavefront error values per frame (1602) dhs.qas.ydim Int The number of frames in the BDT buffer (TBD) dhs.qas.bitpix Int the number of bits per value (16) BSCALE Real 1.0 (preserves the raw value) ICD 2.3/4.3 Page 9 of 11

10 BZERO Real 0.0 BUNIT String Raw DMSCALE Real TBD (converts from raw to nm of wavefront) DMZERO Real 0.0 DMUNIT String nm TTSCALE Real TBD (converts from raw to arc-sec of tilt) TTZERO Real 0.0 TTUNIT String arc-sec The BSCALE and BZERO values are set such that they will not modify the data values when automatically applied by a FITS reader. The DMSCALE, DMZERO, DMUNIT, TTSCALE, TTZERO and TTUNIT attributes must be saved as custom FITS keywords and used to interpret the data. DMSCALE will convert the residual WFE values in the pupil from raw units to nm of wavefront error. TTSCALE will convert the final two tip-tilt values from raw units to arc-sec of tilt error. The size of the residual wavefront error data will be N frames * 2 * 1602 bytes Actuator Commands The actuator commands are the current values of the DM and TT actuators and represent the corrected wavefront error that is not sensed by the HOWFS for the current HOWFS camera frame. It is in the same format and units as the residual wavefront error described above, including the meta-data. The actuator command data will be published using the BDT topic name hoaoactuatorcmds Generic BDT Meta Data In addition to the meta-data described above, the WCCS is required to publish meta-data as described in SPEC-0122, DKIST Data Model (see table for keywords WFC_nnn). The following meta-data will be published along with the meta-data described above for each of the three BDT streams: BDT Meta-Data Attribute Name Type FITS Keyword FITS Comment wavelength Real WAVELENTH None dmlockstatus Boolean WFC_002 HOAODMFrameLockStatus ttlockstatus Boolean WFC_XXX HOAOTTFrameLockStatus ReconMatID String WFC_003 HOAOReconstructionMatrixID lockpointx Real WFC_004 [arcs] HOAOLockOffPointingX lockpointy Real WFC_005 [arcs] HOAOLockOffPointingY hoaodmpgain Real WFC_006 HOAODMCtrlLoopPValue hoaodmigain Real WFC_007 HOAODMCtrlLoopIValue hoaottpgain Real WFC_XXX HOAOTTCtrlLoopPValue hoaottigain Real WFC_XXX HOAOTTCtrlLoopIValue howfsframerate Int WFC_008 [Hz] HOAOWFSFrameRate Note that these attributes will be published using the names in the left hand column, which are easily interpreted, and the FITS conversion software must translate the names to those listed in the FITS Keyword column. ICD 2.3/4.3 Page 10 of 11

11 BDT Data Published by the CV The Context Viewer publishes its image data to the BDT. The internal camera format is 2048 x 2048 with 12 bit monochrome output (as 16 bit words) and the frame rate is nominally 10 Hz. The CV applies dark and gain corrections to the images. To minimize impact on the BDT bandwidth, the published images are kept in 16 bit unsigned format. The data will be published to the BDT topic name aocvimagedata with one frame per BDT transaction and will supply the following meta-data: Name Type Value aocvimagedata dhs.qas.xdim Int The number of pixels along the x axis (2048) dhs.qas.ydim Int The number of pixels along the y axis (2048) dhs.qas.bitpix Int The number of bits per pixel (16) platescale Real The plate scale of the CV based on the selected FOV, in arc-sec wci:tcsdmdpos Real[3] the current TCS demand position wci:coudedmdangle Real the current coudé demand angle wci:tcsinposition Boolean the TCS in position status wci:tcscurpos Real[3] the TCS current position wci:coudecurangle Real the coudé current position wci:offsets Real[3] the current TCS offsets The wci attributes are the telescope position data provided by the CSF tcswatch utility. These values are requested by the CV at the time of image capture. ICD 2.3/4.3 Page 11 of 11