40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 223 of 341 Not logged in
ID Date Author Type Category Subject
14762   Mon Jul 15 18:55:05 2019 gautamUpdateIOOMegatron hard-rebooted

[koji, gautam]

In addition to c1psl needing a reboot, megatron was un-ssh-able (although it was responding to ping). Clue was that the NPRO PZT control voltage was drifting a lot on the StripTool trace. Koji hard-rebooted the machine. Now IMC is locked, and FSS slow servo is also running.

14763   Tue Jul 16 15:00:03 2019 gautamUpdateSUSMultiple small EQs

There were several small/medium earthquakes in Ridgecrest and one medium one in Blackhawk CA at about 2000 UTC (i.e. ~ 2 hours ago), one of which caused BS, ITMY, and ETM watchdogs to trip. I restored the damping just now.

14765   Tue Jul 16 16:00:01 2019 gautamUpdateCDSc1iscaux Supermicro setup

I worked on preparing for the c1iscaux upgrade a bit today.

1. Attachment #1: This shows where the 120 GB solid-state hard-drive and the 2 RAM cards (2GB each) are installed.
• I found that it required considerable application of force to get the RAM cards into their slots.
• Note: the 4GB RAM is broken up into two separate physical cards, each 2GB. The labeling is a bit confusing, as each card suggests it is by itself 4GB.
2. OS install for c1iscaux:
• I followed Jon's instructions (and added some of mine to the wiki page to hopefully make this process even less thinking-intensive).
• To be able to use the IP address 192.168.113.83, removed "bscteststand" from chiara martian.hosts and rev.113.168.192.in-addr.arpa as the last mention I could find of this machine was from 2009 (and I'm pretty sure it isn't an active unit anymore). I then restarted the bind9 process.
• The hostname for this machine is currently "c1iscaux3" for testing purposes, I will change it once we do the actual install.
• There was an error in the installation instructions to allow incoming ssh connections - it is openssh-server that is required, not openssh-client. This has now been fixed on the wiki page instructions.
3. Acromag static IP assignment:
• Assigned 2 ADCs (XT1221), 5 DACs (XT1541) and 5 sinking BIO units (XT1111) static IP addresses (and labelled them for easy reference) using the windows laptop and the Acromag IP config utility.
• I saw no reason not to use the 192.168.114.yyy scheme for the Acromag subnet on this machine, even though c1auxex and c1vac both have subnets with this addressing prefix. For reasons unknown to me, Jon opted to use 192.168.115.yyy for the c1susaux Acromag subnet.
4. Followed the excellent step-by-step to install EPICS, Modbus and Asyn.
• This took a while, ~1 hour, dominated by the building of EPICS. The other two took only a couple of minutes each.
• The same combination suggested on Jon's wiki, of Modbus R2-11, EPICS base-7.0.1 and asyn4-33, are the most current at the time of installation.
• Couple of typos that prevented straight up copy-pasting were fixed on the wiki.
5. Playground for testing new database files:
• made a directory /cvs/cds/caltech/target/c1iscaux3 and copied over the .db files from /cvs/cds/caltech/target/c1iscaux and /cvs/cds/caltech/target/c1iscaux2 over.
• Johannes said he did not develop any code to automate the process of translating the old .db files into the new ones for the Acromag - I won't invest the time in developing any either as I think just manually editing the files will be faster.
• I think I will follow the c1susaux convention of grouping .db files by the physical electronics system where possible (e.g. REFL11 channels in one file, CM channels in one file etc), as I think this makes for easier debugging.
• There is an old "PZT_AI.db" file which I think consists completely of obsolete channels.
6. Next steps:
• Wire up the crate [Chub]
• Make the database files and modbus files for talking to the Acromags on the internal subnet [Gautam], check the .db files [Koji]
• Wiring of whitening switching from P1 to P2 connector, Issue #1 in this elog (this will also requrie the installation of the DIN shrouds) [Koji]
• Soldering of P2 interface boards [Gautam]
• Bench testing [Gautam, Koji, Chub]
• Installation and in-situ testing [Gautam, Koji, Chub]

All the required additional parts should be here by the end of the week - I'd like to aim for Wednesday 7/24 for the installation in 1Y3 and in-situ testing. While talking to Rana, I realized that we should also factor in the c1aux slow channels into this acromag crate - there is no need for a separate machine to handle the shutters and illuminators. But let's not worry about that for now, those channels can simply be added later.

Attachment 1: IMG_7769.JPG
14769   Wed Jul 17 21:22:41 2019 gautamUpdateCDSCM board Latch Enable subtlety

[koji, gautam]

Koji pointed out an important subtlety pertaining to the "LATCH ENABLE" signal line on the CM board. The purpose of this line is to smoothly facilitate the transition of a change in the "multi-bit-binary-outputs", a.k.a. "mbbo", that are controlled by MEDM gain sliders, to the analog electronics on the CM board. Why is this necessary? Imagine changing the gain from 7dB (=0111 in mbbo representation) to 8dB (=1000 in mbbo representation). In order to realize this change, all 4 bits have to change their state. But this almost certainly doesn't happen synchronously, because our EPICS interface isn't synchronous. So at some intermediate times, the mbbo representation could be 0100 (=4dB), or 1111 (=15dB), or many other possible values, which are all significantly different from either the initial value or the desired final state. This is clearly undesirable.

In order to protect against this kind of error, a Latched output part, 74ALS573, is used to buffer the physical digital logic levels from the switches in the analog gain stages. So in the default state, the "LATCH ENABLE" signal line is held "LOW". When a change happens in the EPICS value corresponding to a gain slider, the "LATCH ENABLE" state is quickly toggled to "HIGH", so as to enable the appropriate analog gain stages to be switched, and then again to "LOW", at which point the latch holds its output state. This logic is currently implemented by a piece of code called "latch.o", which is the compiled version of "latch.st", which may be found in /cvs/cds/caltech/target/c1iool0 where it presumably was written for the IMC servo board, but not in /cvs/cds/caltech/target/c1iool0  , which is where the CM board database files reside. The only elog reference I can find pertaining to this particular piece of code is from Alan, and doesn't say anything about the actual logic.

