[Manasa, Koji, Jenne]

We went into the BS and IOO chambers, and aligned the green beams such that they came out of the vacuum chamber.  The idea here was to get the beams at the same height, but slightly offset in yaw.  This required moving the Periscope on BS table, PBS in front of that periscope, the Periscope on the IOO table, and 2 steering mirrors on the IOO table after the 2nd periscope.  The tables were not releveled, although we have aligned the full interferometer to this situation, so we do not want to touch the tables.  The MC spot positions are still consistent with those measured earlier this afternoon, before this work, so I'm not concerned.

We confirmed that both green beams are hitting a good place (centered in pitch, and just left and right of center in yaw) on the mirror in the OMC chamber, and are getting to the center of the first mirror on the PSL table.  We then coarsely aligned the beams on the PSL table.

We then relocked and aligned the arms for IR, and checked that the AS beam is centered on the mirrors in the BS chamber, and that the beam is coming out, and to the AS table.  I touched the last mirror before PZT3 a small amount in yaw, and then PZT3 in pitch and yaw, until we saw the beam recentered on the first mirror on the AS table.  At that point, we were also back to the center of the AS camera (which is good, since Koji had aligned all of that the other day).  So, the AS beam is good.

We checked IPPOS, and have centered the beam on all the mirrors, and aligned the beam onto the QPD. 

We checked IPANG, by looking through the viewports at the mirrors in the ETMY chamber.  We are now centered in yaw, but clipping a bit low.  This is what we want, since we always end up drifting high during the pump-down. 

We see a nice, unclipped REFL beam on the camera.

We see a beam a little high on the POP camera, but Koji looked on the table with a card, and saw the beam....we just need to do minor alignment on the out of vac mirrors.

We checked again that the green TEM00 beams from both arms come to the PSL table. 

We are getting POX and POY out, since we are using them to lock and align the arms.

Manasa and Koji recovered one clean allen key from the bottom of the chambers, but one remains, as a sacrifice to the vacuum gods. 

I believe that, with the exception of checking the oplevs and taking photos of PR3, and the green steering optics, we have finished all of our vent tasks.  We should do a quickie alignment on Monday, check the oplevs, take some photos, and put on the heavy doors.  Pumping can start either Monday afternoon or Tuesday morning. 

I had to make a CDS change to the c1lsc model in an effort to get a few more signals into the models. Rather than risk requiring hard reboots (typcially my experience if I try to restart a model), I opted for the more deterministic scripted reboot, at the expense of spending ~20mins to get everything back up and running.

Update 2230: this was more complicated than expected - a nuclear reboot was necessary but now everything is back online and functioning as expected. While all the CDS indicators were green when I wrote this up at ~1800, the c1sus model was having frequent CPU overflows (execution time > 60 us). Not sure why this happened, or why a hard power reboot of everything fixed it, but I'm not delving into this.

The point of all this was that I can now simultaneously digitize 4 channels - 2 DCPDs, and 2 demodulated quadratures of an RF signal.

I found the 8 vertex watchdogs tripped today morning. The ETMs were fine, suggesting this was not an actual earthquake. I suspect it was connected to this remote work? Was there a reason why they were left tripped?

On a side note - I don't think we log the watchdog state explicitly. We can infer whether the optic is damped by looking at the OSEM sensor time series, but do we want to record the watchdog state to frames?

Yes, this was a consequence of the systemd scripting I was setting up. Unlike the old susaux system, we decided for safety NOT to allow the modbus IOC to automatically enable the coil outputs. Thus when the modbus service starts/restarts, it automatically restores all state except the watchdog channels, which are left in their default disabled state. They then have to be manully enabled by an operator, as I should have done after finishing testing.

This EQ seems to have knocked all suspensions out. ITMX was stuck. It is now released, and the IMC is locked again. It looks like there are some serious aftershocks going on so let's keep an eye on things.

This morning I found all the watchdogs had tripped during the night.

I restored them all.

