Matt, Hang

We wrote some codes to optimize a2l coupling coeffecients. The script will measure omc dcpd's response to injected angular dither, and do a linear fit (for I and Q separately) of this response as a function of a2l gain. With a proper rotation of the I-Q plane s.t. the rotated Q' stays as a constant, the minimum of the response will be at the zero of the rotated I'. 

We ran the script for ITMX, ETMX, and ETMY. Results are shown in the attachments. The errorbars were underestimated because the raw data might be correlated if the sampling frequency was not low enough, thus we just plotted them as a reference but no minimization of chi-sq in the fit. 

Based on them, we did the following changes:

H1:SUS-ITMX_L2_DRIVEALIGN_P2L_GAIN: 2.300 -> 1.947
H1:SUS-ITMX_L2_DRIVEALIGN_Y2L_GAIN: 1.350 -> 0.632

H1:SUS-ETMX_L2_DRIVEALIGN_P2L_GAIN: 1.100 -> 0.927
H1:SUS-ETMX_L2_DRIVEALIGN_Y2L_GAIN: 1.370 -> 0.927

H1:SUS-ETMY_L2_DRIVEALIGN_P2L_GAIN: -0.200 -> 0.000
H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_GAIN: -0.600 -> -0.700

Rana, Evan

Yesterday, Rana made a low-pass filter in order to remove EX ESD saturations when ALS DIFF is used as a DARM sensor. However, today we continued to see some locklosses around the time that DARM is handed off from ALS DIFF to AS45Q.

Therefore, we looked at FM8 and FM10 in the DARM filter bank, which are low-pass filters used with DIFF only. We found that we could relax the amount of rolloff in order to win some phase at 10 Hz and below (see attached foton plot). There is not nearly as much suppression above 500 Hz, but it doesn't really matter since most of the rms drive to the EX ESD is accumulated below 100 Hz. The attached spectrum shows the EX UIM and ESD drives both before (blue) and after (red) retuning. There is no increase in the the rms drive to the ESD (part of this is also due to Rana's retuning of the UIM/ESD crossover).

Finally, the attached transfer function shows the ALS DIFF OLTF before (blue) and after (red) retuning. The "before" OLTF was taken yesterday and has 4 dB less gain than the red transfer function (because we added 4 dB of missing gain in the LSC-DARM violin bandstop filters).

Additionally, we switched FM1 and FM7 in LSC-DARM. FM7 was a boost that would cause the OMC transmission to flutter when first engaged. FM1 was the suspension compensation, and since it is always on there is no point in having it in such prime real estate. So we've switched them and updated the appropriate settings in the ISC_LOCK and ALS_DIFF guardians.

Guardian core upgraded again with additional patch to further address issues from last fix

Current version:

• guardian r1450

The previous upgrade to r1449 included a patch to throw errors if any other internal state inconsistencies (like that which caused the "double main()" bug) are detected.  The errors encountered since Friday are from failures of these internal consistency checks, apparently from situations not fully covered in the battery of unit tests. This patch covers those situations. I'm looking into improvements to the unit tests to cover more of the user phase space.

No nodes have been restarted.

the probability a freeze-up does not impact at lease one dolphined FE is very small, so I'm using the h1boot dolphin node manager's logs to data mine these events. The dolphin manager was restarted when h1boot was rebooted Tuesday 7th July, so data epochs at that time.

As I was seeing with my monitoring programs, the restarts preferentially happen in the 20-40 minute block within the hour. The first histogram is the number of events within the hour, divided into 10 minute blocks.

We are also seeing more events recently, the second histogram shows number of events per day. The spike on Tue 14th is most probably due to front end computer reboots during maintenance. Friday's increase is not so easily explained.

FE IOC freeze up time listing:

controls on h1boot

grep "not reachable by ethernet" /var/log/dis_networkmgr.log |awk '{print $2r, $4}'|awk 'BEGIN{FS=":"}{print $1":"$2}'|sort -u

total events 197

minutes within the hour, divided into 10 min blocks

00-09 11  :*****

10-19 11  :*****

20-29 67  :*********************************

30-39 79  :****************************************

40-49 17  :*********

50-59 12  :******

events per day in July (start tue 07)

wed 08 09 :*****

thu 09 09 :*****

fri 10 08 :****

sat 11 07 :****

sun 12 08 :****

mon 13 09 :*****

tue 14 22 :***********

wed 15 10 :*****

thu 16 20 :**********

