User Tools

Site Tools


chara:discussion_of_alignment_procedures

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
chara:discussion_of_alignment_procedures [2024/03/20 21:44]
gail_stargazer
chara:discussion_of_alignment_procedures [2024/07/10 19:35] (current)
gail_stargazer
Line 28: Line 28:
   * When slewing to next star, send M7 to default position and repeat.   * When slewing to next star, send M7 to default position and repeat.
  
-==== New Alignment Sequence ====+==== Current Alignment Sequence ====
  
 Implemented January-July 2023 Implemented January-July 2023
Line 38: Line 38:
   * Align TelWFS boxes to center on the red beacon.   * Align TelWFS boxes to center on the red beacon.
   * Align blue beacon to labAO using dichroic.   * 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.   * Focus blue beacon on labAO and red becaon on TelWFS.
   * If aberration terms are high, ZERO CENTROIDS to adjust relative positions of the boxes.   * If aberration terms are high, ZERO CENTROIDS to adjust relative positions of the boxes.
Line 53: Line 55:
   * If coma and astigmatism high, create sky flat on bright star - Turn off **[DM]**, **[SV FLT]**, **[FLATEN]**, then relock the **[DM]**.   * 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 IR combiners, move beacon flat to align star to STST.
-  * For SPICA, move beacon flat to align star on SPICA FTT.+  * 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>
 +  * <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>*
   * Star Acquired.   * Star Acquired.
   * 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.   * 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.
Line 61: Line 64:
 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> 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.+<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. **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 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. **Proposed Changes to the Alignment Sequence**  - rough ideas - comment in different color to provide feedback or propose different steps.
Line 71: Line 83:
   * Send M7 to default.   * Send M7 to default.
   * Align red beacon to the reference TelWFS boxes (NOT the offset boxes) using beacon flat.   * Align red beacon to the reference TelWFS boxes (NOT the offset boxes) using beacon flat.
-  * Align blue beacon to lab WFS using DICHROIC.+  * 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.   * Lock star on TT and TelAO DM.
   * Move beacon flat to center star on STST or SPICA FTT.   * Move beacon flat to center star on STST or SPICA FTT.
Line 77: Line 89:
   * 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 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).   * 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. The coordinated Beacon/M7 movements (using STST button on obsgtk) will speed up compensating for big shifts after sending M7 to default.
