The MCautolocker had stalled - there were no additional lines to the logfile after 12:17pm (~20mins ago). Normally, it suffices to ssh into megatron and run sudo initctl restart MCautolocker - but it seems that there was no running initctl instance of this, so I had to run sudo initctl start MCautolocker. The FSS Slow control initctl process also seemed to have been terminated, so I ran sudo initctl start FSSslowPy.

It is not clear to me why the initctl instances got killed in the first place, but MC locks fine now.

Last night, I tried to estimate the contribution of OL feedback signal to the MICH length error signal.

In order to do so, I took a swept sine measurement with a few points between 50 Hz and 500 Hz. The transfer function between C1:LSC-MICH_OUT_DQ and the Oplev Servo Output point (e.g. C1:SUS-BS_OL_PIT_OUT etc) was measured. I played around with the excitation amplitude till I got coherence > 0.9 for the TF measurement, while making sure I wasn't driving the Oplev error point too hard that side-lobes began to show up in the MICH control signal spectrum.

The Oplev control signal is not DQ-ed. So I locked the DRMI again and downloaded the 16k data "live" for ~5min stretch using cdsutils.getdata on the workstation. The Oplev error point is DQ-ed at 2k, but I found that the excitation amplitude needed for good SNR at the error point drove the servo to the limiter value of 2000cts - so I decided to use the control signal instead. Knowing the transfer function from the Oplev *_OUT* channel to C1:LSC-MICH_IN1_DQ, I backed out the coupling - the transfer function was only measured between 50 Hz and 500 Hz, and no extrapolation is done, so the estimation is only really valid in this range, which looks like where it is important anyways (see Attachment #2, contributions from ITMX, ITMY and BS PIT and YAW servos added in quadrature).

I was also looking at the Oplev servo shapes and noticed that they are different for the ITMs and the BS (Attachment #1). Specifically, for the ITM Oplevs, an "ELP15" is used to do the roll-off while an "ELP35" is employed in the BS servo (though an ELP35 also exists in the ITM Oplev filter banks). I got lost in an elog search for when these were tuned, but I guess the principles outlined in this elog still hold and can serve as a guideline for Oplev loop tweaking.

Coil driver noise estimation to follow

GV 10 May 12:30pm: I've uploaded another copy of the NB (Attachment #3) with the contributions from the ITMs and BS separated. Looks like below 100Hz, the BS coupling dominates, while the hump/plateau around 350Hz is coming from ITMX.

Gautam and Steve,

Surge protective power strip was install on Friday, May 5 in the Control Room

Computers not connected to the UPS are plugged into Isobar12ultra.

I tried to get some minute trend data today, but was unable to get it from inside or outside the control room using our matlab or python tools.

It seems the NDS2 interface will not work anywhere since it needs our minute trends to be written as frames; in the last version that Jamie left us, our minute trend frame files are not being written since they lead to periodic daqd crashes.

From inside the control room, we can get the minute trend (only with DataViewer). I've attached 30 days of BS_X just to show its real.

We can get the numerical data from the Grace plot window using the menu option Data->Export->ASCII.

You must select all of the 'Write Sets' to get all of the traces in the plot window. The resulting ascii file is not in a great format, but its not terrible.

I think the most important next two items to budget are the optical lever noise, and the coil driver noise. The coil driver noise is dominated at the moment by the DAC noise since we're operating with the dewhitening filters turned off.

Olympus SP570 UZ - without  IR blocker, set up as Atm.3  Camera distance to MC  face ~85 cm,  IOO-MC_TRANS_SUM 16,300 counts, Lexan cover on not coated viewport.

Image mode: RAW + JPG,  M-costum,  manual focus,  Lens: Olympus 4.6 - 92 mm, f2.8 - 4.5,  Apeture: F2.8 - 8,  Image pick up device: 1/2.33" CCD (primary color filter)

Atm.1,       212k.jpg of raw 15 MB,  exp 0.025s,   apeture 2.97,  f 4.6,   iso 64,  

Atm.2,        Copied through my Cannon S100  (  3.3 MB.jpg of raw from UFraw photo shop )I will look up the original raw file for details.

Summary:

I've been playing around with Evan's NB code trying to put together a noise budget for the data collected during the DRMI locks last week. Here is what I have so far.

Attachment #1: Sensing matrix measurement.

• This is basically to show that the MICH error signal is mostly in AS55Q.
• The whitening gain used was 0dB, and the demod phase was -82 degrees.
• The MICH sensing response was 5.31*10^8 V/m, where V is the demod board output. The 40m wiki RFPD page for AS55 says the RF transimpedance is ~550ohms, and I measured the Demod Board puts out 5.1V of IF signal (measured at after the Preamp, which is what goes to the ADC) for 1V of RF signal at the PD input. Using these numbers, and assuming a PD responsivity of 0.8 A/W at 1064nm, the sensing response is 2.37*10^5 W/m. I don't have a feeling yet for whether this is a reasonable number, but it would be a number to compare to what my Finesse model tells me to expect, for example.
• Actuator calibration used to arrive at these numbers was taken from this elog. 

Attachment #2: MICH OLTF measurement vs model

• In order to build the MICH OLTF model, I used MATLAB to put together the following transfer functions:
  • BS pendulum
  • Digital servo filters from LSC_MICH
  • Violin mode filters 
  • Analog/Digital AA and AI filters. For the digital AA/AI filters, I took the coefficients from /opt/rtcds/rtscore/release/src/fe/controller.c
• The loop measurement was taken with digital filter modules FM1, FM2, FM3, FM7, FM9 engaged. 
• In order to fit the model to the measurement, I tried finding the best-fit values for an overall loop gain and delay. 
• The agreement between model and measurement isn't stellar, but I decided to push ahead for a first attempt. This loop TF was used to convert various noises into displacement noise for plotting.

Attachment #3: Noise budget

• It took me a while to get Evan's code going, the main changes I made were to use nds2 to grab data instead of GWPy, and also to replace reading in .txt files with importing .mat files. This is a work in progress.
• Noises plotted:
  • Measured - I took the in loop error signal and estimated the free-running displacement noise with the model OLTF, and calibrated it into metres using the sensing response measurement. This looks consistent with what was measured back in Dec 2015.
  • Shot noise - I used the measured DC power incident on the PD, 13mW, RF transimpedance of 550 V/A, and the V/m calibration factor mentioned above, to calculate this (labelled "Quantum Noise").
  • Dark noise - measured with PSL shutter closed.
  • Seismic noise, thermal noise, gas noise - calculated with GWINC

I think I did the various conversions/calibrations/loop algebra correctly, but I may have overlooked something. Now that the framework for doing this is somewhat set up, I will try and put together analogous NBs for PRCL and SRCL. 

GV 22 August 2017: Attachment #4 is the summary of my demod board efficiency investigations, useful for converting sensing measurement numbers from cts/m to W/m.

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

Freshmen Rebecca Zhang as " work study undergrad "  received 40m specific basic safety training yesterday.

I made an Altium schematic for the microphone amplifier circuit for fabrication.

mic_schematicv2.pdf

I also have a functional one on my desk, which has one of the wires repaired.

- Is there any machine that can handle 4K? I have one 4K LCD for no use.
- I also can donate one 24" Dell

It seems we lost three monitors basically overnight.

The main (landscape, left) displays of Pianosa, Rossa and Allegra are all broken with the same failure mode:

their backlights failed. Gautam and I confirmed that there is still an image displayed on all three, just incredibly faint. While Allegra hasn't been used much, we can narrow down that Pianosa's and Rossa's monitors must have failed within 5 or 6 hours of each other, last night.

One could say ... they turned to the dark side

Quick edit; There was a functioning Dell 24" monitor next to the iMac that we used as a replacement for Pianosa's primary display. Once the new curved display is paired with Rossa we can use its old display for Donatella or Allegra.

One is broken, two are ready to steer green and 3 available in un known condition

[johannes, gautam]

I forgot we had done this last year already, but we updated the control room network switch labels and double checked all the connections. Here is the status of the connections and labels as of today:

There are a few minor changes w.r.t. labeling and port numbers compared to the Dec 2015 entry. But it looks like there was no IP clash between Rossa and anything (which was one of the motivations behind embarking on this cleanup). We confirmed by detatching the cable at the PC end of Rossa, and noticed the break in the ping signals. Plugging the cable back in returned the pings. Because Rossa is currently un-bootable, I couldn't check the MAC address.

We also confirmed all of this by using the web browser interface for the switch (IP = 192.168.113.249).

MC2 ccd camera is replaced by Olympus 570 zoom temporarly.

So as the ETMY ccd camera is replaced by Cannon Rebel.

Both viewport are under Lexan protection and covered by Aluminum foil....still, turn all lighting off if you do not want room light in the IFO

Do not remove Lexan shield!

For the traces I posted, I had not turned on the whitening for the SRCL sensing PD (REFL55). However, I took a spectrum on a subsequent lock, with the analog whitening + digital dewhitening turned on for all 3 PDs (AS55, REFL11 and REFL55), and the HF part of the SRCL spectrum still looked anomalous. I'm putting together the detailed NB, but here's a comparison between the signals from the 3 RFPDs with the PSL shutter closed (but whitening engaged, and with the analog gains at the same values as used during the locking).

To convert the y-axis into m/rtHz, I used data from a sensing matrix measurement I took yesterday night during a DRMI lock - I turned on lines between 300 Hz and 325 Hz for the 3DOFs for ~5 minutes, downloaded the RFPD error signal data and did the demodulation. I used numbers from this elog to convert the actuator drive from cts to m. The final numbers I used were:

MICH (AS55_Q):   8.706 * 10^11 cts/m

PRCL (REFL11_I): 2.757 * 10^12 cts/m

SRCL (REFL55_I): 1.995 * 10^10 cts/m

So it looks like there may be something weird going on with the REFL55 signal chain. Looking at the LSC rack (and also suggested by an elog search), it looks like the demodulation is done by a demod board labelled "POP55" - moreover, the demodulated outputs are taken not from the regular output ports on this board, but from the "MON" ports on the front panel. 

We ought to put the camera software on the shared disk; I don't think there's any speed reasons that it needs to be local.

Its OK to use optimus as the camera server for testing at the moment, but once we have things running, we'll install a few more cameras. With ~4-5 GigE running, we may not want to share with optimus, since we're also using it for comsol and skymap calculations.

You'll likely have to run camera_server.py using the same ini file first before you can use the client. Since the pylon installation is not on the shared drive but only local to optimus at the moment you would have to do it from there. You'll need to add /opt/pylon5/lib64/ to LD_LIBRARY_PATH or it won't find some required libraries. I couldn't start up the server all the way, probably because we need to define some slow EPICS channels before running the server script, as Joe points out in his document T1300202. You'll find instructions how to do that for example in this elog.

I took a closer look at the POP QPD/ PRC angular feedforward situation yesterday. I thought it would be useful to have a POP QPD MEDM screen. Looking at the PIT and YAW channel filter modules, the anti-whitening filters seemed different from what we have for other channels that are connected to the Pentek interface board (e.g. MCL). So I copied over the 150:15 (z:p) filter, and also turned on a 60Hz comb. The LSC offsets script does not set the dark offsets for this QPD, so I manually put in the dark offsets for the PIT, YAW and SUM channels as well. For the locking, I first locked the arms on IR an dither aligned them. Then I locked the PRMI on carrier, ran the PRC dither alignment, and went over to the ITMX pickoff table and centered the beam on the QPD by making the PIT and YAW channel timeseries oscillate around approximately zero. 

After these tweaks, I collected ~40mins of data with the angular FF OFF/ON. I did not DC couple the ITM Oplev servos, but Eric tells me that this did not make a difference to the achievable subtraction in the past. Here is the frequency domain multicoherence analysis - I used the BS_X and BS_Y seismometer channels as witnesses. I've also put a plot with what the raw FF filter coefficients look like (no fitting yet). 

Looks like we can do better for both DOFs - it even seems like we are injecting noise with the current FF filters in some bands, perhaps we can do a better job of rolling off the filters outside the band of interest. Eric and I were discussing MATLAB's "reduce" routine for this purpose, I will play around with it and see if I get a better fit.

Unfortunately, I encountered a strange error when trying to pull data with nds2 today, it kept complaining RuntimeError: Too many channels or too much data requested. even though I have pulled longer stretches of data for more channels with 16k sampling rate as recently as last week. Shorter duration requests (<600 seconds) seemed to work fine though... So I had to use cds.getdata to pull the data, and they're much too large to attach. Has anyone else encountered a similar error?

The mystery of the spots on the ITMs when the PRC is locked on carrier remains - after talking this over with Koji, we figured that even with the carrier resonant, the spot will be much dimmer than the spots when the arms are locked, but what I see on the cameras is still a pretty beefy spot. The real cavity mode is actually visible where it should be (I marked the locations of the spots with arms well-aligned with a marker on the monitors), as given away by some twinkling that is visible only when the cavity is locked. But what ghost beam is so intense it looks almost as bright as when the arm is locked?

GV 10pm 28 April 2017: Turns out this is the spot from the single bounce off the ETM transmitting back through the ITM and hitting the suspension cage (hence the bright spot). Johannes and I confirmed by moving the ETM, the spot moved with it. I just never paid attention to this spot before.

Using /ligo/apps/linux-x86-64/camera/bin/camera_client.py -c  /opt/rtcds/caltech/c1/scripts/GigE/SnapPy/L1-CAM-MC1.ini, the Python script was able to run without error but didn't show any video feed from the camera in GStreamer. Problem might be in the configuration of the camera in the .ini file.
 

one of these signals does not look like the others: explanation?

I got a couple of ~30min long DRMI lock stretches today. The settings I used are essentially the same as what I had back in November. Though we have since made some changes to the IMC RF signal chain, I guess it is not unreasonable that the LSC Demod phases that worked then work now as well. 

In the lock stretches, I did the following:

• Took loop measurements for MICH, PRCL, SRCL
• Turned on the sensing oscillator lines for error signal calibration
• Tried turning on the analog whitening on AS55, REFL11 and REFL55. The latter two worked fine, but everytime I turned the REFL55 whitening on, I broke the lock. I'm also unable to acquire lock if I leave the whitening turned on all the time. The ADC overflow indicators also indicate frequent overflows when I turn the whitening on. Oddly, this seems to happen even if I turn the analog whitening gain to 0dB - the signals look well within the ADC range on dataviewer and DTT timeseries mode. Not sure what's going on here, I will investigate further tomorrow.
• We should have some stretches where we can look at the possibility of seismic feedforward for some DRMI length DOFs.

On the side, I'm also looking at whether the PRC angular feedforward filters, last trained in October 2016, remain valid. Even post midnight, I am unable to lock the DRMI without turning on the FF, and looking at the POP QPD PIT and YAW signal spectra with the FF on vs FF off, there is definitely some improvement in the 1-4Hz band (plot to follow), question is whether we can do better and hence improve the DRMI duty cycle/ make the lock acquisition easier. To this end, I centered the beam on the POP QPD after locking and dither aligning the PRC on carrier, and have taken some data to look at.

So, much data analysis to follow - the idea is to put together a DRMI noise budget with Evan's NB code. For now, here are the uncalibrated control signal spectra.

Yesterday I failed to take good pictures of ETMY  resonant arm of 1064 nm with Cannon Rebel T3i in RAW 22-27Mp & JPG dual- format. UFRaw file converter worked well. The IR blocker filter seems to be too good.

Today I used Olympus SP-570UZ ( without IR blocker), in raw format of 15Mp, fl 22.4mm, 15s including 2-3s flashlight,  f/8 and auto focus  This is just too much scattered IR for the Olympus.

Overexposed raw picture' jpg is shown  at the PSL with diffraction patter of the camera.

I'll go back using  the Nikon D40 with zoom 55-200mm as this Atm2 of May 2007 : manual focus, 15s, f/4-5.6, ISO 560,  826KB

Since we'd like to get back to DRSE locking, I tried locking the DRMI tonight. I did the following:

• First, I aligned the arms, and ran the dither alignment scripts to maximize the arm transmission
• Next, I misaligned the ETMs, and tried to lock the PRC resonant for the carrier (i.e. PRCL on REFL11I, MICH on AS55Q). I got brief lock stretches of a few seconds but not longer. Turns out the AS55 beam was barely hitting the photodiode. I guess this wasn't looked at since Johannes modified the AS path for the loss measurements. Anyways, it just required a minor tweak to center the beam on the AS55 photodiode.
• Once the PRC was locked, I ran the PRC and MICH dither align scripts. The way these are set up right now, the error signals to these servos are REFLDC and ASDC respectively (demodulated at the respective dither frequencies). But looking at the spots on the ITM cameras with the PRC resonant, the spots seem shifted (in both PIT and YAW) relative to the spots when the arm cavity is resonant. Shouldn't they be the same mode? Or maybe I am missing something.
     
• Next, I tried to lock the DRMI with the 1f error signals: i.e. PRCL on REFL11 I, SRCL on REFL55 I, and MICH on AS55 Q. After some demod phase tweaking, I was able to get some locks going. Turning on the PRC angular feedforward seemed to help the locking, but I have no idea if the installed filters are still the correct ones. I believe the POP QPD channels are the witnesses used to train this filter, I will look at the predicted vs achieved subtraction.
• At this point, I was able to get locks lasting a few minutes - see the attachment. I ran the UGF servos and tweaked the loop gains a little, but before I could start a loop measurement, I lost the lock. I am calling it for the night.

GV 26 April 2017, 3pm: Forgot to note yesterday that I re-connected the suspect Satellite box, which has been connected to the SRM signal chain, back to the SRM suspension. I did not see any instances of glitching during my work last night. Also added pictures showing shifted spots on ITMs when PRC is locked relative to when arms are locked...

Dataviewer wouldn't launch on pianosa - it seemed to work fine on Donatella though. Rana suggested using the ipcs -q command. The complete fix can be found in this elog. This did the trick, dataviewer runs fine on Pianosa now...

1064 nm Semiconductor Laser Fiber Distribution System and Mirror Tomography

Below threshold these Semiconductor Fabry-Perot lasers have an axial mode structure with a spacing of about a THz. As you turn up the current to above threshold the first mode to oscillate saturates the gain down on all the modes and only it oscillates.  The laser I have here in my office (a backup for the one you have at the 40 meter) has a wavelength of 1064.9 nm at 70 Degrees C.  We should be able to temperature tune it down to 1064.3 nm although this could be a bit tedious the first time we do it. The specifications claim a "spectrum width" of 1.097 nm which I believe is the temperature tuning range.  I don’t know what the line width is but it will be single frequency and we shouldn’t have mode hoping problems.  So we should be able to use it in the “Mirror Tomography” experiment.  You might want to use some sort of polarization diversity to avoid the problems of fiber polarization drift.

There have been 2 student projects on using the fiber distributed PD frequency response at1064 nm laser.

“Automated Photodiode Frequency Response Measurement System,” Alexander Cole - T1300618

“Final Report: Automated Photodiode Frequency Response Measurement System for Caltech 40m lab,” Nichin Sreekantaswamy - P140021

I’ll look up a few more references and add include them in the next elog.

Eric

I looked through the lab area to do a fast photodiode inventory check, as we may need to buy some for the higher order mode spectroscopy SURF project. I looked on the following optical tables: ETMY, ITMY, BS, AS, PSL, SP, ITMX, Jenne laser table, and ETMX, as well as the photodiode cabinet, and could only find two 1611s. Here is a summary of the inventory: 

• Power supply 0901: 2x in photodiode cabinet (E6 along the Y arm), 1x on Jenne laser table
• Newfocus 1611 S/N 7284-WX, labelled "REF DET" on ITMY optical table, currently unused
• Newfocus 1611 S/N 57109 on Jenne laser table

I have not yet checked if these photodiodes are in working order.

I used a one hour stretch of data from last night to look at coherence between the PMC control signal and MCL, to see if the former can be used as a witness channel in some frequency band for MCL stabilization. Here is a plot of the predicted subtraction and coherence, made using EricQs pynoisesub code. I had thought about adopting the greedy channel ranking algorithm that Eric has been developing for noise subtraction in site data, but since I am just considering 3 witness channels, I figured this straight up comparison between different sets of witness channels was adequate. Looks like we get some additional coherence with MCL by adding the PMC control signal to the list of witness channels, there is about a factor of a few improvement in in the 1-2Hz band...  

What's the reasoning behind setting the the gain to this new value? i.e. why do these 'margins' determine what the gain should be?

Here are the details:

1. PMC OLTF:
   • the procedure used was identical to what Koji describes in this entry.
   • I used the SR785 to take the measurement.
   • MEDM gain slider was at +20dB 
   • I used the two single pin LEMO front panel monitor points to make the measurement. 
   • Mix_out_mon was CH2A, HV_out_mon was CH1A on the SR785
   • A = CH2A/CH1A with the SR785 excitation applied to the EXT_DC single pin LEMO input on the front panel. I used an excitation amplitude of 15mV
   • B = CH2A/CH1A without any excitation
   • Couple of lines of loop algebra tells us that the OLTF is given by the ratio A/B. The plot below lines up fairly well with what Koji measured here, UGF is ~3.3kHz with a phase margin of ~60degrees, and comparable gain margin at ~28kHz. As noted by Koji, the feature at ~8kHz prevents further increase of the servo gain. I've updated the nominal gain on the PMC MEDM screen accordingly... I couldn't figure out how to easily extract Koji's modelled OLTF so I didn't overlay that here... Overlaid is the model OLTF. No great care was taken in analyzing the goodness of the agreement with the model and measurement by looking at residuals etc, except that the feature that was previously at 28.8kHz now seems to have migrated to about 33.5 kHz. I'm not sure what to make of that. 
     
2. PMC DAQ calibration:
   • The calibration was done using the swept cavity, the procedure is basically the same as described by Koji in this elog.
   • The procedure was slightly complicated by the fact that I added gain to the AD620 buffers that provide the DAQ signals. So simply sweeping the cavity saturates the AD620 very quickly.
   • To workaround this, I first hooked up the un-amplified single pin LEMO front panel monitor points to the DAQ channels using some of the available BNC-LEMO patch cables.
   • I then did the swept cavity measurement, and recorded the error and control signals fron the single pin LEMO front panel monitor points. Sweep signal was applied to EXT_DC input on front panel.
   • In the nominal DAQ setup however, we have the amplification on the AD620. I measured this amplification factor by hooking up the single pin LEMO monitor point, along with its corresponding AD620 amplified counterpart, to an SR785 and measuring the transfer function. For the PMC_ERR channel, the AD620 gain is ~53.7dB (i.e. approx 484x). For the PMC_CTRL channel, the AD620 gain is ~33.6dB (i.e. approx 48x). These numbers match up well with what I would expect given the resistors I installed on the PMC board between pins 1 and 8 of the AD620. These gains are digitally undone in the corresponding filter modules, FM1.
   • To calibrate the time axis into frequency, I located the zero crossings of the sidebands and equated the interval to 2 x fmod. For the PMC servo, fmod = 35.5MHz. I used ~1Hz triangle wave, 2Vpp to do the sweep. The resulting slope was 1.7026 GHz/s.
   • The linear part of the PDH error signal for the carrier resonance was fitted with a line. It had a slope of 1.5*10^6 cts/s.
   • The round trip length of the PMC cavity was assumed to be 0.4095m as per Koji's previous entry. This allows us to calibrate the swept cavity motion from Hz to m. The number is 1.4534 * 10^-15 m/Hz. I guess we could confirm this by sweeping the cavity with the DC bias slider through the full range of 0-250V, but we only have a slow readback of the PMC reflection (and no readback of the PMC transmission).
   • Putting the last three numbers together, I get the PMC_ERR signal calibration as 1.6496 pm/ct. This is the number in the "cts2m" filter module (FM10).
   • An analogous procedure was done to calibrate the control signal slope: from the sweep, I got 4617 cts/s, which corresponds to 2.7117*10^-6 cts/Hz. Using the FSR to convert into cts/m, I get for PMC_CTRL, 535.96 pm/ct. This is the number in the "cts2m" filter module (FM10).
   • For convenience, I also added "cts2Hz" calibration filters in FM9 in the corresponding filter modules. 

The updated schematic with changes made, along with some pictures, have been uploaded to the DCC page...

Quick entry, details to follow in the AM tomorrow.

• I calibrated the PMC DAQ channels into physical units - there now exists in the filter modules  cts2m and cts2Hz filter modules, though of course only one must be used at a time
• Finally measured the PMC OLTF, after moving the PMC PDH error signal demodulation off the servo board - I used the same procedure as Koji when he made the modifications to the PMC servo board, I will put up the algebra here tomorrow. Turns out the previously nominal servo gain of +10dB on the MEDM sliders was a little low, the new nominal gain is +20dB, and has been updated on the MEDM screen.

ToDo:

• Put up the modified schematic on the 40m DCC tree Done April 18 10pm
• Check calibration by comparing inferred PMC cavity displacement from error point and control point spectra, using the measured OLTF
• Finish up looking at multicoherence with MCL and various witness channel combinations

we installed a new curved 34" doublewide monitor on Rossa, but it seems like it has a defective dead pixel region in it. Unless it heals itself by morning, we should return it to Amazon. Please don't throw out he packing materials.

Steve 8am next morning: it is still bad The monitor is cracked. It got kicked while traveling. It's box is damaged the same place.

Shipped back 4-17-2017

Our minute trends are still not available through NDS2 from the outside world due to the bad config of the DAQ, but I can confirm that we still have the minute-raw capability. This is 111 days of Seismic BLRMS.

However, it seems we're only able to get ~1 week of lookback on our second trends and that is low-down dirty shame. We used to have over a month of second trend lookback before the last decade of 'upgrades'.

Why ITMY UL can not see this earth quake? SRM and PRM are misaligned. ETMX is still not well.

We have to remember to check OSEM - magnet alignment when vented.

Here is a more detailed comparison of the spectra of the signals at the front panel DAQ LEMO output, measured with the Agilent analyzer. I've left the scale linear, it looks like when the demodulation is done on the servo board, the 1x, 3x and 5x harmonics of the 35.5MHz modulation are clearly visible. I also plut in a plot of the spectra when both the PD and LO inputs to the servo board are terminated (and so the PMC is unlocked), but with the HV In and OUT of the servo board still connected. In this case, the higher harmonics vanish, but a 35.5MHz peak of ~-50dBm remains. Since this is present with no input to the servo board, this must be direct pickup from the nearby LO board? 

In any case, it looks like many of the harmonics that are present with the nominal demod setup either vanish or are much more suppressed when the error signal demodulation is done off the servo board .

Further down the signal chain, I had noticed sometime last week that the ADC signals for the PMC DAQ channels I set up seemed to saturate around 4000 counts. Rana mentioned that the ADC interface box with LEMO connectors on the front is powered with +/-5V. Valera and co. had simply increased the suppy voltage sometime ago to get around this problem, so I did something similar, and increased the supply voltage to +/- 15V. I then confirmed that the ADC doesn't get saturated by driving the input with a +/-5V signal. So now the amplified AD620 signals from the PMC servo board are better matched to the ADC range. 

Here is an uncalibrated spectrum (taken with IMC locked), compared to the current ADC noise and signal levels before the AD620s were given gain.

I now need to think a little about what exactly the control scheme would be if the PMC is used as a reference for the IMC over some frequency range...

As discussed at the Wednesday meeting last week, I tried moving the demodulation of the PMC error signal off the PMC servo board, by using some minicircuits components. This is just a quick summary elog, more details to follow tomorrow.

• I used the Mini Circuits ZAD-6+. This is a level 7 mixer, and the LO board puts out ~16dBm, so I replaced the existing 3dB attenuator between the LO board and the input to the PMC servo board with a 9dB attenuator.
• On the RF side, I retained the 35.5 MHz bandpass filter on the PD input.
• On the IF output, I used an in-line 50ohm terminator in series with a minicircuits BLP1.9+ low pass filter
• The mixer output was routed to the FP1 test input of the servo board
• After some twiddling with the demod phase MEDM screen, I was able to lock the PMC. I've not done a thorough characterization of the loop with the current configuration, this will be done tomorrow. But the PMC and IMC have been stably locked for the last couple of hours...

During the course of this work, I noticed that there was a 35.5MHz line (at ~-55dBm) in the 4-pin LEMO DAQ outputs even when all other inputs to the servo board were terminated. So it seems like this pickup is not coming from the RFPD or demod path. The LO board has a shield enclosure similar to what we have on the LSC demod boards, but perhaps this shield does not enclose the full RF path, and there is some residual pickup between the two cards in close proximity in the Eurocrate?

On the bright side, with this demod setup, the higher harmonic peaks seem to be significantly suppressed.

In particular, the 3x35.5 MHz peak which was very prominent when I looked at these spectra with the nominal demod setup, seems to be much suppressed. 

I'm leaving the PMC servo in this configuration (off servo board demodulation using minicircuits parts) overnight.

It looks like we may not need to use this old Pylon version after all. Gautam and I looked into installing SnapPy with the makefile in scripts/GigE/SnapPy/ that he modified (removed the linkage to paths that don't exist in Pylon 5). Compiling took a while (~10 minutes) but eventually succeeded. The package was installed to /ligo/apps/linux-x86_64/camera/

GV 10pm April 10 2017: We didn't actually try executing an image capture or change some settings using the python utilities, that remains to be done..

When trying to install an older version of Pylon packaged for Debian that Joe B. had sent, it gave the warning that the package was of bad quality along with the details below.

Is it safe to ignore the warning? Or should I hold off on the installation?

Lintian check results for /home/controls/Downloads/pylon-2.3.3-1.deb:
Use of uninitialized value $ENV{"HOME"} in concatenation (.) or string at /usr/bin/lintian line 108.
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.IpConfigurator
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.PylonViewerApp
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.SpeedOMeter
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3.2
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3.7.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/plugins/imageformats/libqtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libXMLLoader_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApiPreProcessor
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGCBase_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGenApi_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libLog_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libMathParser_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/liblog4cpp_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige.so

Koji and I have been going over these calculations again before we send a list of revised requirements to Ramin. I've uploaded v3 of the specs to the DCC page. Here is a summary of important changes.

1. Change in RoC specification - I condensed the mode-matching information previously in 8 plots into the following 2 plots. Between tangential and saggital planes, the harmonic mean was taken. Between X and Y cavities, the arithmetic mean was taken. Considering the information in the following plots, we decided to change the spec RoC from 600 +/- 50m to 1000 +/- 150m. The required sensitivity in sag measurement is similar to the previous case, so I think this should be feasible.
   
   Why this change? From the phase map information at  /users/public_html/40m_phasemap/40m_TT, I gather that we have 2 G&H mirrors, one with curvature ~ -700m and the other with curvature ~ -500m. An elog search suggests that the installed PR2 has RoC ~ -700m, so this choice of RoC for PR3 should give us the best chance of achieving optimal modematching between the RCs and arms as per the plots below.
   
   
2. Cavity stability checks - these plots confirm that the cavity remains stable for this choice of RoC on PR3...
     
3. Coating design - I've been playing around with the code and my understanding of the situation is as follows. to really hit low AR of 10s of ppms, we need many dielectric layer pairs. But by adding more pairs, we essentially become more susceptible to errors in layer thickness etc, so that even though the code may tell us we can achieve R_AR(532nm) < 50ppm, the minima is pretty sharp so even small perturbations can lead to much higher R of the order of a few percent. On the HR side, we need a large number of layer pairs to achieve T_HR(1064nm)=50ppm. Anyways, the MC studies suggest that for the HR coating design, with 19 layer pairs, we can be fairly certain of T_HR(1064nm)<100ppm and R_HR(532nm)>97% for both polarizations, which seems reasonable. In order to make the R_HR(532nm) less susceptible to errors, we need to reduce the number of layer pairs, but then it becomes difficult to achieve the 50ppm T_HR(1064nm) requirement. Now, I tried using very few layer pairs on the AR side - the best result seems to be with 3 layer pairs, for which we get R_AR(532nm)<1% and T_AR(1064nm)>95%, both numbers seem reasonable to me. In the spectral reflectivity, we also see that the minima are much broader than with large number of layer pairs.
   
   First row below is for the HR side, second row is for the AR side. For the MC studies, I perturbed the layer thicknesses and refractive indices by 1%, and the angle of incidence by 5%.
       
      

If there are no objections, I would like to send this version of the specs to Ramin and get his feedback. Specifically, I have assumed values for the refractive indices of SiO₂ and Ta₂O₅ from google, Garilynn tells me that we should get these values from Ramin. Then we can run the code again if necessary, but these MC studies already suggest this coating design is robust to small changes in assumed values of the parameters...

AIC Wiki updated to latest stable version of DokuWiki: 2017-02-19b "Frusterick Manners" + CAPTCHA + Upgrade + Gallery PlugIns

I'm suspicious of this temperature sensor comparison. Usually, what they mean by accuracy is not the same as what we mean. I would not buy these yet. How about we just use what Caryn used several years ago (elog search) ?

  PS  Steve LM34             

    Jan. 26,  2017              RIN test stared with P947034, made Apr. 2016  

    Apr.  10,  2017              purchased two 1103P from Edmund:  sr P964438 & sr P964431, made 02/2017

We are planning to test 3 identical 1103Ps RIN with  continous temp monitoring and control later.

Selected  temp sensor   Platinum RTD 1PT100KN1515CLA   or           RTD-830 

Temp controller  with analoge output 0-10Vdc, CNi854  and external dc pulse driven  relay

Order placed 4-12-17 for sensor  RTD-830,  controller CNi8-5-4 and relay  SSRL240DC25 = ~$500.

Still need: fuse, fuse housing, on/off switch, female  AC receptical, chassy box and AC power cord.

ETMX enclosure feedtrouh cabeling corrected.