After yesterday's maintence time the range has been back in the 117 MPc range (front end range which is a bit higher than GDS), and the behavoir of the monitor channel for the removed 200MHz driver is still related to the range.  (Screenshot attached).  

Comparig the glitch rate on the summary pages  for today and yesterday shows that the glitch rate is again reduced when we are in the lower range state.  

Yesterday durring the maintence window Richard and I went to the racks to attempt to understand better what this channel could be connected to.  We didn't do anything that should have had an impact.  We did find that there were BNC T's left in the drive input channels for both of the AOM drivers used for itensity stabilization.  We removed these and replaced them with the right adapters, but this should not have any impact.  

Mark also spent some time trying to understand where this channel is coming from, (H1:ISC-C_RF_SQZAOM200M_OUTPUTMON), no real clues came from that. 

ADC overflows for the TMS QPDs 
YB upper left, XB upper right are overflowing during this lock.
These do not seem to have an immediate effect on the interferometer: No locklosses, no immediately apparent glitches [although those might be happening, these QPDs are used for CHARD control]

Looking at whether we can align the TMS at 2 watts and trust it will be well-aligned at 38 watts input (33.5 watts on back of PRM)
Seems like yes, we can align red on the TMS QPDs at 2 watts and expect it to be okay for 38 watts, as long as it's after MOVE_SPOTS.  

During the guardian state MOVE_SPOTS, we adjust the spots on the ITMs and to avoid our point absorbers prior to going to full power.  
During this stage we move significantly on our TMS QPDs, especially in pitch.  Not a lock killer, but enough to saturate a segment once we reach full power.
After we've reached full power, the QPD alignment continues to drift but nowhere near as significantly as the MOVE_STOPS change.  

If we realign the TMS to center on the QPDs after MOVE_SPOTS, I suspect our saturations will go away.

I checked the CHARD error and control signals during a time when the TRX and TRY B QPDs were saturated (now) and not saturated (early in the lock).

The CHARD error signal consists of 5 PD signals for pitch, and 6 for yaw.  
TRY B is not one of those PDs.  TRX B is.  

TRX B's signal is only slightly altered by the single segment saturation. (PDF 2)
The normalized sum is falling as the TMS drifts further off this QPD.  This causes the NSUM, PIT, and YAW ASDs to all decrease at AC.  The saturated segment does not contribute at AC.
Basically, our signal from this QPD is falling to zero, decreasing the overall gain of the loop.

Ultimately, saturating in TRX B does not produce huge noise effects in CHARD due to the number of PDs contributing to CHARD's error signal, and the fact that TRX B's signal has not completely flatlined due to the other segments still contributing.  
There is a small increase in noise in pitch from 4 to 8 Hz.  See PDF 1.
There is effectively no increase in noise in yaw.

Would you be able to provide a list of times that the Beckhoff was powered and connected and when it was not? I'd would like to figure out if the connection has impacated spectral artifacts in addition to any glitches. Thanks in advance!

JeffK noted that we don't have a good all in one place how-to on setting the initial alignment offsets.  So, here's an attempt at it.  This assumes that the QPDs are all close enough to center (or can be made to be so by moving TMS) that you do not need to use the picomotors.  Using the picos requires more thought and care.

The attachment is my desktop when I'm doing this, so you can see all of the windows that I'm looking at. 

• ndscopes:
  • bottom left: reacquire lock 'scope from my Locking screen
  • bottom middle: ADS 'scope from my Locking screen
  • right side: New template in ..../jenne.driggers/Templates/Scope/green_wfs_setpoints.yml
• medm screens:
  • sitemap, just because I always have the sitemap open
  • ALS camera setpoint screens, from each ALS end overview screen, then CAM ITM PIT green button.
  • tiny A2L screen: these are the A2L spot position gains from each test mass's PUM stage.  You can pull them each open individually from each SUS, or get this compact screen from my Locking screen, near the top right.
  • Compact QPD screen for the 4 IR transmon QPDs, to make sure that we're not falling off the IR QPDs.  Get this from my Locking screen, "ASC Pointing" button.
  • Green QPD offset sliders, get from either of the ALS end overview screens.
  • Sliders for the 2 TMSs.
• Terminal windows:
  • One running setEndGreenQPDOffsets_XARM.py
  • One running setEndGreenQPDOffsets_YARM.py

Process for each arm (can be done in parallel since each arm is independant of the other for this work):

• Ensure IFO is at 2W with all ASC engaged and converged (DC readout is a good spot for this).  Make sure that the ADS error signals are close to zero.
• Ensure green shutters are open (sitemap -> LSC -> Shutters, then "Open" on the two shutters in the second from right column)
• Ensure that the green laser is locked on the TEM00 mode to the cavity.
  • If it is not, you can noodle around the green QPD offset sliders.  Since these are in-loop with the pointing PZTs on the ALS in-air table, this effectively changes the pointing of the green laser into the vacuum, and into the cavity.
• Run the setEndGreenQPDOffsets_[X,Y]ARM.py script, which will adjust the green QPD offset sliders to adjust the green laser input pointing to match the arm cavity (the metric in the script is zeroing the ALS WFS signals on the bottom row of the right-most ndscope). 
  • Watch the QPD offsets to make sure they aren't moving the spots too close to the edges of the QPDs.  Top two rows of the rightmost ndscope have Ylims set to +/-1, so it should be easy to tell when you're getting too close.  The third row is the sum of light on the QPDs, so you know that if that starts dropping you're getting too close to the edge.  We've been operating at offsets of more than 0.8 for all of O3, so while that's not great, it's not unacceptable (since these are unused in Observation mode).
• Slowly move the TMS (steps of 0.1 urad seem fine with the standard 2 sec ramp) to get the beam closer to center on the IR QPDs.  Hopefully the green offset script will be pulling the green offsets closer to center, if they were close to their edges.  If they don't, you should stop here and reconsider things.  You may need to use the picos. 
• Once you've got the TMS moved to center the IR QPDs and the script has converged such that the green wfs signals are close to zero, you should set the camera offsets.
• Now, you're done and you should ensure that your new setpoints are saved in the down and observe SDF snapshots of the ALS end stations.

If you must pico, I'd recommend only pico-ing the IR QPDs since they're much easier to think about and independent of other beams.  I'd start the green QPD setpoint scripts to make the green QPDs follow your movement.  Then I'd make a small step in TMS alignment in the direction that will put the green QPD offsets closer to zero, and then pico the IR steering picos to get the IR QPDs closer to zero.

I've edited the code that sets the green QPD offsets (/opt/rtcds/userapps/trunk/als/h1/scripts/setEndGreenQPDOffsets_XARM.py and setEndGreenQPDOffsets_YARM.py) -- check out LHO aLOG 51476 for further commentary.

This procedure needs to be modified because we are now setting green references with our spots centered on the optics.  We would like to center the IR on the IR QPDs once we have our spots in their final positions, however, not necessarily with the spots centered.

Since Craig added in the TMS servoing to center the IR QPD, we should still be able to follow this procedure at DC readout.  At DC readout, in the current situation, we are servoing the spots to the centers of all 4 test masses at 2W input power.  This is the position we want to set the initial alignment references to. 

Later in the acquisition sequence the power is increased to 10W, and then the beam spots are moved to their final high power positions, then we further increase the power and continue on to NomLowNoise.

Before setting the green camera references, we should remember to check that the camera image is good and that any mask applied is appropriate.  We can check this by opening up the digital camera screen and taking a snapshot, then finding the snapshot in /ligo/data/camera