40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 6 of 344 Not logged in
ID Date Author Type Category Subject
17090   Thu Aug 18 16:35:29 2022 CiciUpdateGeneralUGF linked to optical gain!

TL;DR: When the laser has good lock, the OLTF moves up and the UGF moves over!

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

Figured out with Paco yesterday that when the laser is locked but kind of weakly (mirrors on the optical table sliiightly out of alignment, for example), we would get a UGF around 5 kHz, but when we had a very strong lock (adjusting the mirrors until the spot was brightest) we would get a UGF around 13-17 kHz. Attached are some plots of us going back and forth (you can kind of tell from the coherence/error that the one with the lower UGF is more weakly locked, too). Error on the plots is propagated using the coherence data (see Bendat and Piersol, Random Data, Table 9.6 for the formula).

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

Want to take data next week to quantitatively compare optical gain to UGF!

Attachment 1: rpi_OLG_2022_08_17_18_03_52.pdf
Attachment 2: rpi_OLG_2022_08_17_18_00_50.pdf
17089   Thu Aug 18 14:49:35 2022 YehonathanSummaryLSCFPMI Sensitivity

{Yuta, Yehonathan}

We wrote a notebook found on Git/40m/measurements/LSC/FPMI/NoiseBudget/FPMISensitivity.ipynb for calculating the MICH, DARM (currently XARM), CARM (currently YARM) sensitivities in the FPMI lock which can be run daily.

The IN and OUT channels of each DOFs are measured at a certain GPS time and calibrated using the optical gains and actuation calibration measured in the previous post.

Attachment shows the results.

It seems like the UGFs for MICH and DARM (currently XARM) match the ones that were estimated previously (100Hz for MICH, 120Hz for DARM) except for CARM for which the UGF was estimated to be 250Hz and here seems to be > 1kHz.

Indeed one can also see that the picks in the CARM plot don't match that well. Calculation shows that at 250Hz OUT channel is 6 times more than the IN channel. Calibrations for CARM should be checked.

MICH sensitivity using REFL55 at high frequencies is not much better than what was measured with AS55.

DARM sensitivity at 10Hz is a factor of a few better than the single arm lock sensitivity.

Now it is time to do the budgeting.

Attachment 1: Sensitivity_Plot_1344133503.pdf
17088   Wed Aug 17 11:10:51 2022 ranaUpdateComputersc1teststand rack mounting for CDS upgrade

we want to be able to run SimPlant on the teststand, test our new controls algorithms, test watchdogs, and any other software upgrades. Ideally in the steady state it will run some plants with suspensions and cavities and we will develop our measurement scripts on there also (e.g. IFOtest).

 Quote: [Tega, Yuta] I keep getting confused about the purpose of the teststand. The view I am adopting going forward is its use as a platform for testing the compatibility of new hardware upgrade, instead of thinking of it as an independent system that works with old hardware.
17087   Wed Aug 17 10:27:49 2022 CiciUpdateGeneralLocking X-arm AUX laser

TL;DR: Got the x-arm aux laser locked again and took more data - my fit on my transfer functions need improvement and my new method for finding coherence doesn't work so I went back to the first way! See attached file for an example of data runs with poor fits. First one has the questionable coherence data, second one has more logical coherence. (ignore the dashed lines.)

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