For the new c1iscaux, we need to implement this logic somehow. After discussion between Koji and me, we feel that a piece of python code is sufficient. This would continuously run in the background on the supermicro server machine. The channel hierarchy for each gain channes is as follows (I've taken the example of C1:LSC-CM_REFL1_GAIN):

• C1:LSC-CM_REFL1_GAIN ------ this is the channel tied to an MEDM slider, and so is a "soft" channel
• C1:LSC-CM_REFL1_SET ------- this is a "soft" channel that gets converted to an mbbo
• C1:LSC-CM_REFL1_BITS ------ this is a channel that actually controls (multiple) physical binary outputs on the Acromag

So the logic will be that it continuously scans the EPICS channel C1:LSC-CM_REFL1_GAIN  for a change in set value. When a change is detected, it has to update the C1:LSC-CM_REFL1_SET channel. In the next EPICS refresh cycle, this would result in the mbbo bits, C1:LSC-CM_REFL1_BITS , all changing to the appropriate values. After these changes have happened, we need to toggle the LATCH ENABLE in order to allow the changes to propagate to the analog gain stage switches. Need to think about what's the best way to do this.

14771   Thu Jul 18 10:46:04 2019 gautamUpdateCDSDatabase files made

I completed the translation of the .db files for the EPICS database records from the VME notation to the Acromag/Modbus/Asyn notation. The channels are now organized into 5 database files, located in /cvs/cds/caltech/target/c1iscaux3/,  for convenience:

1. C1_ISC-AUX_LSCPDs.db -------- This handles whitening gain, AA enable/bypass, Demodulator FE, and PD Interface Board channels for REFL11, REFL55, REFL33, REFL165, POP22, POP110, POX11, POY11, AS55 and AS110 photodiodes.
2. C1_ISC-AUX_CM.db -------------- This handles all channels for the CM board. The mbbo addressing notation needs to be checked.
3. C1_ISC-AUX_QPDs.db ----------- This handles all channels for the IPPOS QPD.
4. C1_ISC-AUX_ALS.db ------------- This handles all channels for the IR ALS DFD LO and RF power monitoring.
5. C1_ISC-AUX_SPARE.db ---------- This handles the unused channels for the various whitening, AA and PD interface boards.

For reasons unknown to me, the database files in the other Acromag system target directories (e.g. c1susaux, c1auxex) all had 755 level access permission - maybe this is required for systemctl to handle the EPICS serving? Anyways, I upgraded the permission level of the above 5 files using chmod.

There are almost certainly typos / other errors, and I may have missed copying over some soft/calibrated channels, but I hope that this way of grouping by subsystem will make the debugging less painful. Once Chub connects up the power lines to the Acromags, I will run the soft tests. For this purpose, I've also made a C1_ISC-AUX.cmd file and a C1_ISC-AUX.env file in the above target directory, and also made the modbusIOC.service file in /etc/systemd/system on the supermicro.

14773   Thu Jul 18 19:58:56 2019 gautamUpdateCDSWork on Acromag chassis

Now that the .db files were prepared, I wanted to test for errors. So I did the following:

1. Acromags were mounted on the DIN rails. Attachment #1 shows the grouping of ADC, DAC and BIO units. They are labelled with their IP addresses.
2. Wiring of power:
• Chub had already prepared the backplane with the power connectors, switches and indicator LEDs.
• So I just had to daisy chain the +24 V (RED) and GND (BLACK) terminals for all the acromags together, which I did using 24 AWG wire (we may want to use heavier gauge given the current draw).
3. Ethernet cables were used to daisy chain the network connectivity between the various units.  Attachment #1 shows the current state of the chassis box.
4. Front panel pieces were attached and labelled, see Attachment #2
• I found it was sufficient to use the front - we may use the rear panel slots when we want to add connections for controlling the c1aux machine channels.
• The D15 P2 connector panel for the CM board will arrive tomorrow and will be installed then.
5. Entire setup was connected to power and ethernet, see Attachment #3
• As usual, the current draw is significant for the collection of Acromags, I got around this problem by using the bench supply to "Parallel" mode to enhance the current driving capacity.
• For the ethernet connection, I used the office space port #6, which I connected at the network rack end to the eth1 port of the Supermicro.

All the Acromags are seen on the 192.168.114 subnet on c1iscaux3 - however, when I run the modbusIOC process, I see various errors in the logfile , so more debugging is required. Nevertheless, progress.

Update 2245: Turns out the errors were indeed due to a copy/paste error - I had changed the IP addresses for the ADCs from the .115 subnet c1susaux was using, but forgot to do so for the DACs and BIOs. Now, if I turn off the existing c1iscaux so that there aren't any EPICS clashes, the EPICS server initializes correctly. There are still some errors in the log file - these pertain to (i) the mbbo notation, which I have to figure out, and (ii) the fact that this version of EPICS, 7.0.1, does not support channel descriptions longer than 28 characters (we have several that exceed this threshold). I think the latter isn't a serious problem.

Getting closer... Note that I turned off the c1iscaux VME crate to prevent any EPICS server clashes. I will turn it back on tomorrow.

Attachment 1: IMG_7771.JPG
Attachment 2: IMG_7770.JPG
Attachment 3: IMG_7772.JPG
14776   Fri Jul 19 12:50:10 2019 gautamUpdateSUSDC bias actuation options for SOS

Rana and I talked about some (genius) options for the large range DC bias actuation on the SOS, which do not require us to supply high-voltage to the OSEMs from outside the vacuum.

What we came up with (these are pretty vague ideas at the moment):

1. Some kind of thermal actuation.
2. Some kind of electrical actuation where we supply normal (+/- 10 V) from outside the vacuum, and some mechanism inside the chamber integrates (and hence also low-pass filters) the applied voltage to provide a large DC force without injecting a ton of sensor noise.
3. Use the blue piers as a DC actuator to correct for the pitch imbalance --- Kruthi and Milind are going to do some experiments to investigate this possibility later today.

For the thermal option, I remembered that (exactly a year ago to the day!) when we were doing cavity mode scans, once the heaters were turned on, I needed to apply significant correction to the DC bias voltage to bring the cavity alignment back to normal. The mechanism of this wasn't exactly clear to me - furthermore, we don't have a FLIRcam picture of where the heater radiation patter was centered prior to my re-centering of it on the optic earlier this year, so we don't know what exactly we were heating. Nevertheless, I decided to look at the trend data from that night's work - see Attachment #1. This is a minute trend of some ETMY channels from 0000 UTC on 18 July 2018, for 24 hours. Some remarks:

1. We did multiple trials that night, both with the elliptical reflector and the cylindrical setup that Annalisa and Terra implemented. I think the most relevant part of this data is starting at 1500 UTC (i.e. ~8am PDT, which is around when we closed shop and went home). So that's when the heaters were turned off, and the subsequent drift of PIT/YAW are, I claim, due to whatever thermal transients were at play.
2. Just prior to that time, we were running the heater at close to its maximum rated current - so this relaxation is indicative of the range we can get out of this method of actuation.
3. I had wrongly claimed in my discussion with Rana this morning that the change in alignment was mostly in pitch - in fact, the data suggests the change is almost equal in the two DoFs. Oplev and OSEMs report different changes though, by almost a factor of 2....
4. The timescale of the relaxation is ~20 minutes - what part(s) of the suspension take this timescale to heat up/cool down? Unlikely to be the wire/any metal parts because the thermal conductivity is high?
5. In the optimistic scenario, let's say we get 100 urad of actuation range - over 40m, this corresponds to a beam spot motion of ~8mm, which isn't a whole lot. Since the mechanism of what is causing this misalignment is unclear, we may end up with significantly less actuation range as well.
6. I will repeat the test (i.e. drive the heater and look for drift in the suspension alignment using OSEMs/Oplev) in the afternoon - now I claim the radation pattern is better centered on the optic so maybe we will have a better understanding of what mechanisms are at play.

Also see this elog by Terra.

Attachment #2 shows the results from today's heating. I did 4 steps, which are obvious in the data - I=0.6A, I=0.76A, I=0.9A, and I=1.05A.

In science, one usually tries to implement some kind of interpretation. so as to translate the natural world into meaning.

Attachment 1: heaterPitch_2018.pdf
Attachment 2: Screenshot_from_2019-07-19_16-39-21.png
14777   Fri Jul 19 15:51:55 2019 gautamUpdateGeneralProjector lightbulb blown out

[chub, gautam]

Bulb replaced. Projector is back on.

14778   Fri Jul 19 15:54:47 2019 gautamUpdateGeneralControl room UPS Batteries need replacement

The control room UPS started making a beeping noise saying batteries need replacement. I hit the "Test" button and the beeping went away. According to the label on it, the batteries were last repalced in March 2016, so maybe it is time for a replacement, @Chub, please look into this.

14780   Fri Jul 19 17:42:58 2019 gautamUpdateGeneralrossa Xdisp bricked

For some reason, rossa's Xdisplay won't start up anymore. This happened right after the UPS reset. Koji and I tried ~1.5 hours of debugging, got nowhere.

14781   Fri Jul 19 19:44:03 2019 gautamUpdateCDSDatabase file test

Summary:

The database files for C1ISCAUX seem to work file - the exception being the mbbo channels for the CM board.

Details:

This was just a software test - the actual functionality of the channels will have to be tested once the Acromag crate has been installed in the rack. One change I had to make on the MEDM screen for the LSC PD whitening gains was to get rid of the "NMS" suffix on the EPICS channel names for whitening gain sliders/drop-down-menus. I suspect this has to do with the EPICS version we are using, 7.0.1. Furthermore, AS165 and POP55 no longer exist - I hold off removing them from the MEDM screen for the moment.

Next steps:

From the software point of view, the major steps are:

1. Fix the mbbo channel notation in the database files
2. Write and test the latch enabling code
3. Figure out what scripted tests can be done to test the functionality of the new Acromag box.

I am stopping the EPICS server on the new machine and restarting the old VME crate over the weekend.

Attachment 1: Whitening.png
14783   Sat Jul 20 01:03:37 2019 gautamUpdate Dataviewer error

What channels are you trying to read?

 Quote: I'm not able to get trends of the TM adjustment test that Rana had asked us to perform, from the dataviewer. It's throwing the following error: Connecting to NDS Server fb (TCP port 8088) Connecting.... done Server error 7: connect() failed datasrv: DataWrite failed: daq_send: Resource temporarily unavailable T0=19-07-20-01-27-39; Length=600 (s) No data output.
14784   Sat Jul 20 11:24:04 2019 gautamUpdateGeneralrossa bricked

Summary:

SnapPy scripts made to work on Pianosa.

Details:

Of course rossa was the only machine in the lab that could run the python scripts to interface with the GigE camera. And it is totally bricked now. Lame.

So I installed several packages. The key was to install pypylon - if you go to the basler webpage, pypylon1.4.0 does not offer python2.7 support for x86_64 architecture, so I installed pypylon1.3.0. Here are the relevant lines from the changelog:

gstreamer-plugins-bad-0.10.23-5.el7.x86_64    Sat 20 Jul 2019 11:22:21 AM PDT gstreamer-plugins-good-0.10.31-13.el7.x86_64  Sat 20 Jul 2019 11:22:11 AM PDT gstreamer-plugins-ugly-0.10.19-31.el7.x86_64  Sat 20 Jul 2019 11:20:08 AM PDT gstreamer-python-devel-0.10.22-6.el7.x86_64   Sat 20 Jul 2019 10:34:35 AM PDT pygtk2-devel-2.24.0-9.el7.x86_64              Sat 20 Jul 2019 10:34:34 AM PDT pygobject2-devel-2.28.6-11.el7.x86_64         Sat 20 Jul 2019 10:34:33 AM PDT pygobject2-codegen-2.28.6-11.el7.x86_64       Sat 20 Jul 2019 10:34:33 AM PDT gstreamer-devel-0.10.36-7.el7.x86_64          Sat 20 Jul 2019 10:34:32 AM PDT gstreamer-python-0.10.22-6.el7.x86_64         Sat 20 Jul 2019 10:34:31 AM PDT gtk2-devel-2.24.31-1.el7.x86_64               Sat 20 Jul 2019 10:34:30 AM PDT libXrandr-devel-1.5.1-2.el7.x86_64            Sat 20 Jul 2019 10:34:28 AM PDT pango-devel-1.42.4-1.el7.x86_64               Sat 20 Jul 2019 10:34:27 AM PDT harfbuzz-devel-1.7.5-2.el7.x86_64             Sat 20 Jul 2019 10:34:26 AM PDT graphite2-devel-1.3.10-1.el7_3.x86_64         Sat 20 Jul 2019 10:34:26 AM PDT pycairo-devel-1.8.10-8.el7.x86_64             Sat 20 Jul 2019 10:34:25 AM PDT cairo-devel-1.15.12-3.el7.x86_64              Sat 20 Jul 2019 10:34:25 AM PDT mesa-libEGL-devel-18.0.5-3.el7.x86_64         Sat 20 Jul 2019 10:34:24 AM PDT libXi-devel-1.7.9-1.el7.x86_64                Sat 20 Jul 2019 10:34:24 AM PDT pygtk2-doc-2.24.0-9.el7.noarch                Sat 20 Jul 2019 10:34:23 AM PDT atk-devel-2.28.1-1.el7.x86_64                 Sat 20 Jul 2019 10:34:21 AM PDT libXcursor-devel-1.1.15-1.el7.x86_64          Sat 20 Jul 2019 10:34:20 AM PDT fribidi-devel-1.0.2-1.el7.x86_64              Sat 20 Jul 2019 10:34:20 AM PDT pixman-devel-0.34.0-1.el7.x86_64              Sat 20 Jul 2019 10:34:19 AM PDT libXinerama-devel-1.1.3-2.1.el7.x86_64        Sat 20 Jul 2019 10:34:19 AM PDT libXcomposite-devel-0.4.4-4.1.el7.x86_64      Sat 20 Jul 2019 10:34:19 AM PDT libicu-devel-50.1.2-15.el7.x86_64             Sat 20 Jul 2019 10:34:18 AM PDT gdk-pixbuf2-devel-2.36.12-3.el7.x86_64        Sat 20 Jul 2019 10:34:17 AM PDT pygobject2-doc-2.28.6-11.el7.x86_64           Sat 20 Jul 2019 10:34:16 AM PDT pygtk2-codegen-2.24.0-9.el7.x86_64            Sat 20 Jul 2019 10:34:15 AM PDT

Camera server is running on a tmux session on pianosa. But it keeps throwing up some gstreamer warnings/errors, and periodically (~every 20 mins) crashes. Kruthi tells me that this behavior was seen on Rossa as well, so whatever the problem is, doesn't seem to be because I missed out on installing some packages on pianosa. Moreover, if the server is in fact running, I am able to take a snapshot - but the camera client does not run.

14785   Sat Jul 20 11:57:39 2019 gautamSummaryCDSP2 interface board

The boards arrived. I soldered on a DIN96 connector, and tested that the goemetry will work. It does . The only constraint is that the P2 interface board has to be installed before the P1 interface is installed. Next step is to confirm that the pin-mapping is correct. The pin mapping from the DIN96 connector to the DB15 was also verified.

*Maybe it isn't obvious from the picture, but there shouldn't be any space constraint even with the DB37/DB15 cables connected to the respective adapter boards.

Attachment 1: IMG_7773.JPG
14786   Sat Jul 20 12:16:39 2019 gautamUpdateCamerasCNNs for beam tracking || Analysis of results
1. Make the MSE a subplot on the same axes as the time series for easier interpretation.
2. Describe the training dataset - what is the pk-to-pk amplitude of the beam spot motion you are using for training in physical units? What was the frequency of the dither applied? Is this using a zoomed-in view of the spot or a zoomed out one with the OSEMs in it? If the excursion is large, and you are moving the spot by dithering MC2, the WFS servos may not have time to adjust the cavity alignment to the nominal maximum value.
3. What is the minimum detectable motion given the CCD resolution?
4. Please upload a cartoon of the network architecture for easier visualization. What is the algorithm we are using? Is the approach the same as using the bright point scatterers to signal the beam spot motion that Gabriele demonstrated successfully?
5. What is the significance of Attachment #6? I think the x-axis of that plot should also be log-scaled.
6. Is the performance of the network still good if you feed it a time-shuffled test dataset? i.e. you have (pictures,Xcoord,Ycoord) tuples, which don't necessarily have to be given to the network in a time-ordered sequence in order to predict the beam spot position (unless the network is somehow using the past beam position to predict the new beam position).
7. Is the time-sync problem Koji raised limiting this approach?
14789   Sun Jul 21 12:54:18 2019 gautamUpdateLoss MeasurementMC2 loss map

Can you please be more specific about what the error is? Is this the usual instability with the camera server code? Or was it something new?

 Quote: The camera server is throwing an error and is not grabbing snapshots :(
14790   Sun Jul 21 12:55:38 2019 gautamUpdateCDSCM board Latch Enable test script

DATED, SEE ELOG14941 for the most up-to-date info on latch.py.

I wrote (/cvs/cds/caltech/target/c1iscaux3/latch.py) and tested the logic illustrated in Attachment #1. Results of a test are shown in Attachment #2, the various channels change as expected. Note that for negative values of the gain channel, the corresponding "BITS" channel will take on values like 65536 - this is because the mbboDirect data type is a 16 bit data type, and presumably the MSB is the sign bit. A bit mask is applied to this channel before the actual BIO unit bits are set - we should verify that the correct behavior happens, but I don't immediately see any problems.

To me, this is a robust logic, but it will benefit from more sets of eyes giving it a look over. The idea is to run this continuously on the Supermicro machine.

Apart from this, I also fixed some errors in the mbboDirect record syntax - so now I am able to start up the EPICS server without it throwing any error messages. It remains to verify that changing an EPICS gain slider results in the appropriate gain bits being flipped in the correct way (on the hardware side, I think the correct behavior is happening on the software end). For this testing, I turned off the old c1iscaux crate at ~10am, and started up the server on c1iscaux3. I am reverting to the nominal config now (~1pm).

Further testing will require the wiring inside the Acromag chassis to be completed. This should be the priority task for next week.

*Update 1130 22 July 2019: I've now installed the required dependencies on c1iscaux3 and setup the latch.py script to run as a systemctl process dependent on modbusIOC.service.

Attachment 1: LatchLogic.pdf
Attachment 2: LatchLogicTest.png
14795   Mon Jul 22 07:21:13 2019 gautamUpdateCDSpainosa messed with

Somebody changed the settings on painosa without elogging anything about it. Why does this keep happening? I thought the point of the elog was to communicate. I think there are sufficient number of problems in the lab without me having to manually reset the control room workstation settings every week. Please make an elog if you change something.

14800   Mon Jul 22 23:53:16 2019 gautamUpdateALSIR ALS locking attempt

Summary:

My goal tonight was to lock the PSL frequency to be resonant in the XARM cavity, using the PSL+EX beat as the error signal. I was not successful - mainly, I was plagued by huge BR mode coupling in the error signal, and I could not enable the BR notch filter in the control loop without breaking the lock. Need to think about next steps.

Details:

• POX and POY locking was easily restored.
• EX green alignment was tweaked at the end-table. A large YAW correction was required, which I opted to apply on the mechanical mirror mounts rather than the PZTs. GTRX ~0.4 was recovered.
• The arm cavity length was first locked using POX as an error signal
• Then I looked at the out-of-loop ALS noise, trusting the DFD's V/Hz calibration (red-trace in Attachment #1).
• I judged it to be close enough to the benchmark reference (green-trace in Attachment #1), and so decided that I could go ahead and try locking.
• A modified version of the script /opt/rtcds/caltech/c1/scripts/XARM/Lock_ALS_XARM.py was used to transition control from POX to the ALS error signal
• I found that I had to change the sign of the CARM loop gain for the servo to remain stable (in this config, CARM-->MC2 length, thereby modifying the IMC frequency to keep the PSL resonant in the XARM cavity).
• I don't know why this sign change was required - we are still sticking to the same convention that the beat frequency increases when the temperature slider for the EX laser is incremented in counts.
• The script failed multiple times at the BOOST/BR notch filter enabling step.
• Doing these steps manually, I found that turning the BR notch, FM6, ON destroyed the lock immediately.
• Motivated by this observation, I looked at the in-loop error signal spectrum, see Attachment #2. Here, the PSL frequency is servoed by the ALS error signal, but the BR notch filter isn't enabled.
• The Bounce-mode peak is huge - where is this coming from? It is absent in the ALS spectrum when the XARM is locked with POX. So it is somehow connected with actuating on the MC2 suspension? Or is it that the FM6=BounceRoll filter of the XARM loop is squishing the noise when looking at the ALS spectrum in POX lock, i.e. Attachment #1? In which case, why can't I engage FM6 for the CARM loop???

Anyway, now that I have a workable set of settings that gets me close to the ALS lock of the XARM, I expect debugging to proceed faster.

Update 2019 July 23: I looked at the control loop shape today, see Attachment #3. I'm not sure I understand why the "BounceRoll" filter  in this filter bank looks like a resonant gain rather than a notch, as it does for the Oplev or SUSPOS loops for example - don't we want to not actuate at these frequencies because the reason the signal exists is because of the imperfect OSEM/magnet positioning? This does not explain the spectrum shown in Attachment #2 however, as that filter was disabled.

Attachment 1: ALS_X_outOfLoopnoise.pdf
Attachment 2: ALS_X_inLoopnoise.pdf
Attachment 3: CARM_loopShape.pdf
14802   Wed Jul 24 00:22:24 2019 gautamUpdateALSPSL frequency locked to XARM length using ALS

Summary:

I succeeded in locking the PSL frequency to the XARM cavity length, with 9 pm RMS (Attachment #1) motion below 1 kHz, by actuating on MC2 to change the IMC length. The locks were pretty stable (~20 minutes) - the dominant cause of lockloss was the infamous ETMX drifting problem.

Details:

1. I did not need to do anything to fix the anomalosly high BR mode coupling I reported yesterday .
• To test where this could be coming from - I looked at the ALS spectrum again with the XARM length locked to the PSL frequency using POX.
• Then I compared the spectra with the BR filter in the XARM servo enabled/disabled, see Attachment #2
• There bounce/roll peak heights even with the BR filter disabled is ~x100 smaller than what I reported yesterday (it remained the case today, because without enabling the BR filter in the CARM servo bank, the TRX level was fluctuating wildly at ~16 Hz).
2. The CARM loop (which is what the PSL frequency was slaved to) had ~150 Hz UGF with ~40 degrees phase margin, see Attachment #3.
3. The quoted RMS sensing noise is if we trust the old POX calibration - may be off by a factor of a few, but probably not an order of magnitude. I'll recalibrate using the free-swinging Michelson technique in the coming days.
4. The two broad humps in Attachment #1, centered at ~180 Hz and ~300 Hz, are present in the XARM lock as well - so it is somehow imprinted on the arm cavity length. Fixing that will improve the RMS noise performance significantly.

My main motivation here is to make some measurements and investigate the SoCal idea using a toy system, i.e. a single arm cavity controlled using ALS, so that's what Craig and I will attempt next.

Attachment 1: ALS_X_noise_POX.pdf
Attachment 2: BR_comparison.pdf
Attachment 3: ALS_CARM_OLG.pdf
14808   Wed Jul 24 20:23:52 2019 gautamUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

Since there are multiple SURF projects that rely on the cameras:

1. I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories.
2. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon).
3. There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.

My changes were necessary because the grabHDR.py script was throwing python exceptions, whereas it was running just fine before Jon's changes. We can move the "new_*" dirs to the default once the SURFs are gone.

Let's freeze the camera software config in this state until next week.

14811   Thu Jul 25 12:25:56 2019 gautamUpdateALSIR ALSX noise

Summary:

1. There are some broad peaks in the ALS out-of-loop noise, centered at ~145 Hz, ~245 Hz and ~570 Hz which are absent in both the POX in-lock error signal and in the green PDH error signals (see Attachment #1). So I conclude they originate in the IR ALS beat chain somewhere. Needs more investigation, in the general quest to improve the ALS noise.
2. This measurement also shows that the ALS noise is limited by unsuppressed EX green PDH frequency noise above ~400 Hz (100 Hz if you ignore the unexplained broad humps).

These spectra were taken with the arm cavity length locked to the PSL frequency using POX as an error signal, and the EX laser frequency locked to the XARM cavity length by the analog PDH servo at EX, so there is no feedback control with the ALS beat signal as an error signal.

Other details:

• The transition of arm resonance control from POX to ALS error signal is more robust now - I am able to do this during daytime, and also maintain the lock for >20 minutes at a time.
• Rana encouraged me not to spend too much time on this - so my next goal here will be to get the Y arm IR ALS working, and then we can control the two arms using ALS error signals in the CARM/DARM basis instead of the X/Y basis.
• I still think it's worth getting the ALS good enough that the locking becomes repeatable and reliable.
• The main task here is going to be re-doing the EY green layout to match the EX layout, get good MM into the cavity etc.
• The IR light also has to be coupled into the fiber at EY.
14812   Thu Jul 25 14:28:03 2019 gautamConfigurationComputersfirewalld disabled for EPICS CA

I think rana did some more changes to this workstation to make it useful for commissioning activities - but the MEDM screens were still white blanks. The problem was that the firewalld wasn't disabled (last two steps of the KThorne setup wiki). I disabled it. Now donatella can run MEDM, ndscope and StripTool. DTT doesn't work to get online data because of a "Synchronization Error", I'm not bothering with this for now. I think Kruthi successfully demonstrated the fetching of offline data with DTT.

Attachment 1: donatellaCommissioning.png
14813   Thu Jul 25 20:08:36 2019 gautamUpdateComputersSolidworks machine

I brought one CPU (Dell T3500) and one 28" monitor from Mike Pedraza's office in Downs to the 40m. It is on Steve's desk right now, pending setup. The machine already has Solidworks and Altium installed on it, so we can set it up at our leisure. The login credentials are pasted on the CPU with a post-it should anyone wish to set it up.

14815   Mon Jul 29 13:32:56 2019 gautamUpdateLoss MeasurementLoss measurement PD installed in AS path

[yehonathan, gautam]

• we placed a PDA520 photodiode in the AS beampath, so AS110 and AS55 no longer see any light.
• ITMX and ETMX were misaligned (since the plan is to measure the Y arm loss).
• The PDA520 and MC2 transmission are currently going to the Y arm ALS beat channels in the DAQ system. Unfortunately, we have no control over the whitening gains for these channels because of the c1iscaux2 situation.
14817   Tue Jul 30 09:13:31 2019 gautamUpdatePSLc1psl keyed, Agilent setup cleared
1. IMC would not lock. c1psl EPICS channels were unresponsive. I keyed the crate and went through the usual burtrestore/PMC-relocking dance.
2. While at 1X2, I decided to take this opportunity to clean up the AG4395 setup that has been setup there unused for several weeks now.
• Unplugged the active probe connected via BNC-T connector to the mixer IF output.
• Noticed that the active probe (S/N 2850J01450) did not have it's power connection connected. According to the manual, this is bad. I don't know if the probe is damaged or not.
• Moved the AG4395 cart out of the way so that there is a little more room around 1X1/1X2.
14819   Wed Jul 31 09:41:12 2019 gautamUpdateBHDOMC cavity geometry

Summary:

We need to determine the geometry (= round-trip length and RoC of curved mirrors) of the OMC cavities for the 40m BHD experiment. Sticking to the aLIGO design of a 4 mirror bowite cavity with 2 flat mirrors and 2 curved mirrors, with a ~4deg angle of incidence, we need to modify the parameters for the 40m slightly on account of our different modulation frequencies. I've setup some infrastructure to do this analytically - even if we end up doing this with Finesse, it is useful to have an analytic calculation to validate against (also not sure if Finesse can calculate HOMs up to order 20 in a reasonable time, I've only seen maxtem 8).

Attachment #1: Heatmap of the OMC transmission for the following fields:

• Carrier TEM00 is excluded, but HOMs up to m+n=20 included for both the horizontal and vertical modes of the cavity.
• f1 and f2 upper and lower sidebands, up to m+n=20 HOMs for both the horizontal and vertical modes of the cavity, including TEM00.
• Power law decay assumed for the HoM content incident on the OMC - this will need to be refined
• The white region is where the cavity isn't geometrically stable.
• Green dashed line indicates a possible operating point, white dashed line indicates the aLIGO OMC operating point. On the basis of this modeling, we would benefit from choosing a better operating point than the aLIGO OMC geometric parameters.

Algorithm:

1. Compute the round-trip Gouy phase, $\phi_{\mathrm{gouy}}$, for the cavity.
2. With the carrier TEM00 mode resonant, compute the round-trip propagation phase, $\phi_{\mathrm{prop}} = \frac{2 \pi f_{\mathrm{offset}} L_{\mathrm{rt}}}{c}$, and the round-trip Gouy phase, $\phi_{\mathrm{G}} = (m+n)\phi_{\mathrm{gouy}}$ for the $\mathrm{TEM}_{mn}$ mode of the field, with $f_{\mathrm{offset}}$ specifying the offset from the carrier frequency (positive for the upper sideband, negative for the lower sideband). For the aLIGO cavity geometry, the 40m modulation sidebands acquire ~20% more propagation phase than the aLIGO modulation sidebands.
3. Compute the OMC transmission for this round-trip phase (propagation + Gouy).
4. Multiply the incident mode power (depending on the power law model assumed) by the cavity transmission.
5. Sum all the fields.

Next steps:

1. Refine the incident mode content (and power) assumption. Right now, I have not accounted for the fact that the f2 sideband is resonant inside the SRC while the f1 sideband is not. Can we somehow measure this for the 40m? I don't see an easy way as it's probably power dependent?
2. Make plots for the projection along the slices indicated by the dashed lines - which HOMs are close to resonating? Might give us some insight.
3. What is the requriement on transmitted power w.r.t. shot noise? i.e. the colorbar needs to be translated to dBVac.
4. If we were being really fancy, we could simultaneously also optimize for the cavity finesse and angle of incidence as well.
5. Question for Koji: how is the aLIGO OMC angle of incidence of ~4 degrees chosen? Presumably we want it to be as small as possible to minimize astigmatism, and also, we want the geometric layout on the OMC breadboard to be easy to work with, but was there a quantitative metric? Koji points out that the backscatter is also expected to get worse with smaller angles of incidence.

The code used for the ABCD matrix calcs have been uploaded to the BHD modeling GIT (but not the one for making this plot, yet, I need to clean it up a bit). Some design considerations have also been added to our laundry list on the 40m wiki.

Attachment 1: paramSpaceHeatMap.pdf
14820   Wed Jul 31 14:44:11 2019 gautamUpdateComputersSupermicro inventory

Chub brought the replacement Supermicro we ordered to the 40m today. I stored it at the SW entrance to the VEA, along with the other Supermicro. At the time of writing, we have, in hand, two (unused) Supermicro machines. One is meant for EY and the other is meant for c1psl/c1iool0. DDR3 RAM and 120 GB SSD drives have also been ordered, but have not yet arrived (I think, Chub, please correct me if I'm wrong).

Update 20190802: The DDR3 RAM and 120 GB SSD drives arrived, and are stored in the FE hardware cabinet along the east arm. So at the time of writing, we have 2 sets of (Supermicro + 120GB HD + 4GB RAM).

 Quote: We should ask Chub to reorder several more SuperMicro rackmount machines, SSD drives, and DRAM cards. Gautam has the list of parts from Johannes' last order.
14823   Fri Aug 2 11:37:38 2019 gautamUpdateALSEY IR ALS Assay

Summary:

I'd like to confirm that the IR ALS scheme will work for locking. The X-arm performance so far has been encouraging. I want to repeat the characterization for the Y arm. So I inspected the layout on the EY table, and made a list of characterization tasks. The current EY beam routing is difficult to work with, and it will definitely benefit from a re-do. However, I don't know how much time I want to spend re-doing it, so for a start, I will just try and couple some amount of light into a fiber and bring it to the PSL table, and see what noise performance I get.

Details:

Attachment #1: Photo of the current beam layout. The powers indicated were measured with the Ophir power meter.

• I measure an SHG conversion efficiency of 0.87 %/W, which is considerably lower than the ~3.7%/W that is theoretically expected, and 1.5%/W that is realized at EX.
• Of the 0.5 mW of green light that is generated, I measure ~0.375 mW at the viewport into the EY chamber. So there is ~25 % loss in the green beam path on the EY table. Seems high to me.
• The previous solution of coupling IR light into the fiber realized at EY was to use the SHG leakage IR beam. While there isn't a measurement showing that this dirty beam is noisier than a cleaner pickoff, I'd like to adopt the solution used at EX, which is to use the leakage beam from the first steering mirror in the NPRO beam path. This will allow better mode-matching and polarization control of the beam being coupled into the fiber, which at least in principle, translates to less phase noise.
• However - the beam layout at the EY table offers much less freedom to work with this idea than EX. A constraint is the clamp that secures the enclosure to the optical table, labelled in the photo. Further behind it, the green steering optics occupy all available space. A more comprehensive photo of the EY table can be found here.
• Off the top of my head, I don't see any other good open spots on the EY table where we could couple IR light into the fiber.
• One other change I'd like to make is to replace the first steering mirror after the NPRO head, which is currently a Y1 HR mirror, with a R=99% BS. This will make it easier to control the amount of power coupled into the fiber, which is something we'd like.

Attachment #2: A candidate mode-matching solution, given the constraints outlined above. It isn't great, with only 85% modematching even theoretically possible. The lenses required are also pretty fast lenses. But I think it's the best possible without a complete overhaul of the EY layout. I'm still waiting for the lens kit to arrive, but as soon as they get here, I will start this work.

• Characterize SHG at EY [done 7/28]
• Characterize gPDH at EY (loop TFs, improve MM, PDH discriminant, check the polarization)
• Couple IR light into fiber with good MM at EY [done with 36% MM 8/9]
• Clean fiber at EY, and at the PSL table [done 8/9]
• Make the PSL + Y IR beat [done 8/9]
• Noise budget
Attachment 1: IMG_7780.JPG
Attachment 2: Ey_MM_20190802.pdf
14826   Sun Aug 4 14:39:41 2019 gautamUpdateGeneralsome lab activity
1. Unresponsive c1psl, c1iool0, c1auxey and c1iscaux VME crates were keyed.
2. c1psl channels were burt-restored, did a burtrestore, and re-locked the PMC. Tweaked the pointing into the PMC on the PSL table to increase the PMC transmission from ~0.69 to ~0.71.
3. Re-locked IMC. Ran WFS offset script to relieve the ~100 DAC counts (~10 urad) DC offset from the WFS servos to the IMC suspensions (a serious calibration of this into physical units should be made part of the planned 40m WFS activity). Now that I think about it, since we change the IMC alignment to match the input beam alignment, some post-IMC clipping could modulate the power incident on the ITMs, which is a source of error for the arm cavity loss determination using DC reflection. We need a better normalizing data stream than the IMC transmission.
4. The IFO_OVEREVIEW medm screen was modified such that the threshold for the PMC transmitted beam to be visible was lowered from 0.7 to 0.6, so that now there is a continuous beam line from the NPRO to the PRM when the IMC is locked even when the PMC transmission degrades by 5% due to thermally driven pointing drifts on the PSL table.
5. The wmctrl utility on pianosa wasn't working so well, I wasn't able to use my usual locking MEDM autoconfig scripts. Turned out to be due to a zombie MEDM window which I killed with xkill, now it is working okay again.
6. The misaligned XARM was re-aligned and the loss measuring PDA520 at the AS port was removed from the beam path (mainly to avoid ADC saturations the fringing Michelson will cause).
7. I noticed that the ETMX Oplev HeNe SUM level has degraded to ~50% of its power level from 200 days ago [Attachment #1], may need a new HeNe here soon. @Chub, do we have spare HeNes in stock?

I want to collect some data with the arms locked to investigate the possibility/usefullness of having seismic feedforward implemented for the arms (it is already known to help the IMC length and PRC angular stability at low frequencies). To facilitate diagnostics I modified the file /users/Templates/Seismic/Seismic_vs_TRXTRYandMC.xml to have the correct channel names in light of Lydia's channel name changes in 2016. Looking at the coherence data, the alignment of the cartesian coordinate system of the Seismometers at the ends and the global interferometer coordinate system can be improved.

I don't know if for the MISO filter design if there is any difference in using TRX/TRY as the target, or the arm length control signal.

Data collection started at 1249018179. I've setup a script running in a tmux shell to turn off the LSC enable in 2 hours.

Attachment 1: ETMX_OL.png
Attachment 2: Seismic_TRXTRYandMC_4Aug2019.pdf
14829   Mon Aug 5 17:23:26 2019 gautamSummaryComputersWiFi Settings on asia

The VEA laptop asia was configured to be able to connect to too many WiFi networks - it was getting conflicted in its default position at the vertex and trying to hop between networks, for some reason trying to connect to networks that had poor signal strength. I deleted all options from the known networks except 40MARS. Now the network connection seems much more stable and reliable.

14832   Tue Aug 6 14:55:23 2019 gautamUpdateCDSMaking Matlab R2015b the default

ML2013 is unable to open Simulink on any of the workstations. We decided to make the default version of Matlab R2015b (the default of the version of RCG we are using).

I commenced the procedure of the migration, starting with making a tagged commit of the current running simulink models. A local backup was also made, plus we have the usual chiara-based backup so I think we're in good hands.

Currently the branch and tag are protected - once we verify that everything works as expected post migration, I will open it up. I changed the directory structure of the models, need to confirm that the rtcds compilers don't have any hardcoded paths which may break due to my change.

The symlink to Matlab R2013 was deleted and a new symlink to R2015b was made. I activated the license using the Caltech campus license. Now running matlab from shell starts up R2015b . Simulink even works 😲 .

Attachment 1: ML2015b.png
14833   Tue Aug 6 15:52:06 2019 gautamUpdateBHDPreliminary BHD calculations

Summary:

The requirement on the phase noise on the direct backscatter from the OMC back into the SRM is that it be less than $10^{-5} \, \mathrm{rad/\sqrt{Hz}} \approx 10^{-12} \, \mathrm{m/\sqrt{Hz}}$ @ 100 Hz, for a safety factor (arbitrarily chosen) of 10 (= 20dB below unsqueezed vacuum). Assuming 5 optics between the OMC and SRM which contribute incoherently for a factor of sqrt(5), and assuming a total of 1 ppm of the LO power to be backscattered, we need the suspensions to be moving $< 5 \times 10^{-13} \, \mathrm{m/\sqrt{Hz}}$ @ 100 Hz. This seems possible to realize with single stage suspensions - I assume we get f^4 filtering from the pendulum at 100 Hz, and that there is an additional 80 dB attenuation (from the stack) of the assumed 1 micron/rtHz motion at 100 Hz, for an overall 160 dB attenutaiton, yielding 10^-14 m/rtHz at 100 Hz.

Details:

This is the same calculation as I had posted a couple of months ago (see elog that this is a reply to), except that Koji pointed out that the LO power is expected to dominate the (carrier) power incident on the OMC cavity(ies). So the more meaningful comparison to make is to have the x-axes of the plots denote the backscatter fraction, $\epsilon_{\mathrm{BS}}$ rather than the LO power. One subtlety is that because the phase of the scattered field is random, the displacement-noise induced phase noise could show up in the amplitude quadrature. I think that in these quadrature field amplitude units, the RIN and phase noise are directly comparable but I might have missed a factor of 2*pi. But in the worst case, if all the phase noise shows up in the amplitude quadrature, we end up being only ~10dB below unsqueezed vacuum (for 1 ppm backscatter).

For the requirement on the noise in the intensity quadrature - I think this is automatically satisfied because the RIN requirement on the incident LO field is in the mid 10^-9 1/rtHz regime.

Attachment 1: OMCbackscatter.pdf
14835   Tue Aug 6 23:09:20 2019 gautamUpdateALSEY table work
• Removed power monitoring PD (It was off anyways)
• Installed Steering mirror and collimator in K6XS mount (fast axis = p-pol to best effort by eye)
• Installed lens mounts in approx position
• Cleaned fiber at EY and connected to the collimator
• Coupled EY--->PSL and spare PSL-->EY fibers together at the PSL table to facilitate coupling.
• tbc tomorrow...
 Quote: Couple IR light into fiber with good MM at EY
14836   Thu Aug 8 12:01:12 2019 gautamUpdateIOOMC1 suspension oddness

At ~1am PDT today, all the MC1 shadow sensor readbacks (fast CDS channels and Slow Acromag channels, latter not shown here) went to negative values. Of course a negative value makes no sense. After ~3 hours, they came back to positive values again. But since then, the shadow sensor RMS noise has been significantly higher in the >20 Hz band, and there are frequent glitches which kick the suspension. The IMC has been having trouble staying locked. I claim that this has to do with the Satellite box.

No action being taken now while I work on the ALS. In the past the problem has fixed itself.

Attachment 1: MC1_suspension.png
Attachment 2: MC1_suspension.pdf
14837   Fri Aug 9 08:59:04 2019 gautamUpdateCDSPrep for install of c1iscaux

[chub, gautam]

We scoped out the 1Y3 rack this morning to figure out what needs to be done hardware wise. We did not think about how to power the Acromag crate - the LSC rack electronics are all powered by linear supplies and not Sorensens, and the linear supplies are operating at pretty close to their maximum current-drive. The Acromag box draws ~3A of current from the 20 V supply, not sure what the current draw will be from the 15 V supply. Options:

1. Since there are sorensens in 1Y2 and 1Y1, do we really care about installing another pair of switching supplies (+20 V DC and +15 V DC) in 1Y3?
• Contingent on us having two spare Sorensens available in the lab. Chub has already located one.
2. Use the Sorensens installed already in 1Y1.
• Probably the easiest and fastest option.
• +15 V already available, we'd have to install a +20 V one (or if the +/-5 V or +12 V is unused, reconfigure for +20 V DC).
• Can argue that "this doesn't make the situation any worse than it already is"
• Will require the running of some long (~3 m) long cabling to bring the DC power to 1Y3 where it is required.
3. Get new linear supplies, and hook them up in parallel with the existing.
• Need to wait for new linear supply to arrive
• Probably expensive
• Questionable benefit to electronics noise given the uncharacterized RF pickup situation at 1Y2

I'm going with option #2 unless anyone has strong objections.

14838   Fri Aug 9 16:37:39 2019 gautamUpdateALSMore EY table work

Summary:

1. 220 uW / 600 uW (~36 % mode-matching) of IR light coupled into fiber at EY.
2. Re-connected the RF chain from the beat mouth output on the PSL table to the DFD setup at 1Y2.
3. A beat note was found between the PSL and EY beams using the BeatMouth.

Motivation:

We want to know that we can lock the interferometer with the ALS beat note being generated by beating IR pickoffs (rather than the vertex green transmission). The hope is also to make the ALS system good enough that we can transition the CARM offset directly to 0 after the DRMI is locked with arms held off resonance.

Details:

Attachment #1: Shows the layout. The realized MM is ~36 %. c.f. the 85% predicted by a la mode. It is difficult to optimize much more given the tight layout, and the fact that these fast lenses require the beam to be well centered on them. They are reasonably well aligned, but I don't want to futz around with the pointing into the doubling crystal. Consequently, I don't have much control over the pointing.

Attachment #2: Shows pictures of the fiber tips at both ends before/after cleaning. The tips are now much cleaner.

The BeatMouth NF1611 DC monitor reports ~580 mV with only the EY light incident on it. This corresponds to ~60 uW of light making it to the photodiode, which is only 25% of what we send in. This is commensurate with the BS loss + mating sleeve losses.

To find the beat between PSL and EY beams, I had to change the temperature control MEDM slider for the EY laser to -8355 cts (it was 225 cts). Need to check where this lies in the mode-hop scan by actually looking at the X-tal temperature on the front panel of the EY NPRO controller - we want to be at ~39.3 C on the EY X-tal, given the PSL X-tal temp of ~30.61 C. Just checked it, front panel reports 39.2C, so I think we're good.

Next steps:

• Fix the IMC suspension
• Measure the ALS noise for the Y arm
• Determine if improvements need to be made to the IR beat setup (e.g. more power? better MM? etc etc).

EY enclosure was closed up and ETMY Oplev was re-enabled after my work. Some cleanup/stray beam dumping remains to be done, I will enlist Chub's help on Monday.

Attachment 1: IMG_7791.JPG
Attachment 2: fiberCleaning.pdf
14840   Sun Aug 11 11:47:42 2019 gautamUpdateCDSBench test of c1iscaux

I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.

1. DAC channels were tested using 4 ch oscilloscope and stepping the whitening gain sliders through their 15 gain settings
• Response was satisfactory - the output changes between 0 - 5 V DC in 15 steps.
• This analog voltage is converted to binary representation by an on-board ADC on the whitening boards. So we may have to tune the offset voltage and range to avoid accidental bit flipping due to the analog voltage of a particualr step falling close to the bit-flipping edge of the on-board ADC. This will require an in-situ test.
• Test passed
2. BIO output channels were tested using a DMM, and monitoring the resistance between the BIO pin and the RTN pin. In the "ON" state, the expected resistance is ~5 Mohm, and in the off state, it is ~3 ohms.
• The AA filter switches on BIO1 unit do not show the expected behavior - @ Chub, please check the wiring.
• All others (except the mbboDirect bits, see next bullet) were okay, including those for the CM board that are NOT part of the mbboDirect groups.
• Test failed
3. ADC channels were tested by driving a ~2Vpp 300mHz sine wave with a function generator, and looking at the corresponding EPICS channel with StripTool.
• I found that all the ADC channels don't function as expected.
• Part of the problem is due to incorrect formatting of the EPICS records in the db files, but I think the ADCs also need to be calibrated with the precision voltage source.
• Why only ADCs require calibration and not the DACs????
• Test failed
4. mbboDirect BIO output test - I made a little LED breadboard tester kit to simultaneously monitor the status of these groups of binary outputs.
• The LSB is toggled as expected when moving the gain slider along.
• However, the other bits in the group are not toggled correctly.
• I believe this is a problem with either (i) the way the EPICS record is configured to address the bits or (ii) the incorrect modbus datatype is used to initialize the ioc.
• It will be helpful if someone can look into this and get the mbboDirect bits working, I don't really want to spend more time on this.
• Test failed

I am leaving the crate powered (by bench supplies) in the office area so I have the option to work remotely on this.

14841   Mon Aug 12 17:36:04 2019 gautamUpdateCDSMore bench test of c1iscaux

[chub, gautam]

With Chub's help, most of the problems have been resolved. Summary: I judge that we are good to go ahead with an install tomorrow.

1. The problem with the BIO channels was a mis-wiring internal to the chassis - Chub fixed this and now all 32 AA enable/disable switches seem to work as advertised. Of course we will need to do the in-situ test to make sure.
2. The problem with the ADC channels were multiple:
• On the software end, I had gotten some addressing wrong - this was fixed.
• On the hardware side - even though the inputs of the Acromag are "differential", I found that the readback was extremely noisy (~0.5 V RMS for a 3 V DC signal from the handheld calibrator unit ðŸ˜² ). Looking through the manual, I found a recommendation (pg10) that the "IN-" terminal of the Acromag ADC units be tied to the "RTN" pins on the same units. I don't know if this preserves the differential receiving capability of the Acromag ADCs - anyways, after Chub implemented this change, all the Analog Input channels behave as expected (I tested with a DC voltage and also a 200 mHz sine wave from a function generator).
• Note that most of the Eurocard electronics we use are single-ended sending anyways.
• What does this mean for the other Acromag ADCs (e.g. OSEM Shadow Sensor monitors) we have installed????? I saw no documentation in the elog/wiki.
3. Binary input channel:
• This is used by the "CM LIMIT" channel.
• I found that I had to initialize a separate alias for the BIO3 unit, which acquires this signal, to use the modbus function "4" corresponding to "Read Input Registers" - c.f. the binary output modbus function 6, which is to "Write Single Register".
• The fix for the mbbo channels is also likely to be along this lines - but I don't have the energy for that endavor right now.
4. Testing of the physical mbboDirect bit channels using the Acromag Window utility
• I can't get the mbboDirect EPICS record to work as expected, so I decided to use the native Acromag utility to test the functionality
• First I released control of the acromags from the supermicro (stopped modbus)
• There were several wiring errors - Chub had left for the day so I just fixed it myself.
• The LED tester kit was used to check that the correct bits were flipped - they were.
5. At the time of writing, the non-functional channels (in EPICS) are all related to the CM board:
• C1:LSC-CM_LIMIT (binary input) tested later in the day, works okay...
• C1:LSC-CM_REFL1_BITS (mbboDirect)
• C1:LSC-CM_REFL2_BITS (mbboDirect)
• C1:LSC-CM_AO_BITS (mbboDirect)
• C1:LSC-CM_BOOST2_BITS (mbboDirect)

Since we don't immediately need the CM board, I say we push ahead with the install - at least that will restore the ability to lock PRMI / DRMI. Then we can debug these issues in situ - I'm certain the issue is related to the EPICS/Modbus setup and not the hardware because I verified the physical channel map using the Acromag windows utility.

1. Install power supply cables at 1Y3
2. Install supermicro and Acromag crates in 1Y3
3. Migrate existing P1 connectors to P2 where applicable (Whitening boards)
4. Connect Dsub-->P1 / P2 adaptors
5. Run in-situ tests
 Quote: I bench tested the functionality of all the c1iscaux Acromag crate channels. Summary: we are not ready for a Monday install, much debugging remains.
Attachment 1: iscauxCheclist.pdf
14842   Mon Aug 12 19:58:23 2019 gautamUpdateIOOMC1 suspension oddness

Repair plan:

1. Get "spare" satellite box working --- Chub
• According to elog14441, this box has flaky connectors which probably need to be remade
2. Re-make the 64-pin IDC crimped connection on the cable from the coil driver board to sat. box, at the Satellite box end --- Chub and gautam

Any other ideas? The problem persists and it's annoying that the IMC cannot be locked.

14844   Tue Aug 13 08:07:09 2019 gautamUpdateCDSP1--->P2

This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?

14845   Tue Aug 13 14:36:17 2019 gautamUpdateCDSP1--->P2

As it turns out, only one extra shroud needed to be installed - I did this and migrated the cables for the 4 whitening boards from the P1 to P2 connectors. So until the new Acromag box is installed, we have no control over the whitening gains (slow channels), but do still have control over the whitening filter enable/disable (controlled by fast BIO). I am thinking about the easiest way to test the latter - I think the ambient PD dark noise level is too low to be seen above ADC noise even with the whitening enabled, and setting up drive signals to individual channels is too painful - maybe with +45dB of whitening gain, the (z,p) whitening filter shape can be seen with just PD/demod chain electroncis noise.

 Quote: This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?
14846   Thu Aug 15 18:54:54 2019 gautamUpdateALSALS sensing noise due to IMC

Summary:

I came aross an interesting suggestion by Yutaro that KAGRA's low-frequency ALS noise could be limited by the fact that the IMC comes between the point where the frequencies of the PSL and AUX lasers are sensed (i.e. the ALS beat note), and the point where we want them to be equal (i.e. the input of the arm cavity). I wanted to see if the same effect could be at play in the 40m ALS system. A first estimate suggests to me that the numbers are definitely in the ballpark. If this is true, we may benefit from lower noise ALS by picking off the PSL beam for the ALS beat note after the IMC.

Details:

Even though the KAGRA phase lock scheme is different from the 40m scheme, the algebra holds. I needed an estimate of how much the arm cavity moves, I used data from a POX lock to estimate this. The estimate is probably not very accurate (since the arm cavity length is more stable than the IMC length, and the measured ALS noise, e.g. this elog, is actually better than what this calculation would have me believe), but should be the right order of magnitude. From this crude estimate, it does look like for f<10 Hz, this effect could be significant. I assumed an IMC pole of 3.8 kHz for this calculation.

I've indicated a "target" ALS performance where the ALS noise would be less than the CARM linewidth, which would hopefully make the locking much easier. Seems like realizing this target will be touch-and-go. But if we can implement length feedforward control for the arm cavities using seismometers, the low frequency motion of the optics should go down. It would be interesting to see if the ALS noise gets better at low frequencies with length feedforward engaged.

1. Took data from Kiwamu's paper for the seismic noise
2. Overlaid measured ALS noise
Attachment 1: ALSsensingNoise.pdf
14848   Fri Aug 16 16:40:04 2019 gautamUpdateCDS1Y3 work

[chub, gautam]

Installation: The following equipment were installed in 1Y3, see Attachment #1:

1. Supermicro server, which is the new c1iscaux machine, with IP Address 192.168.113.83.
2. 6U Acromag chassis which contains all the ADCs, DACs and BIO units.
3. 2 Sorensen DC power supplies to provide +24 V DC and +15 V DC to the Acromags.
4. Fusable DIN rail power blocks were installed on the North side of the 1Y3 rack - I placed 2 banks of 5 connectors each for +15 V DC and +24 V DC.

Removal: The following equipment was removed from 1Y3:

1. VME crates that were the old c1iscaux and c1iscaux2 machines.
2. Spare VME crate that used to be c1susaux, which Chub and I brought over to 1Y3 in an attempt to revive the broken c1iscaux2.
3. Approximately 30 twisted ribbon cables that were going to the cross connects. For now, we have not done a full cleanup and they are just piled along the east arm (see Attachment #2), beware if you are walking there!

Software:

1. I connected the c1iscaux machine to the martian network.
2. Then I edited the relevant files on chiara to free up the IP addresses previously used by c1iscaux (192.168.113.81) and c1iscaux2 (192.168.113.82), and re-assigned the IP address used for c1iscaux to be 192.168.113.83.
3. I also changed the hostname of the c1iscaux machine (it was temporarily called c1iscaux3 to allow bench testing).
4. I moved the old /cvs/cds/caltech/target/c1iscaux and /cvs/cds/caltech/target/c1iscaux2 directories to /cvs/cds/caltech/target/preAcromag_oldVME/c1iscaux and /cvs/cds/caltech/target/preAcromag_oldVME/c1iscaux2 respectively.
5. I moved the temporarily named /cvs/cds/caltech/target/c1iscaux3 directory, from which I was running all the tests, to /cvs/cds/caltech/target/c1iscaux.
6. I edited all references to c1iscaux3 in the systemd files so that we can run the approriate systemd services.

Next steps:

1. We did not get around to running the DB37 cables between the Acromag chassis and the 1Y2 Eurocrates today - this operation itself took the whole day as we also needed to lay out some support struts etc on the rack to support the Sorensens and the Acromag chassis.
2. Once the Acromags are connected to the Eurocrates, we have to run in-situ tests to make sure the appropriate functionality has been restored.
3. We must have bumped something in the c1lsc expansion chassis - the CDS FE overview screen is reporting some errors (see Attachment #3). I will fix this.
4. General tidiness, strain-relief etc.
 Quote: I judge that we are good to go ahead with an install tomorrow.
Attachment 1: newLook1Y3.JPG
Attachment 2: IMG_7803.JPG
Attachment 3: c1lsc_crashed.png
14849   Sat Aug 17 16:49:23 2019 gautamUpdateCDSMore 1Y3 work

Work done today:

1. All ribbon cable connections to the backplane of the 1Y2 Eurocrates were removed. The cables themselves were cleared for more space to work with.
2. 20x 15ft DB37 Cables were run between 1Y2 and 1Y3 via overhead cable tray.
3. Backplane interface boards were installed for 1Y2 Eurocrate boards.
4. Connections were made between the Acromag chassis and the eurocrate electronics modules.

Testing of functionality:

1. Fast BIO switching was verified to work for the following photodiodes:
• AS55, AS110, REFL11, REFL33, REFL55, REFL165, POX11, POY11, POP22, POP110.
• No light was incident on the PDs.
• Test was done by increasing the whitening gain to +45 dB, and then looking at the ASD of the electronics noise between 50 Hz and 500 Hz with the whitening enabled/disabled. We expect x10 difference between the two states. This was seen.
2. "DetMon" channels were verified to work - see Attachment #1
• Y-axis units is volts
• Test was done by toggling the output of the 11 MHz Marconi, and looking for a change.
• As seen in the attachment, all 5 monitor channels show a change.
• This needs to be calibrated into some sensible units - I don't know why the different modulation frequencies have such different readbacks from supposedly identical Demod Board monitor points.
• Not sure if the ~10 V reported by the REFL165 monitor point is real or saturated.
• These channels are installed to signal/help debug the infamous ERA-5 decay problem, but maybe already some are decayed?
3. QPD interface channels were verified to work - see Attachment #2
• Test was done by shining a green laser pointer on QPD quadrants.

Much testing remains to be done, but I defer further testing till Monday - the main functionality to be verified in the short run is the whitening gain stepping. The strain-relief of cables and general cleanup will be undertaken by Chub. Current state of affairs is in Attachment #3, leaves much to be desired in terms of cleanliness.

I will also setup the autoburt for the new machine on Monday. We will also need to add some channels to C0EDCU.ini if we want to trend them over some years (e.g. RF signal powers for monitoring ERA-5 health).

* c1lsc FE was rebooted using the usual script, and everything seems to be healthy in CDS-land again, see Attachment #4.

 Quote: Next steps:  We did not get around to running the DB37 cables between the Acromag chassis and the 1Y2 Eurocrates today - this operation itself took the whole day as we also needed to lay out some support struts etc on the rack to support the Sorensens and the Acromag chassis. Once the Acromags are connected to the Eurocrates, we have to run in-situ tests to make sure the appropriate functionality has been restored. We must have bumped something in the c1lsc expansion chassis - the CDS FE overview screen is reporting some errors (see Attachment #3). I will fix this. General tidiness, strain-relief etc.
Attachment 1: Screen_Shot_2019-08-17_at_3.00.57_PM.png
Attachment 2: Screen_Shot_2019-08-17_at_3.12.23_PM.png
Attachment 3: IMG_7804.JPG
Attachment 4: Screenshot_from_2019-08-17_17-04-47.png
14850   Mon Aug 19 14:36:21 2019 gautamUpdateCDSc1iscaux remaining work

Here is what is left to do:

1. Strain relief of all cabling. Chub will take care of this in the coming days. I have said he can connect and disconnect cables as he pleases, but after this work, we may require a hard reboot of the Acromag chassis before restoring functionality to the channels, as it is known that the Acromags can sometimes get "stuck" by a sudden connection of voltage.
2. Installation of DB15 cable to the P2 connector of the CM board and a DB9 cable to the ALS demod unit (LO and RF power monitors). These will arrive in the next couple of days and Chub will take care of the install.
3. Design, manufacture and install of a custom version of the backplane P1 adaptor board with only 1 D37 connector - for some of the PD DC signals, a custom adaptor board, part number D010005 for which I can't find any schematics is already installed on the P2 connector, and makes the DC monitor signals available to 4 LEMO connectors. These signals are then digitized by the fast CDS system, presumably for PDH signal normalization. The footprint of this P2--->LEMO adaptor is such that we cannot simply install our P1---> 2xDB37 adaptor boards, because of space constraints. Fortunately, there is a simple fix to reduce the footprint of the board: remove the bottom DB37 connector, which is unused in the c1iscaux system except for the CM board. I recommend getting ~10 pcs of such boards, as it is also useful in a few other places, where the power cabling to the eurocrates are a space constraint. See Attachment #1 for a picture explaining this situation. Anyone want to volunteer to take care of this?
4. In-situ testing. This is easiest done with some light available in the interferometer. Which in turn requires IMC to be locked. Which in turn requires satellite box fixing. Anyone want to volunteer to take care of this?
5. Modify C0EDCU.ini to trend the new slow channels we may want long-term monitoring of (e.g. LO power levels to the Demod boards). Anyone want to volunteer to take care of this?
6. Decide what to do about the CM latch logic. There are some contraints with the way the acromag register addressing works, that I've had to change the way the mbboDirect bits are controlled. Unfortunately, this seems to sometimes and unpredictably cause the bits to flip in a non-robust way, which is the whole point of having the latch in the first place. Either the latch logic needs to be improved, or we need to implement the latch logic in the fast CDS system, not the slow.

Today I set up the autoburt.req file for the c1iscaux channels, and confirmed that the snapshots are getting recorded. There were a lot of channels in the old autoburt.req file which I thought were un-necessary (and several which no longer exist), so now the only channels that are burt-ed are the whitening gains and states of the AA filters. If someone feels we need more channels to be snapshot recorded, you can add them to the file.

In the old target directory, there were also various versions of a "saverestore.req" file - why do we need this in addition to an autoburt? I guess it is possible they are used by the IFOconfigure scripts to setup some whitening gains etc...

Attachment 1: caseForSmallerFootprint.pdf
14854   Fri Aug 23 10:01:14 2019 gautamUpdateBHDOMC cavity geometry - some more modeling

Summary:

I did some more investigation of what the appropriate cavity geometry would be for the OMC. Unsurprisingly, depending on the incident mode content, the preferred operating point changes. So how do we choose what the "correct" model is? Is it accurate to model the output beam HOM content from NPROs (is this purely determined by the geometry of the lasing cavity?), which we can then propagate through the PMC, IMC, and CARM cavities? This modeling will be written up in the design document shortly.

*Colorbar label errata - instead of 1 W on BS, it should read 1 W on PRM. The heatmaps take a while to generate, so I'll fix that in a bit.

Update 230pm PDT: I realize there are some problems with these plots. The critically coupled f2 sideband getting transmitted through the T=10% SRM should have significantly more power than the transmission through a T=100ppm optic. For similar modulation depth (which we have), I think it is indeed true that there will be x1000 more f2 power than f1 power for both the IFO AS beam and the LO pickoff through the PRC. But if the LO is picked off elsewhere, we have to do the numbers again.

Details:

Attachment #1: Two candidate models. The first follows the power law assumption of G1201111, while in the second, I preserved the same scaling, but for the f1 sideband, I set the DC level by assuming a PRG of 45, modulation depth of 0.18, and 100 ppm pickoff from the PRC such that we get 50 mW of carrier light (to act as a local oscillator) for 10 W incident on the back of PRM. Is this a reasonable assumption?

Attachment #2: Heatmaps of the OMC transmission, assuming (i) 0 contrast defect light in the carrier TEM00 mode, (ii) PRG=45 and (iii) 1 W incident on the back of PRM. The color bar limits are preserved for both plots, so the "dark" areas of the plot, which indicate candidate operating points, are darker in the left-hand plot. Obviously, when there is more f1 power incident on the OMC, more of it is transmitted. But my point is that the "best operating point(s)" in both plots are different.

Why is this model refinement necessary? In the aLIGO OMC design, an assumption was made that the light level of the f1 sideband is 1/1000th that of the f2 sideband in the interferometer AS beam. This is justified as the RC lengths are chosen such that the f2 sideband is critically coupled to the AS port, but the f1 is not (it is not quite anti-resonant either). For the BHD application, this assumption is no longer true, as long as the LO beam is picked off after the RF sidebands are applied. There will be significant f1 content as well, and so the mode content of the f1 field is critical in determining the OMC filtering performance.

Attachment 1: modeContentComparison.pdf
Attachment 2: OMCtransComparison.pdf
14857   Sun Aug 25 14:18:08 2019 gautamUpdateCDSc1iscaux remaining work

There were a bunch of useless / degenerate channels added - e.g. whitening gains which are alreay burt-snapshot. Maybe there are many more useless channels being trended, but no need to add more.

Copy-pasting wasn't done correctly - the first 4 added channels were duplicates. There are in fact 5 LO power mons, one for each of the frequencies 11, 33, 55, 110 and 165 MHz.

I cleaned up. Basically only the detect-mon channels, and the ALS channels, are new in the setup now. I will review if any extra channels are required later. While checking that the daqd is happy, I noticed c1lsc FEs are in their stuck state, see Attachment #1. I guess a cable was bumped when the strain relief operation was underway. I'm not attempting a remote resuscitation.

 Quote: I added the list of new c1iscaux channels to /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini and restarted the framebuilder. Koji had thought some of these channels might have previously existed under slightly different names. However, after looking through C0EDCU.ini and the other _SLOW.ini files, I did not find any candidates for removal. As far as I can tell, all of these channels are being recorded for the first time.
Attachment 1: Screen_Shot_2019-08-25_at_10.38.37_PM.png
14873   Thu Sep 12 09:49:07 2019 gautamUpdateComputerscontrol rm wkstns shutdown

Chub wanted to get the correct part number for the replacement UPS batteries which necessitated opening up the UPS. To be cautious, all the workstations were shutdown at ~9:30am while the unit is pulled out and inspected. While looking at the UPS, we found that the insulation on the main power cord is damaged at both ends. Chub will post photos.

However, despite these precautions, rossa reports some error on boot up (not the same xdisp junk that happened before). pianosa and donatella came back up just fine. It is remotely accessible (ssh-able) though so maybe we can recover it...

 Quote: please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding
Attachment 1: IMG_7943.JPG
14879   Mon Sep 16 09:11:37 2019 gautamSummaryCDSDIN 96pin to DSUB37 adapter (single) ready for use

I installed 6 of these in 1Y2. Three were for PD INTF #1-3, and I used three more for the AS110, REFL11, and REFL33 Demod board FEs, where the strain-reflief of the DC power cables to the Eurocrate was becoming a problem. So now there are only 4 units available as spares.

Once the strain-relieving of the Dsub cabling to 1Y3 is done, we can move ahead with testing. I'd like to put this to bed this week if possible.

ELOG V3.1.3-