Reports until 12:25, Sunday 31 May 2015
H1 ISC
daniel.hoak@LIGO.ORG - posted 12:25, Sunday 31 May 2015 (18734)
OMC alignment dither (again), DARM offset

Tonight I worked on (re)commissioning the OMC alignment dither and measuring the AS power as a function of DARM offset.

 

OMC Alignment Dither

Since (re)commissioning the OMC ASC dither last month, the yaw loop had become unstable.  In case this becomes a persistent problem, I've written a script that will measure the dither sensing matrix, invert, and loads the resulting control matrix into the appropriate fields in the DACTMAT matrix.  (Not sure what DACTMAT means...I would have called it DITHER2DOF.)  The script is here (I have committed it to the svn):

~userapps/release/omc/common/scripts/ditherDCsense.py

The script inserts DC offsets into the OMC ASC loops and measures the response in the dither error signals.  It's gentle enough that it can be run in DC readout without breaking the lock.  Using the script I recalculated the dither control matrix and turned the dither loops back on; a screenshot of the new control matrix is attached.  They work, but I recommend very low gain - 0.05 on the OMC ASC master slider.  This reduces the UGF of the loops enough that noise is not being injected into the OMC alignment; with the gain too high there is clear scattering noise at low frequencies.  Enabling the dither gave the range a 1-2Mpc boost.  For now this is not in the Guardian, but we should start using the dither alignment.

If you use the script, keep an eye on the OMC SUS and make sure the offsets to the ASC loops don't saturate the drive.  If this happens your matrix will have a problem and you will not go to dither today.

Interestingly, the optimal alignment on the QPDs is different in the 2.3W and 23W states.  Is this due to some junk light in the DRMI?  For now I have left the QPD offsets to have the optimal low-power alignment, assuming that the dither will be engaged later on.  At high power the dither alignment pushes the OMC in pitch such that the outputs to the DAC are ~90k counts.  This seems like a lot to me, and we can't offload the drive anywhere, except perhaps some pico-motoring on the AS WFS to make the tip-tilts point the beam at a charitable angle.  We need to work out a HAM6 centering scheme that doesn't use the OMC SUS.

 

DARM Offset Scan

With the alignment into the OMC optimized I scanned the DARM offset at 2.3W input power and measured the DCPD Sum.  Plot attached; the curve is very well fit by a quadratic with a small static offset from the origin, about the same magnitude that Stefan, Keita and I observed two weeks ago - a few tenths of a picometer.  So, no surprises.  Note, the data points in the plot have error bars representing the 1-sigma statistical noise in the measurement, but they are too small to see.

In the second plot attached I have scaled the data to 125W input power, to make a comparison with Fig. 7 of the LSC design document (T1000298).  From this simple scaling it looks as though the DARM resonance we observe is much narrower than in T1000298...but I think I'm forgetting what parameters are assumed in Fig 7.  There was an error in my plotting - the data are a reasonable match to Fig 7 if a factor of 125/1.84 is applied to the DCPDSum, where 1.84 is the power incident on the PRM with 2.3W into the IMC.  (Note on this log-scale plot you can see the slight assymmetry in the data points, indicating a static DARM offset.)  Our standard low-noise, high-power configuration is 23W, and an offset of 1e-5 counts, which we think is 14pm.  With these settings we get ~18mA in DCPD Sum.

 

Other Notes

Tonight I've been increasing the ETMX roll mode damping gain to 200.  Also I've been engaging the DHARD rolloff filter (:12^2), this seems to improve the noise around 20Hz.

There is a very narrow line at exactly 3801Hz that I haven't seen before.  There's no sign of aliasing - the high-frequency features in DARM, as measured by the 64kHz DCPD channels from the DAC, have not changed dramatically.  The line has been slowly growing all night.  This could be an 8th harmonic violin mode of ETMY, although the exact integer frequency is a little suspicious.  I have added another notch to the ETMY_L3_LOCK filter bank, vStop8+9, but I have not turned it on.

Images attached to this report
Non-image files attached to this report