PSL frequency noise is better than indicated in DBB (diagnostic breadboard) scans.

JasonO et al. have been running weekly DBB scans  (see this link) that indicate that the PSL frequency noise is well above requirements.

However, spectra of MC_F, the IMC control signal that drives the VCO indicate that the frequency noise is much better than what is reported by the DBB.

Attached below is a recent DBB report and spectra of MC_F taken during a recent full interferometer lock.

I took a look at the ISS this morning and found the dfifracted power up around ~11% + with a ref signal of ~ -1.8. It's been adjusted to ~ 7% at a refsignal of -2.02. Also, FSS TPD[V] are down to 1.4 from 1.6. There maybe the need for incursion on maintenance day to do touch ups and discovery.

[Evan, Koji]

M7.5 - 55km SE of Kokopo, Papua New Guinea 2015-03-29 23:48:31 (UTC)

The EQ knocked off most of the HEPI/ISI/SUSs. The ground motion calmed down after a couple of hours.

The WDs were reset.

Current status:

- All of the HEPIs are in the "ROBUST_ISOLATED" mode.

- All of the HAM ISIs are in the "ISOLATED" mode.
  All of the BSC ISIs except for the BS ISI are in the "FULLY-ISOLATED" mode.
  BS-ISI is in the "ISOLATED_DAMPED" mode. (As it was like this, I left it so. If it is necessary to go to "ISOLATED", please do so.)

- All SUSs except for PRM and SRM are in the "ALIGNED" mode.
  PRM and SRM are in the "MISALIGNED" mode.
  WDs of the TTs were restored too.

An attempt to measure the amount of misalignment that is currently present  in the PSL-to-IMC coupling.

First I centered the direct reflection from the IMC onto the WFS A and WFS B sensors.  There was about 30% reduction in the RIN.  See attached png and xml files: IMC_jitter_centering.*

Next, I  injected an excitation in to the PSL_PZT pitch and yaw  at 7.33 Hz .  I then took a PSD of the IM4_TRANS_SUM signal to measure the power fluctuations in at 7.33 Hz and 14.66 Hz (P1f and P2f) respectively. 

Attached files show these peaks in the IM4_TRANS_SUM spectra.  Attached also are the xml files which have the data and an excel file which has the computation of the amount of misalignment.

In summary: 

       1)  Pitch misalignment is 0.6% of the IMC cavity beam divergence

       2) Yaw misaligment is 1.2% of the IMC cavity beam divergence.

An attempt to see how the misalignment could have arisen:

I  tried to vary several offsets to see whether this coupling from jitter to RIN could be changed.  The ones I tried are

a) Common mode offset in the MC servo board: To see if a length offset is causing this H1:IMC-REFL_SERVO_COMOFS

b) Slow offset in the MC servo board H1:IMC-REFL_SERVO_SLOWOFS

c) Slow out offset in the MC servo board H1:IMC-REFL_SERVO_SLOWOUTOFS

d) DOF1 to DOF3 offsets in both both pitch and yaw in the MC WFS servo loops.

None of these by themselves had a significant impact on the jitter to RIN coupling.  More investigation required.

And now for those nay sayers :-)  Things I did not do!! 

1)  I returned all offsets to where they were.

2) The MC2 spot is centered and the IM4_TRANS spot has not moved from before to after my WFS centering => output beam has not shifted

3) The WFS outputs were not off loaded: the IMC alignment slider values have remained the same

4) No other Pico motors other than that of IMC WFS A and IMC WFS B were touched.

So in essence if something broke, its not coz of me!!  :-p

(The log is messing up with me and my entry from last night got deleted this morning when I tried to add a plot - new failure mode for me)

Commissioning Team 

Sensitivity status

