40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 339 of 344 Not logged in
ID Date Author Type Category Subject
13440   Tue Nov 21 17:51:01 2017 KojiConfigurationComputersnodus post OS migration admin

The post OS migration admin for nodusa bout apache, elogd, svn, iptables, etc can be found in https://wiki-40m.ligo.caltech.edu/NodusUpgradeNov2017

Update: The svn dump from the old svn was done, and it was imported to the new svn repository structure. Now the svn command line and (simple) web interface is running. And "websvn" was also implemented.

13442   Tue Nov 21 23:47:51 2017 gautamConfigurationComputersnodus post OS migration admin

I restored the nodus crontab (copied over from the Nov 17 backup of the same at /opt/rtcds/caltech/c1/scripts/crontab/crontab_nodus.20171117080001. There wasn't a crontab, so I made one using sudo crontab -e.

This crontab is supposed to execute some backup scripts, send pizza emails, check chiara disk usage, and backup the crontab itself.

I've commented out the backup of nodus' /etc and /export for now, while we get back to fully operational nodus (though we also have a backup of /cvs/cds/caltech/nodus_backup on the external LaCie drive), they can be re-enabled by un-commenting the appropriate lines in the crontab.

 Quote: The post OS migration admin for nodusa bout apache, elogd, svn, iptables, etc can be found in https://wiki-40m.ligo.caltech.edu/NodusUpgradeNov2017 Update: The svn dump from the old svn was done, and it was imported to the new svn repository structure. Now the svn command line and (simple) web interface is running. "websvn" is not installed.

13445   Wed Nov 22 11:51:38 2017 gautamConfigurationComputersnodus post OS migration admin

Confirmed that this crontab is running - the daily backup of the crontab seems to have successfully executed, and there is now a file crontab_nodus.ligo.caltech.edu.20171122080001 in the directory quoted below. The $HOSTNAME seems to be "nodus.ligo.caltech.edu" whereas it was just "nodus", so the file names are a bit longer now, but I guess that's fine...  Quote: I restored the nodus crontab (copied over from the Nov 17 backup of the same at /opt/rtcds/caltech/c1/scripts/crontab/crontab_nodus.20171117080001. There wasn't a crontab, so I made one using sudo crontab -e. This crontab is supposed to execute some backup scripts, send pizza emails, check chiara disk usage, and backup the crontab itself. I've commented out the backup of nodus' /etc and /export for now, while we get back to fully operational nodus (though we also have a backup of /cvs/cds/caltech/nodus_backup on the external LaCie drive), they can be re-enabled by un-commenting the appropriate lines in the crontab. 13461 Sun Dec 3 05:25:59 2017 gautamConfigurationComputerssendmail installed on nodus Pizza mail didn't go out last weekend - looking at logfile, it seems like the "sendmail" service was missing. I installed sendmail following the instructions here: https://tecadmin.net/install-sendmail-server-on-centos-rhel-server/ Except that to start the sendmail service, I used systemctl and not init.d. i.e. I ran systemctl start sendmail.service (as root). Test email to myself works. Let's see if it works this weekend. Of course this isn't so critical, more important are the maintenance emails that may need to go out (e.g. disk usage alert on chiara / N2 pressure check, which looks like nodus' responsibilities). 13462 Sun Dec 3 17:01:08 2017 KojiConfigurationComputerssendmail installed on nodus An email has come at 5PM on Dec 3rd. 13504 Fri Jan 5 17:50:47 2018 ranaConfigurationComputersmotif on nodus I had to do 'sudo yum install motif' on nodus so that we could get libXm.so.4 so that we could run MEDM. Works now. 13505 Fri Jan 5 19:19:25 2018 ranaConfigurationSEIBarry Controls 'air puck' instead of 'VOPO style' breadboard We've been thinking about putting in a blade spring / wire based aluminum breadboard on top of the ETM & ITM stacks to get an extra factor of 10 in seismic attenuation. Today Koji and I wondered about whether we could instead put something on the outside of the chambers. We have frozen the STACIS system because it produces a lot of excess noise below 1 Hz while isolating in the 5-50 Hz band. But there is a small gap between the STACIS and the blue crossbeams that attache to the beams that go into the vacuum to support the stack. One possibility is to put in a small compliant piece in there to gives us some isolation in the 10-30 Hz band where we are using up a lot of the control range. The SLM series mounts from Barry Controls seems to do the trick. Depending on the load, we can get a 3-4 Hz resonant frequency. Steve, can you please figure out how to measure what the vertical load is on each of the STACIS? Attachment 1: mm_slm.jpg Attachment 2: Screen_Shot_2018-01-05_at_7.25.47_PM.png 13524 Wed Jan 10 14:17:57 2018 johannesConfigurationComputer Scripts / Programsautoburt no longer making backups I was looking into setting up autoburt for the new c1auxex2 and found that it stopped making automatic backups for all machines after the beginning of the new year. There is no 2018 folder (it was the only one missing) in /opt/rtcds/caltech/c1/burt/autoburt/snapshots and the /latest/ link in /opt/rtcds/caltech/c1/burt/autoburt/ leads to the last backup of 2017 on 12/31/17 at 23:19. The autoburt log file shows that the back script last ran today 01/10/18 at 14:19, as it should have, but doesn't show any errors and ends with "You are at the 40m". I'm not familiar with the autoburt scheduling using cronjobs. If I'm not mistaken the relevant cronjob file is /cvs/cds/rtcds/caltech/c1/scripts/autoburt/autoburt.cron which executes /cvs/cds/rtcds/caltech/c1/scripts/autoburt/autoburt.pl I've never used perl but there's the following statement when establishing the directory for the new backup: $yearpath = $autoburtpath."/snapshots/".$thisyear;   # print "scanning for path $yearpath\n"; if (!-e$yearpath) {     die "ERROR: Year directory $yearpath does not exist\n"; } I manually created the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2018/ directory. Maybe this fixes the hickup? Gotta wait about 30 minutes. 13525 Wed Jan 10 15:25:43 2018 johannesConfigurationComputer Scripts / Programsautoburt making backups again  Quote: I manually created the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2018/ directory. Maybe this fixes the hickup? Gotta wait about 30 minutes. It worked. The first backup of the year is now from Wednesday, 01/10/18 at 15:19. Ten days of automatic backups are missing. Up until 2204 the year folders had been pre-emptively created so why was 2018 missing? gautam: this is a bit suspect still - the snapshot file for c1auxex at least seemed to be too light on channels recorded. this was before any c1auxex switching. to be investigated. 13526 Wed Jan 10 16:27:02 2018 SteveConfigurationSEIload cell for weight measurement We could use similar load cells to make the actual weight measurement on the Stacis legs. This seems practical in our case. I have had bad experience with pneumatic Barry isolators. Our approximate max compression loads are 1500 lbs on 2 feet and 2500 lbs on the 3rd one.  Quote: We've been thinking about putting in a blade spring / wire based aluminum breadboard on top of the ETM & ITM stacks to get an extra factor of 10 in seismic attenuation. Today Koji and I wondered about whether we could instead put something on the outside of the chambers. We have frozen the STACIS system because it produces a lot of excess noise below 1 Hz while isolating in the 5-50 Hz band. But there is a small gap between the STACIS and the blue crossbeams that attache to the beams that go into the vacuum to support the stack. One possibility is to put in a small compliant piece in there to gives us some isolation in the 10-30 Hz band where we are using up a lot of the control range. The SLM series mounts from Barry Controls seems to do the trick. Depending on the load, we can get a 3-4 Hz resonant frequency. Steve, can you please figure out how to measure what the vertical load is on each of the STACIS? Attachment 1: stacis3LoadCells.png 13539 Fri Jan 12 12:31:04 2018 gautamConfigurationComputerssendmail troubles on nodus I'm having trouble getting the sendmail service going on nodus since the Christmas day power failure - for some reason, it seems like the mail server that sendmail uses to send out emails on nodus (mx1.caltech.iphmx.com, IP=68.232.148.132) is on a blacklist! Not sure how exactly to go about remedying this. Running sudo systemctl status sendmail.service -l also shows a bunch of suspicious lines: Jan 12 10:15:27 nodus.ligo.caltech.edu sendmail[6958]: STARTTLS=client, relay=cluster6a.us.messagelabs.com., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256 Jan 12 10:15:45 nodus.ligo.caltech.edu sendmail[6958]: w0A7QThE032091: to=<umakant.rapol@iiserpune.ac.in>, ctladdr=<controls@nodus.ligo.caltech.edu> (1001/1001), delay=2+10:49:16, xdelay=00:00:39, mailer=esmtp, pri=5432408, relay=cluster6a.us.messagelabs.com. [216.82.251.230], dsn=4.0.0, stat=Deferred: 421 Service Temporarily Unavailable Jan 12 11:15:23 nodus.ligo.caltech.edu sendmail[10334]: STARTTLS=client, relay=cluster6a.us.messagelabs.com., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256 Jan 12 11:15:31 nodus.ligo.caltech.edu sendmail[10334]: w0A7QThE032091: to=<umakant.rapol@iiserpune.ac.in>, ctladdr=<controls@nodus.ligo.caltech.edu> (1001/1001), delay=2+11:49:02, xdelay=00:00:27, mailer=esmtp, pri=5522408, relay=cluster6a.us.messagelabs.com. [216.82.251.230], dsn=4.0.0, stat=Deferred: 421 Service Temporarily Unavailable Jan 12 12:15:25 nodus.ligo.caltech.edu sendmail[13747]: STARTTLS=client, relay=cluster6a.us.messagelabs.com., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256 Jan 12 12:15:42 nodus.ligo.caltech.edu sendmail[13747]: w0A7QThE032091: to=<umakant.rapol@iiserpune.ac.in>, ctladdr=<controls@nodus.ligo.caltech.edu> (1001/1001), delay=2+12:49:13, xdelay=00:00:33, mailer=esmtp, pri=5612408, relay=cluster6a.us.messagelabs.com. [216.82.251.230], dsn=4.0.0, stat=Deferred: 421 Service Temporarily Unavailable Why is nodus attempting to email umakant.rapol@iiserpune.ac.in? 13540 Fri Jan 12 16:01:27 2018 KojiConfigurationComputerssendmail troubles on nodus I personally don't like the idea of having sendmail (or something similar like postfix) on a personal server as it requires a lot of maintenance cost (like security update, configuration, etc). If we can use external mail service (like gmail) via gmail API on python, that would easy our worry, I thought. 13542 Fri Jan 12 18:22:09 2018 gautamConfigurationComputerssendmail troubles on nodus Okay I will port awade's python mailer stuff for this purpose. ### gautam 14Jan2018 1730: Python mailer has been implemented: see here for the files. On shared drive, the files are at /opt/rtcds/caltech/c1/scripts/general/pizza/pythonMailer/ gautam 11Feb2018 1730: The python mailer had never once worked successfully in automatically sending the message. I realized this may be because I had put the script on the root user's crontab, but had setup the authentication keyring with the password for the mailer on the controls user. So I have now setup a controls user crontab, which for now just runs the pizza mailing. let's see if this works next Sunday...  Quote: I personally don't like the idea of having sendmail (or something similar like postfix) on a personal server as it requires a lot of maintenance cost (like security update, configuration, etc). If we can use external mail service (like gmail) via gmail API on python, that would easy our worry, I thought. 13545 Sat Jan 13 02:36:51 2018 ranaConfigurationComputerssendmail troubles on nodus I think sendmail is required on nodus since that's how the dokuwiki works. That's why the dokuwiki was trying to send an email to Umakant. 13546 Sat Jan 13 03:20:55 2018 KojiConfigurationComputerssendmail troubles on nodus I know it, and I don't like it. DokuWiki seems to allow us to use an external server for notification emails. That would be the way to go. 13555 Wed Jan 17 23:36:12 2018 johannesConfigurationGeneralAS port laser injection Status of the AS-port auxiliary laser injection • Auxiliary laser with AOM setup exists, first order diffracted beam is coupled into fiber that leads to the AS table. • There is a post-PMC picked-off beam available that is currently just dumped (see picture). I want to use it for a beat note with the auxiliary laser pre-AOM so we can phaselock the lasers and then fast-switch the phaselocked light on and off. • I was going to use the ET3010 PD for the beat note unless someone else has plans for it. • I obtained a fixed triple-aspheric-lens collimator which is supposed to have a very small M^2 value for the collimation on the AS table. I still have the PSL-lab beam profiler and will measure its output mode. • Second attached picture shows the space on the AS table that we have for mode-matching into the IFO. Need to figure out the desired mode and how to merge the beams best. Attachment 1: PSLbeat.svg.png Attachment 2: ASpath.svg.png 13570 Tue Jan 23 16:02:05 2018 SteveConfigurationSEIload cells 1500 and 2000 lbs load cells arrived from MIT to measure the vertical loads on each leg.  Quote: We've been thinking about putting in a blade spring / wire based aluminum breadboard on top of the ETM & ITM stacks to get an extra factor of 10 in seismic attenuation. Today Koji and I wondered about whether we could instead put something on the outside of the chambers. We have frozen the STACIS system because it produces a lot of excess noise below 1 Hz while isolating in the 5-50 Hz band. But there is a small gap between the STACIS and the blue crossbeams that attache to the beams that go into the vacuum to support the stack. One possibility is to put in a small compliant piece in there to gives us some isolation in the 10-30 Hz band where we are using up a lot of the control range. The SLM series mounts from Barry Controls seems to do the trick. Depending on the load, we can get a 3-4 Hz resonant frequency. Steve, can you please figure out how to measure what the vertical load is on each of the STACIS? Attachment 1: stacis3LoadCells.png Attachment 2: DSC00025.JPG Attachment 3: DSC00026.JPG 13681 Tue Mar 13 20:03:16 2018 johannesConfigurationComputersc1auxex replacement I assembled the rack-mount server that will long-term replace c1auxex, so we can return the borrowed unit to Larry. • Intel Atom N2800 (2 cores, 1.8GHz, 1MB, 64-bit) • 4GB (2x2GB) DDR3 RAM • 128 GB SSD I installed a standard Debian Jessie distribution, with option LXDE for minimal resource usage. Steps taken after fresh install 1. Give controls sudo permission: usermod -aG sudo controls 2. mkdir /cvs/cds 3. apt-get install nfs-common 4. Added line "chiara:/home/cds /cvs/cds nfs rw,bg,nfsvers=3" to end of /etc/fstab 5. Configured network adapter in /etc/network/interfaces  iface eth0 inet static address 192.168.113.48 netmask 255.255.255.0 gateway 192.168.113.2 dns-nameservers 192.168.113.104 131.215.125.1 131.215.139.100 dns-search martian I first assigned the IP 192.168.113.59 of the original c1auxex, but for some reason my ssh connections kept failing mid-session. After I switched to a different IP the disruption no longer happened. 6. Add lines "search martian" and "nameserver 192.168.113.104" to /etc/resolv.conf 7. apt-get install openssh-server At this point the unit was ready for remote connections on the martian network, and I moved it to the XEND. 8. Added lines to /home/controls/.bashrc to set paths and environment variables: export PATH=/cvs/cds/rtapps/epics-3.14.12.2_long/base/bin/linux-x86_64:/cvs/cds/rtapps/epics-3.14.12.2_long/extensions/bin/linux-x86_64:$PATH export HOST_ARCH=linux-x86_64 export EPICS_HOST_ARCH=linux-x86_64 export RPN_DEFNS=~/.defns.rpn export LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:/cvs/cds/rtapps/epics-3.14.12.2_long/base/lib/linux-x86_64:/cvs/cds/rtapps/epics-3.14.12.2_long/modules/modbus/lib/linux-x86_64/:/cvs/cds/rtapps/epics-3.14.12.2_long/modules/asyn/lib/linux-x86_64
9. apt-get install libmotif-common libmotif4 libxp6 (required to run burtwb utility)