I can't damp ITMX. I noticed that its driving matrix is all 1s and -1s as the the right values had been lost in some previous burtrestoring.

Rana fixed the problem. He found that the side damping was saturating. He lowered the gain a little for a while, waited for the the damping to slow down the optic and then he brought the gain back where it was.

He also upadted the MEDM screen snapshot.

Looks like a M=4.6 earthquate in Barstow,CA tripped all the suspensions. ITMX got stuck. I restored the local damping on all the suspensions just now, and freed ITMX. Looks like all the suspensions damp okay, so I think we didn't suffer any lasting damage. IMC was re-aligned and is now locked.

This EQ in Nevada seems to have tripped all watchdogs. ITMX was stuck. It was released, and all the watchdogs were restored. Now the IMC is locked.

So after having broke Allegra by updating the kernel, I was able to get it running again by copying the xorg.conf.backup file over xorg.conf in /etc/X11.  So at this point in time, Allegra is running with generic video drivers, as opposed to the ATI specific and proprietary drivers.

 This problem seems to be restricted to allegra.  Dataviewer works fine on Rosalba  and op440m, as well as using ssh -X into rosalba to run dataviewer remotely.  DTT seems to work fine on allegra.  The disk usage seems no where near full on allegra.  Without knowing which "device" its refering to (although it must be a device local to allegra), I'm not sure what to look at now. 

I'm going to do a reboot of allegra and see if that helps.

Update:  The reboot seems to have fixed the issue.

I found the dataviewer didn't work only on Allegra. This thing sometimes happened as described in the past entry.

I rebooted Allegra, then the problem was fixed.

Allegra had no network cable and no mouse. We found Allegra'snetwork cable (black) and connected it.

I found a dirty old school mouse and connected it.

I wiped Allegra and now I'm currently installing debian 10 on allegra following Jon's elog.

04/01 update: I forgot to mention that I tried installing cds software by following Jamie's instruction: I added the line in /etc/apt/sources.list.d/lscsoft.list: "deb http://software.ligo.org/lscsoft/debian/ stretch contrib". But this the only thing I managed to do. The next command in the instructions failed.

I was trying to give Allegra a second head, and it didn't quite work.  It's still in progress.  Steve, you might not like how I've 'mounted' the second monitor, so we can talk about something that might work tomorrow.

[koji, chub, jon, rana, gautam]

Full story tomorrow, but we went through most of the required pre close-up checks/tasks (i.e. both arms were locked, PRC and SRC cavity flashes were observed). Tomorrow, it remains to 

1. Confirm clearance between elliptical reflector and ETMY
2. Confirm leveling of ETMY table
3. Take pics of ETMY table
4. Put heavy door on ETMY chamber
5. Pump down

The ETMY suspension chain needs to be re-characterized (neither the old settings, nor a +/- 1 gain setting worked well for us tonight), but this can be done once we are back under vacuum.

Attachment 5: RF delay line was accommodated in 1X3B. (KA)

[Anchal, Radhika]

Attachment 2: The custom cables which were part of the intermediate setup between old electronics architecture and new electronics architecture were found.
These include:

• 2 DB37 cables with custom wiring at their connectors to connect between vacuum flange and new Sat amp box, marked J4-J5 and J6-J7.
• 2 DB15 to dual head DB9 (like a Hydra) cables used to interface between old coil drivers and new sat amp box.

A copy of these cables are in use for MC1 right now. These are spare cables. We put them in a cardboard box and marked the box appropriately.
The box is under the vacuum tube along Yarm near the center.

Behind the X arm tube

[Anchal, Radhika]

The cables in USPS open box were important cables that are part of the new electronics architecture. These are 3 ft D2100103 DB15F to DB9M Reducer Cable that go between coil driver output (DB15M on back) to satellite amplifier coil driver in (DB9F on the front). These have been placed in a separate plastic box, labeled, and kept with the rest of the D-sub cable plastic boxes that are part of the upgrade wiring behind the tube on YARM across 1Y2. I believe JC would eventually store these dsub cable boxes together somewhere later.

