The CHARA Array Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Discussion of Alignment Procedures ======

==== Old Alignment Sequence ====

At stow:

  * M7 to default
  * Make sure red beacon goes into the ACQ hole, fine tune into boxes —move beacon flat
  * Make sure that the laser from the lab, with m2 corner cube goes into the hole —move dichroic
  * Turn off laser and red beacon and turn on blue beacon, to fine tune spots into labao —move dichroic
  * Focus blue beacon on labao — then focus red beacon on telescope
  * Repeat until convergence and small errors.

Slewing to star:

  * At star, the red beacon on telwfs likely won't have moved much, blue beacon on labao may need significant adjustment.
  * M7 to default
  * Red beacon - TelWFS - beacon flat
  * Blue beacon - Labao - dichroic
  * Blue beacon focus - Labao - "focus beacon button" - lab parabola
  * Red beacon focus -TelWFS - "focus WFS " button scope parabola.
  * Turn off red beacon.
  * Lock star - TT
  * Close TELWFS DM loop
  * Close LABAO DM loop
  * AUTOM7 - to offload tilt in lab to M7
  * Star acquired
  * When slewing to next star, send M7 to default position and repeat.

==== Current Alignment Sequence ====

Implemented January-July 2023

At stow:

  * M7 to default. Load default boxes on tel WFS. Load default flats on telAO and labAO.
  * Move Beacon flat to center beacon in ACQ hole.
  * Align TelWFS boxes to center on the red beacon.
  * Align blue beacon to labAO using dichroic.
      * <font inherit/inherit;;#2980b9;;transparent>I do not understand why M2 corner cube is not used here, with laser coming from lab as in original sequence? I think it is the only way to orient the dichroic.</font>
      * <font inherit/inherit;;#cc0000;;inherit>The laser/cc is not used for the fine alignment for the same reason the acq camera is not used for aligning the red beacon to tel wfs. The ao system aligns to sub arcsec.</font><font inherit/inherit;;#8e44ad;;inherit>I do not believe the laser has ever been used to align during observing since the AO system has been installed. I have never used it or the corner cube. The cc is at times unreliable and can get lost or stuck. The laser spots can be seen without the corner cube if needed to realign the dichroic. What are we to see or align with the laser and corner cube that we don’t see without?</font>* Focus blue beacon on labAO and red becaon on TelWFS.
  * If aberration terms are high, ZERO CENTROIDS to adjust relative positions of the boxes.

Slewing to Star:

  * On first slew only, align red beacon to TelWFS boxes using beacon flat.
  * Align blue beacon to lab WFS using M7.
  * Focus blue beacon on labAO and red becaon on TelWFS.
  * Turn off red beacon.
  * Turn off blue beacon and lock star (TT only) - move TelWFS boxes to get star centered and evenly illuminated on ACQ hole.
  * Lock star on Tel AO - DM servo
  * Turn on blue beacon - lock LABAO servo
  * Turn on DM AUTO - use DM to correct tilt and offload to M7 when needed.
  * If coma and astigmatism high, create sky flat on bright star - Turn off **[DM]**, **[SV FLT]**, **[FLATEN]**, then relock the **[DM]**.
  * For IR combiners, move beacon flat to align star to STST.
  * For SPICA, move beacon flat to align star on SPICA FTT. <font inherit/inherit;;#16a085;;inherit>(denis: we validated the combined method BF+M7 on E1 on April 23 and it did excellent worj, permitting to use the Right/Left,Up/Down axes of the IPDET to put the star in the FTT boxes.)</font>* Star Acquired.
  * <font inherit/inherit;;#1abc9c;;inherit>(denis: when FTT is locked turn on the offload to keep the alignment during tracking =⇒ good for FTT and good for Alignment. This has been successfully implemented in April 2024)</font>* When slewing to the next star, DO NOT send M7 to default. If next star is bright, then align beacon flat to center star on STST/SPICA FTT. If star is faint, keep beacon flat fixed or align beacon flat to center red beacon in offset beacon boxes on TelWFS.


==== Proposed Revisions to Current Alignment Sequence ====