We achieved  36 Mpc  on Friday, improving the sensitivity over the previous day by: 
Adding cut-offs in the ASC DHARD dofs
Switching off completely the ETMX ESD driver after switching to the low noise ESD on ETMY
Adding MICH and SRCL feed-forward subtraction (still not optimal, but somewhat effective, see  Evan's entry 
We had one single lock lasting for about 2h, while making measurements/tests, so data are not clean (see range summary). We collected only a few minutes of clean data (March 27, 23:50-23:55 UTC, if I remember correctly - Evan please check this). The second plot shows the progression of sensitivity this week, starting from 16 Mpc (not shown in this plot), to the red curve from last night. 

We noticed that the high frequency part of the sensitivity is slightly worse than the previous day, without any apparent reasons beside different initial alignment. 

Also, we learned a few things about data quality based on the analysis of the long lock from the night before. Sheila and Kiwamu tracked down the  ISS glitching problem , which is now fixed (not permanently - need some automatic way of keeping the ISS happy). Also, Josh et al. pointed out that the long lock the other night showed  ETMY L3 DAC glitches , and this needs to be fixed. This adds to the already reported  whistles , that also need attention.


Other news

Daniel and Evan attempted to make the ETMX ESD driver remotely switchable in the afternoon, but this first attempt failed (not a big deal yesterday as we had only one long lock)
On a positive side, adding a digital limiter to the ESD correction signal seems to have solved the problem with the EY ESD driver switching off after each unlock (see   this entry and comments  


Problems in the evening

The last thing we wanted to get done on Friday to conclude this great week was to close the beam diverters on the transmon. At the same time, some of the low noise steps done outside the Guardian (like the BS M2 coil driver switch to low noise) were added to the Guardian code. These two (apparently innocent) goals created a couple of unexpected problems (see  entry 17547  and  entry 17548 ), but I believe at this point Sheila and Jamie fixed both. Also, the wind started blowing hard right after dinner (see  Dan and Evan's entry ). 

For the records, the prophetic words of wisdom that Daniel told us right after the 36 Mpc lock were: "Go home, it can only go down-hill from here". 

On my drive in I saw a kiddie pool flying across Jadwin Ave, so I knew it would be a good day to work on ALS.  The gusts today are up to 45- 50 mph; I can hear the building shake when one hits. While the changes I've made so far aren't enough to lock the IFO under these conditions, there is a lot of progress.

• I've switched back to using the IMC VCO to drive the fiber AOM. 
• Comon tidal feedback is disabled for now (the UGF is set to 0 Hz). This is not needed with the omc vco driving the fiber aom, at least not for locks of tens of minutes
• We are now locking ALS COMM first then DIFF, instead of doing them in parallel as we have been.  Locking ALS COMM was not a problem today once first two things were done, but DIFF locking was trickier since the PLL was not staying in range for verry long at all.  With the IMC VCO driving the fiber AOM, locking COMM means that at low frequecies the Y arm is following the X arm because of tidal.  (COMM means that the IMC VCO follows the X arm, using the IMC VCO to drive the fiber AOM means that with Y arm tidal running the Y arm follows the  X arm.)  Once COMM is locked like this the DIFF PLL stays in range long enough to grab a lock with DIFF.  
• I increased the bandwidth of the X arm  green WFS DOF1 P (to the ETM), the gain changed from -0.003 to -0.01.  This goes unstable with a gain of -0.02, but we could think about adding the PUM to increase the bandwith so that we can supress the motion at the 0.45 sus resonance.  The higher gain is OK when using all the X arm green WFS loops, so I've left it in.  
• With the higher bandwidth ETM WFS and the pitch oplev damping engaged (gain -4500, described in alog 16968), we can keep ALS locked for about 10 minutes although the noise is clearly quite high.  

One more thing, this morning I opened the X end beam divereter and re did the inital alignment.   Now both beam divereters are open. The inital alingment has it's own problems when the wind is this high. 

The problem experienced yesterday in the ISC_LOCK guardian was caused by an errant instantiation of an ezca object in the main importable part of the bs_m2_switch.py module.  This extra ezca instance created a separate EPICS interface that interfered with the one provided by guardian.  Avoid doing this, since, as was shown, it causes problems.

It's understandable why one would think this is necessary, though, because of the somewhat obscure way that guardian provides the ezca interface to the usercode.  Guardian puts a special ezca instance into the main "built-in" namespace which makes it universaly available to all usercode.  When writing usercode modules, though, it's unclear how to emulate this for the purposes of testing, or to make a module usable in other contexts.

I've added the following code to the bottom of the bs_m2_switch.py module.  This makes the module directly executable from the command line, outside of the context of guardian.  The "__name__ == '__main__'" conditional defines code that will only be executed when the code is directly executed, rather than imported by something else.  It then instantiates an ezca object into the "__builtin__" namespace in a way that mimics what guardian does.  The primary function defined in the module (m2_switch()) is then callable in the same way it would be in guardian:

if __name__ == '__main__':
    import __builtin__
    from ezca import Ezca
    __builtin__.ezca = Ezca()
    m2_switch()

This should be considered as a prototype for all other similar modules that people want to be executable outside of guardian.

In general, though, I would encourage programers to make states dedicated to the execution of this kind of logic, which can then executed on their own via e.g.:

  guardian ISC_LOCK BS_M2_SWITCH

model restarts logged for Fri 27/Mar/2015
2015_03_27 13:26 h1fw1

one unexpected restart.

Commissioning Team

We will write a more meaningful entry later, but here is a list of things we did/tried this afternoon, so we don't forget:

• Added cut-offs on ASC DHARD (made the noise better < 20 Hz)
• Completely switched off ESD driver on ETMX after lock acquisition (some small improvement seen around 50 Hz)
• Attempt to make the ESD driver remotely switchable (failed)
• MICH subtraction (it turned out that previously we were actuating not only on L2 as we thought, but on M0 as well)
• SRCL subtraction  (~ 3 reduction in SRCL coupling around 40 Hz)
• Charge measurement
• Low noise MCs SUS (implemented, but not tested yet; we still haven't tried again to switch the SRM to low noise (it unlocked the other day)
• Closing end beam diverters (still work in progress, attempt from full lock failed)

We collected a ~ 2h lock with range around 36 Mpc (not clean data).

J. Kissel, J. Warner, J. Romie, H. Radkins, N. Kijbunchoo, K. Izumi, G. Moreno

SUMMARY: We just finished ~7 HOUR lock stretch at our best sensitivity ever, between 32 and 34 [Mpc]!

We've all been pleasantly surprised this morning to see that the lock stretch that Sheila Evan, Dan and Lisa started last night lasted the entire night. Unfortunately, as of ~10 minutes ago (~8:40a PDT, ~15:40 UTC), there are GIANT glitches and non-stationarity that keep popping up, spoiling the sensitivity. There's no one in the LVEA, so we're not at all sure what's caused the sudden change in behaviour. Wind seems fine at ~5 [mph], ground motion is still pretty low, the 1-3 [Hz] hasn't even come up yet.

Anxious to explore things, Jim installed some low-pass filters in the HAM5 and HAM6 ISIs at around 8:45 to try to reduce scattering / acoustic coupling to the ISI, and Kiwamu began exploring MICH coupling to DARM. 

But, as I write this log, we lost lock. However, for DetChar purposes, one can assume the detector was undisturbed from March 27 9:00 UTC to March 27 ~15:00 UTC.

The whistles in DARM are still quite prominent in this lock. As briefly summarized in this alog, they happen whenever the PSL VCO frequency crosses 79.2 MHz. This points to the likely cause. This is a reliable enough indicator that we can get some statistics. In the first hour of the current lock (Mar 27 9 UTC to 10 UTC), the whistles happen at a rate of 4 per minute.

Below are four spectrograms. The first two show some whistles identified this way. A new feature is that there seems to be a second oscillator very close by, or maybe some harmonic of the beat note. The next two spectrograms show a minute with several whistles, and the next minute where none occurred. Even when none go through zero frequency, you can still see the beat note hovering up near Nyquist.

Dan, Sheila

The attached screenshot shows a one second trend of the beckhoff channel that is the fast shutter trigger readback, along with two RCG channels, the first is AS_C sum, this PD should be the source for the fast shutter trigger, and ASAIR_LF,  which should see similar power fluctuations.  

The beckhoff channel seems to be 0.2 seconds ahead of the RCG channels.  This timing difference sometimes makes it appear as though the fastshutter shut first, causing the lockloss, as in the second attached screenshot. 

We would like to prove definteively that the shutter is only shutting when it should, but we don't have a readback that we trust.