fri 17 38 :*******************

sat 18 16 :********

Rana, Matt, Evan

Low-noise commissioning was derailed by various CARM-reduction locklosses:

• Locklosses at and around the transition of CARM from ALS to the arm transmission signals.
• Locklosses at and around the transition of DARM from DIFF to AS45Q. At the very least, Rana has removed the EX saturations that happen around this time. Unclear whether this will also stop the locklosses. Please make a note of any locklosses near this transition step.
• Locklosses at and around the transition of CARM from the arm transmission signals to the normalized PDH signal. Even for the successful transitions, there is significant instability and we seem to survive only because we have shortened as much as possible the amount of time spent in this state. Additionally, the successful transitions lead to resonance with good recycling gain (>37 W/W), indicating that this is not a sufficient condition for ensuring a stable transition.

We're having some mysterious lock losses as we move from large CARM offset to less large offset. With the DRMI locked, the ALS starts bringing the arms in and the ALS / IMC lose lock.

Suspecting the recent FSS tunings, we looked at the FSS screen. The FAST gain was down at +5 dB. Also, the EOM Drive readback was up at +3V. The attached plot shows the EOM readback (PC_MON) as the FAST gain is tuned.

I have left it at 22.2 dB, where the EOM drive is minimized. IN mid-April, there are a series of entries from Rick and Peter where the loop is tuned up, but the fast gain is turned down incrementally from 21 to 5 dB. Why so??

Also, it seems like we should aim for a ~250 kHz UGF for the FSS to avoid the peaking at 1.8 MHz where the notch is not getting all of the EOM resonance.

Cataloging the many ways in which we are breaking lock or failing to lock since Friday, we found this one:

Sitting quietly at 10W DC readout, there was a slow ring up of a pitch instability in several ASC signals. Perhaps its time we went back to seriously controlling the ASC in the hard/soft basis instead of the optic basis in which its currently done. The frequency is ~1 Hz and the time constant is ~1 min. It would be great if someone can look at the signs of the fluctuations in the OL and figure out if this was dHard or cHard or whatever.

The DAC for the BS M2 stage can put out 131000 counts, but the RMS is only 500 counts after transitioning into 'state 3' of the coil driver (Acq OFF, LP ON).

Seems like we're not in the best state here. We don't want to reduce the BS range for acquisition.

Should we be putting in an offset to avoid the DAC glitches or has this DAC been improved by some EEPROM upgrades?

Has anyone in DetChar seen BS DAC glitches from ER7?

Evan, Matt, Stefan

- Matt wrote a many - optic ASC relief function, which we added to the DRMI guardian. This saves us some time.

- for the rest we were chasing  random fast lock losses that hit us pretty much anywhere - Prep_TR_CARM, REFL_TRANS just sitting on resonance at low power, and sitting at high power.

- Evan started to systematically go through and check loop,gains.
- He found the digital REFL   CARM loop to be slightly low, increase Tr_REFLAIR_9 gain from -0.5 to -0.8
- ALS diff looked fine.

What I did
- Take a filter that ramps over 3sec (always on)
- edit the foton file top a 1 sec ramp
- start the ramp, but before it finishes - load the new filter.
- The filter module keeps ramping, and never finishes...

- I could reproduce this twice.
- I attached a snap of the still ramping FM1 on LSC-REFLBIAS.

- To fix it, I considered rebooting, but since the I suspected the problem to be a runaway counter, I simply added a filter with 600sec ramp time (long enough to catch the original filter ramp). 10min later (the time it took to write this log) it was fixed...

Evan, Rana, Stefan

After we mostly fixed the CARM_ON_TR lock losses we ran into the REAFL_TRANS ones. There is definitely a loop instability on TR_REFL_TRANS. Be sped up this transition which at least once seemed to help. However we also randomly lost lock at other places, and never made it to low noise. We'll have another systematic approach tomorrow.

Guardian core upgraded to fix "double main" execution bug.

I have just installed a new version of Guardian core:

guardian r1449

It address the "double main" execution bug that was been has been plaguing the system.  See guardian bug 879, ECR 1078.

The new version is in place, but none of the guardian nodes have been restarted yet to pull in the new version.

You can either manually restart the nodes with 'guardctrl restart', or just try rebooting the whole guardian machine.  I might start with the former, to just target the important lock acquisition nodes (ISC_LOCK, etc.), and wait until Tuesday maintenance for a full restart of the Guardian system.