[ericq, lydia, steve, gautam]

• We aligned the arms, and centered the in-air AS beam onto the PDs and camera
• Misaligned the ITMs in a controlled ramp, observed ASDC level, didn't see any strange features
• We can misalign the ITMs by +/- 100urad in yaw and not see any change in the ASDC level (i.e. no clipping). We think this is reasonable and it is unlikely that we will have to deal with such large misalignments. We also scanned a much larger range of ITM misalignments (approximately +/-1mrad), and saw no strange features in the ASDC levels as was noted in this elog - we used both the signal from the AS110 PD which had better SNR and also the AS55 PD. We take this to be a good sign, and will conduct further diagnostics once we are back at high power.
• Opened up all light doors, checked centering on all 6 OM mirrors again, these were deemed to be satisfactory 
• To solve the green scattering issue, we installed a 1in wide glass piece (~7inches tall) mounted on the edge of the OMC table to catch the reflection off the window (see Attachment #1) - this catches most of the ghost beams on the PSL table, there is one that remains directly above the beam which originates at the periscope in the BS/PRM chamber (see Attachment #2) but we decided to deal with this ghost on the PSL table rather than fiddle around in the vacuum and possibly make something else worse
  Link to IMG_2332.JPG
  Link to IMG_2364.JPG
• Re-aligned arms, ran the dither, and then aligned the PRM and SRM - we saw nice round DRMI flashes on the cameras
• Took lots of pictures in the chamber, put heavy doors back on. Test mass Oplev spots looked reasonably well centered, I re-centerd PRM and SRM spots in their aligned states, and then misaligned both
• The window from the OMC chamber to the AS table looked clean enough to not warrant a cleaning..
• PSL shutter is closed for now. I will check beam alignment, center Oplevs, and realign the green in the evening. Plan is to pump down first thing tomorrow morning

AS beam on OM1

Link to IMG_2337.JPG

AS beam on OM2

I didn't manage to get a picture of the beam on OM5 because it is difficult to hold a card in front of it and simultaneously take a photo, but I did verify the centering...

It remains to update the CAD diagram to reflect the new AS beam path - there are also a number of optics/other in-vacuum pieces I noticed in the BS/PRM and OMC chambers which are not in the drawings, but I should have enough photos handy to fix this.  

Here is the link to the Picasa album with a bunch of photos from the OMC, BS/PRM and ITMY chambers prior to putting the heavy doors back on...

SRM satellite box has been removed for diagnostics by Rana. I centered the SRM Oplev prior to removing this, and I also turned off the watchdog and set the OSEM bias voltages to 0 before pulling the box out (the PIT and YAW bias values in the save files were accurate). Other Oplevs were centered after dither-aligning the arms (see Attachment #8, ignore SRM). Green was aligned to the arms in order to maximize green transmission (GTRX ~0.45, GTRY ~0.5, but transmission isn't centered on cameras).

I don't think I have missed out on any further checks, so unless anyone thinks otherwise, I think we are ready for Steve to start the pumpdown tomorrow morning.

These old specs are not so bad. But we now want to get replacements for the TRX and TRY and PSL viewports that are R <0.1% at 532 and 1064 nm.

I don't know of any issues with keeping BK-7 as the substrate.

We wanted to re-activate the Heater for the reference cavity today to use it as a testbed for PID autotuning and the new heater driver circuit that Andrew is working on for the coating thermal noise experiment.

Unfortunately, it seems that the large power supply which is used for the heater is dead. Or maybe I don't remember how to use it?

The AC power cord was plugged in to a power strip which seems to work for IO chassis. We also tried swapping power strip ports.

We checked the front panel fuses. The power one was 3 Ohms and the 'bias' one was 55 Ohms. We also checked that the EPICS slider did, in fact, make voltage changes at the bias control input.

Non of the front panel lights come on, but I also don't remember if that is normal.

Have those lights been dead a long time? We also reconnected the heater cable at the reference cavity side.

Pumping again after 7 days at atmosphere.

BS, ITMY and OMC chambers were open only.

Checked: jam nuts, viewport covers and beam shutters.

Oplev servo turned off and medm screens shots taken.

New item in vacuum:  green shade 14 glass beam block at IR-input [ from the PSL ] viewport to block green reflection-scatter.

Reminder: viewport is not AR coated for green!

IFO pressure 1.7E-4 Torr on new not logged cold cathode gauge. P1 <7E-4 Torr

Valve configuration: vac.normal with anunulossess closed off.

TP3 was turned off with a failing drypump. It will be replaced tomorrow.

The pressure on the newly installed gauge on the X arm was 6E-5 torr when I came in today evening, so I decided to start the recovery process.

1. I first tried working at low power. I was able to lock the IMC as well as the arms. But the dither alignment didn't work so well. So I decided to go to nominal PSL power.
2. I first changed the 2" HR mirror that is used to send all the MC REFL light to the MC REFL PD in low power operation with a 10% BS. I then roughly aligned the beam onto the PD using the tiny steering mirror. At this point, I also re-installed the ND filters on the end Transmon QPDs and also the CCD at the Y end.
3. I then rotated the waveplate (the second one from the PSL aperture) until I maximized the power as measured just before the PSL shutter with a power meter. I then re-aligned the PMC to maximize transmission. After both these steps, we currently have 1.09W of IR light going into the IMC
4. I then re-aligned MC REFL onto the PD (~90mW of light comes through to the PD) and maximized the DC output using an oscilloscope. I then reverted the Autolocker to the nominal version from the low power variant that has been running on megatron during the vent (although we never really used it). The autolocker worked well and I was able to lock the IMC without much trouble. I tweaked the alignment sliders for the IMC optics, but wasn't able to improve the transmission much. It is ~14600 cts right now, which is normal I think
5. I then centered the beams onto the WFS QPDs, ran the WFSoffsets script after turning the inputs to the WFS servos off, and ran the relief script as well - I didn't try anything further with the IMC
6. I then tried to lock the arms - I first used the green to align the test-masses. Once I was able to lock to a green 00-mode, I saw strong IR flashes and so I was able to lock the Y arm. I then ran the dither. Next, I did the same for the X arm. Even though I ran LSCoffsets before beginning work tonight, the Y arm transmission after maximization is ~5, and that for the X arm is ~2.5. I refrained from running the normalization scripts in case I am missing something here, but the mode itself is clearly visible on the cameras and is a 00-mode.
   GV edit 21Oct2016: For the Y-arm, the discrepancy was down to TRY being derived from the high gain PD as opposed to the QPD. Switching these and running the dither, TRY now maxes out at around 1.0. For TRX, the problem was that I did not install one of the ND filters - so the total ND was 1.2 rather than 1.6, which is what we were operating at and which is the ND on TRY. Both arms now have transmission ~1 after maximizing with the dither alignment...
7. The AS spot looks nice and round on the camera, although the real check would be to do the sort of scan Yutaro and Koji did, and monitor the ASDC levels. I am leaving this task for tomorrow, along with checking the recycling cavities.
8. Lastly, I centered the Oplevs for all the TMs

Dry pump of TP3 replaced after 9.5 months of operation.[ 45 mTorr d3 ]

The annulosses are pumped.

Valve configuration: vac normal, IFO pressure 4.5E-5 Torr [1.6E-5 Torr d3 ] on new ITcc gauge, RGA is not installed yet.

Note how fast the pressure is dropping when the vent is short.

All time stamps are blank on the MEDM screens.

I worked on recovering ALS today. Alignments had drifted sufficiently that I had to to the alignment on the PSL table onto the green beat PDs for both arms. As things stand, both green (and IR) beats have been acquired, and the noise performance looks satisfactory (see Attachment #1), except that the X beat noise above 100Hz looks slightly high. I measured the OLTF of the X end green PDH loop (after having maximized the arm transmission, dither alignment etc, measurement done at error point with an excitation amplitude of 25mV), and adjusted the gain such that the UGF is ~10kHz (see Attachment #2).

[ericq,gautam]

Given that most of the post vent recovery tasks were done, and that the ALS noise performance looked good enough to try locking, we decided to try PRFPMI locking again last night. Here are the details:

PRM alignment, PRMI locking

• We started by trying to find the REFL beam on the camera, the alignment biases for the 'correct' PRM alignment has changed after the vent
• After aligning, the Oplev was way off center so that was fixed. We also had to re-center the ITMX oplev after a few failed locking attempts
• The REFL beam was centered on all the RFPDs on the ASDC table

Post the most recent vent, where we bypass the OMC altogether, we have a lot more light now at the AS port. It has not yet been quantified how much more, but from the changes that had to be made to the loop gain for a stable loop, we estimate we have 2-3 times more power at the AS port now.

PRFPMI locking

• We spent a while unsuccessfully trying to get the PRMI locked and reduce the carm offset on ALS control to bring the arms into the 'buzzing' state - the reason was that we forgot that it was established a couple of weeks ago that REFL165 had better MICH SNR. Once this change was made, we were readily able to reduce the carm offset to 0
• Then we spent a few attempts trying to do blend in RF control - as mentioned in the above referenced elog, the point of failure always was trying to turn on the integrator in the CARM B path. We felt that the appearance of the CARM B IN1 signal on dataviewer was not what we are used to seeing but were unable to figure out why (as it turns out, we were locking CARM on POY11 and not REFL11 , more on this later)
• Eric found that switching the sign of the CARM B gain was the solution - we spent some time puzzling over why this should have changed, and hypothesized that perhaps we are now overcoupled, but it is more likely that this was because of the error signal mix up mentioned above...
• We also found the DC coupling of the ITM Oplev loops to be not so reliable - perhaps this has to do with the wonky ITMY UL OSEM, more on this later. We usually turn the DC coupling on after dither aligning the arms, and in the past, it has been helpful. But we had more success last night with the DC coupling turned off rather than on.
• Once the sign flip was figured out, we were repeatedly able to achieve locks with CARM partially on RF - we got through about 3 or 4, each was stable for just tens of seconds though. Also, we only progressed to RF on CARM on 1 attempt, the lock lasted for just a few seconds
• Unfortunately, the mode cleaner decided to act up just about after we figured all this out, and it was pushing 4am so we decided to give up for the night.
• The arm transmissions hit 300! We had run the transmission normalization scripts just before starting the lock so this number should be reliable (compare to ~130 in October last year). The corresponding PRG is about 16.2, which according to my Finesse models suggest we are still undercoupled, but are close to critical coupling (this needs a bit more investigation, supporting plots to follow). => Average arm loss is ~150ppm! So looks like we did some good with the vent, although of course an independent arm loss measurement has to be done...
• Lockloss plot for one of the locks is Attachment #1

Other remarks:

• Attachment #2 shows that the ITMY UL coil is glitchy (while the others are not). At some point last night, we turned off this sensor input to the damping servos, but for the actual locks, we turned it back on. I will do a Satellite box swap to see if this is a Sat. Box problem (which I suspect it is, the bad Sat. Boxes are piling up...)
• Just now, eric was showing me the CM board setup in the LSC rack, because for the next lock attempts, we want to measure the CARM loop - but we found that the input to the CM board was POY and not REFL! This probably explains the sign flip mentioned above. The mix-up has been rectified
• The MICH dither align doesn't seem to be working too well - possibly due to the fact that we have a lot more ASDC light now, this has to be investigated. But last night, we manually tweaked the BS alignment to make the dark port dark, and it seemed to work okay, although each time we aligned the PRMI on carrier, then went back to put the arms on ALS, and came back to PRMI, we would see some yaw misalignment in the AS beam...
• I believe the SRM sat. box is still being looked at by Ben so it has not been reinstalled...
• Eric has put together a configure script for the PRFPMI configuration which I have added to the IFO configure MEDM screen for convenience
• For some reason, the appropriate whitening gain for POX11 and the XARM loop gain to get the XARM to lock has changed - the appropriate settings now are +30dB and 0.03 respectively. These have not been updated in some scripts, so for example, when the watch script resets the IFO configuration, it doesn't revert to these values. Just something to keep in mind for now...

Great to hear that we have the PRG of ~16 now!

Is this 150ppm an avg loss per mirror, or per arm?

[Gautam, Johannes]

The autolocker was acting up today, Gautam traced it to EPICS channels ( namely C1:IOO-MC_LOCK_ENABLE and C1:IOO-MC_AUTOLOCK_BEAT ) served by c1iool0 not being responsive and keyed the crate. This restored it nominal operation.

We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

I realized that I did not have a Finesse model to reflect the current situation of flipped folding mirrors (I've been looking at 'ideal' RC cavity lengths with folding mirrors oriented with HR side inside the cavity so we didn't have to worry about the substrate/AR surface losses), and it took me a while to put together a model for the current configuration. Of course this calculation does not need a Finesse model but I thought it would be useful nevertheless. 

In summary - the model with which the attached plot was generated assumes the following:

• Arm lengths of 37.79m, given our recent modification of the Y arm length
• RC lengths are all taken from here, I have modelled the RC folding mirrors as flipped with the substrate and AR surface losses taken from the spec sheet
• The X axis is the average arm loss - i.e. (L_ITMX+L_ITMY+L_ETMX+L_ETMY)/2. In the model, I have distributed the loss equally between the ITMs and ETMs.

This calculation agrees well with the analytic results Yutaro computed here - the slight difference is possibly due to assuming different losses in the RC folding mirrors. 

The conclusion from this study seems to be that the arm loss is now in the 100-150ppm range (so each mirror has 50-75ppm loss). But these numbers are only so reliable, we need an independent loss measurement to verify. In fact, during last night's locking efforts, the arm transmission sometimes touched 400 (=> PRG ~22), which according to these plots suggest total arm losses of ~50ppm, which would mean each mirror has only 25ppm loss, which seems a bit hard to believe.

It is also difficult to have a high arm transmission without having high PRG.

What about to plot the arm trans and the REFL DC power in a timeseries?
Or even in a correlation plot (X: Arm Trans or PRG vs Y: REFL Reflectivity)

This tells you an approximate location of the critical coupling, and allows you to calibrate the PRG, hopefully.

As Gautam mentioned, we had some success locking the PRFPMI last night. (SRM satellite box is still in surgery...)

Unsurprisingly, changing the loss/PRG/CARM finesse means we had to fiddle with the common mode servo parameters a little bit to get things to work. However, before too long, we achieved a first lock on the order of a few minutes. Not long afterwards, we had a nice half hour lock stretch where we could tune up the AO crossover and loop UGFs. The working locking script was committed to SVN. Really, no fundamentally new tactics were used, which is encouraging. (One thing I wondered about was whether a narrower CARM linewidth would still let our direct ALS->REFL11 handoff with no offset reduction work. Turns out it does)

However, the step where we increase the analog CARM gain isn't as bulletproof as it once had been. The light levels "sputter" in and out sometimes if the gain increases are too agressive, and can cause a lockloss. Maybe this is an effect of the narrower linewidth and injecting more ALS noise at high frequencies with the higher CARM bandwidth.

The spatial profiles of the light on the cameras is totally bananas. Here's AS and REFL.

As Koji suggested, here is a 2D histogram of TRY vs REFLDC. It appears that the visibility would max out at 75% or so at arm powers around 400. Indeed, we briefly saw powers that high, but as can be seen on the plot, we were usually a little under 300. Exploring the transmon QPD offset space didn't seem to have much effect here.

One thing that I hadn't looked at in previous locks is coherence with our ground seismometers. It would be cool to have more seismic feedforward, and looking at the frequency domain multiple coherence, it looks like we can win a lot between 1 and 20 Hz. I expected more of a win at 1Hz, though.

Following Koji's suggestion, I decided to investigate the relation between my Finesse model and the measured data.

For easy reference, here is the loss plot again:

Sticking with the model, I used the freedom Finesse offers me to stick in photodiodes wherever I desire, to monitor the circulating power in the PRC directly, and also REFLDC. Note that REFLDC goes to 0 because I am using Finesse's amplitude detector at the carrier frequency for the 00 mode only. 

Both the above plots essentially show the same information, except the X axis is different. So my model tells me that I should expect the point of critical coupling to be when the average arm loss is ~100ppm, corresponding to a PRG of ~17 as suggested by my model.

Eric has already put up a scatter plot, but I reproduce another from a fresh lock tonight. The data shown here corresponds to the IFO initially being in the 'buzzing' state where the arms are still under ALS control and we are turning up the REFL gain - then engaging the QPD ASC really takes us to high powers. The three regimes are visible in the data. I show here data sampled at 16 Hz, but the qualitative shape of the scatter does not change even with the full data. As an aside, today I saw the transmission hit ~425!

I have plotted the scatter between TRX and REFL DC, but if I were to plot the scatter between POP DC and REFL DC, the shape looks similar - specifically, there is an 'upturn' in the REFL DC values in an area similar to that seen in the above scatter plot. POP DC is a proxy for the PRG, and I confirmed that for the above dataset, there is a monotonic, linear relationship between TRX and POPDC, so I think it is legitimate to compare the plot on the RHS in the row directly above, to the plot from the Finesse model one row further up. In the data, REFL DC seems to hit a minimum around TRX=320. Assuming a PRM transmission of 5.5%, TRX of 320 corresponds to a PRG of 17.5, which is in the ballpark of the region the model tells us to expect it to be. Based on this, I conclude the following:

• It seems like the Finesse model I have is quite close to the current state of the IFO 
• Given that we can trust the model, the PRC is now OVERCOUPLED - the scatter plot of data supports this hypothesis
• Given that in today's lock, I saw arm transmission go up to ~425, this suggests that at optimal alignment, PRG can reach 23. Then, Attachment #1 suggests the average arm loss is <50ppm, which means the average loss per optic is <25ppm. I am not sure how physical this is, given that I remember seeing the specs for the ITMs and ETMs being for scatter less than 40 25ppm, perhaps the optic exceeded the specs, or I remember the wrong numbers, or the model is wrong

In other news, I wanted to try and do the sensing matrix measurements which we neglected to do yesterday. I turned on the notches in CARM, DARM, PRCL and MICH, and then tuned the LO amplitudes until I saw a peak in the error signal for that particular DOF with peak height a factor of >10 above the noise floor. The LO amplitudes I used are 

MICH: 40

PRCL: 0.7

CARM: 0.08

DARM: 0.08

There should be about 15 minutes of good data. More impressively, the lock tonight lasted 1 hour (see Attachment #6, unfortunately FB crashed in between). Last night we lost lock while trying to transition control to 1f signals and tonight, I believe a P.C. drive excursion of the kind we are used to seeing was responsible for the lockloss, so the PRFPMI seems pretty stable.

With regards to the step in the lock acquisition sequence where the REFL gain is turned up, I found in my (4) attempts tonight that I had most success when I adjusted the CARM A slider while turning up the REFL gain to offload the load on the CARM B servo. Of course, this may mean nothing... 

I don't think the loss of 25 ppm is outrageous. Its just surprisingly good. The SIS model predicted numbers more like 1 ppm / mirror taking into account just the phase map and not the coating defects.

However, we should take into account the lossed in the DRMI to be more accurate: AR coating reflectivities, scatter loss on those surfaces, as well as possible clipping around BS or some other optics.

https://chat.ligo.org/ligo/channels/40m

Quad rods and  ionizer kit: consisting of repeller cage, anode grid, focus plate and  filament were replaced....... under repair # RGA200/12 ECA 100416-12967

The electronic ECU is not connected. It is beeing pumped at IFO ITcc 9.7E-6 Torr vacNormal

Salton See is shaking again.

I poked around a bit thinking about what we need for a single AS WFS. 

New things that we would need:

• The WFS head itself: aLIGO ASC RF Photodetector (WFS) - E1400103 (Which will need some modification for 55MHz)
• Interface board for DC power and DC signals: aLIGO WFS Interface Chassis - D1101906
• Quad Demod chassis: Quad IQ Demodulator Chassis -  D0902796 [Variant B (WFS)] (Needs LO, but we have unused outputs in the LSC LO distributor)

Things we have:

• Many Eurocard-style Whitening chassis, such as we use for all of the LSC PDs. 
• Enough ADC (c1ioo has two ADCs, but doesn't even use 32 channels, so we can steal one, and throw it into c1lsc)

We'd have 12 new signals to acquire: 4 quadrants x DC, I, Q. In principle the DC part could go into a slow channel, but we have the ADC space to do it fast, and it'll be easier than mucking around with c1iscaux or whatever.

Open question: What to do about AA? A quick search didn't turn up any eurocard AA chassis like the ones we use for the LSC PDs. However, given the digital AA that happens from 64kHz->16kHz in the IOP, we've talked about disabling/bypassing the analog AA for the LSC signals. Maybe we can do the same for the QPD signals? Or, modify the post-demod audioband amplifer in the demod chassis to have some simple, not too agressive lowpass.

installing the BLRMS 2k blocks turned out to be quite non-trivial due to a whole host of CDS issues that had to be debugged, but i've restored everything to a good state now, and the channels are being logged. detailed entry with all the changes to follow.

Building:         Campus Wide         

Date:             Thursday 11/03/16 at Approx. 6:20 a.m.   

Notification:     Unplanned City Wide Power Glitch Affecting Campus   

*This is to notify you that the Caltech Campus experienced a campus wide power glitch at approx. 6:20 a.m. this morning.

The city was contacted and they do not expect any further interruptions related to this event.

The vacuum was not effected. ITM sus damping restored. IFO room air conditions on.

PSL Innolight and ETMY Lightwave lasers turned on

I did the following:

• Hard reboots for fb, megatron, and all the frontends, in that order
• Checked time on all FEs, ran sudo ntpdate -b -s -u pool.ntp.org where necessary
• Restarted all realtime models
• Restarted monit on all FEs
• Reset Marconi to nominal settings, fCarrier=11.066209MHz, +13dBm amplitude
• In the control room, restarted the projector and set up the usual StripTool traces
• Realigned PMC
• Slow machines did not need any touchups - interestingly, ITMX did not get stuck during this power glitch!

There was a regular beat coming from the speakers. After muting all the channels on the mixer and pulling the 3.5mm cable out, the sound persisted. It now looks like the mixer is broken

     ProFX8v2

A number of changes were made to C1PEM and some library parts. Recall that the motivation was to add BLRMS channels for all our suspension coils and shadow sensor PDs, which we are first testing out on the IMC mirrors.

Here is the summary:

BLRMS_2k library block

• The name of the custom C code block in this library part was named 'BLRMSFILTER' which conflicted with the name of the function call in the C code it is linked to, which lead to compilation errors
• Even though the part was found in /opt/rtcds/userapps/release/cds/c1/models and not in the common repository, just to be safe, I made a copy of the part called BLRMS_2k_40m which lives in the above directory. I also made a copy of the code it calls in /opt/rtcds/userapps/release/cds/c1/src

C1PEM model + filter channels

• Adding the updated BLRMS_2k_40m library part still resulted in some compilation errors - specifically, it was telling me to check for missing links around the ADC parts
• Eric suggested that the error messages might not be faithfully reporting what the problem is - true enough, the problem lay in the fact that c1pem wasn't updated to follow the namespace convention that we now use in all the RT models - the compiler was getting confused by the fact that the BLRMS stuff was in a namespace block called 'SUS', but the rest of the PEM stuff wasn't in such a block
• I revamped c1pem to add namespace blocks called PEM and DAF, and put the appropriate stuff in the blocks, after which there were no more compilation errors
• However, this namespace convention messed up the names of the filter modules and associated channels - this was resolved with Eric's help (find and replace did the job, this is a familiar problem that we had encountered not too long ago when C1IOO was similarly revamped...)
• There was one last twist in that the model would compile and install, but just would not start. I tried the usual voodo of restarting all the models, and even did a soft reboot of c1sus, to no avail. Looking at dmesg, I tracked the problem down to a burt restore issue - the solution was to press the little 'BURT' button next to c1pem on the CDS overview MEDM screen as soon as it appeared while restarting the model

All the channels seem to exist, and FB seems to not be overloaded judging by the performance overnight up till the power outage. I will continue to monitor this...

GV Edit 3 Nov 2016 7pm:

I had meant to check the suitability of the filters used - there is a detailed account of the filters implemented in BLRMSFILTER.c here, and I quickly looked at the file on hand to make sure the BP filters made sense (see Attachment #1). These the BP filters are 8th order elliptical filters and the lowpass filters are16th order elliptical filters scaled for the appropriate frequency band, which are somewhat different from what we use on the seismometer BLRMS channels, where the filters are order 4, but I don't think we are significantly overloaded on the computational aspect, and the lowpass filters have sufficiently steep roll-off, these should be okay...

The projector failed just now with a pretty loud 'pop' sound - I've never been present when the lamp goes out, so I don't know if this is usual. I have left the power cable unplugged for now...

Replacement is ordered Nov 4

It seems that the EX and EY BLRMS banks were missing the BP and LP filters for the 0.03-0.1 and 0.1-0.3 bands. I've copied over the filters from the BS seismometer.

However, if it looks like the integrated C code BLRMS block works out well, we could replace the seismometers' filter module heavy BLRMS blocks and cut down on the PEM model bloat.

Here are the channels we are planning to switch over from c1auxex to Acromag, and their current pin numbers on the existing VME boards. 

Analog inputs: 

C1:SUS-ETMX_UL_AIOut    #C0 S0
C1:SUS-ETMX_LL_AIOut    #C0 S1
C1:SUS-ETMX_UR_AIOut    #C0 S2
C1:SUS-ETMX_LR_AIOut    #C0 S3
C1:SUS-ETMX_Side_AIOut    #C0 S4
C1:SUS-ETMX_OL_SEG1    #C0 S5
C1:SUS-ETMX_OL_SEG2    #C0 S6
C1:SUS-ETMX_OL_SEG3    #C0 S7
C1:SUS-ETMX_OL_SEG4    #C0 S8
C1:SUS-ETMX_OL_X    #C0 S9
C1:SUS-ETMX_OL_Y    #C0 S10
C1:SUS-ETMX_OL_S    #C0 S11
C1:SUS-ETMX_ULPD    #C0 S12
C1:SUS-ETMX_LLPD    #C0 S13
C1:SUS-ETMX_URPD    #C0 S14
C1:SUS-ETMX_LRPD    #C0 S15
C1:SUS-ETMX_SPD    #C0 S16
C1:SUS-ETMX_ULV    #C0 S17
C1:SUS-ETMX_LLV    #C0 S18
C1:SUS-ETMX_URV    #C0 S19
C1:SUS-ETMX_LRV    #C0 S20
C1:SUS-ETMX_SideV    #C0 S21
C1:SUS-ETMX_ULPD_MEAN    #C0 S12
C1:SUS-ETMX_LLPD_MEAN    #C0 S13
C1:SUS-ETMX_SDPD_MEAN    #C0 S16

Analog Outputs:

C1:ASC-QPDX_S1WhiteGain    #C0 S0
C1:ASC-QPDX_S2WhiteGain    #C0 S1
C1:ASC-QPDX_S3WhiteGain    #C0 S2
C1:ASC-QPDX_S4WhiteGain    #C0 S3
C1:SUS-ETMX_ULBiasAdj    #C0 S4
C1:SUS-ETMX_LLBiasAdj    #C0 S5
C1:SUS-ETMX_URBiasAdj    #C0 S6
C1:SUS-ETMX_LRBiasAdj    #C0 S7
C1:LSC-EX_GREENLASER_TEMP    #C0 S0 This appears to have the same pin as another channel-- is it not being used? 

Binary Outputs:

C1:SUS-ETMX_UL_ENABLE    #C0 S0
C1:SUS-ETMX_LL_ENABLE    #C0 S1
C1:SUS-ETMX_UR_ENABLE    #C0 S2
C1:SUS-ETMX_LR_ENABLE    #C0 S3
C1:SUS-ETMX_SD_ENABLE    #C0 S4
C1:ASC-QPDX_GainSwitch1    #C0 S7
C1:ASC-QPDX_GainSwitch2    #C0 S8
C1:ASC-QPDX_GainSwitch3    #C0 S9
C1:ASC-QPDX_GainSwitch4    #C0 S10
C1:AUX-GREEN_X_Shutter2    #C0 S15

We don't need to record any of the AIOut channels, the OL channels (since we record them fast), or the _MEAN channels (I think they must be CALC records or just bogus).

I just realized that Gautam set this test up and turned damping off......He will explane the details

Short summary of my Sat. Box. debugging activities over the last few days. Recall that the SRM Sat. Box has been plugged into the PRM suspension for a while now, while the SRM has just been hanging out with no electrical connections to its OSEMs.

As Steve mentioned, I had plugged in Ben's extremely useful tester box (I have added these to the 40m Electronics document sub-tree on the DCC) into the PRM Sat. Box and connected it to the CDS system over the weekend for observation. The problematic channel is LR.  Judging by Steve's 2 day summary plots, LR looks fine. There is some unexplained behavior in the UR channel - but this is different from the glitchy behaviour we have seen in the LR channel in the past. Moreover, subsequent debugging activities did not suggest anything obviously wrong with this channel. So no changes were made to UR. I then pulled out the PRM sat.box for further diagnostics, and also, for comparison, the SRM sat. box which has been hooked up to the PRM suspension as we know this has been working without any issues. 

Tracing out the voltages through the LED current driver circuit for the individual channels, and comparing the performance between PRM and SRM sat. boxes, I narrowed the problem down to a fault in either the LT1125CSW Quad Op-Amp IC or the LM6321M current driver IC in the LR channel. Specifically, I suspected the output of U3A (see Attachment #1) to be saturated, while all the other channels were fine. Looking at the spectrum at various points in the circuit with an SR785, I could not find significant difference between channels, or indeed, between the PRM/SRM boxes (up to 100kHz). So I decided to swap out both these ICs. Just replacing the OpAmp IC did not have any effect on the performance. But after swapping out the current buffer as well, the outputs of U3A and U11 matched those of the other channels. It is not clear to me what the mode of failure was, or if the problem is really fixed. I also checked to make sure that it was indeed the ICs that had failed, and not the various resistors/capacitors in the signal path. I have plugged in the PRM sat. box + tester box setup back into our CDS data acquisition for observation over a couple of days, but hopefully this does the job... I will update further details over the coming days.

I have restored control to PRM suspensions via the working SRM sat. box. The PRM Sat. Box and tester box are sitting near the BS/PRM chamber in the same configuration as Steve posted in his earlier elog for further diagnostics...

GV Edit 2230 hrs 7Nov2016: The signs from the last 6 hours has been good - see the attached minute trend plot. Usually, the glitches tend to show up in this sort of time frame. I am not quite ready to call the problem solved just yet, but I have restored the connections to the SRM suspension (the PRM and SRM Sat. Boxes are still switched). I've also briefly checked the SRM alignment, and am able to lock the DRMI, but the lock doesn't hold for more than a few seconds. I am leaving further investigations for tomorrow, let's see how the Sat. Box does overnight.

I've been trying to understand the green beat setup on the PSL table to see if I can explain the abysmal mode-matching of the arm and PSL green beams on the broadband beat PDs. My investigations suggest that the mode-matching is very sensitive to the position of one of the lenses in the arm green path. I will upload a sktech of the PSL beat setup along with some photos, but here is the quick summary.

1. I first mapped the various optical components and distances between them on the PSL table, both for the arm green path and the PSL green path
2. Next, setting the PSL green waist at the center of the doubling oven and the arm green waist at the ITMs (in vacuum distances for the arm green backed out of CAD drawing), I used a la mode to trace the Gaussian beam profile for our present configuration. The main aim here was to see what sort of mode matching we can achieve theoretically, assuming perfect alignment onto the BBPDs. The simulation is simplified, the various beam splitters and other transmissive optics are treated as having 0 width
3. It is pretty difficult to accurately measure path lengths to mm accuracy, so to validate my measurement, I measured the beam widths of the arm and PSL green beams at a few locations, and compared them to what my simulation told me to expect. The measurements were taken with a beam profiler I borrowed from Andrew Wade, and both the arm and PSL green beams have smooth Gaussian intensity profiles for the TEM00 mode (as they should!). I will upload some plots shortly. The agreement is pretty good, to within 10%, although geometric constraints on the PSL table limited the number of measurements I could take (I didn't want to disturb any optics at this point)
4. I then played around with the position of a fast (100mm EFL) lens in the arm green path, to which the mode matching efficiency on the BBPD is most sensitive, and found that in a +/- 1cm range, the mode matching efficiency changes dramatically

Results:

Attachments #1 and 2: Simulated and measured beam profiles for the PSL and arm green beams. The origin is chosen such that both beams have travelled to the same coordinate when they arrive at the BBPD. The agreement between simulation and measurement is pretty good, suggesting that I have modelled the system reasonably well. The solid black line indicates the (approximate) location of the BBPD

Attachment #3: Mode matching efficiency as a function of shift of the above-mentioned fast lens. Currently, after my best efforts to align the arm and PSL green beams in the near and far fields before sending them to the BBPD results in a mode matching efficiency of ~30% - the corresponding coordinate in the simulation is not 0 because my length measurements are evidently not precise to the mm level. But clearly the mode matching efficiency is strongly sensitive to the position of this lens. Nevertheless, I believe that the conclusion that shifting the position of this lens by just 2.5mm from its optimal position degrades the theoretical maximum mode matching efficiency from >95% to 50% remains valid. I propose that we align the beams onto the BBPD in the near and far fields, and then shift this lens which is conveniently mounted on a translational stage, by a few mm to maximize the beat amplitude from the BBPDs. 

Unrelated to this work: I also wish to shift the position of the PSL green shutter. Currently, it is located before the doubling oven. But the IR pickoff for the IR beat setup currently is located after the doubling oven, so when the PSL green shutter is closed, we don't have an IR beat. I wish to relocate the shutter to a position such that it being open or closed does not affect the IR beat setup. Eventually, we want to implement some kind of PID control to make the end laser frequencies track the PSL frequency continuously using the frequency counter setup, for which we need this change...

[Lydia, Johannes]

We're waiting on the last couple electrical components to arrive that are needed to complete the acromag chassis, but it is essentially operational. Right now it is connected to the PSL Mephisto's diagnostics port, for which only a single XT1221 A/D unit is needed. We assigned the IP address 192.168.113.121 to it. For the time being I'm running a tmux session on megatron (named "acromag") that grabs and broadcasts the epics channels, with Lydia's original channel definitions. Since the chassis is 4U tall, there's not really any place in the rack for it, so we might want to move it to the X-end before we start shuffling rack components around. Once we finalize its location we can proceed with adding the channels to the frames.

For the eventual gradual replacement of the slow machines, we need to put some thought into the connectors we want in the chassis. If we want to replicate the VME crate connectors we probably need to make our own PCB boards for them, as there don't seem to be panel-mount screw terminal blocks readily available for DIN 41612 connectors. Furthermore, if we want to add whitening/AA filters, the chassis may actually be large enough to accomodate them, and arranging things on the inside is quite flexible. There are a few things to be considered when moving forward, for example how many XT units we can practically fit in the chassis (space availability, heat generation, and power requirements) and thus how many channels/connectors we can support with each.

Steve: 1X3 has plenty of room

This is where the mammal came though. It is reach able from room 108 CES

Looks like the PRM Sat. Box is now okay, no evidence of the kind of glitchy behaviour we are used to seeing in any of the 5 channels.

We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.

This is long overdue, but our burt files for SDF now live in the LIGO userapps SVN, as they should.

The canonical files live in places like /opt/rtcds/userapps/release/cds/c1/burtfiles/c1x01_safe.snap and are symlinked to files like /opt/rtcds/caltech/c1/target/c1x01/c1x01epics/burt/safe.snap

I tried to realize an improvement in the mode matching onto the BBPDs by moving the lens mentioned in the previous elog in this thread. My best efforts today yielded X and Y beats at amplitudes -15.9dBm (@37MHz) and -25.9dBm (@25MHz) respectively. The procedure I followed was roughly:

1. Do the near-field far-field alignment of the arm and PSL green beams
2. Steer beam onto BBPD, center as best as possible using the usual technique of walking the beam across the photodiode
3. Hook up the output of the scope to the Agilent network analyzer. Tweak the arm and PSL green alignments to maximize the beat amplitude. Then move the lens to maximize the beat amplitude.

As per my earlier power budget, these numbers translate to a mode matching efficiency of ~53% for the X arm beat and ~58% for the Y arm beat, which is a far cry from the numbers promised by the a la mode simulation (~90% at the optimal point, I could not achieve this for either arm scanning the lens through a maximum of the beat amplitude). Looks like this is the best we can do without putting in any extra lenses. Still a marginal improvement from the previous state though...

I've been noticing over the last couple of days that the EPICS freezes are occurring more frequently again. Attached is an instance of StripTool traces flatlining. Not sure what has changed recently in terms of the network to cause the return of this problem... Also, they don't occur coincidentally on multiple workstations, but they do pop up in both pianosa and rossa.

Not sure if it is related, but we have had multiple slow machine crashes today as well. Specifically, I had to power cycle C1PSL, C1SUSAUX, C1AUX, C1AUXEX, C1IOOL0 at some point today

Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.

As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

I took data of the ETMX SUSPOS, SUSPIT and SUSYAW channels while driving each of the 4 face coils. I manually turned off all the damping except the side. 

Excitation: I used white noise bandpassed from 0.4 to 5 Hz in order to examine the responses around the resonance frequencies. To avoid ringing things up too much, I started with a very weak drive signal and gradually increased it until it seemed to have an effect on the mirror motion by looking at the oplev signals/sensor RMS values on the SUS screen; it's possible I'll need to do it again with a stronger signal if there's not enough coherence in the data. 

Finding the matrix: The plan is to estimate the transfer function of the coil drive signal with the sensed degrees of freedom (specified by the already diagonalized input matrix). This transfer function can be averaged around the resonance peak for each dof to find the elements of the matrix that converts signals to dof responses, (the "response matrix", which is the inverse of the output matrix). Each column of the response matrix gets normalized so that the degrees of freedom influence the drive signals in the right ratio. 

Other notes: 

• I had some trouble getting the awg python library to work: I had to manually edit a CDLL statement to use the absolute path of an .so file. I wasn't sure what environment variable to set to make it look in the right folder automatically.
• The awg ArbitraryLoop object seems to be affected by cds getdata calls (The EXC signal stopes early and then stop() hangs) so I ended up doing the excitation and data reading in 2 separate scripts. 
• Reminder that the watchdogs must be on "Normal" for the EXC signal to make it to the coils, so the damping must be turned off manually with the watchdogs still on if you want to drive without damping. 

Looking back at elog 12528, the uncertainty in the armloss number from the individual quantities in the equation for can be written as:

Making some generous assumption about the individual uncertainties and filling in typical values we get in our measurements, results in the following uncertainty budget:

In my recent round of measurements I had a 2.5% uncertainty in the ASDC reading, which completely dominates the armloss assessment.

The most recent numbers are 57 ppm for the YARM and 21 ppm for the XARM, but both with an uncertainty of near 150 ppm, so while these numbers fit well with Gautam's estimate of the average armloss via PRG, it's not really a confirmation.

I set the whitening gain in ASDC to 24 dB and ran LSC offsets, and now I'm getting a relative uncertainty in measured reflected power of .22%, which would be sufficient for ~25ppm accuracy according to the above formula. I'm going to start a series of measurements tonight when I leave, should be done in ~2 hours (10 pm) the latest.

If anybody wants to do some night work: I misaligned ITMY by a lot to get its reflection off ASDC. Approximate values are saved as a restore point. Also the whitening gain on ASDC will have to be rolled back (was at 0dB) and LSC offsets adjusted.

PRM and SRM sat. boxes have been switched for some time now - but the PRM sat. box has one channel with a different transimpedance gain, and the damping loops for the PRM and SRM were not systematically adjusted to take this into account (I just tweaked the gain for the PRM and SRM side damping loops till the optic damped). Since both sat. boxes are nominally functioning now, I saw no reason to maintain this switched configuration so I swapped the boxes back, and restored the damping settings to their values from March 29 2016, well before either of this summer's vents. In addition, I want to collect some data to analyze the sat. box noise performance so I am leaving the SRM sat. box connected to the DAQ, but with the tester box connected to where the vacuum feedthroughs would normally go (so SRM has no actuation right now). I will collect a few hours of data and revert later tonight for locking activities....

I powered up the existing ace100gm GigE cam with the PoE injector and tried to interface with it as described in elog 4163. After a few initial problems with IP assignment and interfacing I connected it to one of the gigabit hubs and installed the most recent pre-compiled software suite on /opt/pylon5 on optimus, after which I was able to find it with the configuration software. I named it "c1gige_bas100-1" and gave it the static IP address 192.168.113.151.

Afterwards the image acquisition worked without problems.

It may be a good idea to leave the gigecam interfacing up to a dedicated machine. I was thinking I could use Mafalda for this, and also for developing the code for framegrabbing and imager settings, but found that it was dead, burnt at the stake so to say. I guess it wasn't running anything critical, since it wasn't even connected to the network and smelled like burnt electronics. I'll get a replacement desktop for it.

I had a mistake in my script that reported the wrong error after averaging several datapoints, and because I hadn't looked at the individual numbers I didn't catch it so far. Thanks to Gautam it is no more.

The updated numbers are (with fresh, more trustworthy data):

XARM: 21 +/ 35 ppm
YARM: 69 +/- 45 ppm

This looks much better. I'm planning to take more data with the AS110 PD rather than AS55 when I get the chance, increase the averaging time, and also sigma filter the datapoints. That should get us to a good spot and cut down the uncertainty even further.

After much trial and error with whitening gains, demod phases and overall loop gains, I was finally able to lock the DRMI on both 1f and 3f signals! I went through things in the following order tonight:

1. Lock the arms, dither align
2. Lock the PRMI on carrier and dither align the PRM to get good alignment
3. Tried to lock the DRMI on 1f signals - this took a while. I realized the reason I had little to no success with this over the last few days was because I did not turn off the automatic unwhitening filter triggering on the demod screens. I had to tweak the SRM alignment while looking at the AS camera, and also adjust the demod phases for AS55 (MICH is on AS55Q) and REFL55 (SRCL is on REFL55I). Once I was able to get locks of a few seconds, I used the UGF servos to set the overall loop gain for MICH, PRCL and SRCL, after which I was able to revert the filter triggering to the usual settings
4. Once I adjusted the overall gains and demod phases, the DRMI locks were very stable - I left a lock alone for ~20mins, and then took loop shape measurements for all 3 loops
5. Then I decided to try transfering to 3f signals - I first averaged the IN1s to the 'B' channels for the 3 vertex DOFs using cds avg while locked on the 1f signals. I then set a ramp time of 5 seconds and turned the gain of the 'A' channels to 0 and 'B' channels to 1. The transition wasn't smooth in that the lock was broken but was reacquired in a couple of seconds.
6. The lock on 3f signals was also pretty stable, the current one has been going for >10 minutes and even when it loses lock, it is able to reacquire in a few seconds

I have noted all the settings I used tonight, I will post them tomorrow. I was planning to try a DRFPMI lock if I was successful with the DRMI earlier tonight, but I'm calling it a night for now. But I think the DRMI locking is now back to a reliable level, and we can push ahead with the full IFO lock...

It remains to update the auto-configure scripts to restore the optimized settings from tonight, I am leaving this to tomorrow as well...

Updated 16 Nov 2016 1130am

Settings used were as follows:

Nice job.

I am currently looking at the acoustic noise around both arms to see if there are any frequencies from machinery around the lab that stand out and to see what we can remove/change.

• Attachment 1 is a picture of the microphone and suspension system (bungee cords) that hangs from the cable trays to isolate it from vibrations.
• To record data, I used both the microphone (attachment 1) attach it its preamp connected to a spectrum analyzer in order get a graph of power spectral density, recording from 0-10k Hz and 10-100kHz. I started recording data at the furthest end of the x arm and worked towards the center taking measurements every couple of feet (ten rungs on the cable tray). 
• The second attachment is the first 5 psd I got from the furthest end of the x arm going 10 rungs on the cable tray closer each measurement.
• Going forward, I am going to take more measurements with greater resolution at the lower frequencies from 0-200 and stepping up from there by factors of 2.

Indeed. I suggest discussing with Joe B. I believe we should use a dedicated cam network to get the camera signals from the ends and corner all into one machine. Do not use the main CDS FE network for this since it might produce weird collissions. How about make a diagram, post it to elog, and send link to Joe?

As a starting point, I was looking at some of the old elogs and tried turning on the MCL feedback path with the existing control filters today. I tried various combinations of MCL Feedback and FF on and off, and looked at the MCL error signal (which I believe comes from the analog MC servo board?) spectrum for each case. We had used this earlier this year when EricQ and I were debugging the EX laser frequency noise to stabilize the low frequency excursions of the PSL frequency. The low frequency suppression can be seen in Attachment #1, there looks to be some excess MCL noise around 16Hz when the servo is turned on. But the MC transmission (and hence the arm transmission) decays and gets noisier when the MCL feedback path is turned on (see Attached StripTool screenshots).

I don't like AS110 or AS55. Neither of them are designed for DC and so the DC readout chain is hokey. How about use an actual transimpedance PD with a 100-1000 Ohm resistor and a 3 mm diode? This would eliminate the alignment sensitivity and the drifts due to electronics and room lights.