• The aux laser on the x-arm was still off after the power shutdown, so Paco and I turned it back on, and realigned the oplev of the ETMX - initial position was P = -0.0420, Y = -5.5391.
• Locked the x-arm and took another few runs - was calculating coherence by I/Q demodulation of the buffers and then recombining the I/Q factors and then taking scipy.signal.coherence(), but for some reason this was giving me coherence values exclusively above 0.99, which seemed suspicious. When I calculated it the way I had before, by just taking s.s.coherence() of the buffers, I got a coherence around 1 except for in noisy areas of the data where it dropped more significantly, and seemed to be more correlated to the data. So I'll go back to using that way.
• I also think my fits are not great - my standard error of the fits (calculated using the coherence as weight, see Table 9.6 of Random Data by Piersol and Bendat for the formula I'm using) are enormous. Now that I have a good idea that the UGF is between 1 - 15 kHz, I'm going to restrict my frequency band and try to fit just around where the UGF would be.

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

To do:

• Reduce frequency band and take more data
• Get fit with better standard error, use that error to calculate the uncertainty in the UGF!
Attachment 1: rpi_OLG_2022_08_16_17_00_41.pdf
Attachment 2: rpi_OLG_2022_08_16_17_01_21.pdf
17086   Wed Aug 17 10:23:05 2022 TegaUpdateGeneralc1vac issues, pressure gauge replacement

- Disk full

I updated the configuration file '/etc/logrotate.d/rsyslog' to set a file sise limit of 50M on 'syslog' and 'daemon.log' since these are the two log files that capture caget & caput terminal outputs. I also reduce the number of backup files to 2.

controls@c1vac:~cat /etc/logrotate.d/rsyslog /var/log/syslog { rotate 2 daily size 50M missingok notifempty delaycompress compress postrotate invoke-rc.d rsyslog rotate > /dev/null endscript } /var/log/mail.info /var/log/mail.warn /var/log/mail.err /var/log/mail.log /var/log/daemon.log { rotate 2 missingok notifempty size 50M compress delaycompress postrotate invoke-rc.d rsyslog rotate > /dev/null endscript } /var/log/kern.log /var/log/auth.log /var/log/user.log /var/log/lpr.log /var/log/cron.log /var/log/debug /var/log/messages { rotate 4 weekly missingok notifempty compress delaycompress sharedscripts postrotate invoke-rc.d rsyslog rotate > /dev/null endscript } - Vacuum gauge The XGS-600 can handle 6 FRGs and we currently have 5 of them connected. Yes, having a spare would be good. I'll see about placing an order for these then.  Quote: - Disk Full: Just use the usual /etc/logrotate thing - Vacuum gauge I rather feel not replacing P1a. We used to have Ps and CCs as they didn't cover the entire pressure range. However, this new FRG (=Full Range Gauge) does cover from 1atm to 4nTorr. Why don't we have a couple of FRG spares, instead? Questions to Tega: How many FRGs can our XGS-600 controller handle? 17085 Wed Aug 17 07:35:48 2022 yutaBureaucracyGeneralMy wish list for IFO commissioning FPMI related - Better suspension damping HIGH - Investigate ITMX input matrix diagonalization (40m/16931) - Output matrix diagonalization * FPMI lock is not stable, only lasts a few minutes for so. MICH fringe is too fast; 5-10 fringes/sec in the evening. - Noise budget HIGH - Calibrate error signals (actually already done with sensing matrix measurement 40m/17069) - Make a sensitivity curve using error and feedback signals (actuator calibration 40m/16978) * See if optical gain and actuation efficiency makes sense. REFL55 error signal amplitude is sensitive to cable connections. - FPMI locking - Use CARM/DARM filters, not XARM/YARM filters - Remove FM4 belly - Automate lock acquisition procedure - Initial alignment scheme - Investigate which suspension drifts much - Scheme compatible with BHD alignment * These days, we have to align almost from scratch every morning. Empirically, TT2 seems to recover LO alignment and PR2/3 seems to recover Yarm alignment (40m/17056). Xarm seems to be stable. - ALS - Install alignment PZTs for Yarm - Restore ALS CARM and DARM * Green seems to be useful also for initial alignment of IR to see if arms drifted or not (40m/17056). - ASS - Suspension output matrix diagonalization to minimize pitch-yaw coupling (current output matrix is pitch-yaw coupled 40m/16915) - Balance ITM and ETM actuation first so that ASS loops will be understandable (40m/17014) - Suspension calibrations - Calibrate oplevs - Calibrate SUSPOS/PIT/YAW/SIDE signals (40m/16898) * We need better understanding of suspension motions. Also good for A2L noise budgeting. - CARM servo with Common Mode Board - Do it with single arm first BHD related - Better suspension damping HIGH - Invesitage LO2 input matrix diagonalization (40m/16931) - Output matrix diagonalization (almost all new suspensions 40m/17073) * BHD fringe speed is too fast (~100 fringes/sec?), LO phase locking saturates (40m/17037). - LO phase locking - With better suspensions - Measure open loop transfer function - Try dither lock with dithering LO or AS with MICH offset (single modulation) - Modify c1hpc/c1lsc so that it can modulate BS and do double demodulation, and try double demodulation - Noise Budget HIGH - Calibrate MICH error signal and AS-LO fringe - Calibrate LO1, LO2, AS1, AS4 actuation using ITM single bounce - LO fringe - Check BHD DCPD signal chain (DCPD making negative output when fringes are too fast; 40m/17067) - Make a sensitivity curve using error and feedback signals - AS-LO mode-matching - Model what could be causing funny LO shape - Model if having low mode-matching is bad or not * Measured mode-matching of 56% sounds too low to explain with errors in mode-matching telescope (40m/16859, 40m/17067). IMC related - WFS loops too fast (40m/17061) - Noise Budget - Investigate MC3 damping (40m/17073) - MC2 length control path 17084 Wed Aug 17 01:18:54 2022 KojiUpdateGeneralNotice: SURF SUS test setup blocking the lab way Juan and I built an analog setup to measure some transfer functions of the MOS suspension. The setup is blocking the lab way around the PD test bench. Excuse us for the inconvenience. It will be removed/cleared by the end of the week. Attachment 1: PXL_20220817_060428109.jpg 17083 Tue Aug 16 18:22:59 2022 TegaUpdateComputersc1teststand rack mounting for CDS upgrade [Tega, Yuta] I keep getting confused about the purpose of the teststand. The view I am adopting going forward is its use as a platform for testing the compatibility of new hardware upgrade, instead of thinking of it as an independent system that works with old hardware. The initial idea of clearing 1X7 cannot be done for now, because I missed the deadline for providing a detailed enough plan before Monday power up of the lab, so we are just going to go ahead and use the new rack as was initially intended and get the latest hardware and software tested here. We mounted the DAQ, subnet and dolphin IX switches, see attachement 1. The mounting ears that came with the dolphin switch did not fit and so could not be used for mounting. We looked around the lab and decided to used one of the NavePoint mounting brackets which we found next to the teststand, see attachment 2. We plan to move the new rack to the current location of the teststand and use the power connection from there. It is also closer to 1X7 so that moving the front-ends and switches to 1X7 should be straight forward after we complete all CDS upgrade testing. Attachment 1: IMG_20220816_180157132.jpg Attachment 2: IMG_20220816_175125874.jpg 17082 Mon Aug 15 20:09:18 2022 KojiUpdateGeneralc1vac issues, 1 pressure gauge died - Disk Full: Just use the usual /etc/logrotate thing - Vacuum gauge I rather feel not replacing P1a. We used to have Ps and CCs as they didn't cover the entire pressure range. However, this new FRG (=Full Range Gauge) does cover from 1atm to 4nTorr. Why don't we have a couple of FRG spares, instead? Questions to Tega: How many FRGs can our XGS-600 controller handle? 17081 Mon Aug 15 18:06:07 2022 AnchalUpdateGeneralc1vac issues, 1 pressure gauge died [Anchal, Paco, Tega] ### Disk full issue: c1vac was showing /var disk to be full. We moved all gunzipped backup logs to /home/controls/logBackUp. This emptied 36% of space on /var. Ideally, we need not log so much. Some solution needs to be found for reducing these log sizes or monitoring them for smart handling. ### Pressure sensor malfunctioning: We were unable to opel the PSL shuttter, due to the interlock with C1:Vac-P1a_pressure. We found that C1:Vac-P1a_pressure is not being written by serial_MKS937a service on c1vac. The issue was the the sensor itself has become bad and needs to be replaced. We believe that "L 0E-04" in the status (C1:Vac-P1a_status) message indicates a malfunctioning sensor. Quick fix: We removed writing of C1:Vac-P1a_pressure and C1:Vac-P1a_status from MKS937a and mvoed them to XGS600 which is using the sensor 1 from main volume. See this commit. Now we are able to open PSL shutter. The sensor should be replaced ASAP and this commit can be reverted then. 17080 Mon Aug 15 15:43:49 2022 AnchalUpdateGeneralComplete power shutdown and startup documentation All steps taken have been recorded here: https://wiki-40m.ligo.caltech.edu/Complete_power_shutdown_2022_08 17079 Mon Aug 15 10:27:56 2022 KojiUpdateGeneralRecap of the additional measures for the outage prep [Yuta Koji] (Report on Aug 12, 2022) We went around the lab for the final check. Here are the additional notes. • 1X9: The x-end frontend machine still had the AC power. The power strip to which the machine is connected was disconnected from the AC at the side of the rack. (Attachment 1) • 1X8: The vacuum rack still supplied the AC to c1vac. This was turned off at the UPS. (Attachment 2) • 1X6: VMI RFM hub still had the power. This was turned off at the rear switch. (Attachment 3) • PSL: The PSL door was open (reported above). Closed. (Attachment 4) • 1Y2: The LSC rack still had the DC power. The supplies were turned off at the KEPCO rack (the short rack). (Attachment 5) Note that the top-right supply for the +15V is not used. (The one in the empty slot got busted). We may need some attention to the left-most one in the second row. It indicated a negative current. Is this just the current meter problem or is the supply broken? • Control room: The CAD WS was turned off. I declare that now we are ready for the power outage. Attachment 1: PXL_20220812_234438097.jpg Attachment 2: PXL_20220812_234655309.jpg Attachment 3: PXL_20220812_234748559.jpg Attachment 4: rn_image_picker_lib_temp_b5f3e38d-796c-4816-bc0e-b11ba3316cbe.jpg Attachment 5: PXL_20220812_235429314.jpg 17078 Fri Aug 12 13:40:36 2022 JCUpdateGeneralPreparing for Shutdown on Saturday, Aug 13 [Yehonathan, JC] Our first step in preparing for the Shutdown was to center all the OpLevs. Next is to prepare the Vacuum System for the shutdown. 17077 Fri Aug 12 02:02:31 2022 KojiUpdateGeneralPower Outage Prep: nodus /home/export backup Took the backup (snapshot) of /home/export as of Aug 12, 2022 controls@nodus> cd /cvs/cds/caltech/nodus_backup controls@nodus> rsync -ah --progress --delete /home/export ./export_220812 >rsync.log& As the last backup was just a month ago (July 8), rsync finished quickly (~2min). 17076 Thu Aug 11 17:15:33 2022 CiciUpdateGeneralMeasuring AUX Laser UGF with Red Pitaya TL;DR: Have successfully measured the UGF of the AUX laser on my Red Pitaya! Attached is one of my data runs (pdf + txt file). --------------------------------------------------------------- • Figured out how to get a rudimentary coherence (use scipy.signal.coherence to get Cxy = abs(Pxy)**2/(Pxx*Pyy), then find what point is the closest to the frequency I'm inserting on that iteration of the swept sine and get the coherence closest to that). Not precisely the coherence at the frequency I'm inserting though, so not perfect... more of a lower bound of coherence. • Figured out how to get the UGF from the data automatically (no error propagation yet... necessary next step) • Put my red pitaya in the X-arm AUX laser control electronics (thank you to Anchal for help figuring out where to put it and locking the x-arm.) Counts dropped from 4500 to 1900 with the x-arm locked, so 58% mode matching. I lose lock at an amplitude >0.05 or so. • Wrote a little script to take data and return a time-stamped text file with all the parameters saved and a time-stamped pdf of the TF magnitude, UGF, phase, and coherence, so should be easy to take more data next time! ---------------------------------------------------------------- • need to take more accurate coherence data • need to propagate uncertainty on UGF (probably high...) • take more data with higher coherence (the file attached doesn't have great coherence and even that was one of my better runs, will probably increase averaging since increasing amplitude was a problem) Attachment 1: rpi_OLG_2022_08_11_16_51_53.pdf Attachment 2: rpi_OLG_2022_08_11_16_51_53.txt # frequency start: 500.0 # frequency stop: 50000.0 # samples: 50 # amplitude: 0.01 # cycles: 500 # max fs: 125000000.0 # N: 16384UGF: 9264.899326705621 # Frequency[Hz] Magnitude[V/V] Phase[rad] Coherence 4.999999999999999432e+02 5.216612299292965105e+01 -7.738468629291910261e-01 7.660920305860696722e-02 5.492705709937790743e+02 3.622076363933444298e+01 -5.897393740774580229e-01 3.183076012979469405e-01  ... 49 more lines ... 17075 Thu Aug 11 16:48:59 2022 ranaUpdateComputer Scripts / ProgramsNDS2 updates We had several problems with our NDS2 server configuration. It runs on megatron, but I think it may have had issues since perhaps not everyone was aware of it running there. 1. channel lists were supposed to updated regularly, but the nds2_nightly script did not exist in the specified directory. I have moved it from Joe Areeda's personal directory (/home/nds2mgr/joework/server/src/utils/) to nds2mgr/channel-tracker/. 2. The channel history files (/home/nds2mgr/channel-tracker/channel_history/) are stored on the local megatron disk. These files had grown up to ~50 GB over tha past several years. I backed these up to /users/rana/, and then wiped them out so that the NDS could regen them. Now that the megatron local disk is not full, it seems to work in giving raw data. 3. Need to confirm that this serves up trend data (second and minute) 4. I think there is a nds2-server package for Debian, so we should update megatrons OS to the preferred flavour of DebIan and use that. Who to get to help in this install? Since Megatron is currently running the "Shanghai" Quad-core Opteron processor from ~2009, its ~time to replace it with a more up to date thing. I'll check with Neo to see if he has any old LDAS leftovers that are better. 17074 Wed Aug 10 20:51:14 2022 TegaUpdateComputersCDS upgrade Front-end machine setup Here is a summary of what needs doing following the chat with Jamie today. Jamie brought over the KVM switch shown in the attachment and I tested all 16 ports and 7 cables and can confirm that they all work as expected. TODO 1. Do a rack space budget to get a clear picture of how many front-ends we can fit into the new rack 2. Look into what needs doing and how much effort would be needed to clear rack 1X7 and use that instead of the new rack. The power down on Friday would present a good opportunity to do this work on Monday, so get the info ready before then. 3. Start mounting front-ends, KVM and dolphin network switch 4. Add the BOX rack layout to the CDS upgrade page. Attachment 1: IMG_20220810_171002928.jpg Attachment 2: IMG_20220810_171019633.jpg 17073 Wed Aug 10 20:30:54 2022 TegaSummarySUSCharacterisation of suspension damping [Yuta, Tega] We diagnosed the suspension damping of the IMC/BHD/recycling optics by kicking the various degree of freedom (dof) and then tuning the gain so that we get a residual Q of approx. 5 in the cases where this can be achieved. MC1: Good MC2: SIDE-YAW coupling, but OK MC3: Too much coupling between dofs, NEEDS ATTENTION LO1: Good LO2: Good AS1: POS-PIT coupling, close to oscillation, cnt2um off, NEEDS ATTENTION AS4: PIT-YAW coupling, cannot increase YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION PR2: No cnt2um, No Cheby PR3: POS-PIT coupling, cannot increase POS/PIT/YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION SR2: No cnt2um Attachment 1: BHD_SUSPIT_KICK.png Attachment 2: BHD_SUSPOS_KICK.png Attachment 3: BHD_SUSSIDE_KICK.png Attachment 4: BHD_SUSYAW_KICK.png Attachment 5: IMC_SUSPIT_KICK.png Attachment 6: IMC_SUSPOS_KICK.png Attachment 7: IMC_SUSSIDE_KICK.png Attachment 8: IMC_SUSYAW_KICK.png Attachment 9: PRSR_SUSPIT_KICK.png Attachment 10: PRSR_SUSPOS_KICK.png Attachment 11: PRSR_SUSSIDE_KICK.png Attachment 12: PRSR_SUSYAW_KICK.png 17072 Wed Aug 10 19:36:45 2022 KojiBureaucracyGeneralLab cleaning and discovery During the cleaning today, we found many legacy lab items. Here are some policies what should be kept / what should be disposed Dispose • VME crates and VME electronics as long as they are not in use • Eurocard SUS modules that are not in use. • Eurocard crates (until we remove the last Eurocard module from the lab) • Giant steel plate/palette (like a fork lift palette) along the Y arm. (Attachment 1) • An overhead projector unit. Keep • Spare Eurocard crates / ISC/PZT Eurocard modules • Boxes of old 40m logbooks behind the Y arm (see Attachment 2/3). • Ink-plotter time-series data (paper rolls) of 1996 IFO locking (Attachment 4). Now stored in a logbook box. • A/V type remnants: Video tapes / video cameras / casette tapes as long as they hold some information in it. i.e. Blank tapes/blank paper rolls can be disposed. Attachment 1: steel_plate.jpg Attachment 2: logbook1.jpg Attachment 3: logbook2.jpg Attachment 4: paper_plots.jpg 17071 Wed Aug 10 19:24:19 2022 ranaUpdateGeneralWorking Red Pitaya VNA Boom! 17070 Wed Aug 10 15:33:59 2022 CiciUpdateGeneralWorking Red Pitaya VNA TL;DR: I am now able to inject a swept sine and measure a transfer function with python on my Red Pitaya! Attached is a Bode plot for a swept sine from 1 - 30 MHz, going through a band pass filter of 9.5 - 11.5 MHz. ------------------------------------------------------------------------------------ • Spent too long trying to get pyRPL to work, do not recommend. The code on their website has a lot of problems (like syntax-error level problems), and is ultimately designed to open up and start a GUI, which is not what I want even if it did work. • Found some code on the git repository of someone at Delft University of Technology, worked better but still not great (oscilloscope/spectrum analyzer functions were alright, but couldn't successfully run a VNA with it, and overcomplicated). Helped me figure out appropriate decimation factors. Realized it was not using the FPGA to get TF data but instead just collecting a lot of time trace data and then taking an FFT in the code to get the TF, which wasn't ideal. • Eventually switched to using the Red Pitaya SCPI server to talk to the Red Pitaya myself, successful! I inject a swept sine with a for loop that just cycles through frequencies and takes the transfer function at each one. • Was originally getting the transfer function by using scipy.signal.csd() and scipy.signal.welch() to get Pxy and Pxx and dividing, and then just finding the closest point in the frequency spectrum to the frequency I was inserting. • Switched to doing IQ demodulation myself: where x(t) is the measurement before the band pass filter and y(t) is the measurement after, taking the mean of (x(t) * cos(2pi*freq)) = a1, mean(x*sin()) = a2, mean(y*cos()) = b1, mean(y*sin()) = b2, and then TF(freq) = (b1 + i b2)/(a1 + i a2). • Unfortunately still taking time trace data and then calculating the TF instead of using the FPGA, but I have not found anything online indicating that people are able to get VNA capabilities on the Red Pitaya without collecting and sending all the time trace data... I'm still not sure if that's actually a Red Pitaya capability yet. ------------------------------------------------------------------------------------- To do: • Will go take measurements of the AUX laser loop with the RPi! Have a good diagram of when I did it with the SR785 so it shouldn't be too hard hopefully. • Figure out how to get coherence data!! • Figure out how to get the RPi on the wifi. Right now I'm just plugging the RPi into my computer. Paco and I were working on this before and had trouble finding old passwords... Hopefully will not be too much of a roadblock. Attachment 1: rpi_vna_test.pdf 17069 Tue Aug 9 19:54:31 2022 yutaSummaryLSCFPMI locking tonight [Tega, Anchal, Yuta] We resored FPMI locking settings. Below is the summary of locking configurations tonight. To ease the lock acquisition, the step to feedback POX11_I to ETMX and POY11_I to MC2 before POX and POY mixing was necessary tonight. CARM (YARM): - 0.5 * POX11_I + 0.5 * POY11_I handed to 0.5 * REFL55_I - YARM filter module, FM4,5 for acquisition, FM1,2,3,6,8 triggered, C1:LSC-YARM_GAIN = 0.012 - Actuation on -0.77 * MC2 - UGF ~ 250 Hz DARM (XARM): - 0.5 * POX11_I - 0.5 * POY11_I handed to 4.6 * AS55_Q (it was 2.5 in 40m/17012) - XARM filter module, FM5 for acquisition (no FM4), FM1,2,3,6,8 triggered, C1:LSC-XARM_GAIN = 0.015 - Actuation on 0.5 * ETMX - 0.5 * ETMY - UGF ~ 120 Hz MICH: - 1 * REFL55_Q (turned on after XARM and YARM acquisition) - MICH filter module, FM4,5,8 for acquisition, FM2,3 triggered, C1:LSC-MICH_GAIN = +40 - Actuation on 0.5 * BS - UGF ~ 100 Hz Measured sensing matrix: Sensing Matrix with the following demodulation phases {'AS55': 200.41785156862835, 'REFL55': 93.7514468401475, 'POX11': 105.08325063571438, 'POY11': -11.343909976281823} Sensors DARM CARM MICH C1:LSC-AS55_I_ERR_DQ 5.27e-02 (-154.105 deg) 2.83e-01 (132.395 deg) 1.17e-04 (-40.1051 deg) C1:LSC-AS55_Q_ERR_DQ 3.99e-02 (-151.048 deg) 1.42e-02 (125.504 deg) 1.41e-04 (-2.42846 deg) C1:LSC-REFL55_I_ERR_DQ 5.59e-02 (77.6871 deg) 1.15e+00 (-44.589 deg) 3.55e-04 (69.2585 deg) C1:LSC-REFL55_Q_ERR_DQ 1.84e-03 (16.3186 deg) 3.35e-03 (125.67 deg) 4.59e-05 (4.18718 deg) C1:LSC-POX11_I_ERR_DQ 1.54e-01 (-157.852 deg) 6.07e-01 (-42.1078 deg) 5.55e-05 (73.3963 deg) C1:LSC-POX11_Q_ERR_DQ 6.83e-05 (-148.591 deg) 6.37e-04 (121.983 deg) 1.35e-06 (43.7201 deg) C1:LSC-POY11_I_ERR_DQ 1.85e-01 (36.1624 deg) 5.73e-01 (-43.1776 deg) 2.12e-04 (82.16 deg) C1:LSC-POY11_Q_ERR_DQ 2.16e-05 (130.937 deg) 6.38e-05 (-173.194 deg) 1.40e-06 (47.5416 deg)  FPMI locked periods: - 1344129143 - 1344129520 - 1344131106 - 1344131305 - 1344133503 - 1344134020 Next: - Restore CM servo for CARM 17068 Tue Aug 9 15:50:22 2022 KojiUpdateBHDBHD fringe contrast improved from 43% to 74% For both 40m/17020 and 40m/17024, what does the contrast mean if the numbers are leaking out to ~-100cnt? Also how much is it if you convert this contrast into the mode matching? 17067 Tue Aug 9 15:33:12 2022 yutaUpdateBHDBHD fringe contrast improved from 43% to 74% [Anchal, Yehonathan, Yuta] We did the constrast measurement with the method same as 40m/17020. Contrast between ITM single bounce and LO beam increased to 74% (we had 43% before unclipping LO beam in 40m/17056). From equations in 40m/17041 and measured ITM sigle bounce power (93 or 138 counts @ BHD DCPD) and LO power (130 or 124 counts @ BHD DCPD) from 40m/17056, expected visibility for perfectly mode-matched case is 99%. Measured constrast of 74% indicate mode-matching of 56%. Both arms locked, MICH fringe (20% percentile) Contrast measured by C1:LSC-ASDC_OUT is 80.66 +/- 0.20 % Contrast measured by C1:LSC-POPDC_OUT is 92.27 +/- 0.66 % Contrast measured by C1:LSC-REFLDC_OUT is 89.59 +/- 0.84 % Contrast measured by all is 87.51 +/- 1.69 % Both arms misaligned, MICH fringe (20% percentile) Contrast measured by C1:LSC-ASDC_OUT is 82.50 +/- 0.61 % Contrast measured by C1:LSC-POPDC_OUT is 94.18 +/- 0.26 % Contrast measured by C1:LSC-REFLDC_OUT is 92.78 +/- 0.19 % Contrast measured by all is 89.82 +/- 1.75 % ITMX-LO fringe (40% percentile) Contrast measured by C1:HPC-DCPD_A_OUT is 73.93 +/- 1.52 % Contrast measured by C1:HPC-DCPD_B_OUT is 73.56 +/- 1.22 % Contrast measured by all is 73.74 +/- 0.98 % ITMY-LO fringe (40% percentile) Contrast measured by C1:HPC-DCPD_A_OUT is 73.45 +/- 0.61 % Contrast measured by C1:HPC-DCPD_B_OUT is 75.27 +/- 0.50 % Contrast measured by all is 74.36 +/- 0.54 % Attachment 1: HPC-DCPD_B_OUT_1344118517_ITMY-LO.png Attachment 2: HPC-DCPD_A_OUT_1344118517_ITMY-LO.png Attachment 3: HPC-DCPD_B_OUT_1344118318_ITMX-LO.png Attachment 4: HPC-DCPD_A_OUT_1344118318_ITMX-LO.png 17066 Mon Aug 8 17:16:51 2022 TegaUpdateComputersFront-end machine setup Added 3 FE machines - c1ioo, c1lsc, c1sus - to the teststand following the instructions in elog15947. Note that we also updated /etc/hosts on chiara by adding the names and ip of the new FE since we wish to ssh from there given that chiara is where we land when we connect to c1teststand. Two of the FE machines - c1lsc & c1ioo - have the 6-core X5680 @ 3.3GHz processor and the BIOS were already mostly configured because they came from LLO I believe. The third machine - c1sus - has the 6-core X5650 @ 2.67GHz processor and required a complete BIOS config according to the doc. Next Step: I think the next step is to get the latest RTS working on the new fb1 (tower machine), then boot the frontends from there. KVM switch note: All current front-ends have the ps/2 keyboard and mouse connectors except for fb1, which only has usb ports. So we may not be able to connect to fb1 using a ps/2 KVM switch that works for all the current front-ends. The new tower machine does have a ps/2 connector so if we decide to use that as the bootserver and framebuilder, then we should be fine. Attachment 1: IMG_20220808_170349717.jpg 17065 Mon Aug 8 14:47:10 2022 ranaUpdatePSLFSSSlow/MCAutolocker issue (docker) can't we just go back to the old python script that was working for many years, and tested? I imagine that as soon as someone besides you tries to debug the docker setup, this is what will happen.  Quote: Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance. the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before. I've also added a wiki page for scripts documentation. 17064 Fri Aug 5 17:03:31 2022 YehonathanSummaryGeneralTesting 950nm laser found in trash pile I set out to test the actuation bandwidth of the 950nm laser. I hooked the laser to the output of the bias tee of PD testing setup. I connected the fiber coming out of the laser to the fiber port of 1611 REF PD. The current source was connected to the DB9 input of the PD testing setup. I turned on the current source and set the current to 20mA. I measured with a fluke ~ 2V at the REF PD DC port. I connected the AC port of the bias tee to the RF source of the network analyzer and the AC port of the REF PD to the B port of the network analyzer. Attachment 2 shows the setup. I took a swept sine measurement (attachment) from 100kHz to 500MHz. It seems like the bandwidth is ~ 1MHz which is weird considering the spec sheet says that the pulse rise time is 0.5ns. To make sure we are not limited by the bandwidth of the cables I looped the source and the input of the network analyzer using the cables used for the previous measurement and observed that the bandwidth is a few 100s of MHz. Attachment 1: 20220805_164434.jpg Attachment 2: LaserActuation_TF_Measurement.drawio.pdf 17063 Fri Aug 5 12:42:12 2022 KojiUpdateIOOIMC WFS: Overnight observation The IMC lock survived overnight and the WFS servo loops kept it aligned. The IMC was unlocked in the morning. The left 6 plots are the WFS servo outputs and the right most two plot show the transmission and reflection of the IMC. If the WFS is making the lock unstable under high seismic conditions, please turn the loops off. Attachment 1: Screen_Shot_2022-08-05_at_12.04.01.png 17062 Thu Aug 4 22:32:31 2022 KojiUpdateIOOUpon leaving the lab (WFS investigation) Upon leaving the lab: - HEPA is ON at the original speed (i.e. same speed at 5PM today) - WFS servo is ON, partly because we want to see how stable it is. It is not handled with the autolocker right now. So there is a possibility that the WFS servo goes wild and make the IMC totally misaligned (and does not come back) In such a case, go to the WFS servo screen and push "CH" (clear history) of each servo filters. 17061 Thu Aug 4 22:14:38 2022 KojiUpdateIOOWFS investigation WFS/MCTRANS_QPD Power Spectra Attachment 1: HEPA ON WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P) MC2 TRANS PIT is largely contaminated by the other WFS loops. MC2 TRANS YAW is slightly contaminated but not much compared to the one for pitch. Attachment 2: HEPA OFF Again, WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P) MC2 TRANS PIT is still contaminated but better. MC2 TRANS YAW is not contaminated. Observation WFS1/2 signals are largely disturbed when PSL HEPA is ON. Probably the amount of HEPA air flow was not optimized. Above 1Hz, invacuum suspension are quieter than the beam incident on the IMC. The dirty WFS signals are fedback to the mirrors. Due the large motion of the beam and also the imperfection of the actuator matrix cause the MC2 spot rather moves than stabilized. This means that the WFS loops should leave the mirrors untouched above 1Hz i.e. The loop bandwidths should be low (~<0.1Hz). (Yes I know) However, the simple gain reduction (x10) does make the servos unstable. So more adjustment is necessary. (<-Not for today) Attachment 1: Screenshot_2022-08-04_22-17-19.png Attachment 2: Screenshot_2022-08-04_22-18-45.png 17060 Thu Aug 4 22:14:20 2022 KojiUpdateIOOWFS investigation Sensing matrix measurement MCx_ASCyyy_EXC was shaken with the amplitude of 3000 cnt. Measure the transfer functions to each segment of the WFS I&Q demod outputs. - Pitch excitations consistently indicated WFS1 SEG2&3 / SEG1&4, and WFS2 SEG 1&2 / SEG 3&4 are the pairs. - Yaw excitations consistently indicated WFS1 SEG1&2 / SEG3&4, and WFS2 SEG 1&4 / SEG 2&3 are the pairs. ---> WFS1P matrix {1,-1,-1,1}, WFS1Y matrix {1,1,-1,-1}, WFS2P matrix {1,1,-1,-1}, WFS2Y matrix {-1,1,1,-1} Now look at the servo input. The following lists show the important numbers for the actuation to sensor matrices. The numbers were the measured transfer function between 7~10Hz and the unit is 1/f^2 [cnt/cnt]. CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, -77.4602 +/- 18.4495 CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -22.6042 +/- 5.289 CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.0007949 +/- 0.00019046 CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -60.5557 +/- 14.1008 CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -206.3526 +/- 47.1332 CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.00027094 +/- 6.6131e-05 CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 57.8636 +/- 35.3874 CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -185.079 +/- 104.679 CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, 0.00089367 +/- 0.00052603 CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -349.7898 +/- 202.967 CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -193.7146 +/- 111.2871 CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.003911 +/- 0.0023028 CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 65.5405 +/- 14.305 CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, 78.8535 +/- 17.1719 CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.00087661 +/- 0.00020837 CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -130.7286 +/- 29.6898 CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, 129.0654 +/- 28.6328 CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, -0.00024944 +/- 5.9112e-05 Put these numbers in the matrix calculation and take the inverse for pitch and yaw separately. We obtained WFS1P WFS2P MCTP -4.017 -4.783 -7.306e5 MC1P 3.611 -5.252 -2.025e5 MC2P 7.323 -1.017 -6.847e5 MC3P WFS1Y WFS2Y MCTY -3.457 -4.532 -5.336e5 MC1Y -0.1249 0.3826 2.635e5 MC2Y -5.714 1.076 -4.578e5 MC3Y Basically we can put these numbers into the output matrix. The last column corresponds to the spot position servo and we want to make this slow. So used x1e-5 values (i.e. removed e5) instead of these huge numbers. Attachment 1: IMC_SUS_channels_TF.pdf Attachment 2: IMC_WFS_channels_TF.pdf Attachment 3: IMC_WFS_segment_TF.pdf Attachment 4: IMC_WFS_220804.xlsx 17059 Thu Aug 4 21:58:18 2022 KojiUpdateIOOWFS investigation OK... It seems that all the 6 dof of the IMC WFS servo loops were closed with some condition... - Measured the transfer functions from ASCPIT/YAW_EXC of each suspensions to WFS segs. - FInd the proper input matrix for PIT and YAW for WFS1 and WFS2 - Closed loops one by one => This was not so successful because the loop shape was quite conditional. - Closed WFS1/WFS2 loops one by one only with FM4 (0.8Hz Zero / (100Hz pole)^2). Adjust the gains to have the UGF at a few Hz. - Found that the separation between WFS1P and WFS2P was not good. This caused instability of these loops when the gains were matched. I ended up lowering the gain of WFS1P by a factor of 10. This made the loop OK to work. FM3 (Integrator below 0.8Hz) worked fine. - FM9 Rolloff filters (RLP12) makes the loops unstable. - The MC2 spot loops (MC2_TRANS_PIT/YAW) are supposed to be slow loops. From the time series behavior it looks they are working. MEDM Snapshots (Attchaments 1~4) Attachment 1: Screenshot_2022-08-04_22-10-57.png Attachment 2: Screenshot_2022-08-04_22-11-16.png Attachment 3: Screenshot_2022-08-04_22-11-53.png Attachment 4: Screenshot_2022-08-04_22-12-39.png 17058 Thu Aug 4 19:01:59 2022 TegaUpdateComputersFront-end machine in supermicro boxes Koji and JC looked around the lab today and found some supermicro boxes which I was told to look into to see if they have any useful computers. Boxes next to Y-arm cabinets (3 boxes: one empty) We were expecting to see a smaller machine in the first box - like top machine in attachement 1 - but it turns out to actually contain the front-end we need, see bottom machine in attachment 1. This is the same machine as c1bhd currently on the teststand. Attachment 2 is an image of the machine in the second box (maybe a new machine for frambuilder?). The third box is empty. Boxes next to X-arm cabinets (3 boxes) Attachement 3 shows the 3 boxes each of which contains the same FE machine we saw earlier at the bottom of attachement 1. The middle box contains the note shown in attacment 4. Box opposite Y-arm cabinets (1 empty box) In summary, it looks like we have 3 new front-ends, 1 new front-end with networking issue and 1 new tower machine (possibly a frame builder replacement). Attachment 1: IMG_20220804_184444473.jpg Attachment 2: IMG_20220804_191658206.jpg Attachment 3: IMG_20220804_185336240.jpg Attachment 4: IMG_20220804_185023002.jpg 17057 Thu Aug 4 11:28:22 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker) Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance. the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before. I've also added a wiki page for scripts documentation. 17056 Wed Aug 3 16:00:51 2022 yutaUpdateBHDBHD fringe aligned with reduced LO and AS beam clipping Last week, we could find an alignment which realizes LO beam and AS beam both unclipped, but it was not consistent with an alignment which realize BHD fringe (40m/17046). Today, we tweaked the alignment of SR2, AS1, AS4 to have BHD fringe with reduced LO and AS beam clipping. AS beams on AP table and BHD both still look clipped, but much better now. Ideally, SR2 and AS1 will unclip AS beam, and LO1, LO2, AS4 would make BHD fringe, but it is hard right now since LO beam seem to have little room and LO2 have little actuation range. BHD optics on ITMY table, including camera, and AS55/ASDC were realigned after the aglinment work (Note that DCPD_A path have a pick-off for camera path, and this pick-off mirror have quite significant incident angle dependence of R/T ratio). Current alignment scheme: Current alignment scheme I figured out is the following. - Check Y green. If it is transmitted at good spot on GTRY camera, Yarm is OK. If not, tweak ITMY/ETMY. alignment. - Mis-align AS4, align TT1, TT2, LO1 to have DCPD_A_OUT of ~130 and DCPD_B_OUT of ~125. - Align PR3, PR2 to maximize TRY_OUT to ~1.05. - Tweak ITMY/ETMY if the beam spot on them are not good. - Align BS, ITMX to have good MICH fringe and TRX_OUT to ~1.1. - Tweak ITMX/ETMX if the beam spot on them are not good. - Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs, and align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6. DC PD values in various configurations: Both arms locked with POX/POY, MICH free, PRM/SRM misaligned  Mean Max Min C1:IOO-MC_TRANS_SUM : 14088.57 13947.52 14167.04 C1:LSC-ASDC_OUT16 : 0.16 -0.02 0.34 C1:LSC-POPDC_OUT16 : 369.34 -74.88 854.34 C1:LSC-REFLDC_OUT16 : 0.03 -0.00 0.06 C1:LSC-TRY_OUT16 : 1.00 0.95 1.04 C1:LSC-TRX_OUT16 : 1.07 1.04 1.08 Only LO beam to BHD DCPDs  Mean Max Min C1:IOO-MC_TRANS_SUM : 14121.32 14057.71 14159.38 C1:HPC-DCPD_A_OUT16 : 129.80 128.37 130.68 (Consistent with, 40m/17046. Power as expected within 20%. Squashed shape) C1:HPC-DCPD_B_OUT16 : 123.42 121.92 124.48 ITMX single bounce (ITMY, ETMX, ETMY, PRM, SRM, LO misalgined)  Mean Max Min C1:IOO-MC_TRANS_SUM : 14105.13 14000.89 14171.91 C1:HPC-DCPD_A_OUT16 : 92.54 91.45 93.30 (Consistent with 40m/17040, Power as expected within 40%. Clipped to the left in camera) C1:HPC-DCPD_B_OUT16 : 137.70 136.55 138.53 (Note that DCPD_A/B ratio is different from LO, due to BHD BS R/T unbalance; 40m/17044) C1:LSC-ASDC_OUT16 : 0.10 0.09 0.10 (Power as expected 40m/16952. Clipped to the right in camera) C1:LSC-POPDC_OUT16 : 309.19 288.93 327.10 (Power as expected within 30% 40m/17042.) C1:LSC-REFLDC_OUT16 : 0.02 0.01 0.02 ITMY single bounce (ITMX, ETMX, ETMY, PRM, SRM, LO misalgined)  Mean Max Min C1:IOO-MC_TRANS_SUM : 14112.09 14025.37 14154.51 C1:HPC-DCPD_A_OUT16 : 92.58 92.01 93.26 C1:HPC-DCPD_B_OUT16 : 137.68 136.81 138.27 C1:LSC-ASDC_OUT16 : 0.10 0.09 0.10 C1:LSC-POPDC_OUT16 : 308.48 290.49 319.73 C1:LSC-REFLDC_OUT16 : 0.02 0.01 0.02 MICH fringe only (ETMX, ETMY, PRM, SRM, LO misalgined)  Mean Max Min C1:IOO-MC_TRANS_SUM : 14090.34 13979.15 14143.86 C1:HPC-DCPD_A_OUT16 : 325.60 91.92 714.57 C1:HPC-DCPD_B_OUT16 : 400.27 18.37 762.57 C1:LSC-ASDC_OUT16 : 0.19 -0.05 0.41 C1:LSC-POPDC_OUT16 : 595.66 -119.21 1334.11 C1:LSC-REFLDC_OUT16 : 0.03 -0.01 0.07 LO-ITMX fringe only (ITMY, ETMX, ETMY, PRM, SRM misalgined)  Mean Max Min C1:IOO-MC_TRANS_SUM : 14062.58 13968.05 14113.67 C1:HPC-DCPD_A_OUT16 : 224.31 89.57 371.66 C1:HPC-DCPD_B_OUT16 : 259.74 85.37 421.86 Next: - Measure contrast (40m/17020) and estimate mode-matching of LO-AS again (40m/17041) - Now that we have better LO-AS fringe, lock LO phase in MICH (40m/17037) - Now that Dolphin issue was fixed, try double-demodulation to lock LO phase Attachment 1: Screenshot_2022-08-03_15-46-36_BHDfringeAlmostUnclipped.png 17055 Wed Aug 3 15:01:13 2022 KojiUpdateGeneralBorrowed Dsub cables Borrowed DSUB cables for Juan's SURF project - 2x D25F-M cables (~6ft?) - 2x D2100103 ReducerCables Attachment 1: PXL_20220803_215819580.jpg 17054 Tue Aug 2 17:25:18 2022 TegaConfigurationBHDc1sus2 dolphin IPC issue solved [Yuta, Tega, Chris] We did it! Following Chris's suggestion, we added "pciRfm=1" to the CDS parameter block in c1x07.mdl - the IOP model for c1sus2. Then restarted the FE machines and this solved the dolphin IPC problem on c1sus2. We no longer see the RT Netstat error for 'C1:HPC-LSC_DCPD_A' and 'C1:HPC-LSC_DCPD_B' on the LSC IPC status page, see attachement 1. Attachment 2 shows the module dependencies before and after the change was made, which confirms that the IOP model was not using the dolphin driver before the change. We encountered a burt restore problem with missing snapfiles from yesterday when we tried restoring the EPICS values after restarting the FE machines. Koji helped us debug the problem, but the summary is that restarting the FE models somehow fixed the issue. Log files: /opt/rtcds/caltech/c1/burt/burtcron.log /opt/rtcds/caltech/c1/burt/autoburt/autoburtlog.log Request File list: /opt/rtcds/caltech/c1/burt/autoburt/requestfilelist Snap files location: /opt/rtcds/caltech/c1/burt/autoburt/today /opt/rtcds/caltech/c1/burt/autoburt/snapshots Autoburt crontab on megatron: 19 * * * * /opt/rtcds/caltech/c1/scripts/autoburt/autoburt.cron > /opt/rtcds/caltech/c1/burt/burtcron.log 2>&1 Attachment 1: c1lsc_IPC_status.png Attachment 2: FE_lsmod_dependencies_c1sus2_b4_after_iop_unpdate.png 17053 Tue Aug 2 01:10:26 2022 KojiUpdateIOOWFS investigation Continued to work on the WFS repair Demod phase adjustment: - Use the PDH signal to adjust the demodulation phase to have uniform signals between the segments. - Excited laser frequency at 1234Hz by injecting 10mVpp into IMC Servo Board IN2. The input was enabled on the MC Servo screen and given the input gain of 0dB. - Looked at the ~real time spectrum in WFS1/2 SEG1/2/3/4 I&Q after the phase rotators. Changed the demod phases 1) to have ~0deg transfer function between C1:IOO-MC_F to C1:IOO-WFSi_Ij 2) to minimize the freq signal in Q phases. (See Attachment 1) - Resulting change of the demod phases: WFS1 SEG1 52.0 -> 38.0deg WFS1 SEG2 54.0 -> 53.0deg WFS1 SEG3 16.6 -> 33.2deg WFS1 SEG4 103.9 ->-37.1deg WFS2 SEG1 17.0 -> 57.8deg WFS2 SEG2 26.6 -> 51.5deg WFS2 SEG3 24.5 -> 44.0deg WFS2 SEG4 -58.0 ->103.7deg SEG4 of both WFSs had significant phase rotation. A quick check of the power spectrum indicates that the Q signals have significantly (<x1/10) lower signals (Attachment 2/3/4). So that's good. Transfer function measurement Now the ASCPIT/ASCYAW of the MC1/2/3 suspension were excited and the transfer functions to WFS1/2 SEG1/2/3/4 and MC Trans P/Y were measured. The analysis will come later. Again here the Q signals have significantly lower sensitivity to the mirror motion. So it is consistent with the above observation of the spectra. However, the quick check of the transfer functions indicated that the conventional input matrices result in the flipped dependence of the combined error signals in pitch and yaw. This might indicate that some of the cables were not inserted into the demod board properly although the cables at the demod boards show no indication of anomaly. (See the photos in ELOG 17048) It might be the case that the cable had been inserted with a special unusual arrangement. In any case, this can be fixed at the input matrix. Native change of the input matrix made WFS1PIT/WFS1YAW/WFS2PIT/WFS2YAW/MC2Trans YAW servos running (after some adjustment of the servo signs). The MC2TRANS PIT servo didn't seem to settle and run away no matter which sign is used. It's probably better to look at the sensing matrix and figure out the proper input/output matrix carefully. So at this moment, no WFSs are working. Note that I left the new demod phases in the system During the transfer function measurement some filters were turned off to make the shaking smoother: IMC ASC filters were turned off to make the FResp flat: - MC1 ASCP/Y FM1/FM5 OFF - MC2 ASCP/Y FM1/FM5/FM6 OFF - MC3 ASCP/Y FM1/FM5 OFF 60Hz comb OSEM Input filters were also turned off to make the transfer functions simpler: - MC1 INPUT FM2 OFF (60Hz comb) - MC2 INPUT FM2 OFF (60Hz comb) - MC3 INPUT FM2 OFF (60Hz comb) cf. Past IMCWFS commissioning http://nodus.ligo.caltech.edu:8080/40m/12684 Attachment 1: 220801_IMC_WFS_DEMOD.pdf Attachment 2: 220801_IMC_WFS_DEMOD2.pdf Attachment 3: WFS1.png Attachment 4: WFS2.png 17052 Mon Aug 1 18:42:39 2022 TegaConfigurationBHDc1sus2 IPC dolphin issue update [Yuta, Tega] We decided to give the dolphin debugging another go. Firstly, we noticed that c1sus2 was no longer recogonising the dolphin card, which can be checked using lspci | grep Stargen or looking at the status light on the dolphin card of c1sus2, which was orange for both ports A and B. We decided to do a hard reboot of c1sus2 and turned off the DAQ chassis for a few minutes, then restared c1sus2. This solved the card recognition problem as well as the 'dis_irm' driver loading issue (I think the driver does not get loaded if the system does not recognise a valid card, as I also saw the missing dis_irm driver module on c1testand). Next, we confirmed the status of all dolphin cards on fb1, using controls@fb1 /opt/DIS/sbin/dxadmin

