This earthquake tripped all suspensions and ITMX got stuck. The watchdogs were restored and the stuck optic was released. The IFO was re-aligned, POX/POY and PRMI on carrier locking all work okay.

I will be in the Clean and Bake lab from 11pm to 4pm

I implemented this change today. We only had 100 ohm, 3W resistors in stock (no 200 ohm with adequate power rating). Assuming 10 V is dropped across this resistor, the power dissipation is V^2/R ~ 1 W, so we should have sufficient margin. DCC entry has been updated with new schematic and photo of the component side of the board. Note that the series resistance of the fast actuation path was untouched.

As expected, the requested voltage no longer exceeds the Acromag DAC range, it is now more like 2.5 V. However, I still notice that the MC REFL spot moves somewhat diagonally on the camera image - so maybe the coil gains are seriously imbalanced? Anyway, the WFS control signals can once again be safely offloaded to the slow bias voltages once again, preserving the fast ADC range for other actuation.

The Johnson noise of the series resistor has now increased by a factor of 2, from ~6.4 pA/rtHz to 12.8 pA/rtHz. Assuming a current to force coefficient of 1.6 mN/A per coil, the length noise of the cavity is expected to be 12.8e-12 * 0.064/0.25/(2*pi*100)^2 ~ 8e-18 m/rtHz at 100 Hz. In frequency units, this is 80 uHz/rtHz. I think our IMC noise is at least 10 times higher than this at 100 Hz (in any case, the noise of the coil driver is NOT dominated by the series resistance). Attachment #1 confirms that there isn't any significant MCF noise increase, and I will check with the arm cavity too. Nevertheless, we should, if possible, align the optic better and use as high a series resistance as possible.

The watchdog for MC1 was disabled and the board was pulled out for this work. After it was replaced, the IMC re-locks readily.

I will be in the Clean and Bake lab today from 11am to 4pm.

Summary:

While the vacuum system was knocked out, I measured the RF transimpedance (using the AM laser setup, didn't do the shot noise intercept current measurement for now) of all the RFPDs (except PMC REFL). At the very least, the following photodiodes are suspect:

1. WFS heads - expected transimpedance is 50 kohm unattenuated, and 5 kohm attenuated. I measure values that are x10 lower than this, and the segments are significantly imbalanced. Morover, the attenuators for some quadrants appear to do nothing. This could be a problem with the Acromag system I guess, but the measured transimpedance is nowhere close to the "expected" value. See Attachments #1 and #2. You can also see that the response at 55 MHz is significantly attenuated, so I'm guessing trying to measure the AS port ASC sensing response is going to be difficult.
   
   Note that I assumed a 1kohm DC transimpedance, which is what I expect from the schematic and also is consistent with the DC voltage I measured, knowing the approximate optical power incident on the photodiode.
2. POP 22/ POP 110 - this is a Thorlabs PDA10CF diode. It should have a flat gain profile out to ~100 MHz, but I measure some weird features. The other PDA10CF we use, at AS110, shows a more reasonable response. See Attachment #3. I don't know what kind of failure mode this is? Anyway I'll try testing another PDA10CF and if it looks more reasonable, I'll switch out this diode. FWIW, the measured AS110 gain is ~3kohms, whereas the datasheet tells us to expect 5 kohms.

For the remaining photodiodes, I measure a transimpedance that is within ~20% of what is on the wiki page. The notches may benefit from some retuning. While I have the data, I will fit this and post a more complete report on the wiki.

Update July 6 1145am: WFS response plots now have legends mapping quadrants, and I've also added the response of a spare PDA10CF (which is now the new POP22/POP110 photodiode).

Judging by the summary pages, some 18 hours after this change was made and the board re-installed, the MC1 shadow sensors began to report frequent glitches. I can't think of a plausible causal connection, especially given the 18 hour time lag, but also hard to believe there isn't one? As a result, the IMC is no longer able to stay locked for extended periods of time. I did the usual cable squishing, and also took off the lid to see if that helps the situation.

While the reduced series resistance means there is more current flowing through the slow path, 

1. There isn't actually an increase in the net current flowing through the satellite box - this change just re-allocates the current from the fast path to the slow path, but by the time it reaches the satellite box, the current is flowing through the same conductor.
2. afaik, the current buffers on the coil driver aren't overdriven - they are rated for 300 mA. No individual coil is drawing more than 30 mA.
3. the resistors themselves should be running sufficiently below their rated power of 3W (I estimate 2.5 V ^2 / 100 ohms ~ 60 mW).
4. The highest current should be through the UL and LR coils according to the voltage outputs from the Acromag. But the UL coil doesn't show significant glitching, and the LL one does despite drawing negligible DC current.

The attached FLIR camera image re-inforces what we already know, that the thermal environment inside the satellite box is horrible. The absolute temperature calibration may be off, but it was difficult to touch the components with a bare finger, so I'd say its definitely > 70 C.

does the FLIR have an option to export image with a colorbar?

How about just leave the lid open? or more open? I don't know what else can be done in the near term. Maybe swap with the SRM sat box to see if that helps?

Hmm I can't seem to export with the colorbar, might be just my phone though. I tried to add some "cursors" with the temperature at a few spots, but the font color contrast is poor so you have to squint really hard to see the temperatures in the photo I attached.

I'll leave the MC1 box open overnight and see if that improves the situation, and if not, I'll switch in the SRM satellite box tomorrow.

I will be in the Clean and Bake lab today from 11:30am to 4pm

There was no improvement to the situation overnight. So, I did the following today:

1. Ramped bias voltages for SRM and MC1 to 0, shutdown watchdogs.
2. Switched SRM and MC1 satellite boxes. The SRM satellite box lid was opened, while the MC1 lid was left open. The boxes have also been re-labelled lest there be some confusion about which box belongs where.
3. Restored watchdogs and bias voltages. Curiously, the MC1 optic now only requires half the bias voltages it did before to have the correct DC alignment for the optic. The Satellite box is just supposed to be a passive conduit for the drive current, so this is indicative of some PCB traces/cabling being damaged inside what was previously the MC1 satellite box?

IMC is now locked again, I will monitor for glitching/stability.

Update 6pm PDT: as shown in Attachment #1, there is a huge difference in the stability of the lock after the sat box swap. Let's hope it stays this way for a while...

A more comprehensive report has been uploaded here. I'll zip the data files and add them there too. In summary:

1. There are several problems with the WFS heads
   • Some attenuators don't seem to work. This could be a problem with the Acromag BIO, or with the relay on the head itself.
   • The measured transimpedance at 29.5 MHz is much lower than expected. We expect ~50 kohms with no attenuation, and 5 kohms without. I measure 100 ohm - 2 kohm with the attenuation disabled, and ~200 ohms with it enabled.
   • Quadrant #3 on both WFS heads behaves differently from the others. There is also evidence of a 200 MHz oscillation for quadrant 3.
   • For some reason, there is a relative minus sign between the TFs measured for the WFS and for the RFPDs. I don't understand where this is coming from - all the OpAmps in the LSC PDs and WFS heads are configured as non-inverting, so why should there be a minus sign? Is this indicative of the polarity of the LEMO output being somehow flipped?
2. POX 11 photodiode does not have a notch at 22 MHz.
3. AS55 resonance appears to have shifted closer to 60 MHz, would benefit from a retuning. But the notches appear fine.
4. PDA10CF photodiode used as the POP22/POP110 readback appears broken in some strange way. As shown in the linked document, a spare PDA10CF in the lab has a much more reasonable response, so I am going to switch out the POP22/POP110 diode with this spare.

I'll upload the data and analysis notebook + liso fit files to the wiki as well shortly. The data, a Jupyter notebook making the plots, and the LISO fit files have been uploaded here.

I didn't do it this time but it'd be nice to also do the noise measurement and get an estimate for the shot-noise intercept current.

Sigh. Do we have a spare sat box?

I will be in the clean and bake lab today from 9am to 4pm.

Summary:

I injected some sensing lines and measured their responses in the various photodiodes, with the interferometer in a few different configurations. The results are summarized in Attachments #1 - #3. Even with the PRMI (no arm cavities) locked on 1f error signals, the MICH and PRCL signals show up in nearly the same quadrature in the REFL port photodiodes, except REFL165. I am now thinking if the output (actuation) matrix has something to do with this - part of the MICH control signal is fed back to the PRM in order to minimize the appearance of the MICH dither in the PRCL error signal, but maybe this matrix element is somehow horribly mistuned?

Details:

Attachment #1:

• ETMs were misaligned and the PRMI was locked with the carrier resonant in the cavity (i.e. sidebands reflected).
• The locking scheme was AS55_Q --> MICH and REFL11_I --> PRCL.

Attachment #2:

• The PRFPMI was locked. The vertex DoFs were still under control using 3f error signals (REFL165_I for PRCL and REFL165_Q for MICH).
• Still, the MICH/PRCL degeneracy in all photodiodes except REFL165 persists.

Attachment #3:

• Nearly identical configuration to Attachment #2.
• The main difference here is that I applied some offsets to the MICH and PRCL error points.
• The offsets were chosen so that the appearance of a ~300 Hz dither in the length of MICH/PRCL was nulled in the AS110_Q / POP22_I signals respectively.
• For the latter, the appearance of this peak in the POP110_I signal was also nulled, as it should be if our macroscopic PRC length is set correctly.
• The offsets that best nulled the peak were 110 cts for PRCL, 25 cts for MICH. The measured sensing response is 1e12 cts/m for PRCL in REFL165_I and 9.2e11 cts/m for MICH in REFL165_Q. So these offsets, in physical units, are: 110 pm for PRCL and 27 pm for MICH. They seem like reasonable numbers to me - the PRC linewidth is ~7.5 nm, so the detuning without any digital offset applied is only 1.5% of the linewidth.
• Note that I changed the POP22/POP110 demod phases to maximize the signal in the I quadrature. The final numbers were -124 degrees / -10 degrees respectively.
• Yet another piece of evidence suggesting these were the correct offsets is that the DC value of POX and POY were zero on average after these offsets were applied.
• However, the MICH/PRCL responses in the 1f REFL port photodiodes remain nearly degenerate.

Some other mysteries that I will investigate further:

1. While POP22 indicated stable buildup of 11 MHz power in the PRC, I couldn't make any sense of the AS110 signals at the dark port - there was large variation of the signal content in the two quadratures, so unlike the POP signals, I couldn't find a digital demod phase that consistently had all the signal in one of the two quadratures. This is all due to angular fluctuations?
2. My ASC simulations suggest that the POP QPD is a poor sensor of PRM motion when the PRFPMI is locked. However, I find that turning on a feedback loop with the POP QPD as a sensor and the PRM as the actuator dramatically reduces the low-frequency fluctuations of the arm cavity carrier buildup. 🤔

I blew the long lock last night because I forgot to not clear the ASS offsets when trying to find the right settings for running the ASS system at high power. Will try again tonight...

This problem reared its ugly head again. I am inclined to believe the problem is electronic and not on the light, since the POY channels seem immune to this issue (see Attachment #1). I will investigate in the daytime tomorrow. Note that while the POX photodiode head has ~twice the transimpedance than POY (per measurement), the POY signal gets amplified by a ZHL-500-HLN amplifier before heading to the demod electronics (nominal gain is 19dB = x9). There is also some imbalance in the light level at the photodiodes I guess, because overall, the PDH fringe is ~twice as large for the Y arm as the X arm. Basically, the y-axes of the attached plot cannot be directly compared between POX and POY.

Mostly this is an annoyance - right now, the POX signal is only used for locking and dither aligning the X arm cavity, and so once that is done, the locking can proceed (as long as the other channels, e.g. REFL11, aren't glitching as well...)

I will be in the Clean and Bake lab from 9am to 4pm today.

I re-connected the 3 accelerometers located near the MC1/MC3 chamber. It was a bit tedious to get the cabling sorted - I estimate the cable is ~80m long, and the excess length had to be wound around a spool (see Attachment #1), which wasn't really a 1 person job. It's neat-ish for now, but I'm not entirely satisfied. I think we should get shorter cables (~20m), and also mount the pre-amp/power units in a rack instead of leaving it on the floor. The pre-amp settings are x100 for all three channels. The MC2 channels are powered, but are unconnected to the seismometers - it was too tedious to unroll the other spool yesterday. Apart from this, the cable for the "Z" channel had to be re-seated in the strain relief clamp.

I did not enable any of the CDS filters that convert the raw signal into physical units, so for now, these channels are just recording raw counts.

Update 7pm: the spectra in the current config are here - not sure what to make of the MC2_Z channel appearing to show lower noise?

Update July 13 2020 430pm: This afternoon, I hooked up the MC2 accelerometer channels too...

​I looked into how the new UPS devices suggested by Chub would communicate with the vac interlocks. There are several possible ways, listed in order of preference:

• Python interlock service directly queries the UPS via a USB link using the (unofficial) tripplite package. Direct communication would be ideal because it avoids introducing a dependency on third-party software outside the monitoring/control capability of the interlock manager. However the documentation warns this package does not work for all models...
• Configure Tripp Lite's proprietary software (PowerAlert Local) to send SYSLOG event messages (UDP packets) to a socket monitored by the Python interlock manager.
• Configure the proprietary software to execute a custom script upon an event occurring. The script would, e.g., set an EPICS flag channel which the interlock manager is continually monitoring.

I recommend we proceed with ordering the Tripp Lite 36HW20 for TP1 and Tripp Lite 1AYA6 for TP2 and TP3 (and other 120V electronics). As far as I can tell, the only difference between the two 120V options is that the 6FXN4 model is TAA-compliant.

In an effort to make a second usable workstation, I did the following (remotely) on rossa today (not necessarily in this order, I wasn't maintaining a live log so I forgot):

1. Fixed /etc/resolv.conf, so that the other martian machines can be found.
2. Copied over .bashrc file, and the appropriate lines from /etc/fstab from pianosa to rossa.
3. Ran sudo apt install nfs-common. Then ran sudo mount -a to get /cvs/cds mounted.
4. Made symlinks for /users and /opt/rtcds , and /ligo. All of these are used by various environment-setting scripts and I chose to preserve the structure, though why we need so many symlinks, I don't know...
5. Set up the shell variable $NDSSERVER using export NDSSERVER=fb:8088. I'm not sure how, but I believe DTT, awggui etc use this on startup to get the channel list (any
6. Followed instructions from Erik von Reis at LHO to install the cds workstation packages and dependencies. Worked like a charm 🎃! 
7. As a test, I plotted the accelerometer spectra in DTT, see Attachment #1. I also launched foton from inside awggui, and confirmed that the sample rate is inherited and I could designate a filter. But I haven't yet run the noise injection to test it, I'll do that the next time I'm in the lab.
8. Also checked that medm, StripTool and ndscope, and anaconda python all seem to work 👍🏾.

So, in summary, rossa is now all set up for use during lock acquisition. However, until this machine has undergone a few months of testing, we should freeze the pianosa config and not mess with it.

Note that this version of the "crtools" is rather new. Please, use them and if there is an issue, report the errors! I am going to occassionally try lock acquisition using rossa. 

As part of an ongoing effort to improve airflow in workspaces/bathrooms on campus, I have installed an air scrubber unit in each of the bathrooms at the 40m lab.

maybe we should make a "dd" copy of pianosa in case rossa has issues and someone destroys pianosa by accidentally spilling coffee on it.

in the lab, checkin on the WFS

Sun Jul 5 18:25:50 2020

I redid Gautam's measurements to get a baseline before changing the head, and my results are very different: To me it looks like the WFS2 quadrants are all OK.

Measurement Details:

1. The whole AG4395 + breadboard Jenne laser is wheeled over next to the SW side of the AP table.
2. The output of the 1611 goes into channel R of the 4395
3. I disconnected all the LEMO cables from the head and then plugged a LEMO-BNC cable into the plugs one at a time. The existing LEMO connectors, which take the signals back to the demode board, were all a little loose, so I adjusted them with some pliers (see video).
4. The Atten = 0 dB for all AG4395 channels
5. Source drive = 0 dBm. Checked with a -10 dBm drive that there was no change in the observed TFs, so I guess a 0 dBm drive doesn't make things nonlinear.
6. When I first turned the setup on, the Yellow 'limit' light was ON on the ILX laser current driver, so maybe the modulation wasn't getting to the laser diode as we wish.
7. did not change any WFS MEDM settings for these measurements. Not sure if any of those buttons work anyway.

I've left the setup as is in case either me or Gautam want to double check. If we're agreed on this response, I'll remove the notches and disable the RF attenuators.

Sun Jul 5 21:42:45 2020

I did

sudo usermod -a -G lpadmin controls

and then was able to add Grazia to the list of printers for Rossa by following the instructions on the 40m Wiki.

I installed color syntax highlighting on Rossa using the internet (https://superuser.com/questions/71588/how-to-syntax-highlight-via-less). Now if you do 'less genius_code.py', it will be highlighting the python syntax.

when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
 

This is strange - I was definitely able to launch medm when I was working on this machine remotely on Friday. But now, there does seem to be a problem with this shared library being missing.

First of all, I installed mlocate to find where the shared library files are installed. Then I made the symlink, and now sitemap seems to work again.

Weirdly, my changes to /etc/resolv.conf got overwritten somehow. Was this machine rebooted? Uptime suggests it's only been running for ~6 hours at the time of writing of this elog.

I will be in the Clean and Bake lab today from 8:30am to 4pm

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

Indeed, this is now fixed by following instructions from here. I rebooted rossa at ~1250 PDT and confirmed that resolv.conf didn't get overwritten. The resolv.conf file also now has the following useful lines at the head:

As suggested last week, Hang and I have reviewed the A+ BHD status (DRD, CDD, and reviewers' comments) and compiled a list of key unanswered questions which could be addressed through Finesse analysis.

In anticipation of others helping with this modeling effort, we've tried to break questions into self-contained projects and estimated their level of difficulty. As you'll see, they range from beginner to Finesse guru.

Last Tuesday evening, while attempting the PRFPMI locking, I noticed a strange feature in the LSC signals, which is shown in Attachment #1 (the PDF exported by dataviewer is 14MB so I upload the jpeg instead). As best as I can tell, the REFL33 and POP22 channels show an abrupt jump in the signal levels, while the other channels do not. POP110 shows a slight jump at around the same time, and the large excursion in AS110_Q actually occurs a few seconds later, and is probably some angular excursion of the PRC/BS. I'm struggling to interpret how this can be explained by some interferometric mechanism, but haven't come up with anything yet. The LO for the 3f error signals is the 2f field, but then why doesn't the POP110 channel show a similar jump if there is some abrupt change in the resonant condition? Is such a change even feasible from a cavity length change point of view? Or did the sideband frequency somehow abruptly jump? But if so, why is the jump much more clearly visible in one sideband than the other?

Does anyone have any ideas as to what could be going on here? This may give some clue as to what's up with the weird sensing matrices, but may also be something boring like broken electronics... 

Summary:

I want to be able to run the dither alignment servo with the PRFPMI locked - I've been thinking about what the scheme should be, and I list here some questions I had while thinking about this.

Details:

1. ITM Oplev DC coupling
   • In the current scheme, I DC couple the ITM Oplev servos after the arms have been aligned to maximize POX/POY transmission.
   • However, looking back at data from when the CARM offset is reduced (e.g. Attachment #1), it looks like the ITMs are being torqued quite a bit during this process (ITMX PIT changes by ~20urad, ITMY YAW by ~10urad in this particular lock attempt). 
   • So the spots are not actually being centered on the test-masses? I guess the spot position on ITMX isn't actually controlled because we have only one actuator (BS) for the XARM beam axis. Is it unexpected that ITMY gets torqued so much? 
   • It is unclear what would happen if the ITM Oplev servos are not DC coupled. I wonder if I'd still be able to reach the high circulating powers and then rely solely on the TR QPDs for the arm cavity angular control.
   • Another possibility is to offload the DC part of the control signal to the optic's slow bias voltage slider, and then turn off the DC coupling. After that, the dither alignment can optimize the cavity alignment.
2. Dither alignment at high circulating power
   • I think that the system should work with the same settings as for the POX/POY locking, with the following changes:
     • Scale the overall loop gain by the arm transmission.
     • Change LSC2ASS matrix element from XARM/YARM ---> DARM.
       Does this sound right?
   • In light of the above, I was thinking that we should introduce a gain scaling field in the c1ass RTCDS model (like we have for the LSC power normalization matrix). Is it worth to go through the somewhat invasive process of model recompilation etc?
   • With the PRFPMI locked, I am wondering if I can simultaneously run the dither alignment loops for all the DoFs. Probably not, especially for MICH, since the actuator is the BS, which is also the actuator for the XARM loop?

I will be in the clean and bake lab today from 9am to 3pm.

I wanted to try using rossa as my locking workstation today. However, a few problems became quickly evident. Basically, any of our scripts that rely on the cdsutils package (there are MANY) will not work on rossa, because of some library error. This machine is running Debian 10, while the cdsutils package is being loaded from a pre-compiled install on the shared drive, so perhaps this isn't surprising?

Digging a little more, I found that actually, a version of cdsutils that actually works with python3 is actually shipped with the standard cds-workstation meta-package. This is great news, and we should try and use this where possible I guess. Deferring further debugging for daytime work.

Anyway, I added a symlink: sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5, and installed wmctrl using sudo apt install wmctrl. 

I will be in the Clean and Bake lab today from 9am to 3pm

Here is the procedure for setting up the three new BHD front-ends (c1bhd, c1sus2, c1ioo - replacement). This plan is based on technical advice from Rolf Bork and Keith Thorne.

The overall topology for each machine is shown here. As all our existing front-ends use (obsolete) Dolphin PCIe Gen1 cards for IPC, we have elected to re-use Dolphin Gen1 cards removed from the sites. Different PCIe generations of Dolphin cards cannot be mixed, so the only alternative would be to upgrade every 40m machine. However the drivers for these Gen1 Dolphin cards were last updated in 2016. Consequently, they do not support the latest Linux kernel (4.x) which forces us to install a near-obsolete OS for compatibility (Debian 8).

Hardware

• Servers: SuperMicro 5018R-M [RECEIVED]
• IPC cards: Dolphin DXH510-A0 (PCIe x4 Gen1) [LLO will provide; I've asked Keith Thorne to ship them]
• I/O cards: One Stop Systems OSS-PCIe-HIB25-x4-H-H (PCIe x4 Gen2) [Rich Abbott will provide; part of the I/O chassis hardware we are receiving from aLIGO]
• I/O cables: One Stop Systems OSS-PCIe-CBL-x4-3M (PCIe x4 3m) [RECEIVED]
• IPC cables: Data Storage Cables C5252-40ME-O (fiber optic 40m) [RECEIVED]

Software

• OS: Debian 8.11 (Linux kernel 3.16)
• IPC card driver: Dolphin DX 4.4.5 [works only with Linux kernel 2.6 to 3.x]
• I/O card driver: None required, per the manual

Install Procedure

1. Follow Keith Thorne's procedure for setting up Debian 8 front-ends
2. Apply the real-time kernel patches developed for Debian 9, but modified for kernel 3.16 [these are UNTESTED against Debian 8; Keith thinks they may work, but they weren't discovered until after the Debian 9 upgrade]
3. Install the PCIe expansion cards and Dolphin DX driver (driver installation procedure)

I noticed these streaky lines again today (but they were not a problem last night). It is annoying if we have to reboot this machine all the time. I wonder if this has something to do with missing drivers. When I ran sudo apt update && sudo apt upgrade, I got several lines like (this isn't the whole stack trace)

Is this indicative of the graphics drivers being installed incorrectly? I am hesitant to mess with this because I think in the past, it was always trying to update some graphics driver that crashed the whole machine into some weird state where we have to wipe the drive and do a fresh re-install of the OS.

Should we just follow these instructions? The graphics card is apparently Quadro P400, which is one of the supported ones according to the list of supported devices.

Or just swap donatella and rossa monitors and defer the problem for later?

Summary:

We can probably learn something about the interferometer / top level BHD plan with an in-air BHD setup, even if the noise is bad. Here are some thoughts about how we would do it. 

LO delivery:

For this first attempt, we don't really care about the PRC filtering. So possible places to pick off an LO beam are:

In all cases, I think the easiest option to actually route whatever beam we choose into a fiber, and then bring it over to whatever cavity we choose to use for an OMC. I'm assuming whatever phase control technique we end up using can cancel the fiber phase noise at relevant frequencies.

LO phase control

• Stress the fiber? This will require us to purchase some custom hardware, and interface it to the CDS system.
• PZT mirror? We should have sufficient hardware available to drive a PI style PZT mirror.

There is a question about the range, but I think these are the only two realistic options we can implement on a reasonable time scale.

OMC:

Again, there are a few options. Here are some pros and cons that come to my mind.

If we can do a vent (we'd just need a single chamber open), I'd go for the option of getting the copper OMC out and using that. Attachment #1 shows the approximate sizes of the various components (OMMT, OMC cavity, DCPDs), while Attachment #2 shows a rough sketch of where things would go on the AP table, with the rectangles approximately to scale.

CDS:

I'd made a c1omc model sometime ago. Basically, I think we have sufficient ADC/DAC channels in the c1ioo machine for any of the options listed above - but using the copper OMC and associated peripherals would allow the easiest interfacing.

Criticisms/comments/thoughts please.

Chub has placed the order for two new UPS units (115V for TP2/3 and a 220V version for TP1).

They will arrive within the next two weeks.

More tomorrow, but I tried the following tonight:

1. Dither alignment for PRC / MICH seems to work when the PRFPMI is locked. Unfortunately, the correct settings for the arm cavity dither alignment loops continue to elude me.
2. I tried some arm ASC loop characterization by stepping the error points of these loops - I saw some weird cross coupling between the loops that needs investigation.
3. I'm unable to turn an integrator on for the "Common YAW" QPD loop - unclear why this is, but every time I attempt to engage said integrator, the lock is immediately blown. Needs some investigation of the signals.
4. With the PRC / MICH angular DoFs aligned with the dither alignemnt, and the arm ASC loops hand tuned, I was able to get the darkest dark port I've seen. In terms of ASDC counts, it was ~ 200, which after undoing all the digital gains etc corresponds to ~100 uW of light. I think we can get a rough estimate of the contrast defect by accounting for (i) T_SRM, (ii) OMC pickoff fraction (iii) other losses between the BS dark port and the AP table (iv) 50/50 BS between AS55 and AS110 PD (the ASDC signal is derived from the former) and (v) the throughput of the 55 MHz sideband to the dark port, although there are many uncertainties. 

I will be in the Clean and Bake lab today from 9am to 4pm

I was looking at some signals from last night, see Attachment #1.

• It looks like as the DC control signal to the MC2 suspension increases, the MC transmission decreases.
  • I confirmed that the IMC REFL level doesn't correspondingly trend up, but didn't include it here for plot compactness, so I think the cavity length isn't being detuned.
  • So the problem is suggestive of some L2A coupling, and the MC2 coil actuators need to be balanced better at DC?
  • You can see from the IMC WFS control signals that the WFS servo is presumably trying to counteract this L2A action, but doesn't succeed, probably because the servo isn't tuned correctly.
  • This is a problem that is distinct from the drifting TT alignment. So it complicates the alignment situation.
  • Ideally, if the dither alignment servos could be made to work for the arm cavities when locked in the PRFPMI config, this wouldn't be so much of a problem, as the TTs would just adjust the beam pointing to match the cavity axes of the arms. But since I haven't managed to get that servo working yet...
• But why should MC2 need such a large DC control signal ever?
  • In the PRFPMI lock, the CARM servo is supposed to match the laser frequency to the average length of the two arm cavities.
  • The MC2 suspension is used as a frequency actuator in order to realize this matching.
  • But, as you can see, the digital CARM control signal picks up a significant DC offset the deeper we go into the lock.
  • Can't we offload this DC signal to the laser crystal temperature servo? Is there going to be some weird interaction with the existing slow loop? Or is the idea itself flawed?

Attachment #2 shows some ASC metrics. My conclusion here is that running the PRCL and MICH dither alignment servos (former demodulating REFLDC and latter demodulating ASDC to get an error signal) that running the dither alignment servo and hand tuning the arm ASC loop offsets improves the mode matching to the IFO, because:

1. The arm transmission increases.
2. POPDC increases.
3. ASDC decreases.

The REFLDC behavior needs a bit more interpretation I think, because if the IFO is overcoupled (as I claim it is), then better alignment would at some point actually result in REFLDC increasing. 

All the DC signals recorded by the fast system come from the backplane P2 connector of the PD interface boards. According to the schematic, these signals have a voltage gain of 2. The LSC photodiodes themselves have a nominal DC gain of 50 ohms. So, the conversion from power to digital counts is: 0.8 A/W * 50 V/A * 2 * 3276.8 cts/V * whtGain. Inverting, I get 3.8 uW/ct for a whitening gain of 1. This is power measured at the photodiode - optical losses upstream of the photodiode will have to be accounted for separately.

Assuming a modulation depth of 0.2, the 55 MHz sideband power should be ~20 mW. The Schnupp asymmetry is supposed to give us O(1) transmission of this field to the AS port. Then, the SRM will attenuate the field by a factor of 10, so we expect ~2 mW at the AS port. Let's assume 80 % throughput of this field to the AP table, and then there is a 50/50 beamsplitter dividing the light between the AS55 and AS110 photodiodes. So, we expect there to be ~700 uW of power in the TEM00 mode 55 MHz sideband field. This corresponds to 1600 cts according to the above calibration (the ASDC whitening gain is set to 18 dB). The fact that much smaller numbers were seen for ASDC indicates that (i) the schnupp asymmetry is not so perfectly tuned and the actual transmission of the sideband field to the dark port is smaller, or (ii) one or more optical splitting fractions assumed above is wrong. If the former is true, we can still probably infer the contrast defect if we can somehow get an accurate measurement of the sideband transmission to the dark port.

After some consultation with Erik von Reis at LHO, this workstation is progressing towards being usable for most commissioning tasks. DTT, awggui, foton, and MEDM are all now working well. The main limitation now comes from the fact that many of our python scripts are written for python2, and rossa doesn't have many dependencies installed for python2. I see no reason to build these dependencies on rossa for python2, we should not have to work with an unsupported language. But at the same time, I don't want to completely wipe all our python2 scripts, and make them python3, because this would involve a lot of tedious testing that I'm not prepared to undertake at the moment (the problem is compounded by the fact that pianosa does not have many dependencies installed for python3).

So what I have done in the interim is make python3 versions of the most important scripts I need to get the PRFPMI locking working - they are in the scripts directory and have the same names as their python2 counterparts, but have a 3 appended to their names. So when working on rossa, these are the scripts that are called. Eventually, after a lot more testing, we can depracate the old scripts. Currently, where applicable, the MEDM screens allow for either the python2 or python3 version of the script to be called.

Please, for the time being, do not try and install any new packages on rossa unless you are prepared to debug any problems caused and return the machine to a workable state. If you find some issue with a missing package on rossa, (i) make a note of it on the elog, and (ii) if possible, set up your own conda environment for testing and install dependencies to that environment only.

> Can't we offload this DC signal to the laser crystal temperature servo?
No. PSL already follows the MC length. So this offset is coming from the difference between the MC length and the CARM length.
What you can do is to offload the MC length to the CARM DC if this helps.

Main goals tonight were:

1. Check if I can lock the interferometer by working on rossa - indeed, I could! It is much snappier than the ageing pianosa. The viewing angle of the CRT monitors from this corner isn't so good though.
2. Measure step responses for the arm ASC loops to see if any insight can be gained into these loops. Analysis forthcoming...

After some hunting, I found this old SURF report with the WFS head measurements. The y-axes don't make much sense to me, and I can't find the actual data anywhere (her wiki page doesn't actually exist). So I think it's still unknown if these heads ever had the advertised transimpedance gain, or if the measured transimpedance of ~1kohm was what it always was.

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

Is it possible to just make a python2 conda environment on rossa? I would guess that its simple and won't interfere with the regular operation of that machine.

1. if IMC REFL is not increasing, I don't think its a mis-alignment. Usually, REFL is a more sensitive indicator of alignment than TRANS since its usually near zero. Maybe the MC2 TRANS PD is not centered or doesn't have enough lens action.
2. to reduce the DC load on MC2, you could have a slow releif drive the ETMs and DC and minimize LSC-MCL

In fact, all these utilities are now available in python3. There may be some bugs (e.g. this), but I've checked basic functionality and things look usable enough for development to proceed. While we can have a python2 env on rossa, I think it's unnecessary.

I tried using the POX_I error signal for the DC CARM_B path today a couple of times. Got to a point where the AO path could be engaged and the arm powers stabilized somewhat, but I couldn't turn the CARM_A path off without blowing the lock. Now the IMC has entered a temperemental state, so I'm abandoning efforts for tonight, but things to try tomorrow are:

1. Check that the demod phase is set correctly
2. With the CARM_B path engaged, measure some CARM OLTFs. Tonight, I was a bit over-optimistic I think, by expecting the scripted transition to take me all the way, but I think I'll have to fiddle around with the gains a bit.
3. Check for offsets. The AO path should be AC coupled, but maybe the POX signal has some offset?

I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be.

The motivation here is to see if the sensing matrix looks any different with a modified locking scheme.

The usual technique is that keeping the IFO locked with the old set of the signals and the relative gain/TF between the conventional and new signals are measured in-lock so that you can calibrate the new gain/demod-phase setting.