The 40m team worked on the power outage preparation. The detailed is summarized on this wiki page. We will still be able to access the wiki page during the power outage as it is hosted some where in Downs.

https://wiki-40m.ligo.caltech.edu/Complete_power_shutdown_2022_07

Yehonathan, please center the EX seismometer.

The attached PDF shows the seismometer signals (I'm assuming that they're already calibrated into microns/s) during the lab tour for the art students on 11/1. The big spike which I've zoomed in on shows the time when we were in the control room and we all jumped up at the same time. There were approximately 15 students each with a mass of ~50-70 kg. I estimate that out landing times were all sync'd to within ~0.1 s.

I have re-centered the EX (and EY) seismometers. They are Guralp CMG40-T, and have no special centering procedure except cycling the power a few times. I turned off the power on their interface box, then waited 10s before turning it back on.

The fist atm shows the comparison using data from 8-9 PM Saturday night:

1. there seems to be a factor of 2 calibration diff between the T240 near the BS, and the Guralp seismometers at the end. Which one is right? When was the last time they were cross calibrated?
2. The low coherence between BS_X and EX_X shows the problem. They should be very coherent (> 0.9) for 0.1-1 Hz.

I check the seismometers in the last 14 hours (Attached). Seems like the coherenece is restored in the x direction.

Koji was right, and I was using much too large of a CARM offset.  Tonight, I set either my CARM or DARM offset to 3 counts, and was able to easily acquire PRMI lock using REFL33. 

For either CARM or DARM offset reduction (the other one was kept at zero offset), I was able to get to about 0.5 counts, but I lose lock when I try to go to 0.4 or 0.3 counts.  One time, I tried "jumping over" the resonance, by going from minus 1 to plus 1 in CARM offset.  Plots of this below.

Locking notes

ALS locked with "Xarm" servo as proxy for DARM, and "Yarm" servo as proxy for DARM.  Pushing only on ETMs today, not the MC. 

MICH / PRCL:

Input matrix:  1's in REFL 33 I&Q, if not using power normalization.  200's in REFL 33 I&Q if power normalization used (either POPDC or POP22).  200 used because that's about the average value of POPDC or POP22 when PRMI sideband-only resonant.

Trigger:  POP22, up 100, down 10.

Power normalization:  1's for both MICH and PRCL in POP22I for one trial.  1's for both MICH and PRCL in POPDC for another trial.  Both seemed to work equally well, although that may change when I'm actually getting IR resonance in the cavity.

FM triggers:  MICH = FM2.  PRCL = FMs 2, 3, 6, 9.  Trigger up = 35, down 10.  PRCL delayed by 0.5 sec, MICH delayed by 5 seconds.

Servo gains:  MICH = 0.4, PRCL = -0.01

Observations:

When I approach the situation of both arms resonating, it pretty consistently looks like the PRM is getting pushed in pitch (and not in yaw).  I don't know why this could be, but it seems like this is the big symptom before lockloss - if the POP spot starts moving (and the PRM suspit signal starts moving), PRMI lock is going to be lost.

I don't know if it's imperfect alignment, imperfect mode matching, or something else, but I see lots of high-order higher order modes on both the POP and AS cameras when the CARM or DARM offset is less than 1 count.  I tried to take a video, but the brightness and contrast aren't set as high as on monitors 3 and 5, so it's hard to see the dim stuff.  Youtube.  At the midpoint of the video, you see a lockloss.

Even though I have overridden the transmission triggers so that I only use the QPDs for the transmission signals, I'm only seeing arm transmission values up to about 50 from each arm.  If we had ideal PRC gain, we expect something like 650 or 700. 

A few plots

All of the raw data for these plots, and several other channels, is in /users/jenne/PRFPMI/PRMI_2arms_8Apr2014/m1_to_p1_carmOffset_1081065069.  As mentioned above, "XARM" is CARM, and "YARM" is DARM.  So, the XARM_IN1 tells us about the CARM offset that I was applying.  The start time is 1081065069, and the plots are all 8 seconds long.

First, the transmitted power and the CARM offset.

The REFL_I error signals and the CARM offset.

The RF signals that we will eventually chose from for CARM and DARM control. Note that I'm not sure about the AS55 phase, so I plot both I and Q.

The PRM suspit and sus yaw angular signals and the CARM offset.  I don't see a huge change in the suspit signal, but it does seem to change character once we approach arm resonances.

The 40m's new undergrad Kevin Kuns was introduced to 40m safety hazards. He is new and needs guidance as specially with 2W laser work.

Peter King will train him on Friday to LIGO-laser standard.

Kevin Vigue, our high school summer student went through the 40m specific safety traning yesterday.

I wanted to try out the unstick.py script on c1aux but kept running into timeout errors. I was also confronted by a blank GigE screen. Further, couldn't telnet into c1aux using telnet c1aux as described here. Therefore, I went in and keyed the c1aux crate (1Y1).