There is some controversy on whether moving the TelWFS boxes corrupts the reconstructor. During engineering time we should try keeping the boxes fixed at their reference positions when the last reconstructor was made using the CalSource. For these tests, do not move the boxes to center on the red beacon at stow, also do not use Zero Centroids to change the relative positions of the boxes. This might mean that beacon/star will be offset in the ACQ hole. <font 11pt/inherit;;inherit;;inherit>It might be better to use the boxes as the absolute reference rather than the Acq hole.</font>

<font 11pt/inherit;;inherit;;inherit>In February, Norm found that some telescopes performed OK with not moving the boxes and other telescopes could not lock stars without adjusting the boxes. If the WFS boxes need to be moved, then it would be a good idea to create a new on-sky reconstructor and flat using a bright star.</font>The gain should be high enough to give good SNR (without saturating) on the TelWFS when recording on-sky reconstructors.

**Action Item:**  Determine best gain settings for creating on sky reconstructors. Give guidance so operators can determine whether WFS counts are approaching saturation.

**<font 11pt/inherit;;inherit;;inherit>Action Item:</font>**<font 11pt/inherit;;inherit;;inherit>Figure out the best way to align star to the reference WFS boxes while simultaneously keeping the star centered in ACQ hole (see discussion/diagram at the end of this page).</font>

<font inherit/inherit;;#2980b9;;transparent>If this problem gets too big on some scopes, we could try to move the TWFS collimator in XY, while maintaining the star centered in Ref Boxes with Tel AO in closed loop (not tested yet). I know Theo have some concerns about risking a complete misalignment, but I hope someone could try when it is safe.</font>

<font inherit/inherit;;#2980b9;;transparent>Another way to deal with it is what operators usually do:</font>

<font inherit/inherit;;#2980b9;;transparent>Moving the boxes allows to get the star back in the hole, but destroys the reconstructor (for a non well-understood reason, probably DM not being in pupil plane…). Maybe we could try moving the boxes and then do an on-sky reconstructor?</font>

<font inherit/inherit;;#cc0000;;inherit>Moving the boxes does not always break the reconstructor. Sometimes it does help. It is very similar to moving the wfs. \\
Any optic moved behind the acq fold is just trying to compensate for something wrong before the fold which is not the best correction.</font>

**Proposed Changes to the Alignment Sequence**  - rough ideas - comment in different color to provide feedback or propose different steps.
  * At the start of a calibration sequence (first slew/pop change/new position on sky), go to a bright star.
  * Send M7 to default.
  * Align red beacon to the reference TelWFS boxes (NOT the offset boxes) using beacon flat.
  * Align blue beacon to lab WFS using DICHROIC. <font inherit/inherit;;#2980b9;;transparent>(Julien would recommend M2 corner cube and laser from lab.)</font>
  * Lock star on TT and TelAO DM.
  * Move beacon flat to center star on STST or SPICA FTT.
  * Measure, compute, and apply on-sky reconstructor.
  * If the next star is bright enough for STST alignment, then send M7 to default and repeat sequence above. [Maybe we only have to do this if next star is far away on sky - new pops, new calibration sequence.]
  * If the next star is too faint for STST [or close on sky?], then keep M7 fixed at current position and use current method of aligning blue beacon by moving M7 (instead of dichroic).

<font inherit/inherit;;#2980b9;;transparent>Remark: it is very difficult to evaluate AO performance without actually watching a “live” image (even if WFS give us the aberrations)</font>

<font inherit/inherit;;#2980b9;;transparent>Using Spica camera is better than STST because it has short exposures. Would it be possible to use Vis Dichro on IR programs? I know it reduces the flux sent to Tel WFS, but maybe some programs are on bright enough objects? IR flux is the same with VIS and IR dichro.</font> \\  \\ <font inherit/inherit;;#8e44ad;;inherit>Is the dichroic alignment coming back for each slew? It is not responsible for coude misalignments so we don’t do it now. What is the reason to bring it back?</font>

The coordinated Beacon/M7 movements (using STST button on obsgtk) will speed up compensating for big shifts after sending M7 to default.

**Please do not experiment with the alignment sequence during science programs, unless the PI requests for the operator to try a new/different approach (that can be done safely) to improve performance.**

**Notes from Discussion between Julien and Theo:**