It looks like the dolphin card on c1sus2 has now been configured and is availabe to all other nodes. We then restated the all FE machines and models to see if we are in the clear. Unfortunately, we are not so lucky since the problem persisted.

Looking at the output of 'dmesg', we could only identity two notable difference between the operational dolphin cards on c1sus/c1ioo/c1lsc and c1sus2, namely: the card number being equal to zero and the memory addresses which are also zero, see image below.

Anyways, at least we can now eliminate driver issues and would move on to debugging the models next.

Attachment 1: c1sus2_dolphin.png
Attachment 2: fb1_dxamin_status.png
Attachment 3: dolphin_num_mem_init2.png
17051   Mon Aug 1 17:19:39 2022 CiciSummaryGeneralRPitaya Data on Jupyter Notebook

Have successfully plotted data from the Red Pitaya on Jupyter Notebook! Have lost years of my life fighting with PyQt. Thanks to Deeksha for heavy contribution. Next task is to get actually good data (seeing mostly noise right now and haven't figured out how to change my input settings) and then to go to set up the RPi in the lab.

17050   Sat Jul 30 12:48:18 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

> it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1.

- OK. Your new MCAutolocker does not reflect the lock status to C1:IOO-MC_LOCK. This causes FSS Slow to go crazy when the IMC is not locked. Can you fix that?

- So C1PSL_SLOW.adl screen, which spawns by the "SLOW Servo" button on the FSS screen, has no effect on the FSS SLOW servo anymore. It is obsolete. At least the screen (or the link to the screen) should be removed. (Work on it once you are back.)

- Also, please make a wiki page and copy the description on the previous page.

17049   Sat Jul 30 10:38:12 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

The FSSSlow script was not properly documented and it was not working, so I had to use one that I knew worked from CTN. This scripts lives in

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDLocker.py

and uses a configuration file

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDConfigFSS.yml

The script runs all the time inside docker container which keeps it running. The heart-beat blinker shows if the script is active or not, but it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1. The second channel is a button on C1PSL_SLOW screen to engage autolocker. It has to be turned on for FSS to work.

docker instructions:

The following message is displayed on login in optimus:

-------------------------------------------------------------------------
This computer runs four services as of Feb 18, 2022 for 40m lab. To check
status of these services, type
> sudo docker ps
For restarting a particular service, type:
> sudo docker restart container_name
where container name can be found from ps command above.
Fimilarly, to check status of a service, type:
> sudo docker logs container_name

In case, you have just rebooted the machine, to start these services do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose up -d
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose up -d

To stop the docker services completely, for example before a reboot, do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose down
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose down

This should remove all active containers from the computer.

To check IP address of running containers, type:
> sudo docker inspect -f '|| {{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}   ||   {{.Name}} ||' \$(sudo docker ps -aq)

The softchansmodbus directory runs modbusEPICS docker image to host some
useful soft EPICS channels. The scripts directory runs pyep docker
image to run MC autolocker, PMC autolocker and FSS PID locker.
-------------------------------------------------------------------------

For checking log files of autolocker script, on optimus do:

sudo docker logs scritps_AL_MC_1

For checking log files of FSS PID loop, on optimus do:

sudo docker logs scripts_PID_

In the above commands, add < | tail -15> to just see the most recent 15 lines in the log file. change 15 to whatever number of lines you want to see from the end.

At any time, if you want to know how docker is running stuff, check out the /opt/rtcds/caltech/c1/Git/40m/scriptsdocker-compose.yml file for self-explanatory script usage.

I'll add some documentation on the wiki soon. That is indeed required and should have been done already.

### Debugging scripts:

All scripts could be debugged by running them on rossa by directly using python command. You can stop the docker container on optimus using:

sudo docker stop container_name

and then run the file on rossa to check it's behavior. After debugging and fixing any issues, please commit the file to gitlab repo and go back to optimus and restart the docker container:

sudo docker restart container_name

I'll add this procedure to a wiki page as well.

### Reverting back to systemd on megatron

The setup on megatron was not removed at all. All service files exist in same place and old scripts can be started in the old manner by doing following on megatron:

For FSSSlow:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

For MC autolocker:

sudo systemctl enable MCautolocker
sudo systemctl restart MCautolocker

For diabling these services again, do:

sudo systemctl stop FSSSlow
sudo systemctl disable FSSSlow
sudo systemctl stop MCautolocker
sudo systemctl disable MCautolocker

Note that one should stop docker containers on optimus before starting these systemd services to avoid conflicting scripts running together.

I have added above instructions on megatron motd. So on loging into megatron, these updated instructions would come.

If someone wants to fix the old scripts and use systemd for managing those scripts, please do so but I won't be able to help in debugging those old scripts. The shell scripts are very complicated and beyond my knowledge and python scripts are lacking documentation.

I'm happy to help debug or extend the functionality of the new scripts that live in the git directory.

17048   Fri Jul 29 22:37:54 2022 KojiUpdateIOOWFS investigation

I wanted to check what's wrong with the WFS.

I played with MC2 misalignment to check the error signals.
MC2 pitch and yaw misalignment optically produce a vertical translation and horizontal rotation of the cavity axis at the waist, respectively. So it is thought to be a more separated excitation of the cavity axis.
Then I noticed that WFS2 error signals in general has high (~100%) pitch-yaw coupling. So it was suspicious.

I went to the rack and found that WFS2 SEG4 RF input (labeled "8") was not completely inserted. (Attachment 1)
It seemed that the LEMO connector or the receptacle didn't latch properly anymore and could be easily pulled.
I gave some elbow grease to fix this but in vain. I ended up to use LEMO-BNC adapters which somehow offered a robust connection.

Desipite the insightful discovery, this was not the intrinsic solution to the issue. I checked the past signal history, but I don't think this loose connection caused the missing signal.

Next, I needed to go a bit deeper. The WFS sensors are supposed to be adjusted to I phase where the PDH signal maximally shows up. And all the segments are supposed to have the same sign in terms of the PDH signal.

I've unlocked the IMC and turned on MC2 tickling. This swept the cavity over the resonances.
WFS1 SEG1I~3I showed about the same waveform, but SEG4 Q shows the PDH signal rather than SEG 4 I.
Then tried the same test for WFS2. The SEG4 I signal has the sign-flipped PDH signal compared to WFS2 SEG1I-SEG3I.

I quickly adjusted the demod phase of WFS1 SEG4 and WFS2 SEG4 to correct them,

WFS1 SEG4 103.9-> -20
WFS1 SEG4 -58  -> 120

This in fact made the pitch and yaw separated but flipped (Pitch signal shows up in WFS1Y and yaw signal shows up in WFS1P. Same for WFS2)

These modifications were reverted upon my leaving.

Now things are much more subtle now. And I need to do a more careful quantitative analysis of the demodulation phases / input matrix / output matrix.

Note: It seems that I had worked on IMCWFS on Dec 21, 2016

Attachment 1: PXL_20220730_040900843.jpg
Attachment 2: PXL_20220730_041216848.jpg
17047   Fri Jul 29 20:21:11 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

MCAutolocker/FSSSlow are not properly documented and not properly working.
Tidy up the script and documentation, or bring it back to megatron

I was aware that the FSSSlow was misbehaving since the shutdown upon the July power outage.
- FSS Slow servo did nothing even though the apparent settings in C1:PSL_SLOW screen looked fine and heart beat blinking
- Wanted to restart FSSSlow at megatron. Despite the login message showing how to do it, the system service does not exist anymore, because it was moved somewhere.
- Searched 40m wiki but found no info how to kill and restart it
- Found an elog. It was moved to docker on optimus ELOG 16480 . The restart procedure can only be found here. Please fix all the documentation inconsistency >> Anchal

According to this elog, the following commands need to be run for starting up MCAutolocker and FSSSlow on optimus:

cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC sudo docker-compose up -d

- Problem continues. Now FSSSlow is running but only when the IMC is locked. It does not stop even when the IMC lock is lost. How can we debug docker thing?
- This is minor but the MCAutolocker log (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log) is no longer updated even though MCAutolocker is running. Was it moved somewhere?

17046   Fri Jul 29 18:24:53 2022 TegaUpdateBHDLO beam power improved by factor of 6 after LO and AS beam alignment

[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.

Attachment 1: LO_and_oldAS_settings.png
Attachment 2: BHD_fringe_settings.png
Attachment 3: Screenshot_2022-07-29_19-37-39.png
Attachment 4: FromTheLeft-AS-POP-LO.JPG
17045   Thu Jul 28 20:16:26 2022 AnchalUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

Some insights from the inside vacuum situation:

• The beam is an incident near normal on PR2 close to the center of the optic. It wasn't hard to align this part, I'm very confident that we aligned it to the center of PR2. So I do not think the LO beam is ghost beam from PR2.
• The place that is most susceptible to clipping is POP_SM5 mirror in front of LO1. The LO beam has little clearance from the edge of the mirror.
• Another possibility of clipping in LO beam is through the cage of LO2. LO2 is a 45-degree incidence mirror, so it is possible we are clipping off the cage or seeing a ghost beam mixed in LO beam here.
• The fact that moving PR2 is affecting LO beam is weird but doesn't necessarily mean it is a ghost from PR2.
17044   Thu Jul 28 16:51:55 2022 TegaUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

[Yuta, Tega, Yehonathan]

To investigate the BHD power imbalance and clipping issues, we did some shaking test of the mirrors in the LO path and AS paths. The results suggests the following:

• The clipping is happening after the BHD BS in DCPD_A path, as opposed to our initial guess of BHD BS transmission clipping in elog 17040.
• The LO beam we are seeing is probably a ghost beam from PR2

We performed both PIT and YAW shaking of all mirrors and looked at the output at DCPD_A and DCPD_B, see table below for details. Since we only see the dithering signal in DCPD_A, it suggests that the clipping is ocurring after the BHD BS and is also confined to the path between BHD BS and DCPD_A. We also swapped the camera location from DCPD_A to DCPD_B on ITMY table and confirmed that the beam was clipped for DCPD_A but not for DCPD_B.

This result discounts the possiblity of clipping being responsible for the power imbalance and therefore suggests that the power imbalance may actually be due to BHD BS not being 50:50. From the measurement in elog 17040, the transmission of BHD BS is 44$\pm$0.3% and the reflectivity is 56$\pm$0.3%. Note that DCPD_A is the transmission of BHD BS for AS beam, whereas DCPD_B is the reflection of BHD BS for AS beam, elog 16932.

We expect the shaking of PR2 to give no signal in either DCPD_A or DCPD_B when the LO beam is purely in trasmission, however, we see a signal in DCPD_A sugesting that the LO beam transit path through PR2 may not be as expected, i.e. the beam might be exiting the side of PR2 instead of the AR coated surface.

Finally, we measured the coherence between the dithering dof and DCPD_A/B & POP, see attachment 2, where we noticed that both DCPD_A/B have high coherence in the 1Hz-10Hz frequency band whereas ther was no coherence in POP as expected. This suggests that there may also be some small clipping in DCPD_B path.

LO Beam Shaking (LO1, LO2, PR2):

 color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue LO1 YAW 304.4 2000 Signal in DCPD_A & No signal in DCPD_B Orange LO1 PIT 304.4 2000 No signal Magenta LO2 YAW 312.2 10000 No signal Purple LO2 PIT 312.2 10000 Signal in DCPD_A & No signal in DCPD_B Green PR2 YAW 308.8 20000 Signal in DCPD_A & No signal in DCPD_B Red PR2 PIT 308.8 20000 Signal in DCPD_A & No signal in DCPD_B

AS Beam Shaking (AS1 and AS4)

 color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue AS1 YAW 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Orange AS1 PIT 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Magenta AS4 YAW 313.3 2000 Signal in DCPD_A & No signal in DCPD_B Purple AS4 PIT 313.3 2000 No signal

Attachment 1: Screenshot_2022-07-28_16-58-34_LOandASShaking.png
Attachment 2: Screenshot_2022-07-28_18-08-55_DCPDPOPSuspensionCoherence.png
17043   Thu Jul 28 15:11:59 2022 KojiUpdateCDSToo huge script_archive

As a result of the following work, the file volume of /cvs/cds was reduced from 3.2TB to 2.2TB, and /opt/rtcds/caltech/c1/scripts was reduced from 10GB to 1.5GB

/cvs/cds/caltech/scripts_archive was cleaned up. Now the archive files are reduced to have:

• every month 1st day from 2005 to 2018/12
• every ten days (1, 11, 21) for 2019 and 2020
• everyday for 2021 and 2022

(scripts)/MEDMtab/image was deleted. I can be restore back from one of the script_archive files.

(scripts)/MC/logs/AutoLocker.log was just deleted and refreshed. For the past settings, we can refer autoburt snapshots or script_archive files.

(scripts)/Admin/n2Check.log

• It turned out that the frequency of the check was reduced to once per 10min on Sep 9th, 2021 (unelogged activity).
• The volume of the text since then was not much volume. So I deleted the lines before this date. And the file size is <7MB now.

(scripts)/ZI was moved to /cvs/cds/apps

/opt/rtcds/caltech/c1/burt/autoburt/snapshots

• 2018, 2019, 2020 snapshots were archived in tar.gz.
• These snapshots were then deleted

17042   Thu Jul 28 14:34:40 2022 YehonathanUpdateBHDLO beam power at BHD DCPDs is significantly lower than expected

{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).

17041   Thu Jul 28 13:09:28 2022 yehonathanUpdateBHDMode matching considerations

The LO beam was found to have a power of 60uW, 10% of the power expected. We are pretty sure about the expectation because the AS beam has a power of 300uW, roughly the expected power. Additionally, the visibility of the MICH fringes in the BHDR is 40%.

If the mode-matching is perfect then we expect the visibility to be $\text{VIS}=\frac{I_\text{max}-I_\text{min}}{I_\text{max}+I_\text{min}}=\frac{2\sqrt{I_\text{LO}I_\text{AS}}}{I_\text{LO}+I_\text{AS}}=\frac{2\sqrt{300\cdot 60}}{300+600}$

which is roughly 74.5%.

If there is some mode-mismatch one can show that the visibility is $\text{VIS}=\frac{2\sqrt{M}\sqrt{I_\text{LO}I_\text{AS}}}{I_\text{LO}+I_\text{AS}}$, where $M=\left|\frac{\int \left(E_\text{LO}^\star E_\text{AS} \right)\mathrm{d}x \mathrm{d}y}{\sqrt{I_\text{LO}I_\text{AS}}}\right|^2$ is the mode-mismatch.

Using Finesse model I calculated \sqrt(M)=0.93 in the MICH configuration so the expected visibility is around 70%, far away from the observed 40%. To explain the observed visibility the mode mismatch would have to be ~ 30% which is very unlikely.

So it could either be a ghost beam or that the LO beam is clipped so badly that it also degrades its phase front (and therefore the mode-matching). The fact that we see fringes on the LO beam might suggest knife edge clipping on one of the auxiliary optics in the BS chamber.

ELOG V3.1.3-