Line 103: Line 119:
  
 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. 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).
 +
 +__**Engineering Report from UT 2024May02**__
 +
 +Rob and Karolina realigned the W1 telao WFS camera yesterday in an attempt to improve the flaring when locking the AO loop. The good news is that W1 telAO performed well on sky. Norm did not have to move the wfs boxes during the alignment at stow nor during any slews. There was no flaring and the star remained in the ACQ hole during slews.
 +
 +But there seemed to be a problem with W1 when we aligned STST. E1 flux on mircx/mystic would increase dramatically (x2) after aligning the star to STST, but W1 flux would drop in half after aligning to STST. The W1 pupil on STST appeared full before aligning STST and was sheared in half after aligning STST. So even though W1 telAO is performing well, something seems to be shearing the beam on the way to labao/stst. [NOTE: The problem with W1 is that STST was not aligned with CHARA beams on Beam 3.]
 +
 +Norm noticed that there is a large shift in the laser ref boxes vs. the beacon ref boxes on W1 labao. The labao ref boxes on other telescopes are much closer together. Could this be causing a problem? Also, when using M7 to move the blue beacon flux on the W1 labao WFS display up, the flux in rows would cut out suddenly (as if something was vignetting it) rather than slowly shifting the spot pattern up. When moving M7 to move the blue beacon flux on the W1 labao WFS display down, the spot pattern would slowly shift downward and off the display as expected.
 +
 +We looked into testing the alignment sequence on W1 of sending M7 to default, aligning the beacon flat to align red beacon on telWFS, aligning the dichroic to align the blue beacon on labAO, and then aligning STST using B/M7. The performance of W1 was similar with both sequences, in terms of not having to move WFS boxes, flux on mircx/mystic, and image/pupil on STST, whether we used the standard alignment sequence (keeping dichroic fixed) vs. moving the dichroic instead of M7 to align blue beacon to labAO. At the moment, there does not appear to be a strong motivation for switching sequences, as it seems that other factors (e.g., realignment of camera and new reconstructors) allow us to keep AO loop locked without moving ref boxes. The dichroic alignment sequence has the drawback that it takes a longer time to align after slewing. We might still want to experiment more on engineering nights though.
 +
 +Note that we went back and redid all of the alignments of W1 at stow with M7 and flats set to default, just to confirm that the vignetting mentioned above was not the result of moving dichroic vs M7.
 +
 +Here is a pdf with some screenshots: {{:chara:files:engineering_report_ut2024may02.pdf|chara:files:engineering_report_UT2024May02.pdf}}
 +
 +Gail
 +
 +__**Engineering Report from UT 2024May16**__
 +  * E1 - AO engineering + obsgtk integration
 +  * Comparison of M7 vs Dichroic alignment tests with SPICA
 +  * UT 04:24 HD 113226, EL 64 deg, AZ 150 deg - M7 alignment (adjust boxes)
 +  * UT 06:00 - dichroic alignment
 +  * UT 07:20 HD 113226, EL 53, AZ 239 deg - realign at stow, go back to M7 align
 +  * video of telao on and off
 +
 +First night with AO running on all 6 telescopes (after W2 DM installation): [[http://www.astro.gsu.edu/~schaefer/chara/movies/ao_video.mp4|video clip]]
 +
 +**Notes from Gail:**
 +
 +We took a short video last night comparing the spots on the Six Telescope Star Tracker (J-band) with the AO on versus AO off. There's still more optimization to be done, but it was good to see the dramatic improvement in spot quality on all 6 telescopes with the AO systems locked.
 +
 +The video starts with AO on. Then the AO servo's are turned off on all scopes and the images blur out. Finally, the AO loops are turned on again with well-defined compact spots.
 +
 +**Notes from Denis:**
 +
 +I have posted some SPICA images recorded during the same engineering tests. They can be viewed on this link:
 +
 +[[https://cloud.oca.eu/index.php/s/kpGeDZXWt8pGwAN|https://cloud.oca.eu/index.php/s/kpGeDZXWt8pGwAN]]
 +
 +For all sequences, we have, from left to right, E1-W2-W1-S2-S1-E1. Images are 10ms exposure and the gifs are 'almost' real time sequence of 30s (but continuous loop).
 +
 +  * 04-56-44: initial situation after opening and standard alignment. Large residual static aberrations on W2W1 clearly. Flux on E's is much less than others. Flat on W1, W2 does not improve the situation.
 +  * 06-31-05: We did a stow, then M7 to default, and then dichroic alignment. Situation is better (but seeing may have evolved in the meantime).
 +  * 07-15-03: BF/M7 alignment. The TopLeft-BottomRight elongation is related to the atmospheric refraction (zenithal distance ~40°).
 +  * 07-30-33: same record close loop
 +  * 07-34-41: record open loop
 +
 +From the last record, it can be seen that the seeing was really poor. The encircled energy computation goes from 3% (open loop) to 7-8% in close loop. We are still far from 25% as expected but the atmospheric refraction (not yet compensated) is also a limitation of course, as well as the seeing conditions. Many beams have residual static aberrations, probably due to LABAO issues, and E's are really presenting a low transmission.
 +
 +Qualitatively and with these conditions, I do not see obvious difference between the two methods of alignment for the AO performance. It's great to have all 6 AO working now.
  
  
chara/discussion_of_alignment_procedures.1710985442.txt.gz · Last modified: 2024/03/20 21:44 by gail_stargazer