[Ian, Anchal]

We are going to kick the optics tonight at 2am.

The optics we will kick are the PRM BS ITMX ITMY ETMX ETMY

We will kick each one once and record for 2000 seconds and the log files will be placed in users/ian/20211015_FreeSwingTest/logs.

[Ian, Anchal]

we ran the free swinging test last night and the results match up with in 1/10th of a Hz. We calculated the peak using the getPeakFreqs2 script to find the peaks and they are close to previous values from 2016.

In attachment 1 you will see the results of the test for each optic.

The peak values are as follows:

The results from 2016 can be found at: /cvs/cds/rtcdt/caltech/c1/scripts/SUS/PeakFit/parameters2.m

I have made a python script to generate the button designed by Jeff Kissel for his ISI screen.

It is currently located at the following location:
/cvs/cds/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator/generate_KisselButton.py
but should be relocated to somewhere appropriate.
It also uses fragmented medm files named "MATRIX*.adl_parts".

# Jamie, could you suggest the right place?

The parameters are assigned at the beggining of the script.
This script print the result to stdout. So you need to redirect the output into a file.
e.g.
> ./generate_KisselButton.py >tmp.adl


The script should be modified such that it accepts the command line options.
It needs more python learning for me.

# Number of the column
mat_h = 20;

# Number of the row
mat_v = 10;

# horizontal pixel size of the rectangular display for each matrix element
button_width = 8;

# vertical pixel size of the rectangular display for each matrix element
button_height = 8;

replace_dict = {
# Title
    '${DISPLAY_LABEL}':'ITMX_INMATRIX', 
# Path of the MEDM file to be open by clicking the button
    '${DISPLAY_NAME}':'/cvs/cds/rtcds/caltech/c1/medm/c1sus/master/C1SUS_ITMX_INMATRI
X_MASTER.adl',
# The channel name of the matrix element
# ($V and $H are replaced to the numbers i.e. "_3_4")
    '${MATRIX_CHAN}':'C1:SUS-ITMX_INMATRIX_$V_$H'
    };

Now the Kissel-button generator takes the command line arguments and options.
The script is fully documented by the usage message of the script itself.
It still needs the external supporting files "MATRIX*.adl_parts".

Now the LSC screen has these buttons for the input and output matrices.
The command lines to generate those buttons are listed at the end of this entry as the examples.

>pwd
/opt/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator


>./generate_KisselButton.py -h
usage:
generate_KisselButton.py [options]  end_row end_column matrix_ch_name

This generates an MEDM screen of a button with the style designed by
Jeff Kissel for his ISI screens. This button has a display of a matrix
elements. If the matrix element is non-zero it glows in green. Otherwise
its color is dark. Usually the button created by this script
is to be copy-pasted to other screens.

Three arguments have to be given:
  end_row         the number of the row at the end
  end_column      the number of the column at the end
  matrix_ch_name  the channel name of the matrix to be monitored
                  e.g. give C1:LSC-OUTPUT_MTRX for C1:LSC-OUTPUT_MTRX_1_1, ...

There are options prepared in order to control the parameters of the button.

example:
generate_KisselButton.py 6 6 C1:LSC-OUTPUT_MTRX
      6x6 matrix for C1:LSC-OUTPUT_MTRX


options:
  -h, --help          show this help message and exit
  --sr=START_ROW      specify the starting row number for the button array.
                      [default: 1]
  --sc=START_COLUMN   specify the starting column number for the button array.
                      [default: 1]
  --bw=BUTTON_WIDTH   specify the pixel width of the small button. [default:
                      8]
  --bh=BUTTON_HEIGHT  specify the pixel height of the small button. [default:
                      8]
  --dl=DISPLAY_LABEL  specify the button label. [default: channel name]
  --sn=SCREEN_NAME    specify the file name of the screen opened when one
                      click the button. The relative or absolute path can be
                      included. [default: a name guessed from the channel
                      name. e.g. C1LSC_OUTPUT_MTRX.adl for C1:LSC-OUTPUT_MTRX]


>./generate_KisselButton.py --bw=3 --bh=4 --dl="RFPD InMTRX" 16 8 C1:LSC-PD_DOF_MTRX > rfpd_mtrx.adl

>./generate_KisselButton.py --sc=21 --bw=6 --bh=4 --dl="DCPD InMTRX" 27 8 C1:LSC-PD_DOF_MTRX > dcpd_mtrx.adl

>./generate_KisselButton.py --bw=4 --bh=4 --dl="Trig MTRX" 11 8 C1:LSC-TRIG_MTRX > trig_mtrx.adl

>./generate_KisselButton.py --bw=4 --bh=4 --dl="Out MTRX" 9 10 C1:LSC-OUTPUT_MTRX > output_mtrx.adl

 I copied the Kissel button generator scripts folder into scripts:

/opt/rtcds/caltech/c1/scripts/KisselButtonGenerator/

Maybe this isn't the most intuitive place ever, since it's a script that only has to do with medm screens, but at least it's better than hidden in the depths of Koji's LSC medm path.....

Osamu and Kiwamu received 40m safety training on Thursday, Feb 19, 2009

Kiwamu had an old set of scripts for measuring the sensing matrices, but they were hidden away in ..../scripts/general/kiwamuscripts/pyplant . I have moved them to a more useful place, and updated them.

The useful scripts (the main one is SensResp.py, and the PRMI-specific one, runPRMI_SENS.py, which calls SensResp.py) have been moved to .../scripts/LSC .  I have also created a folder within the LSC scripts folder called SensMatData for the data.

The 2 big changes to Kiwamu's scripts:  The ezca library that he was calling wasn't working.  I switched it over to using the one that Yuta wrote, in ..../scripts/pylibs.  Also, Kiwamu's script was written back during a time where we must have only had one total lockin for the whole LSC model.  Now we have one per PD in the input matrix.  This meant that several of his channel names were wrong.  I have fixed this, and also made it measure all the sensors at once using tdsread of the _OUT16 channels (the OUT16's have some AA action, other EPICS channels don't).

So, now (after you're locked), it shakes one "mirror" (the ITMs are shaken differentially at the same time, as one "mirror"), and reads out all of the RF PD lockin values.  Then it moves to the next mirror.  (For the PRMI case, there are only 2 "mirrors":  The ITM set and the PRM.)  All of the information is stored in a dictionary, which is written to a text file. 

The format of the dictionary is:

{ OPTIC_1: [Photodiode_1, Lockin_I, Lockin_Q], [Photodiode_2, Lockin_I, Lockin_Q], OPTIC_2: [Photodiode_1, Lockin_I, Lockin_Q], [Photodiode_2, Lockin_I, Lockin_Q] }

At this point, I am too tired to actually do a measurement, although next time the PRMI is locked, we should just have to run the runPRMI_SENS.py, and look at the data.  I'm also not quite sure how to extract the information from a dictionary after it has been written to a text file.  This may not be a good way to store data, and I'll ask Jamie about it tomorrow.

OTHER NOTES:

* I need to set up another iteration of the sensing matrix measurement with no drive, measuring several times, to get an estimate of the error in a single measurement.

* I had the PRMI locked on AS55Q/REFL33I for more than half an hour.  Then the MC started unlocking semi-regularly.  Seismic was good except for one EQ ~2 hours ago.  After the earthquake (unlocked MC, but no tripped optics), the MC has remained locked.

* The LSC Lockin Overview screen does not click-through to the _SIG individual screens.  We need to fix the path to these screens.

* All of the _SIG filters are band passes around 285 Hz, but the names of the filters all say 238Hz.  I need to fix all 27 of these.

* We can perhaps change the LSCoffsets script someday to use tdsread a few times, and average the results (since the PDs don't have lowpass filters, and we're measuring the offset of the IN1 location, not the OUT).  This way we can hopefully measure all the PDs at once and speed up the script, without having failed tdsavg runs.

Koji locked the PRMI for me, and I took some data.  I haven't finished figuring out what to do with it / writing a processing script.

Here is the data, in a python dictionary (not for you to read, but so that it's here and you can use it later if you want).

{'AS55_Q': [['ErrorBarData0', '-1.60826e-05', '0.000154774'], ['ErrorBarData1', '-1.61949e-05', '-9.69142e-05'], ['ITMs', '-0.134432', '0.00240338'], ['PRM', '0.0525864', '0.145516']], 'REFL55_Q': [['ErrorBarData0', '-0.00088166', '-0.00294315'], ['ErrorBarData1', '0.00298076', '-0.000466507'], ['ITMs', '-0.573825', '-0.0865747'], ['PRM', '1.94537', '0.534968']], 'REFL33_Q': [['ErrorBarData0', '0.000868208', '0.000785702'], ['ErrorBarData1', '-0.00136268', '-0.000288528'], ['ITMs', '-0.0653009', '-0.0112035'], ['PRM', '0.875275', '0.419765']], 'REFL11_I': [['ErrorBarData0', '-0.147347', '0.136075'], ['ErrorBarData1', '0.351823', '0.160556'], ['ITMs', '-12.0739', '-80.1513'], ['PRM', '6991.11', '7073.74']], 'REFL33_I': [['ErrorBarData0', '-0.00100624', '0.00134366'], ['ErrorBarData1', '0.00373581', '0.000783243'], ['ITMs', '-0.399404', '-0.774793'], ['PRM', '67.4138', '68.8886']], 'REFL11_Q': [['ErrorBarData0', '-0.0173368', '0.0141987'], ['ErrorBarData1', '0.100048', '0.0882165'], ['ITMs', '6.46585', '-26.2841'], ['PRM', '1653.42', '1663.96']], 'AS55_I': [['ErrorBarData0', '-1.87626e-05', '2.24596e-05'], ['ErrorBarData1', '-5.46466e-05', '-2.96552e-07'], ['ITMs', '-0.00531763', '0.00130579'], ['PRM', '-0.100501', '-0.0706334']], 'REFL55_I': [['ErrorBarData0', '-0.000774208', '-5.32631e-05'], ['ErrorBarData1', '0.00347621', '0.0025103'], ['ITMs', '-0.115633', '-0.83847'], ['PRM', '72.8058', '74.2347']]}

The structure is that each sensor has some "error bar" measurements, when there was no drive to any optics (I, then Q of the lockin), and then response to different optics' drives (waiting 20sec after turning on the oscillator before making a measurement, since the lockin has 0.1Hz lowpasses.  ).

The amplitude that Kiwamu had of 4000 cts in the LSC lockin was fine for MICH, but made PRCL unlock, so this data was taken with an amplitude of 1000 counts, at a frequency 283.1030 Hz. 

Since this is only barely above the UGF for both MICH and PRCL loops, I also have OLTF information at 283Hz from DTT:  PRCL mag = -1.05264 dB, phase = 24.6933 deg, MICH mag = -8.50951 dB, phase = 31.3948 deg.

I have started writing a script SensMatAnalysis.py in the scripts/LSC directory to do the analysis, but after having talked to Koji, I need to do more thinking to make sure I know what I'm doing.  Stay tuned for actual analysis later.

So that I don't have to do loop compensation every time I measure a sensing matrix, I have put (back) in notches into FM10 of all the LSC filter banks, except MC2.  

MICH already had this notch, PRCL and CARM both had it, although it was mislabeled in the filter title as "Notch410" rather than the truth, which is "Notch628". 

The XARM and YARM filter banks were full, since we have not (in those filter banks) combined all of the resonant gains - 3.2Hz, 16Hz, 24Hz - into one module.  I took out a CLP3000 (  cheby1('LowPass",2,3,3000)gain(1.41254)  ) in each of those filter banks, and put in the notch.

I also have changed the band pass filters in the LSC-Lockin#_SIG filter banks to match this new drive frequency.

 To avoid exciting at the PRM violin mode frequency, I have changed all of the filters relevant to the sensing matrix measurement from 628Hz to 580.1Hz.  This includes notches in the LSC control loops, as well as the band pass filters in the lockins.  I have not yet loaded the new filters, since arm locking is in progress.

- Put the circuit diagram of the sum amp on/in the circuit enclosure and associate it with an elog [done].
- Update the circuit diagram of the pomona box [done]
ALL DONE

This is perhaps best put in the LLO elog, but I'm not yet a 'person' there, so I can't write to their elog (yet another thing for the eternal to-do list).  So for now, we're putting things here...

This isn't totally finalized, but I do want to get what I have posted before I hop on a plane in the morning.  Mostly it just needs more time to run, to make the plot longer.  Hopefully I'll be able to edit this in the morning and have a longer-duration plot. 

What's plotted:

This spectrogram shows the amplitude spectra of L1:LSC-DARM_CTRL, after being subtracted via a Static Wiener Filter.  Each spectra is normalized by the very first one, which was created from the same data that was used to determine the Wiener Filter.  The X-axis is time.  The Y-axis is frequency, and the Color/Z-axis is amplitude in dB.  I'm only looking at Science Mode time, so other times when the IFO isn't in science mode, I plot a black stripe to fill in the plot.  The start time of the plot is 83675598, which is Jul 08 2006 06:33:04 UTC. 

Why?

The idea is to see that the filter does equally well a long time after it was created, as when it was initially made.  This will help tell us how often it is useful to recompute the Wiener filters.  Less often is nice, because redoing the Wiener filters may also include remeasuring the high precision transfer functions...if the filter isn't working as well anymore it may be because the transfer function has changed ever so slightly. 

How the plot is created / the background story:

I use one hour of DARM_CTRL data and the following seismometer channels to create an optimal Wiener Filter (pem indicates L0:PEM- , sei indicates L1:SEI- , and lsc indicates L1:LSC- ) :

chans = {[pem 'EX_SEISX'],...
         [pem 'EX_SEISY'],...
         [pem 'EX_SEISZ'],...
         [pem 'EY_SEISX'],...
         [pem 'EY_SEISY'],...
         [pem 'EY_SEISZ'],...
         [pem 'LVEA_SEISX'],...
         [pem 'LVEA_SEISY'],...
         [pem 'LVEA_SEISZ'],...
         [sei 'LVEA_STS2_X'],...
         [sei 'LVEA_STS2_Y'],...
         [sei 'LVEA_STS2_Z'],...
         [sei 'ETMX_STS2_X'],...
         [sei 'ETMX_STS2_Y'],...
         [sei 'ETMX_STS2_Z'],...
         [sei 'ETMY_STS2_X'],...
         [sei 'ETMY_STS2_Y'],...
         [sei 'ETMY_STS2_Z'],...
         [lsc 'DARM_CTRL']};

I then apply this one filter to ten minute chunks of science mode data, for some long period of time.  The game plan is to have a month long plot, but it takes a while to fetch all of the data in separate 10min intervals (~45sec per iteration, times ~3000 iterations), so this plot isn't a full month.  Even if I don't get a chance to plot a full month by Thursday morning, it'll go up here within the next few days. The particular times chosen have the most science mode data within a 30 day period.  I can easily run the code for some other time, if there is a known time (or season) which might be more interesting.  For the spectrogram plot, I then normalize each amplitude spectra by the first one, which comes from the first ten minutes in the hour which was used to make the filter.  This makes it easier to see how the filter's efficacy changes over time.

The analogous analysis for Hanford is in the 40m elog: 1606.  The Hanford stuff in the elog has some cool BLRMS plots also, but I'm not sure that they're so helpful when I only have a few days of L1 data so far.  I'll do those and add them later.

Conclusions:

I can't really say anything yet about the long-term efficacy of a Wiener Filter for LLO yet, since my code hasn't finished filtering my one month of S5 L1 data.  It definitely looks like (so far) that there was a big seismic event around the (arbitrarily defined) 'Day 4'. 

This surface plot is the same as the previous one, with a little more data than I had previously. 

This time around, I also include the "BLRMS" plots for this data.  The first one takes each residual and normalizes it by the DARM_CTRL signal at that time, separates the spectra into bands, and integrates underneath the spectra within that band.  The second one is the raw DARM_CTRL signal's spectra at each time, and integrates under the spectra for each band, and the third BLRMS plot does the same thing for the residuals.  Unfortunately, these plots don't have the same handy black stripe during time which I don't analyze that the spectrogram utilizes.

From the second BLRMS plot we can see that the large red splotch in the spectrogram is due to higher noise in the DARM spectrum, and that (by looking at the Ratio BLRMS plot) the Wiener filter still does a pretty good job during this time.  I expect that for later times when the seismic (or something) event is gone, the Wiener filter will continue performing almost as well as it had been initially.

Again, once the script finishes applying the filter to the many ten minute chunks (the huge time drain is the data fetching, so this shouldn't be a limiting factor for using Wiener filters online), I'll post a final plot.

 [Nichin, Eric Q]

We added a new LAN wire from Rack 1Y4 to 1Y1 to connect the RF switch at 1Y1 to the martian network. The wire is labelled "To RF Switch (1Y1)"

The wire was run along the Y arm in the tray right next to the vaccum chamber, not the one on top.

Shruti picked it up @4pm.

Electrical came by today to see the lights. The issue may be the switches, but they will come by tomorrow to solve the issue. A couple light bulbs were noticed to be out, but they no longer have incandescent lights. . . only LED. I figured this would be preffered because of the reduction on noise. I would prefer to go ahead and ask to change all the incandescent bulbs to LED bulbs. Are there any objections to this?

All incondescent lightsbulbs have been switched over to LED.

Cold LED lights replaced hot halogen ones. Flat LED MYAL 6S,  model #112560002  24VAC

This is a LATE ENTRY.  They were purchased  in Jan 2010 and installed 6 of them around May 2010

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

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=24321

This LHO log indicates that EPICS slow down could be due to NFS activity. Could we make some trend of NFS activity on Chiara and then see if it correlates with EPICS flatlines?

I wonder if our EPICS issues frequency is correlated to the Chiara install.

I did a yum-install of the latest ldg-client (to get onto the LIGO Clusters) on Rossa. 

I followed the instructions on the wiki page, and everything seemed to work nicely.

I think the new ldg client installs somewhere on the local computer, so if anyone wants cluster access on any other computer, they should follow the same directions.

David Nolting, chief LIGO Safety Officer and his lieutenants from LLO and LHO paid homage to the 40m lab this morning.

They give us a few recommendation: update safety documents, move optical table from the front of ETMX-rack and label-identify absorbent plastics on enclosure windows-doors.

We'll correct these short comings ASAP

I installed ligoDV in the /ligo/apps/ligoDV/

Now, by pointing the tool at the local NDS2 server (megatron:31200) you can access the recent local data (raw, trends, etc.)

by running /ligo/apps/ligoDV/ligodv from the command line.

40m crew and visitor Holger Muller from Berkeley.

Thanks to a discussion yesterday with Joe Betzweiser, I was able to identify and fix the remaining problem with the LLO GigE camera software. It is working now, currently only on rossa, but can be set up on all the machines. I've started a wiki page with documentation and usage instructions here:

https://wiki-40m.ligo.caltech.edu/Electronics/GigE_Cameras

This page is also linked from the main 40m wiki page under "Electronics."

This software has the ability to both stream live camera feeds and to record feeds as .avi files. It is described more on the wiki page.

To make this setup more permanent, I modified the c1lsc model to pipe the LO power monitor signals from the Demod chassis to unused channels ADC_0_25 (X channel LO) and ADC_0_26 (Y channel LO) in the c1lsc model. I also added a couple of CDS filter blocks inside the "ALS" namespace block in c1lsc so as to allow for calibration from counts to dBm. I didn't add any DQ channels for now as I think the slow EPICS records will be sufficient for diagnostics. It is kind of overkill to use the fast channels for DC voltage monitoring, but until we have acromag channels readily accessible at 1Y2, this will do.

Modified model compiled and installed successfully, though I have yet to restart it given that I'll likely have to do a major reboot of all vertex FEs

[Paco, Yehonathan, Yuta]

We measured power and counts at BHD DCPDs with LO beam only and ITM single bounce.
We found that LO beam power is ~7 times less than the expected.
We also confirmed that AS beam is clipped somewhere inside vacuum and have 20-50% less power compared with the expected.
LO/AS beams going to DCPD A and B also have power imbalance by 30-40%.

What we did:
 - Run LSCoffsets.py to zero the offsets. I modified the old script so that it can handle new BHD PDs. Also, a bug was fixed (it didn't take into account the gains in filer modules, so INMON is now used instead of OUT16 for calculating offsets).
https://git.ligo.org/40m/scripts/-/blob/main/RFPD/LSCoffsets.py
 - Measured powers and counts in BHD DCPDs at ITMY table with LO beam only and ITMX/ITMY single bounce.
 - During the measurement, we found that power into DCPD A and DCPD B are quite different. One of the reason was a lens and an iris right after the viewport for A path. We removed both of them. Also, only A path have a pickoff which picks off ~20% of light to BHD camera (called SRMF; 40m/16880).
 - We also found that LO beam shape is ugly. ITM single bounce beam from X and Y have similar clipping (see Attached photos). We tried to reduce clipping with various suspensions (LO1, LO2, AS1, AS4, SR2, SRM, BS, ITMX, PR2), but was not possible by moving only single suspension.

Result:
 - Result of counts and power measurements are as follows. Power was measured right in front of DCPD, and also right after the viewport to estimate the loss in the in-air paths. Note that LSC channels have gain of 1, but HPC channels have gain of -1.9 for DCPD_A and -1 for DCPD_B.

                       Blocked  LO       ITMX      ITMY    
C1:LSC-DCPD_A_OUT16    -0.01    -17.89    -91.62    -86.21    
C1:LSC-DCPD_B_OUT16    +0.06    -17.72   -131.83   -131.98    
C1:HPC-DCPD_A_OUT16    +0.07    +34.12   +174.63   +164.24    
C1:HPC-DCPD_B_OUT16    +0.13    +17.60   +131.31   +131.49    
Power at DCPD_A        19 uW    63 uW    278 uW    290 uW    
Power at DCPD_B        19 uW    65 uW    393 uW    404 uW    
Power at viewport A    -- uW    82 uW    350 uW    337 uW    
Power at viewport B    -- uW    64 uW    436 uW    431 uW

DCPD calibration:
 - From the measurements above, counts/W in IN1 can be calculated as follows. Offset of 19 uW is substracted from the measured power to take into account for background light.

C1:LSC-DCPD_A_IN1     -3.59e+05 counts/W
C1:LSC-DCPD_B_IN1     -3.61e+05 counts/W
C1:HPC-DCPD_A_IN1     -3.60e+05 counts/W
C1:HPC-DCPD_B_IN1     -3.57e+05 counts/W

Discussion:
 - DCPD calibration shows that DCPD to ADC itself is quite balanced within 1%. A factor of 1.8-1.9 seen was from unbalanced light between A path and B path (40m/17037).
 - Power expected for ITM single bounce to one of DCPDs is ~520 uW, but was 350-430 uW as measured right after the viewport. Power at A is significantly less than that for B. Note that power at AS55 was as expected (40m/16952). Also, clipping cannot be reduced by moving suspensions. These could mean that clipping is happening after AS2.

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 97.8%(PR2) * 50%(BS) * 98.6%(ITM) * 50%(BS) * 10%(SRM) * 90%(AS2) * 50%(BHDBS) = 520 uW

 - Power expected for LO beam to one of DCPDs is ~530 uW, but was 60-80 uW as measured right after the viewport. Power at A is significantly more than that for B, which is opposite for ITM single bounce. This could mean that something is happening at BHDBS? We are not sure why the power is so low. Are we seeing some ghost beam? For PR2 transmission, 22000 ppm was used for calculation, from 40m/16541.

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 2.2%(PR2) * 50%(BHDBS) = 530 uW

 - As far as we remember, beam shapes were not as bad when we closed out the chambers...

Next:
 - Check if measured power explains the visitivity of LO-ITM single bounce (40m/17020)
 - If not, what is the mode mismatch? Is it possible to explain the mode mismatch with deviations from designed mode-matching telescope?
 - Measure POP power to see if PR2 actually have T=2.2%
 - Play with LO1 and LO2 to invesitate LO beam shape and power
 - Check coherence between LO/AS power fluctuations with suspension motions
 - What is the expected counts/W for these DCPDs?
 - Balance the optical paths in ITMX table for A and B (same lenses, same mirrors)
 - Install better lens in front of camera

{Yuta, Yehonathan}

We went to the BS table to check the POP beam power. We first notice that the POP beam has a nice gaussan profile on the viewing card. We traced it the beam to the viewing port and measured the power there. Before measuring the power we misalign ITMY/ITMX to get rid of interferences. We measure the beam to be 205uW in both cases.

The expected power is

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 97.8%(PR2) * 50%(BS) * 98.6%(ITM) * 50%(BS)  * 2.2%(PR2) = 260uW

which is reasonably close to what we measure which confirms that PR2 transmission is around what we think it is.

This strengthen our suspicion that LO beam gets clipped somewhere.

We also improved the clipping on the POP camera by one of the beamsplitters along the beam path and the alignment to the POPDC PD (~100 cts before, ~ 1000 cts after).

[Yuta, Tega]

From our previous work (elog 17044) of shaking PR2 and seeing a signal in DCPD_A and the fact that LO beam power is far smaller than the expected nominal value, we decided to use TT1 and TT2 to realign the LO beam. This resulted in LO beam power going up by a factor of 6 and an improvement in the LO beam shape. We are still unable to find LO and AS alignment which realize BHD fringe with no clipping everywhere.

Deformed LO beam issue: Following the TT1 and TT2 alignments, used PR2 and PR3 to recover the transmission of the X and Y arms to 1. We also used LO1 and LO2 offsets to further reduce the beam deformation by eliminating the HOM concentric fringes that surounded the LO beam and to maximize the DCPD outputs. BHD optics in ITMY table was tweaked a lot to keep the LO beam centered on the BHD DCPDs and camera. The improved LO beam is still astigmatic in the yaw direction but at least now looks like a TEM00 mode. We also repositioned the DCPD_A path camera lens to remove the circular diffused fringes due to lens clipping. After the alignment, power was measured to be the following. It also reduced the coherence between DCPD outputs and suspension motions (see attached).

                       LO         ITMX
C1:HPC-DCPD_A_OUT16    +127.50    +96.24 (ITMX single bounce consistent to 40m/17040)
C1:HPC-DCPD_B_OUT16    +120.51    +141.52
Power at viewport A    504 uW (almost as expected 40m/17040)
Power at viewport B    385 uW

AP table AS beam clipping: We also noticed clipping in the AS beam in AP table which we removed by moving SR2 and AS1 in YAW and then used AS4 to keep the BHD AS beam centered in the BHD DCPDs.

BHD fringe: After overlaping the LO and AS beams, we saw diagonal fringes indicating beam tilt of LO wrt AS, so we tried to remove the AS beam tilt using AS1 and AS4 but failed to do so because the AS4 mirror seemed to completely distort the beam, so intead we decided to use SR2 and AS1 to remove the tilt between LO and AS beams, which realized BHD fringe. But the motion of SR2 and AS1 then moved the AS beam that it is no longer seen in AP table. The alignment to realize LO and AP AS beam without clipping, and that to realize BHD fringe are attached.

2PM: Arrived at the 40m. Started the work for the coupling of the RF modulated LO beam into a fiber. -> I left the lab at 10:30 PM.

The fiber coupling setup for the phase-modulated beam was made right next to the PSL injection path. (See attachment 1)

• For the alignment of the beam, the main PSL path, including the alignment of the 2" PO mirror, has not been touched.
• There are two PO beams with the optical power of 0.8mW (left) and 1.6mW (right). Both had been blocked but the right one was designed to be used for PSL POS and ANG. For the fiber coupling, the right beam was used.
• The alignment/mode-matching work has been done with a short (2m?) fiber patch cable from Thorlabs. The fiber is the same as the one used for LO delivery.
• I tried to have a mode-matching telescope in the LO path. I ended up having no lens for the best result. The resulting transmitted power is 1.21mW out of 1.64mW incident (~74%). These powers were measured with the Ophir power meter. (Note that Thorlabs' fiber power meter indicated 1.0mW transmission.)

Some notes

• After the PSL activity, the IMC locking was checked to see if I messed up the PSL alignment. It locks fine and looks fine.
  • The input shutter (left closed after Jon's vacuum work?) was opened.
  • The alignment was not optimal and had some pitch misalignment (e.g. TEM03).
  • After some MC SUS alignment, the automatic locking of TEM00 was recovered. Mainly MC3 pitch was moved (+0.17).
  • I've consulted with Gautam and he thinks this is with the level of regular drift. The AS beam was visible.
• The IMC and MI were moving so much, but this seemed just the usual Saturday night Millikan shake.
• During the activity, the PSL HEPA was turned up to 100 and it was reverted to 33 after the work.
• I have been wearing a mask and gloves throughout the work there.

The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box.  I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use. 

The 55MHz had ~600mV peak, so between 5 and 6 dBm. 

The 11MHz had ~800mV peak, so about 8 dBm.

This is not enough dBm for either.  Going in search of RF amplifiers now...

I'm not sure I agree with your conversions, BUT:

The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.

Actually, the LO inputs to the IQ boards have AP1053 (Cougar) amps on them. These are 10 dB amps and so putting 10 dBm in puts us on the very maximum of the LO range at 20 dBm.

I think the distribution box levels are fine. 

 Yeah, I looked and saw that it's a semiconductor mixer, so it doesn't have to be as perfect. 

Everything is plugged in now to the new demod board.  More details soonly...

The I & Q outs are plugged into whitening filter #3, channels 5-8.  11MHz I = chan 5, 11MHz Q = chan 6, 55MHz I = chan 7, 55MHz Q = chan 8.  These channels are probably already recorded, but I haven't checked yet.  Hopefully I'll have time tonight after I pack for my trip.  But Zach, can you look into it tomorrow just to check??  Backup plan is to just go back to using the AS11 and POP55 boards and channels if the new board isn't doing what it's supposed to.

I disconnected the 3rd and 4th channels of the demod box since they were drawing unnecessary current, and making the box hot.  Now the box is just warmish.

In order to check the proper LO level, the IMC demod board was checked. As a short summary, -8dBm is the proper input for the IMC demod board. This was realized when the variable attenuator of the RF AM Stabilizer was set up be -7dB.

Initially, I tried to do the measurement using the extender board. But every board had the issue of +15V not working. After several extender boards were tried, I noticed that the current draw of the demod board burned the 15V line of the extender board.

Then I moved to the work bench. The signals were checked with the 10:1 probe. It's not properly the 50Ohm system, exactly to say.

I found that the LO signals at the mixers have huge distortion as it reaches the nominal 17dBm, and I wondered if ERA-5s were gone. Just in case I replaced the ERA-5s but didn't see any significant change. Then I thought it is due to the mixer itself. The mixer was removed and replaced with a 50Ohm SMD resister. Then the output of the last ERA-5 became sinusoidal, and the level was adjusted to be ~17dBm (4.52 Vpp) when the input power was measured to be -7.7dBm with the RF power meter. Once the mixer was reinstalled, it was confirmed that the waveform becase rectangular like, with the similar amplitude (4.42Vpp).

Now the module was returned to the rack. The RF level at the LO input was adjusted to be -8dBm by setting the attenuator level to be 7dBm.

Once the IMC is locked with this setting, the open loop transfer function was measured. The optical gain seemed almost unchanged compared with the recent nominal. The UGF and PM were measured to be 144kHz and 30deg.

Hmmm. Very non-standard demod. From the photo, looks like someone did some surgery with the attenuators (AT1, AT2, AT3) in the LO path. (might be me from a long time ago).

-8 dBm input to a circuit is a not a low noise situation. It would be best to remove the amplifiers in the I&Q paths and just have a single amplifier in the main path. Ideally we want the LO to never go below -3 dBm and certainly not below 0 dBm while outside of the board.

I doubt that all of the LSC demods were modified in this way - this one ought to get some sharpie or stickers to show its difference.

I didn't finish making the DCC entry for this module yet.

But the attenuators are
- AT1: 10dB. There is a sign that it was 3dB before ---  a 3dB chip was also attached on the boardnext to 10dB.
- AT2/3: Removed. They were replaced with 0Ohm resistors.

Currently the input is -8dBm. The input and output of the first ERA-5 are -17dBm and +7dBm, respectively.
Then the input and output of the second ERA-5 are -2dBm and 17dB, respectively.

In order to remove the second amplification stage, the first stage has to produce 26dBm. This is too much for either ERA-5 or any chips that fits on the foot print. If we use low gain but high output amp like GVA-81 (G=10dB, DF782 package), it is doable

Input 0dBm - [ATTN 3] - -3dBm - [ERA-5 G=20dB] - +16~+17dBm - [Circuits -9dB] - +7dBm - [Attn 0dB] - +7dBm - [GVA-81 G=10dB] - +17dBm

I think we should check the conditions of all the LSC demods.