In our many locks and relocks tonight we have worked out the bugs in the OMC guardian's locking sequence. This process has succeeded several times now and is integrated with the overall ISC_LOCK guardian.
The steps taken by the guardian are the following:
- Engage the OMC QPD alignment loops
- Sweep the cavity with the PZT while recording the DCPD sum (see attached figure), identify the 45MHz sideband peaks, find the carrier peak in the middle, and jump to the PZT voltage. THIS NEVER WORKS EXACTLY, and it's not clear why. (PZT hysteresis?) The guess is always wrong in the same direction, so the code steps slowly downwards until it reaches a resonance.
- Turn on the OMC LSC servo
- Collect ten seconds of OMC-DCPD_SUM and LSC-DARM_IN1 data and calclate the transfer function. Change the OMC-READOUT_SCALE factor and LSC-OMC_DC_OFFSET so that the DCPD input to the LSC matrix matches the current DARM_IN1. (This step allows you to change power settings and the DARM offset without having to retune the scale factor and offset every time.)
The whole thing takes about two minutes. There are ways to make it faster (Stefan suggested locking on a sideband earlier in the acquisition process and jumping to the carrier later on) and more robust (applying some more intelligent peak-finding will be necessary once we go to higher power), but for the near future this seems like a good, hands-free solution.
There's one failure mode which is likely to be encountered not infrequently: if the ETM roll mode is run up (or other modes, but that one is the most problematic) then the DCPDs will saturate and the OMC won't lock. In this case the guardian will fail to read READY_FOR_HANDOFF and the ISC_LOCK guardian will not transition to DC readout. If this happens you can damp the mode and then rerun the OMC guardian to get to low noise.