A shift moves the star into the hole and the detector, while a tilt with star still centered in hole will dim the stars in some external boxes and make stars appear outside of the boxes used, on the opposite side.

{{:chara:facb0877bc105041bd65e11e1ed234db.png}}

About star going out from Acq hole:

1-After alignment, the center of the Acq Hole matches the center of the boxes.

2-Acq Hole plane and detector plane are optically conjugated, means that what happens in Acq Hole is imaged on detector.

3-We have 3 blocks: Acq Hole + Acq camera, Collimator, and WFS (Lenslet + detector).

4-If Acq Hole translates, condition 1 is__ lost__. If it tilts we don't care.

5-If Collimator translates, condition 1 is __lost__, and illumination of the sub-pupils will change. If it tilts we don't care.

6-If WFS translates, condition 1 is __kept__, and illumination of the sub-pupils will change. If it tilts condition 1 is __lost.__

Julien sees no way to explain that star goes away from Acq Hole center while staying at boxes centers and not involving one of those 3 blocks. Whatever happens before Acq Hole in terms of tilt or shear, if the star is centered in boxes and not in Acq (or the opposite) means the initial matching between Acq Hole and Boxes is lost.

<font inherit/inherit;;#cc0000;;inherit>I think your shifted and tilted are opposite.</font>

<font inherit/inherit;;#cc0000;;inherit>In the diagram. The center image is what i would call a field error. If the incoming beam is not on axis.</font>

<font inherit/inherit;;#cc0000;;inherit>The lower image is on axis but the pupil is shifted. The beam coming in is on axis but the pupil is shifted.</font>

<font inherit/inherit;;#cc0000;;inherit>——-</font>

<font inherit/inherit;;#cc0000;;inherit>I see your point that if acqhole and everything to the right is aligned then positioning the star in the center of the acqhole should give #3 or #1 in the diagram. but sometimes we get #2 still.</font>

<font inherit/inherit;;#cc0000;;inherit>if thats the case, then should we not also see it with the beacon? we slew to the next star and align beacon to boxes. we should see the same error as we will see with the star?</font>

<font inherit/inherit;;#cc0000;;inherit>many of these errors may cause a vignetting at the acq hole also.</font>

<font inherit/inherit;;#2980b9;;inherit>Yes, if star shows #2 (at edge of boxes and hole), beacon should behave same way.</font>

<font inherit/inherit;;#2980b9;;inherit>The purpose of my drawings was to decompose what can happen to the incoming beam (either star or beacon) in terms of pure shift (no angle) or pure tilt around the center of acq hole. Any real beam will have a combination of those two effects.</font>

<font inherit/inherit;;#2980b9;;inherit>It shows that there is no way to explain a correct centering in boxes and not in acq hole by a problem with the incoming beam. In this case, Acq hole/Collimator/µL+Detector have moved one to another.</font>

__**Engineering Update - UT 2024Apr03**__

We experimented a bit with the AO alignment sequence. Specifically, on the slew to a new star:

  * Send M7 to default.
  * Align the red beacon to telWFS using the beacon flat.
  * Align the blue beacon to labWFS using the dichroic.
  * Use STST button to center star on STST (coordinated beacon flat/M7 movements).

The biggest issue (and the reason why we replaced the third step above with moving M7 instead) is that on large slews (> 90 deg), the blue beacon moves off labAO. To recover, we needed to turn on the laser and move the dichroic to center the laser in the ACQ hole. After the course adjustment, we could then see the blue beacon on labAO again. If we end up using this sequence on sky, perhaps we can calculate the expected motion of the dichroic and move it automatically during the slew. The main motivation for the change is that since the dichroic is causing the misalignment to the lab, it is probably the more correct optic to move vs. M7.

We tested this with E1, and we were able to keep telAO locked without needing to move the WFS boxes (the star was maybe just slightly on the edge of the ACQ hole when locking the AO loops). DM current was ~ 0.8 A. However, E1 might be one of the scopes where the operators don't ordinarily have to move the WFS boxes much. We can try with additional scopes on future engineering nights and with more diagnostic tools to gauge AO performace (by eye, the star looked good on STST with a bright circular core).
The CHARA Array Wiki

User Tools

Site Tools

Page Tools
