Last night, we put the IFO in FP Michelson configuration. We took transfer functions of CARM and DARM, first using CM excitations directly on the ETMs, and then using modulations of the laser frequency via MC excitation. We found that there was basically no coupling into DARM using the MC excitation, but that there was coherence in DARM using the ETM excitation. Therefore, I tuned the ETM common mode in the output matrix. I did this by taking transfer functions of PD1_Q with PD2_I (see attached plot). I changed the drdown_bang script to set C1:LSC-BTMTRX_14 0.98 and C1:LSC-BTMTRX_24 1.02.
I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise. There are transfer functions for multiple CARM offsets. Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere. POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer. We should look into switching back to REFL-DC.
Here are the corresponding transfer functions for REFL-DC.
I hereby award the previous rainbow transfer functions the plot innovation of the month award for its use of optical frequency to denote CARM offset.
The attached movie here shows the sensing matrix (minus MICH) as a function of CARM offset. There are 3 CARM signals plotted:
GREEN - tonights starting CARM signal - REFL_DC
RED - my favorite CARM signal - REFL 166 I
CYAN - runner up CARM signal - POX 33 I
We installed the watchLockLoss script in scripts/AutoDTT/. This script monitors arm power and uses command line
DTT to save 5 s snapshot of the interferometer when it senses loss of lock. We ran it on linux and it seemed to
save an xml file about half the time; we'll try it on solaris.
I managed to get up to arm power of about 20 a couple of times. IFO lost lock a couple of times after turning
off moving zero. MC2 would often get tripped by lock loss and need resetting. Maybe we will try to stiffen the
Plotted assuming the average arm power goes up to ~80. No DARM offset.
To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.
For POX33, the ideal phase for single arm locking does not yield a zero-offset CARM signal. So the offset needs to be manipulated digitally.
With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring. This is why we have a link between the DARM and CARM optical springs.
For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.
I've plotted TRX, TRY, PD12I and PD11Q. Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.
I should have mentioned that the AS port camera image seems to get progressively uglier over the course of these locks. Maybe we can use the JoeCam to make a movie of it.
locks last for about an hour. this was true last night as well (see "arm power curve" entries). the second lock shown here evolves differently for unknown reasons. the jumps in the arm powers of the first lock are due to turning on DC readout. length-to-angle needs tuning.
attached plot shows MC_IN1/MC_IN2. needs work.
This is supposed to be a measurement of the relative gain of the MCL and AO paths in the CM servo. We expect there to
be a more steep slope (ideally 1/f). Somehow the magnitude is very shallow and so the crossover is not stable. Possible
causes? Saturations in the measurement, broken whitening filters, extremely bad delay in the digital system? needs work.
the align script was run after the third lock here. it would have been interesting to see the arm powers in a 4th lock
It seems that the MC3 problem is intermittent (one-day trend attached). I tried to take advantage of a "clean MC3" night, but the watch script would usually fail at the transition to DC CARM and DARM. It got past this twice and then failed later, during powering up. I need to check the handoff.
Recently the watch script was having difficulty grabbing a lock for more than a few seconds. Rob discovered that the violin notch filters which were activated in the script were causing the instability. We're not sure why yet. The script seems significantly more stable with that step commented out.
We worked on tuning the DD handoff tonight. We checked the DD PD alignments and they looked fine. First I tuned the 3 demod phases to minimize offsets. Then I noticed that the post-handoff MICH xfer function needed an increase in gain to look like the pre-handoff xfer function (which has a UGF of about 25 Hz). I increased the MICH PD9_Q gain from 2 to 7 in the input matrix. But, the handoff to PRC still failed, so tomorrow we will try to find out why.
In the plot, ref0 is before MICH handoff, and ref1 is after MICH handoff. There is also a PRC trace (before PRC handooff).
Rana, Alberto, Pete
We have the DD handoff nominally working. Sometimes, increasing the SRC gain at the end makes MICH get unstable. This could be due to a non-diagonal term in the matrix, or possibly because the DRM locks in a funky mode sometimes.
To get the DD handoff working, first we tuned demod phases in order to zero the offsets in the PD signals handed-off-to. Based on transer function measurements, I set the PRC PD6_I element to 0.1, and set the PD8_I signal to 0, since it didn't seem to be contributing much. We also commented out the MICH gain increase at the end of the DD_handoff script.
It could still be more stable, but it seems to work most of the time.
I played with the DD handoff during the day. The DRM dark port was flickering like a candle flame in Dracula's castle. The demod offsets for the handoff signals looked fine. After MICH handoff, the MICH_CTRL started to get unstable at some low frequency, maybe 3 Hz (I didn't measure). So I increased the MICH gain from 0.1 to 0.17 and it settled down. PRC and SRC went fine. Then the DD_handoff script raised the MICH gain to 0.7, and an instability started to grow in MICH_CTRL (at some higher frequency). I decreased the MICH gain from 0.7 to 0.5, and it settled down and stayed stable.
We were stymied early in the evening by a surreptitiously placed, verbo-visually obfuscated command in the drstep script.
tdsavg 5 C1:LSC-PD4_DC_IN1
was causing grievous woe in the cm_step script. It turned out to fail intermittently at the command line, as did other LSC channels. (But non-LSC channels seem to be OK.) So we power cycled c1lsc (we couldn't ssh).
Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen). We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2. The timing fields went back to 0. But the tdsavg command still intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".
The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.
Let us know if you know how to fix this.
Did you try restarting the framebuilder?
What you type is in bold:
op440m> telnet fb40m 8087