The server is ready to take over for c1auxex2 and does not need any local epics compiled, since it can run the 3.14.12.2_long binaries in /cvs/cds.

Attachment 1: IMG_20180313_105154890.jpg
Attachment 2: IMG_20180313_133031002.jpg
13682   Wed Mar 14 23:58:30 2018 johannesConfigurationComputersc1auxex replacement

I replaced the borrowed server with the permanent one today. Before Removing the current server, Before, I performed several additional preparations:

• Updated Chiara hostables to IP 192.168.113.48 for c1auxex
• apt-get install procserv
• copied ETMXaux2.* files in /cvs/cds/caltech/target/c1auxex2 to ETMXaux.* and changed references from /opt/rtcds/epics (which was a local directory on c1auxex2) to /cvs/cds/rtapps/epics-3.14.12.2_long in the copied files
Environment="LD_LIBRARY_PATH=/cvs/cds/rtapps/epics-3.14.12.2_long/base/lib/linux-x86_64:/cvs/cds/rtapps/epics-3.14.12.2_long/modules/modbus/lib/linux-x86_64/:/cvs/cds/rtapps/epics-3.14.12.2_long/modules/asyn/lib/linux-x86_64"
to /etc/systemd/system/modbusIOC.service  (required for burtwb dependencies)

Then I replaced the server:

1. IFO was in LSC mode with both arms locked
2. Backed up ETMX alignment using save feature in IFOalign screen
3. Disengaged LSC mode
4. Shut down ETMX watchdog
5. Disconnected ETMX satellite box
6. Shut down c1auxex2 and c1auxex
7. Performed the server swap
8. Booted c1auxex
9. Made sure EPICS channels were back online and channel defaults were restored
10. Reconnected satellite box
11. Turned on watchdog
12. Turned on OpLevs
13. Engaged LSC mode -> both arms were instantly locked

I returned c1auxex2 to Larry, who needed it back asap because of some hardware failure

Steve: Acromag XT1221 ordered 3-15-18

13687   Mon Mar 19 14:39:09 2018 johannesConfigurationComputersc1auxex replacement

[gautam, johannes]

The temperature control output channel for the XEND seismometer wasn't working properly. The EPICS channel existed, could be written to and read from, but no physical voltage was observed on the (confirmed properly) wired connector.

The Acromag DAC that outputs this channel was completely spare in the original scheme and does not serve any other channels at the moment. We found it to be unresponsive to ping from the host machine (reminder: the Acromags are on their own subnet with IPs 192.168.114.xxx connected to the secondary ethernet adapter of c1auxex), while all others returned the ping just fine. The modules have daisy-chained ethernet connections, and the one Acromag unit behind the unresponsive one in the chain was still responding to ping and its channels were working, so it couldn't have been a problem with the (ethernet) cabling.

Gautam and I power-cycled the chassis and server, which resolved the issue. The channel is now outputting the requested voltage on the Out1 BNC connector of the chassis (front). When I was setting up the whole system and did frequent rebooting and IP-redefinitions I have seen network issues arise between server and Acromags. In particular, when changing the network settings server-side, the Acromags needed to reboot occasionally. So this whole problem was probably due to the recent server-swap, as the chassis had not been power-cycled since.