In order to install the necessary extensions to epics to make the aLIGO conlog work, I have edited one file in the base epics install that affects makefiles:

/cvs/cds/caltech/apps/linux64/epics/base/configure/CONFIG_COMMON

Jamie said he prefers diffs, so I regenerated the original file and did a diff against the current file:

megatron:configure>diff CONFIG_COMMON.orig.reconstructedMar72012 CONFIG_COMMON.bck.Mar72012
206,207c206,210
< USR_CPPFLAGS =
< USR_DBDFLAGS =
---
> USR_CPPFLAGS = -I $(EPICS_BASE)/include
> USR_CPPFLAGS += -I $(EPICS_BASE)/include/os/Linux/
> USR_CPPFLAGS += -I $(EPICS_BASE)/../modules/archive/lib/linux-x86_64/
> USR_DBDFLAGS = -I $(EPICS_BASE)/dbd
> USR_DBDFLAGS += -I $(EPICS_BASE)/../modules/archive/dbd

This is saved in CONFIG_COMMON.diff.Mar72012_1

 After following up with Patrick Thomas for a while trying to make the extensions to epics work within the currently installed epics, he decided that we should just start over with a fresh install of epics 3.14.10.

I am installing this in /ligo/apps/linux-x86_64/epics/base-3.14.10/

Prior to all of this, I had done a lot of installation and configuration of the packages needed to make LAMP work:

sudo apt-get install lamp-server^

sudo apt-get install phpmyadmin

I then continued to follow the instructions on Patrick's wiki:

https://awiki.ligo-wa.caltech.edu/aLIGO/Conlog#EDCU_library

I installed the c_string library into /ligo/apps/linux-x86_64/ according to his instructions.  (prior to my installs, there was no /ligo/ on this machine at all, so I made the needed parent directories with the correct permissions).

That should be everything up to installing epics (working on that now).

Successful? Installation of Fresh EPICS and Extensions

Fresh Copy of EPICS 3.14.10

/ligo/apps/linux-x86_64/epics

/ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/iocc1_conlog

Rest of Install

New Install Instructions:

You want to create the EPICS IOC boot directory by doing the following:

In the top level of the IOC (.../epics/iocs/conlog) with the appropriate
paths:

/epics/base/bin/linux-x86_64/makeBaseApp.pl -i -t ioc c1_conlog
What application should the IOC(s) boot?
The default uses the IOC's name, even if not listed above.
Application name? conlog

Then you will have to update the st.cmd it creates. You can compare the
st.cmd and st.cmd.backup files in the other directories to see what needs
to be changed.

I don't know if just copying the directory will work, it might.

You will also probably want to change the following line in
/epics/modules/archive/archiveApp/src/drvArchive.c:

queue = epicsMessageQueueCreate(100000000, sizeof(struct message_type));

and reduce 100000000 to something smaller depending on the amount of ram
available to the computer. I think sizeof(struct message_type) is
something like 112 bytes. Then recompile.

You basically put a file with the list of channels to use in the directory
path for "use channel list filepath" in the following command in st.cmd:
drvArchive_read_channel_list_filepaths <add channel list filepath>,<remove
channel list filepath>,<use channel list filepath>
I can send you the script that I currently use to generate that channel
list if you want, but it may need to be changed for your setup.

Once you start the ioc, open the medm which can be checked out from
subversion here: cds_user_apps/trunk/cds/common/medm/CONLOG.adl
with macro substitution for IFO: medm -x -macro "IFO=C1"
and click on the button for "Use channel list".
The number of monitored channels should increase to the number of channels
in the file.

-Patrick

...

The perl script and example file are attached, just redirect the output of
the perl script to a file. It scans autoBurt.req files in a particular
directory and its subdirectories for channel names that meet certain
criteria. All the file contains is a list of channel names, one on each
line. To start the IOC, go to the target directory and run
./startup.c1conlog.

My Notes Regarding These Instructions:

dbLoadRecords("db/conlog.db","IFO=C1")
drvArchive_mysql "C1_conlog","/data/mysql/C1_conlog_epics_user"
drvArchive_read_channel_list_filepaths "/ligo/caltech/data/conlog/c1/add_channel_names","/ligo/caltech/data/conlog/c1/remove_channel_names","/ligo/caltech/data/conlog/c1/use_channel_names"
drvArchive_write_channel_list_filepaths "/ligo/caltech/data/conlog/c1/channel_names","/ligo/caltech/data/conlog/c1/monitored_channel_names","/ligo/caltech/data/conlog/c1/unmonitored_channel_names"

controls: cd /opt/rtcds/<site>/<ifo>/target/conlog/conlogepics
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/db ./
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/dbd ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/envPaths ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/st.cmd ./
controls: echo ./bin/linux-x86_64/conlog st.cmd > startup.<ifo>conlog
controls: chmod a+x startup.<ifo>conlog

megatron:~/ryan>diff -u /var/www/conlog/conlog.php /var/www/conlog/conlog.php.bck.Mar82012_1
--- /var/www/conlog/conlog.php  2012-03-08 15:31:53.152547771 -0800
+++ /var/www/conlog/conlog.php.bck.Mar82012_1   2012-03-08 15:28:23.062704171 -0800
@@ -19,7 +19,7 @@
        <form action="query.php" method="post">
                <h3><label for="database">Database:</label></h3>
                <select id="database" name="database">
-                       <option value="C1_conlog">C1</option>
+                       <option value="h2_conlog">h2</option>
                </select>
 
                <h3><label for="included_channels">Included channels:</label></h3>

megatron:~/ryan>diff -u /var/www/conlog/query.php /var/www/conlog/query.php.bck.Mar82012_1
--- /var/www/conlog/query.php   2012-03-08 15:33:45.122550303 -0800
+++ /var/www/conlog/query.php.bck.Mar82012_1    2012-03-08 15:32:31.772554679 -0800
@@ -168,8 +168,8 @@
        }
 
        $database_name = $_POST["database"];