During the debugging we also found that the c1psl2 channels were not working. This was because I had overlooked to update the epics environment variables for the modbus path defined in /cvs/cds/caltech/target/c1psl2/npro_config.cmd from the local installation /opt/epics/ (which doesn't exist on the new server anymore) to the network location /cvs/cds/rtapps/epics-3.14.12.2_long/. This has been fixed and the slow diagnostic PSL channels are recording again.

13742   Mon Apr 9 23:28:49 2018 johannesConfigurationDAQc1psl channel list

I made a list of all the physical c1psl channels to get a better idea for how many acromags we need to replace it eventually. There  3123 unit is the one whose failure had prevented c1psl from booting, which is why it was unplugged (elog post 12852), and its channels have been inactive since. Are the 126MOPA channels used for the current mephisto? 126 tells me it's for an old lightwave laser, but I was checking a few and found that they have non-zero, changing values, so they may have been rewired.

It also hosts some virtual channels for the ISS with root C1:PSL-ISS_ defined in iss.db and dc.db, the PSL particle counter with root C1:PEM- defined in PCount.db  and a whole lot of PSL status channels defined in pslstatus.db. Transfering these virtual channels to a different machine is almost trivial, but the serial readout of the particle counter would have to find a new home.

Long story short - we need:

 Function Type # Channels #Channels (no MOPA) # Units # Units (no MOPA) ADC XT1221 34 21 5 3 DAC XT1541 17 14 3 2 BIO XT1111 19 10 2 1

C1:PSL-126MOPA_126PWR
C1:PSL-126MOPA_DTMP
C1:PSL-126MOPA_LTMP
C1:PSL-126MOPA_DMON
C1:PSL-126MOPA_LMON
C1:PSL-126MOPA_CURMON
C1:PSL-126MOPA_DTEC
C1:PSL-126MOPA_LTEC
C1:PSL-126MOPA_CURMON2
C1:PSL-126MOPA_HTEMP
C1:PSL-126MOPA_HTEMPSET
C1:PSL-FSS_RFPDDC
C1:PSL-FSS_LODET
C1:PSL-FSS_FAST
C1:PSL-FSS_PCDRIVE
C1:PSL-FSS_MODET
C1:PSL-FSS_VCODETPWR
C1:PSL-FSS_TIDALOUT
C1:PSL-PMC_RFPDDC
C1:PSL-PMC_LODET
C1:PSL-PMC_PZT
C1:PSL-PMC_MODET

C1:PSL-126MOPA_AMPMON
C1:PSL-126MOPA_126MON
C1:PSL-FSS_RCTRANSPD
C1:PSL-FSS_MINCOMEAS
C1:PSL-FSS_RMTEMP
C1:PSL-FSS_RCTEMP
C1:PSL-FSS_MIXERM
C1:PSL-FSS_SLOWM
C1:PSL-FSS_TIDALINPUT
C1:PSL-PMC_PMCTRANSPD
C1:PSL-PMC_PMCERR
C1:PSL-PPKTP_TEMP

## 4116 - DAC

C1:PSL-126MOPA_DCAMP
C1:PSL-126MOPA_DCAMP-
C1:PSL-FSS_INOFFSET
C1:PSL-FSS_MGAIN
C1:PSL-FSS_FASTGAIN
C1:PSL-FSS_PHCON
C1:PSL-FSS_SLOWDC
C1:PSL-FSS_VCOMODLEVEL
C1:PSL-FSS_TIDAL
C1:PSL-FSS_TIDALSET
C1:PSL-PMC_GAIN
C1:PSL-PMC_INOFFSET
C1:PSL-PMC_PHCON
C1:PSL-PMC_RAMP

## XVME-210 - Binary Input

C1:PSL-126MOPA_FAULT
C1:PSL-126MOPA_INTERLOCK
C1:PSL-126MOPA_SHUTTER
C1:PSL-126MOPA_126LASE
C1:PSL-126MOPA_AMPON

## XVME-220 - Binary Output

C1:PSL-126MOPA_126NE
C1:PSL-126MOPA_126STANDBY
C1:PSL-126MOPA_SHUTOPENEX
C1:PSL-126MOPA_STANDBY
C1:PSL-FSS_SW1
C1:PSL-FSS_SW2
C1:PSL-FSS_FASTSWEEP
C1:PSL-FSS_PHFLIP
C1:PSL-FSS_VCOTESTSW
C1:PSL-FSS_VCOWIDESW
C1:PSL-PMC_SW1
C1:PSL-PMC_SW2
C1:PSL-PMC_PHFLIP
C1:PSL-PMC_BLANK

13761   Wed Apr 18 17:15:35 2018 ranaConfigurationComputersNODUS: no xmgrace for dataviewer

Turns out, there is no RPM for XmGrace on Scientific Linux 7. Since this is the graphic output of dataviewer, we can't use dataviewer through X windows until this gets fixed. CDS is looking into a xmGrace replacement, but it would be better if we can hijack a alt RH repo to steal a temporary xmgrace RPM. KT has been pinged.

13764   Wed Apr 18 22:46:23 2018 johannesConfigurationGeneralAS port laser injection

Using Gautam's Finesse file and the cad files for the 40m optical setup I propagated the arm mode out of the AS port. For the location of the 3.04 mm waist I used the average distance to the ITMs, which is 11.321 m from the beam spot on the 2 inch mirror on the AS table close to the viewport. The 2inch lens focuses the IFO mode to a 82.6 μm waist at a distance of 81 cm, which is what we have to match the aux laser fiber output to.

I profiled the fiber output and obtained a waist of 289.4 μm at a distance of 93.3 cm from the front edge of the base of the fiber mount. Next step is to figure out the lens placement and how to merge the beam paths. We could use a simple mirror if we don't need AS110 and AS55, we could use a polarizing BS and work with s polarization, or we find a Faraday Isolator.

While doing a beam scan with the razor blade method I noticed that the aux laser has significant intensity noise. This is seen on the New Focus 1611 that is used for the beat signal between PSL and aux laser, as well as on the fiber output PD. There is a strong oscillation around 210 kHz. The oscillation frequency decreases when the output power is turned down, the noise eater has no effect. Koji suggested it could be light scattering back into the laser because I couldn't find a usable Faraday Isolator back when I installed the aux laser in the PSL enclosure. I'll have to investigate this a little further, look at the spectrum, etc. This intensity noise will appear as amplitude noise of the beat note, which worries me a little.

Attachment 1: ASpath.svg.png
13766   Thu Apr 19 01:04:00 2018 gautamConfigurationGeneralAS port laser injection

For the arm cavity ringdowns, I guess we don't need AS55/AS110 (although I think the camera will still be useful for alignment). But for something like RC Gouy phase characterization, I'd imagine we need the AS detectors to lock various cavities. So I think we should go for a solution that doesn't disturb the AS PD beams.

It's hard to tell from the plot in the manual (pg 52) what exactly the relaxation oscillation frequency is, but I think it's closer to 600 kHz (is this characteristic of NdYAG NPROs)??  Is the high RIN on the light straight out of the NPRO?

 Quote: We could use a simple mirror if we don't need AS110 and AS55, we could use a polarizing BS and work with s polarization, or we find a Faraday Isolator. There is a strong oscillation around 210 kHz. The oscillation frequency decreases when the output power is turned down, the noise eater has no effect.
13772   Thu Apr 19 20:41:09 2018 KojiConfigurationGeneralAux Laser LD dying? (AS port laser injection)

I suspect that the LD of the aux laser is dying.
- The max power we obtain from this laser (700mW NPRO) is 33mW. Yes, 33mW. (See attachment 1)
- The intensity noise is likely to be relaxation oscillation and the frequency is so low as the pump power is low. When the ADJ is adjusted to 0, the peak moved even lower. (Attachment 2, compare purple and red)
- What the NE (noise eater) doing? Almost nothing. I suspect the ISS gain is too low because of the low output power. (Attachment 2, compare green and red)

Attachment 2: Aux_laser_RIN.pdf
13781   Tue Apr 24 08:36:47 2018 johannesConfigurationGeneralAux Laser LD dying? (AS port laser injection)

In September 2017 I measured ~150mW output power, which was already kind of low. What are the chances of getting this one repaired? Steve, can you please check the serial number? It's probably too old like the other ones.

 Quote: I suspect that the LD of the aux laser is dying. - The max power we obtain from this laser (700mW NPRO) is 33mW. Yes, 33mW. (See attachment 1)

13784   Tue Apr 24 11:31:59 2018 gautamConfigurationALSProposed changes to EX fiber coupling

Motivation: I want to make another measurement of the out-of-loop ALS beat noise, with improved MM into both the PSL and EX fibers and also better polarization control. For this, I want to make a few changes at the EX table.

1. Replace existing fiber collimator with one of the recently acquired F220-APC-1064 collimators.
• This gives an output mode of diameter 2.4mm with a beam divergence angle of 0.032 degrees (all numbers theoretical - I will measure these eventually but we need a beam path of ~5m length in order to get a good measurement of this collimated beam).
• I believe it will be easier to achieve good mode matching into this mode rather than with the existing collimator.
• Unfortunately, the mount is still going to be K6X and not K6XS.
2. Improve mode-matching into fiber.
• I used my measurement of the Innolight NPRO mode from 2016, a list of available lenses, and some measured distances to calculate a solution that gives theoretical 100% overlap with the collimator mode, that has beam diameter 2.4mm, located 80cm from the NPRO shutter head location (see Attachment #1).
• The required movement of components is schematically illustrated in Attachment #2.
• One of the required lens positions is close to the bracket holding the enclosure to the table, but I think the solution is still workable (the table is pretty crowded so I didn't bother too much with trying to find alternative solutions as all of them are likely to require optics placed close to existing ones and I'd like to avoid messing with the main green beam paths.
• I will attempt to implement this and see how much mode matching we actually end up getting.
3. Install a PBS + HWP combo in the EX fiber coupling path.
• This is for better polarization control.
• Also gives us more control over how much light is coupled into the fiber in a better way than with the ND filters in current path.
4. Clean EX fiber tip.
5. Dump a leakage IR beam from the harmonic separator post doubling oven, which is currently just hitting the enclosure. It looks pretty low power but I didn't measure it.
6. Re-install EX power monitoring PD.

Barring objections, I will start working on these changes later today.

Attachment 1: EX_fiber_MM.pdf
Attachment 2: EX_fiber_changes.png
13786   Tue Apr 24 18:54:15 2018 gautamConfigurationALSProposed changes to EX fiber coupling

I started working on the EX table. Work is ongoing so I will finish this up later in the evening, but in case anyone is wondering why there is no green light...

1. EX laser shutter was closed.
2. Disconnected EX input to the beat mouth at the PSL table in order to avoid accidentally frying the PDs.
3. Prepared new optomechanics hardware
• To my surprise, I found a bubble-wrapped K6XS mount (the one with locking screws for all DoFs) on the SP table. No idea where this came from or who brought it here, or how long it has been here, but I decided to use it nevertheless.
• Prepared f = 200mm and f = -200mm lenses on traveling mounts (Thorlabs DT12, lenses are also Thorlabs, AR1064).
• Made a slight translation of the beam path towards the north to facilitate going through the center of the mounted lenses.
• Temporarily removed a beam dump from next to the final steering mirror before the Green REFL PD, and also removed one of the brackets between the enclosure and the table for ease of laying out components. These will be replaced later.
4. Installed this hardware on the PSL table, roughly aligned beam path.
• Beam now goes through the center of all lenses and is hitting the collimator roughly in the center.

To do in the eve:

1. Clean fiber and connect it to the collimator.
2. Optimize mode-matching as best as possible.
3. Attenuate power using PBS and HWP so as to not damage the BeatMouth PD (Pthresh = 2mW). These are also required to make the polarizations of the EX coupled light (S-pol) and PSL (P-pol) go along the same axis of the PM fiber.
4. Re-install temporarily removed beam dump and bracket on EX table.
5. Re-install EX power monitoring PD.
6. Measure beat frequency spectrum.
 Quote: Motivation: I want to make another measurement of the out-of-loop ALS beat noise, with improved MM into both the PSL and EX fibers and also better polarization control. For this, I want to make a few changes at the EX table.  Barring objections, I will start working on these changes later today.

gautam 1245am: Fiber cleaning was done - I'll upload pics tomorrow, but it seems like the fiber was in need of a good cleaning. I did some initial mode-matching attempts, but peaked at 10% MM. Koji suggested not going for the final precisely tunable lens mounting solution while trying to perfect the MM. So I'll use easier to move mounts for the initial tuning and then swap out the DT12s once I have achieved good MM. Note that without any attenuation optics in place, 24.81mW of power is incident on the collimator. In order to facilitate easy debugging, I have connected the spare fiber from PSL to EX at the PSL table to the main EX fiber - this allows me to continuously monitor the power coupled into the fiber at the EX table while I tweak lens positions and alignment. After a bit of struggle, I noticed I had neglected a f=150mm lens in my earlier calculation - I've now included it again, and happily, there seems to be a solution which yields the theoretical 100% MM efficiency. I'll work on implementing this tomorrow..

13789   Wed Apr 25 19:09:37 2018 gautamConfigurationALSNew look EX Fiber coupling

Summary:

I implemented most of the things outlined in my previous elog. Implementing the a la mode solution after including all lenses, I managed to achieve >90% mode-matching into the fiber. Power monitor PD has not been re-installed yet, neither has the bracket I removed. The polarization monitoring setup on the PSL table has now been hooked up to the EX fiber, let's see how it does overnight. All quoted power measurements in this elog were made with the Ophir power meter (filter off).

Details:

Attachment #1 shows the implemented MM solution. I did not include the PBS substrate in the calculation, maybe that will help a little.

Attachment #2 shows the new layout. The beam is a little low on the PBS and HWP - I will swap these out to mounts with slightly lower height, that should improve the situation a little. There is no evidence of clipping, and the beam clears all edges by at least 3 beam diameters.

Attachments #3 and #4 show the EX fiber before and after cleaning respectively. Seems like the cleaning was successful.

Attachment #5 shows the beam incident on the coupler with on an IR card. This beam only goes through a QWP, lens, BS and 45 degree steering mirror, so I'm not sure what's responsible for the large halo around the main beam. There is significant power in the halo too - I measured 25mW right before the coupler, but if I use an iris to try and cut off the halo, the power is measured to be ~19mW.

Alignment Procedure:

• Connect spare fiber such that I can monitor coupled power (minus fiber losses and joint loss) at EX table.
• Use Fluke fault analyzer to align input and collimator modes coarsely.
• Monitored coupled power continuously using Fiber Power Meter (although MM calculations were made with Ophir, this was more convenient for "Live" viewing).
• Tweaked one available steering mirror and K6XS axes to maximize coupled power.
• Tweaked lens positions slightly to see if significant improvement could be made.
• After optimizing, I measured 17.1mW coming out of the EX fiber at the PSL table. As mentioned earlier, the input power is tricky to measure given the large amount of junk light around the main mode. But I measured 18.6 mW after the iris. So this is ~95%. In any case, safe to say that we are waaaay better than the previous situation of 380uW out of 1.9mW.
• Added PBS and HWP to cut the incident power to 1.6mW. I measured 1.2mW on the PSL table. Probably adding the PBS screwed up the MM a bit, to be tweaked tomorrow.
• I had moved the Green shutter a bit during this work - as a result, the Green REFL was not making it back to the REFL PD. I remedied this, and EX Green TEM00 mode was locked to the arm. GTRX of ~0.4 was recovered, which is around the number I'm used to seeing.
Attachment 1: EX_fiber_MM.pdf
Attachment 2: IMG_6977.JPG
Attachment 3: IMG_6972.JPG
Attachment 4: IMG_6974.JPG
Attachment 5: IMG_6976.JPG
13791   Thu Apr 26 11:24:50 2018 gautamConfigurationALSNew look EX Fiber coupling - pol stability

Here is a first look at the overnight stability. For the temperature, I used the calibration I found in the old psl database file, seems to give sensible results. It's only 15 hours of data plotted, so we don't see the full 24 hour temperature swing, but I think it is safe to say that for the EX fiber, the dominant cause of the "waveplate effect" is not in fact temperature drift. The polarization extinction is still better than 10dB in the entire period of observation though... I'm going to push ahead with a beat spectrum measurement, though there is room for improvement in the input coupling alignment to fiber special axes.

The apparent increase in these plots towards the end of the 15 hour period is because the lights on the PSL table were switched on.

Annoyingly, it seems like the PSL NPRO channels (which I have hijacked to do this test) do not have minute trend data directly accessible from NDS2. Not sure whether this is an NDS2 problem, or something missing in the way the channels are setup with Acromag. Probably the former, as I am able to generate minute trend plots with dataviewer. I forget whether this is the same as the infamous minute trend problem. Second trend data is available though, and is what I used to make these plots...

Attachment 1: polStab.pdf
13792   Thu Apr 26 18:58:21 2018 BruceConfigurationALSNew look EX Fiber coupling - pol stability

13796   Fri Apr 27 01:36:02 2018 gautamConfigurationALSIR ALS noise performance

Summary:

My goal was to do some further characterization of the IR ALS system tonight. With POX as an OOL sensor, I measured an RMS displacement noise of  8 pm with the arm under ALS control. I calculated the CARM linewidth to be 77 Hz (=10.3 pm) for the 40m parameters, assuming 30ppm arm loss. Fuurthermore, this number is 3x better than the 24 pm RMS quoted in the Izumi et. al. paper. Of course I am quoting the best results from my efforts tonight. Conclusions:

1. [Attachment #1] --- With XARM locked using POX, the ALS beat noise (i.e. Phase Tracker output noise) lines up well with the reference we have been using for some time now (and indeed, is better in some places).
2. [Attachment #2] --- With the arm locked on ALS and POX as an OOL sensor, I measured performance comparable to this measurement we did sometime last year. Anomalies in this measurement and the one above were what precipitated the IMC noise investigation.
3. [Attachment #3] --- The above two attachments are not the whole story. During the day, I get significantly worse performance (so much so that I couldn't even do the handoff to ALS control). But in 5 minutes of measurement, the ALS noise seems quite stationary.
4. [Attachment #4] --- This is really the same as Attachment #2, but I wanted to overlay some vlines. Maybe this is a clue to some 60 Hz / ground loop issues, but the RMS has significant contribution from these harmonics. Tmrw, I will add the old measurement overlaid to this plot (and for what its worth, the Izumi et. al. spectrum as well).
5. [Attachment #5] --- With the arm under ALS control, I was able to maintain the lock for a solid hour (and more as I write up this elog). Somehow inkscape screwed up the fonts, but main point here is that TRX is stable to within 10% throughout the observation time.

Since the stability and noise seemed quite good, I decided to collect some arm scan data to give to our modeSpec SURFs to practice fitting (which is the short dip in TRX in Attachment #4). Although after the discussion with Rana today, I think it may be that we want to do this measurement in reflection and not transmission, and look for a zero crossing in the PDH signal. In any case, I was able to scan 7 FSRs without any issues. I will upload the data to some git repo. GPS start time is 1208850775, sweep was 3mins long.

I think the next step here is to noise-budget this curve. At least the DFD noises

Attachment 1: 2018_04_BeatMouth_POX.pdf
Attachment 2: 2018_04_BeatMouth.pdf
Attachment 3: ALSSpecgram.pdf
Attachment 4: ALS_ASD.pdf
Attachment 5: ALSstab.pdf
13802   Tue May 1 08:04:13 2018 Jon RichardsonConfigurationElectronicsPSL-Aux. Laser Phase-Locked Loop

[Jon, Gautam, Johannes]

Summary: In support of making a proof-of-concept RF measurement of the SRC Gouy phase, we've implemented a PLL of the aux. 700mW NPRO laser frequency to the PSL. The lock was demonstrated to hold for minutes time scales, at which point the slow (currently uncontrolled) thermal drift of the aux. laser appears to exceed the PZT dynamic range. New (temporary) hardware is set up on an analyzer cart beside the PSL launch table.

Next steps:

- Characterize PLL stability and noise performance (transfer functions).

- Align and mode-match aux. beam from the AS table into the interferometer.

- With the IFO locked in a signal-recycled Michelson configuration, inject broadband (swept) AM sidebands via the aux. laser AOM. Coherently measure the reflection of the driven AM from the SRC.

- Experiment with methods of creating higher-order modes (partially occluding the beam vs. misaligning into, e.g., the output Faraday isolator). The goal is identify a viable techinque that is also possible at the sites, where the squeezer laser serves as the aux. laser.

The full measurement idea is sketched in the attached PDF.

Attachment 1: IMG_2553.jpg
Attachment 4: src_gouy_phase_v3.pdf
13807   Wed May 2 21:39:33 2018 gautamConfigurationALSIR ALS for EY

The new K6XS mounts I ordered have arrived. I want to install one of them at the Y-end. I can't find a picture of the current layout but it exists as there is a hardcopy affixed to the ETMY chamber door, Steve, can we dig this up and put it in the wiki? In any case, the current beam going into the fiber is the pickoff from the post-SHG harmonic separator. I'd like to change the layout a bit, and use a pickoff before the doubling oven, but looking at the optical table, this seems like a pretty involved task and would probably require large scale optical hardware rearrangement. In any case, the MM of the green beam into the Y-arm is <50%, so I would like to redo that as well. Does anyone know of a measurement of the mode from the Lightwave NPRO that is installed at EY? I think Annalisa is the one who installed this stuff, but I can't find an actual NPRO mode measurement in her elog thread.

Found it: elog4874, elog8436. I updated the laser inventory page to link the lasers in use to the most recent mode measurements I could find on the elog. I guess ideally we should also link the AM/PM response measurements.

------------------------------------------------------------------------------------------------------

as of 3-31-2016

The oplev path was optimized with AR coated lenses and new He/Ne laser Jan 24, 2017

13810   Thu May 3 10:40:43 2018 johannesConfigurationGeneralAS port laser injection

Instead of trying to couple the fiber output into the interferometer, I'm doing the reverse and maximize the amount of interferometer light going into the fiber. I set up the mode-matching solution shown in attachment #1 and started tweaking the lens positions. Attachment #2 shows the setup on the AS table. After the initial placement I kept moving the lenses in the green arrow directions and got more and more light into the fiber.

When I stopped this work yesterday I measured 86% of the AS port light coming out the other fiber end, and I have not yet reached a turning point with moving the lenses, so it's possible I can tickle out a little more than that.

It occured to me though that I may have been a little hasty with the placement of the mirror that in attachment #2 redirects the beam which would ordinarily go to AS55. For my arm ringdown measurements this doesn't matter, I could actually place it even before the 50/50 beamsplitter that sends light onto AS110 and double the amount of light going into the IFO. What signals are needed for the Guoy phase measurement? Is AS 110 sufficient, or do we need AS55?

Attachment 1: mm_solution_AStable.png
Attachment 2: AStable_beampath.pdf
13811   Thu May 3 12:10:12 2018 gautamConfigurationGeneralAS port laser injection

I think we need AS55 for locking the configuration Jon suggested - AS55 I and Q were used to lock the SRMI previously, and so I'd like to start from those settings but perhaps there is a way to do this with AS110 I and Q as well.

 Quote: What signals are needed for the Guoy phase measurement? Is AS 110 sufficient, or do we need AS55?

13813   Thu May 3 20:29:39 2018 gautamConfigurationElectronicsPSL-Aux. Laser Phase-Locked Loop

Some notes about the setup and work at the PSL table today, Jon can add to / correct me.

• All equipment for the phase locking now sit on a cart that is on the west side of the MC beam tube, near ITMX chamber.
• Cables have been routed through the space between the PSL enclosure and the optical table.
• HEPA was turned up for this work, now it has been turned down to the nominal level of 30%.
• Alignment into the PMC had degraded a bit - I tweaked it and now MC transmission is up at ~15600 which is a number I am used to. We still don't have a PMC transmission monitor since the slow ADC failure.
13814   Fri May 4 13:24:56 2018 Jon RichardsonConfigurationElectronicsAUX-PSL PLL Implementation & Characterization

Attached are final details of the phase-locked loop (PLL) implementation we'll use for slaving the AUX 700 mW NPRO laser to the PSL.

The first image is a schematic of the electronics used to create the analog loop. They are curently housed on an analyzer cart beside the PSL table. If this setup is made permanent, we will move them to a location inside the PSL table enclosure.

The second image is the measured transfer function of the closed loop. It achieves approximately 20 dB of noise suppression at low frequencies, with a UGF of 50 kHz. In this configuration, locks were observed to hold for 10s of minutes.

Attachment 1: PLL_Schematic.pdf
Attachment 2: PLL_AUX-PSL_40m.pdf
13816   Fri May 4 19:06:28 2018 ranaConfigurationElectronicsAUX-PSL PLL Implementation & Characterization

this doesn't make much sense to me; the phase to frequency conversion (mixer-demod to PZT ) should give us a 1/f loop as Johannes mentioned in the meeting. That doesn't agree with your loop shape.

How about give us some more details of the setup including photos and signal/power levels? And maybe measure the LB1005 TF by itself to find out what's wrong with the loop.

13817   Fri May 4 21:17:57 2018 gautamConfigurationALSBeathMouth pulled out of PSL table

I have been puzzled about the beat note level we get out of the BeatMouth for some time.

• The beat PD used is the Menlo FPD310.
• But the version we have is an obsolete version of the product, for which a manual is hard to find.
• Hence, I don't know the transimpedance/electrical characteristics of this PD.
• The optical damage threshold of the PD is quoted as 2mW, which is a number I have been careful not to exceed.
• But I've felt that the beat amplitude level we get out of this PD is far too low considering the amount of DC optical power (as measured with a fiber power meter) incident on the PD.
• After some emailing and online hunting, I've gathered some numbers for the PD which are now on the wiki.
• The fiber beam splitters we use inside the BeatMouth don't have PM fibers. There are 3 such splitters inside the BeatMouth. So the overlap efficiency on the PD is unknown.
• But even so, the beat levels I was seeing were too low.

I have pulled the box out in order to re-characterize the DC power levels incident on the PD, and also to change the gain setting on the PD to the lower gain which is more compatible with the level of optical power we have going into the BeatMouth. The modern catalog for the FPD310 (see wiki) suggests that the maximum output voltage swing of the PD is 1Vpp driving a 50ohm load. With 50% overlapping efficiency between the PSL and AUX beams, and 400 uW of optical power from each beam, I expect an output of 0.5Vpp. Even with perfect overlap, I expect 0.8Vpp. So these numbers seem reasonable.

I also plan to check the scaling of electrical beat amplitude to optical power for a couple of levels to see that these scale as expected...

13824   Tue May 8 00:40:51 2018 gautamConfigurationALSBeathMouth pulled out of PSL table

Summary:

I did some more BeatMouth characterization. My primary objective was to do a power budget. Specifically, to measure the insertion loss of the mating sleeves and of the fiber beam splitters. All power numbers quoted in this elog are measured with the fiber power meter. Main takeaways:

• Measured insertion loss of all mating sleeves, which are ADAFCPMB2, are in agreement with the < 1dB spec. 1 dB in power is ~20%.
• But there is large variance in the above number, between different supposedly identical connectors.
• Measured insertion loss from input port to coupled ports of the fiber beamsplitters are slightly larger than spec (~3.5dB), when measured after mating the fiber beamsplitter (which has Hi1060 flex fiber) and PM980 fiber (which is what brings light to the BeatMouth).
• But measured insertion loss when mating is between Hi1060 flex fiber ends is more in line with the expected value of ~3.5dB.
• Isolation of fiber beam splitters seems to match the spec of >55dB.

Results:

• I used the fiber bringing 416uW of IR light from EY for this test.
• Insertion loss was measured by injecting the fiber light at one port and measuring the transmitted power at various other ports.
• In order to couple the fiber power meter across a single mating sleeve, I used a short (~1m) patch cable from newport (F-SY-C-1FCA). Technically, this is single mode fiber with the correct type of connector, FC/APC, but is not PM.
• See Attachment #2 for the labeling of the connectors which is how I refer to them in the table below.
• Lest there be confusion, I use the definition of insertion loss  $\mathrm{Insertion ~loss [dB] }=10\mathrm{log_{10}}(\frac{P_{in}}{P_{out}})$.
Mating Sleeve # Insertion loss [dB]
1 0.38
2 0.65
3 0.71
4 0.43
5 0.95
6 0.79
7 0.5

Remarks / Questions:

1. Is there any way to systematically reduce the insertion loss? Like getting a better mating part?
2. Question for the fiber experts: How do we deal with the unused port of the beam-splitters? Right now, they are just capped. But as you can see in Attachment #1, the caps certainly don't block all the light. What are the implications of back-scattered light into the fiber on the ALS noise? I guess the beamsplitter itself has the spec'd 55dB directivity, so do we not care about this?
Attachment 1: IMG_6986.JPG
Attachment 2: IMG_6987.JPG
13845   Tue May 15 20:51:27 2018 gautamConfigurationElectronicsMaking PLL setup more permanent

[jon, steve, gautam]

Some points which Jon will elaborate upon (and put photos of) in his detailed elog about this setup:

• PLL electronics (mixer, coupler, ZFL500HLN amplifier and DC power supply for the beatnote, SR560 servo) all reside on the newly installed lower level PSL shelf.
• Cross connect channel C1:PSL-126MOPA_126CURADJ hijacked for remote temperature control of the AUX NPRO. Note that shield of front panel BNC is ground and so even though the manual says the controller accepts +/-10V, this is not a differential input. BNC cable was routed from cross connect to PSL enclosure, MEDM slider will be setup.
• There was an SMA cable running from the VEA to the control room which we decided to use for monitoring of the beatnote amplitude on the control room analyzer. Yesterday, Steve and I routed the end of this inside the VEA, near 1X2 originally, to inside the PSL table where it is hooked up to the (20dB) coupled amplifier output. This required some work on the cable tray, we were careful but in case there is some wonkiness in some signals, perhaps this work is to blame.

We are now in a state where the PLL can be locked remotely from the control room by tweaking the AUX laser temperature . Tomorrow, Keerthana will work on getting Craig's/Johannes' Digital Frequency Counter script working here, I think we can easily implement a PLL autolocker if we have some diagostic that tells us if the PLL us locked or not.

Steve informed me that there is an acoustic hum inside the PSL enclosure which wasn't there before. Indeed, it is at ~295Hz, and is from the Bench power supply used to power the ZFL500HLN amplifier. This will have to go...

13848   Wed May 16 18:52:50 2018 gautamConfigurationElectronicsPLL mysteries solved

[Koji, Gautam]

Summary:

As I suspected, when the SR560 is operated in 1 Hz, first order LPF mode, the (electronic) transfer function has a zero at ~5kHz (!!!).

Details:

This is what allowed the PLL to be locked with this setting with UGF of ~30kHz. On the evidence of Attachment #3, there is also some flattening of the electrical TF at low frequencies when the SR560 is driving the NPRO PZT. I'm pretty sure the flattening is not a data download error but since this issue needs further investigation anyway, I'm not reading too much into it. I fit the model with LISO but since we don't have low frequency (~1Hz) data, the fit isn't great, so I'm excluding it from the plots.

We also did some PLL loop characterization. We decided that the higher output range (10Vp bs 10Vpp for the SR560) of the LB1005 controller means it is a better option for the PLL. The lock state can also be triggered remotely. It was locked with UGF ~ 60kHz, PM ~45deg.

We also measured the actuation coefficient of the NPRO laser PZT to be 4.89 +/- 0.02 MHz/V. Quoted error is (1-sigma) from the fit of the linear part of the measured transfer function to a single pole at DC with unknown gain. I used the "clean" part of the measurement that extends to lower frequencies for the fit, as can be seen from the residuals plot. Good to know that even though the LDs are dying, the PZT is still going strong :D.

Remaining loop characterization (i.e. verification of correct scaling of in loop suppression with loop gain etc.) is left to Jon.

Measurement schemes:

1. OLG (Attachment #1) was measured using the usual IN1/IN2 technique.
2. PZT calibration (Attachment #2) was measured by injecting an excitation at the PLL control point.
• The ratio of the PLL error point (Volts) to Excitation (Volts) was measured using the SR785.
• The error point was calibrated by looking at the PLL open loop Vpp (corresponds to pi radians of phase shift).
• Dividing the fitted gain of the phase->Frequency conversion by the error point calibration, we get the PZT actuation coefficient.

Some other remarks:

1. In the swept-sine mode, the SR785 measures transfer functions by taking the ratio of complex FFT values of its inputs at the drive frequency. So the phase in particular is a good indicator of whether the measurement is coherent or not.
2. In all these measurements, the PLL gain is huge at low frequencies, and hence, the excitation is completely squished on propagating through the loop. E.g. a 10mV excitation is suppressed by a factor of ~60dB = 1000 to 10uV, and if the analyzer autoRange is set to UpOnly, it is easy to see how this is drowned at the IN1 input. This is why the measurements lose coherence below ~1 kHz.
3. It is easy to imagine implementing an EPICS servo that offloads the DC part of the LB box control signal to the SLOW frequency input on the Lightwave controller. This would presumably allow us to extend the lock timescales. We can also easily implement a PLL autolocker.
4. Preliminary investigation of the SR560 situation suggests that individual filter stages can only achieve a maximum stopband attenuation of 60dB relative to the passband. When we cascade two stages together, 120dB seems possible...
Attachment 1: PLLanalysis.pdf
Attachment 2: PZTcal.pdf
Attachment 3: SR560_funkiness.pdf
13858   Thu May 17 13:51:35 2018 Jon RichardsonConfigurationElectronicsDocumentation & Schematics for AUX-PSL PLL

[Jon, Gautam]

Attached is supporting documentation for the AUX-PSL PLL electronics installed in the lower PSL shelf, as referenced in #13845.

Some initial loop measurements by Gautam and Koji (#13848) compare the performance of the LB1005 vs. an SR560 as the controller, and find the LB1005 to be advantageous (a higher UGF and phase margin). I have some additional measurements which I'll post separately.

## Loop Design

Pickoffs of the AUX and PSL beams are routed onto a broadband-sensitive New Focus 1811 PD. The AUX laser temperature is tuned to place the optical beat note of the two fields near 50 MHz. The RF beat note is sensed by the AC-coupled PD channel, amplified, and mixed-down with a 50 MHz RF source to obtain a DC error signal. The down-converted term is isolated via a 1.9-MHz low-pass filter in parallel with a 50 Ohm resistor and fed into a Newport LB1005 proportional-integral (PI) servo controller. Controller settings are documented in the below schematic. The resulting control signal is fed back into the fast PZT actuator input of the AUX laser.

## Hardware Photos

13863   Fri May 18 14:18:03 2018 gautamConfigurationElectronicsBasic MEDM Control Screen setup

I setup a basic MEDM screen for remote control of the PLL.

The Slow control voltage slider allows the frequency of the laser to be moved around via the front panel slow control BNC.

The TTL signal slider provides 0/5V to allow triggering of the servo. Eventually this functionality will be transferred to the buttons (which do not work for now).

The screen can be accessed from the PSL dropdown menu in sitemap. We can make this better eventually, but this should suffice for initial setup.

Attachment 1: AUX_PLL_CTRL.png
13867   Fri May 18 19:59:55 2018 Jon RichardsonConfigurationElectronicsAUX-PSL PLL Characterization Measurements

Below is analysis of measurements I had taken of the AUX-PSL PLL using an SR560 as the servo controller (1 Hz single-pole low-pass, gain varied 100-500). The resulting transfer function is in good agreement with that found by Gautam and Koji (#13848). The optimal gain is found to be 200, which places the UGF at 15 kHz with a 45 deg phase margin.

For now I have reverted the PLL to use the SR560 instead of the LB1005. The issue with the LB1005 is that the TTL input for remote control only "freezes" the integrator, but does not actually reset it. This is fine if the lock is disabled in a controlled way (i.e., via the medm interface). However, if the lock is lost uncontrollably, the integrator is stuck in a garbage state that prevents re-locking. The only way to reset this integrator is to manually flip a switch on the controller box (no remote reset). Rana suggests we might be able to find a workaround using a remote-controlled relay before the controller.

Attachment 1: SR560_OL.pdf
Attachment 2: SR560_CL.pdf
13873   Mon May 21 15:34:19 2018 gautamConfigurationElectronicsChannel hijacking history

Since we've been hijacking channels like there is no tomorrow for the AUX-PLL setup, I'm documenting the channel names here. The next time c1psl requires a reboot, I'll rename these channels to something more sensible. To find the channel mapping, Koji suggested I use this. Has worked well for us so far... We've labelled all pairs of wires pulled out of the cross connects and insulation taped the stripped ends, in case we ever need to go back to the original config.

### Previously unused C1PSL Channels now used for AUX PLL

Channel name AI/AO Function
C1:PSL-126MOPA_126PWR AI PLL error signal monitor
C1:PSL-126MOPA_DMON AI PLL control signal monitor
C1:PSL-FSS_PHCON AO

To mitigate integrator railing

13876   Tue May 22 10:14:39 2018 Jon RichardsonConfigurationElectronicsDocumentation & Schematics for AUX-PSL PLL

Quote:

[Jon, Gautam]

Attached is supporting documentation for the AUX-PSL PLL electronics installed in the lower PSL shelf, as referenced in #13845.

Some initial loop measurements by Gautam and Koji (#13848) compare the performance of the LB1005 vs. an SR560 as the controller, and find the LB1005 to be advantageous (a higher UGF and phase margin). I have some additional measurements which I'll post separately.

## Loop Design

Pickoffs of the AUX and PSL beams are routed onto a broadband-sensitive New Focus 1811 PD. The AUX laser temperature is tuned to place the optical beat note of the two fields near 50 MHz. The RF beat note is sensed by the AC-coupled PD channel, amplified, and mixed-down with a 50 MHz RF source to obtain a DC error signal. The down-converted term is isolated via a 1.9-MHz low-pass filter in parallel with a 50 Ohm resistor and fed into a Newport LB1005 proportional-integral (PI) servo controller. Controller settings are documented in the below schematic. The resulting control signal is fed back into the fast PZT actuator input of the AUX laser.

## Hardware Photos

Attachment 1: Schematic_PLL.pdf
13881   Wed May 23 00:45:18 2018 johannesConfigurationGeneralAS port laser injection

I was planning to set up the additions to the AS table that are outlined in Attachment #1. Unfortunately the beam is too large for the 2mm clear aperture Faraday rotators that we have available at that position. I checked the 40m and QIL and found 5 Faraday isolators/rotators for 1064 nm total, but none have large enough aperture for the current setup. Some options for buying a larger aperture isolator are:

I wanted to leave the rest of the setup undisturbed at first, but I think a much easier solution would be to move the 2" focusing lens up by about 12", which moves the beam focus away from AS55 to where the Faraday will be placed, but we can re-focus it with another lens. I may have to change the mode-matching for the aux laser fiber slightly to accomodate this change, but if there are no other concerns I would like to start this work tomorrow (Wednesday).

13886   Thu May 24 13:06:17 2018 gautamConfigurationALSDFD noises

Summary:

1. The DFD noise floor is ~0.5Hz/rtHz at 100Hz (see Attachment #2).
2. I cannot account for the measured noise floor of the DFD system. The Marconi noise and the AA noise contributions should be neglibible at 100Hz.
3. This SURF report would lead me to believe that the delay line cable length is 50m. But my calibration suggests it is shorter, more like 40m (see Attachment #1). I had made some TF measurements of the delay sometime ago, need to dig up the data and see what number that measurement yields.

Details and discussion: (diagrams to follow)

• Delay line linearity was checked by driving the input with Marconi, waiting for any transient to die down, and averaging the I and Q inputs to the phase tracker servo (after correcting for the daughter board TF) for 10 seconds. The deg/MHz response was then calculated by trigonometry. Not sure what to make of the structure in the residuals, need to think about it.
• DFD noise was checked by driving the DFD input with a Marconi at 50MHz, RF level = 8dBm, which are expected parameters for nominal ALS operation. In this configuration, I measured the spectrum of the phase tracker output. I then used the calibration factor from the above bullet to convert to Hz/rtHz.
• The electronics noise contribution of the daughter board was calibrated to Hz/rtHz by using the Marconi to drive the DFD input with a known FM signal (mod depth ~0.05), and using the SR785 to measure the power of the FM peak. This allows one to back out the V/Hz calibration constant of the delay line. I tweaked the carrier frequency until the ratio of power in I channel to Q channel (or the other way around) was >20dB before making this measurement.
• I have no proof - but I suspect that the whole host of harmonics in the noise spectrum is because the 1U AA chassis sits directly on top of some Sorensen power supplies. These Sorensens power the frequency distribution box in the LSC rack, so the simplest test to confirm would be to turn off the RF chain, and then Sorensens, and see if the peaky features persist.
Attachment 1: DFDcalib.pdf
Attachment 2: DFD_NB.pdf
ELOG V3.1.3-