-       if ($database_name == 'C1_conlog') {
-               $server = '192.168.113.209';
+       if ($database_name == 'h2_conlog') {
+               $server = 'cdsconlog';
        }
        else {
                die('Unknown database.');

megatron:~/ryan>diff -u /etc/mysql/my.cnf /etc/mysql/my.cnf.bck.Mar82012_1
--- /etc/mysql/my.cnf   2012-03-08 15:35:57.122548370 -0800
+++ /etc/mysql/my.cnf.bck.Mar82012_1    2012-03-08 15:35:10.652559315 -0800
@@ -49,7 +49,7 @@
 #
 # Instead of skip-networking the default is now to listen only on
 # localhost which is more compatible and is not less secure.
-#bind-address          = 127.0.0.1
+bind-address           = 127.0.0.1
 #
 # * Fine Tuning
 #
megatron:~/ryan>

Conlog Environment

Too Many Fast Changing EPICS in New Conlog

 I took out a short (~12 cm) SMA cable from the "LO input" path into the MC demod board in an attempt to maximize the power in Q and minimize the power in I. The path might benefit from being shortened a little more, but it's hard to tell since I is noisy. (In the attached plots, channel 1 is Q and channel 2 is I.)

Should you find it necessary to restore the original path length, the cable I took out is in the "SMA ONLY" tupperware and has a printed label with "5" on it.

[anjali, gautam]

just main points, anajli is going to fill out the details.

To rule out mode-matching as the reason for non-ideal output from the MZ, I suggested using the setup I have on the NW side of the PSL enclosure for the measurement. This uses two identical fiber collimators, and the distance between collimator and recombination BS is approximately the same, so the spatial modes should be pretty well matched. 

The spooled fiber we found was not suitable for use as it had a wide key connector and I couldn't find any wide-key FC/PC to narrow-key FC/APC adaptors. So we decided to give the fiber going to the Y end and back (~90m estimated length) a shot. We connected the two fibers at the EY table using a fiber mating sleeve (so the fiber usually bringing the IR pickoff from EY to the PSL table was disconnected from its collimator). 

In summary, we cannot explain why the contrast of the MZ is <5%. Spatial mode-overlap is definitely not to blame. Power asymmetry in the two arms of the MZ is one possible explanation, could also be unstable polarization, even though we think the entire fiber chain is PM. Anjali is investigating.

We saw today that the Thorlabs PM beam splitters (borrowed from Andrew until our AFW components arrive) do not treat the two special axes (fast and slow) of the fiber on equal footing. When we coupled light into the fast axis, we saw huge asymmetry between the two split arms of the beamsplitter (3:1 ratio in power instead of the expected 1:1 for a 50/50 BS). Looking at the patch cord with an IR viewer, we also saw light leaking through the core along it. Turns out this part is meant to be used with light coupled to the slow axis only.

Summary:

Craig and I have been trying to put together a Simulink diagram of the proposed alternative calibration scheme. Each time I talk the idea over with someone, I convince myself it makes sense, but then I try and explain it to someone else and get more confused. Probably I am not even thinking about this in the right way. So I am putting what I have here for comments/suggestions.

What's the general idea?

Suppose the PSL is locked to the MC cavity, and the AUX laser is locked to the arm cavity (with sufficiently high BW). Then by driving a line in the arm cavity length, and beating the PSL and AUX lasers, we can determine how much we are modulating the arm cavity length in metres by reading out the beat frequency between the two lasers, provided the arm cavity length is precisely known.

So we need:

1. Both lasers to be stabilized to be able to sense the line we are driving
2. A high bandwidth PDH loop for locking the AUX laser to the arm cavity such that the AUX laser frequency is able to track the line we are driving
3. An accurate and precise way to read out the beat frequency (the proposal here is to use an FPGA based readout)
4. An accurate measurement of the arm length (I think we know the arm lengths to <0.1% so this shouldn't dominate any systematic error).

To be able to sense a 1kHz line being driven at 1e-16 m amplitude, I estimate we need a beat note stability of ~1mHz/rtHz at 1kHz.

Requirements and what we have currently:

• The PSL is locked to the mode-cleaner, and the arm cavity is locked to the PSL. The former PDH loop is high BW, and so we expect the stabilized PSL to have frequency noise of ~1mHz/rtHz at about 1kHz (to be measured and confirmed)
• The AUX laser is locked to the arm cavity with a medium-BW (~10kHz UGF) PDH servo. From past out-of-loop ALS beat measurements, I estimate the expected frequency noise of the AUX laser at 1kHz to be ~1Hz/rtHz with the current PDH setup
• Rana suggested we "borrow" the stability of the PSL by locking the AUX laser and PSL in a high bandwidth PLL - if we want this loop to have ~300kHz BW, then we need to use an EOM as an actuator. The attached Simulink diagram (schematic representation only, though I think I have measurements of many of those transfer functions/gains anyways) shows the topology I had in mind. Perhaps I did not understand this correctly, but if we have such a loop with high gain at 1kHz, and the error signal being the beat between PSL and AUX, won't it squish the modulation we are applying @1kHz?
• Is it feasible to instead add a parallel path to the end PDH loop with an EOM as an actuator (similar to what we do for the IMC locking)? Ideally, what we want is an end PDH loop which squishes the free-running NPRO noise to ~1mHz/rtHz at 1kHz instead of the 1Hz/rtHz we have currently. This loop would then also have negligible tracking error at 1kHz. Then, we could have a low bandwidth PLL offloading onto the temperature of the crystal to keep the beat between the two lasers hovering around the PSL frequency.

Hardware:

On the hardware side of things, we need:

• Broadband EOM
• FSS box to drive the EOM (Rana mentioned there is a spare available in the Cryo lab)

Koji and I briefly looked through the fiber inventory we have yesterday. We have some couplers (one mounted) and short (5m) patch fibers. But I think the fiber infrastructure we have in place currently is adequate - we have the AUX light brought to the PSL table, and there is a spare fiber running the other way if we want to bring the PSL IR to the end as well.

I need to also think about where we can stick the EOM in given physical constraints on the EX table and the beam diameter/aperture of EOM...

Question for Craig: What does the SNR of our lines have to be? IF we're only trying to calibrate the actuator in the audio band over long time scales, it seems we could get by with more frequency noise. Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?

We get SNR in two ways: the amplitude of applied force and the integration time.  So we are limited in two ways: stability of the lock to applied forces and time of locklosses / calibration fluctuations.

At the sites, you probably know that we blow our spectrum out of the water with the calibration lines, with SNRs of about 100 on the scale of about 10 seconds.  For us this might be impossible, since we aren't as quiet.

If we want 1% calibration on our sweeps, we'll need  0.01 = Uncertainty = sqrt( (1 - COH^2)/(2 * Navg * COH^2) ), where COH is the coherence of the transfer function measurement and Navg is the number of measurements at a specific frequency.  This equation comes from Bendat and Piersol, and is subject to a bunch of assumptions which may not be true for us (particularly, that the plant is stationary in time).

If we let Navg = 10, then COH ~ 0.999.

Coherence = Gxy^2/(Gxx * Gyy), where x(t) and y(t) are the input signal and output signal of the transfer function measurement, Gxx and Gyy are the spectral densities of x and y, and Gxy is the cross-spectral density.  

Usually SNR = P_signal / P_noise, but for us SNR = A_signal / A_noise.

Eric Q and Evan H helped me find the relationship between Coherence and SNR:

P = Pn + Pc, Pn = P * (1 - Coh), Pc = P * Coh

==> SNR = sqrt( Pc / Pn ) = sqrt( Coh / 1 - Coh )

From Coh ~ 0.999, SNR ~ 30.

OK, but the questions still stands: "Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?"

I looked in the optics cabinet to see what lenses we have available, and re-ran the mode-matching calculation to see if we could find a better solution - I'm attaching a plot for what looks like a good candidate (optimized mode-matching efficiency for the X mode is 100%, and for the Y mode, it is 97.98%), though it does involve switching "L1", which is currently a 175mm efl lens, for a 125mm efl lens. I've also indicated on the plot where the various other components are relative to the optimized positions of the lens, and it doesn't look like anything is stacked on top of each other. Also, the beam width throughout is well below 4.7mm, which is the maximum cited width the Faraday can handle, as per its datasheet. "L1" doesn't quite get the waist of the beam to coincide with the geometrical center of the Faraday, but I don't think this is requried? Also, I've optimized the mode matching using the measured X width of the beam (red curve in Attachment #1), and have overlaid the calculated Y width of the beam for the optimized position of the lenses (red curve in Attachment #1). The target waist was 35um at the center of the doubling oven, which the X profile achieves, but the Y profile has a width of 32 um at the same point.

In all the calculations, I've not accounted for possible effects of the HWPs and the Faraday on the beam profile....

I installed and activated Altium, a PCB design software, on the Windows machine M2.

With Altium I am going to design the triple resonant circuit for the broadband EOM.

The goal was to characterise the new amplifier (AP1053). For a practice, I did the characterisation of the old amplifier.This test is similar to that reported in Elog ID 13602.

• Attachment #1 shows the schematic of the setup for gain characterisation and Attachment #2 shows the results of gain characterisation. 
• The gain measurement is comparable with the previous results. From the data sheet, 10 dB gain is guaranteed in the frequency range 10-450 MHz. From our observation, the gain is not flat pver this region. We have measured a maximum gain of 10.7 dB at 6 MHz and it has then decreased upto 8.5 dB at 500 MHz
• Attachement #3 shows the schematic of the setup for the noise characterisation and Attachment # 4 shows the results of noise measurment. 
• The noise measurement doesn't look fine. We probably have to repeat this measurement.

I just realized that I forgot to elog this, but yesterday afternoon I bypassed the amplifier in the BeatX path, and now the X beatnote is about -27dBm.  Arms lock nicely with ALS.

And the out-of-loop level of the ALSX compared with the previous measurement is ...?

Sorry, I had been in a hurry when I worked on this last week, and again when I wrote the elog, but I wanted to at least put in a note for any weekend workers.

The ALS beatnote setups need alignment on the PSL table.  However, even at very low RF beat frequency, the X beatnote now at low frequencies matches our best measurement from last week.  The "HEPA off" (teal and purple) measurements are from last week, and the red and blue are from this week.  The X beatnote was 10MHz and the Y beatnote today was 31MHz.

The top plot shows a sweep from 10 kHz to 5 MHz of the ratio of the voltage output of the PD detecting power from the NPRO laser beam and the RF source voltage (the magnitude of the complex transfer function). The black trace was taken with the laser beam blocked. For runs 2 and 3 I changed the laser temperature set point by 10 mK and 100 mK respectively to see if there was a significant change in the AM response. The bottom plots shows runs 2 and 3 compared to run 1 plotted in dB (to be explicit, i'm plotting 10 times the base 10 log of the magnitude of the ratio of two complex transfer functions). Changing the temperature seems to have only a minor effect on the output except at around 450kHz, where the response has a large peak in run 1 and much smaller peaks in runs 2 and 3. 

The traces in the top plot consist of 16 averages taken with a 300Hz IF bandwidth, 15 dBm source power (attenuated with a 6 dB attenuator) and with 20dB attenuation of the input power from the PD.

Next I'm going to probe a narrow band region where the response is low (2.0MHz or 2.4MHz perhaps) and choose a bandwidth for the dither frequency for the PDH locking.

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

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

 The new RF cables arrived. But unfortunately we did not realize that RG405 was a Semi-rigid coax cable, with a copper shielding. These are meant to be installed in setups that will not be changed / disturbed. We need to order a different set of cables. The new cables have joined the other cables in the plastic box mentioned above.

For now to check if the old setup is still working, I have installed an RF cable (that we earlier pulled out and looks like in good shape, labelled REFL33) between the AS55 Demodulator output PD RF MON in rack 1Y2 and the network analyzer input. Since Manasa and the others were busy working with the interferometer, I did not switch on the laser and did not take any readings. The power supply to REF DET remains off.

I will continue with the measurements tomorrow morning and also try to get the data wirelessly using Alex's code. 

I've fallen down the rabbit hole of trying to reconcile our desire for newer versions of the Numpy and Scipy python packages with the use of our handy cdsutils tools. 

I've set up an installation of Anaconda python in /ligo/apps/anaconda. Installing pyepics, nds2, and cdsutils was straightforward, but there were a myriad of odd python packages that cdsutils depends on, that are typically installed at the OS level (python-gst, gobject, glib) which I just manually copied over to the anaconda directories. Also, the version of readline that anaconda ships with is somewhat borked (dark voodoo fix was found here: github link. The issue mentioned there wasn't why I needed the fix. Somehow libreadline was causing pyepics initialization to fail). 

I was initially hoping this kind of exercise would be useful, as having a separate python environment that we control buffers us from the system installation and allows us to use whatever version of packages we want, but the amount of hackery I did to get to get cdsutils to work probably didn't result in the most robust solution. (Maybe there was a better way!)

In any case, I have not changed any of our machines' default paths or environment variables. Instead, I have simply created an alias that points to Anaconda python: "apython"

Example:

Thus, Diego should now be able to complete his script that needs the newer Scipy, as well as CDSutils. 

Final note: I've tested z (read|write|avg) with $PATH modified to have /ligo/apps/anaconda/bin at the start, and they seem to work. If things seem to hold up, maybe we can replace the default command-line python, but its not strictly necessary. 

 Avoid rabbit holes! What I did at LLO which works is to install an Anaconda in some shared directory and then just make an alias which puts that directory at the head of the path when running the more advanced SciPy installs. It works fine and cannot interfere with our usual operation since its only sourced when running peak find.