40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 2 of 344  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
IDdown Date Author Type Category Subject
  17272   Wed Nov 16 12:53:36 2022 ranaUpdateASCIMC WFS ongoing

In the middle of aportioning gains and signs in the IMC WFS screen, so beware. More updates soon.

  17271   Wed Nov 16 11:56:21 2022 RadhikaUpdatePSLPMC input beam aligned again, IMC

[Yuta, JC, Radhika]

PMC input beam was aligned again, bringing transmission from 0.70 to ~0.75. To avoid blocking the PMC refl beam, I found success handling the yaw knob of the first steering mirror from below.

  17270   Tue Nov 15 19:00:56 2022 yutaSummaryBHDMICH locked with balanced homodyne readout at some LO phase

[Paco, Yuta]

MICH was locked with BHD DCPD A-B signal with LO phase controlled.
Locking procedure and configuration was as follows (see Attachment #1).

1. Lock MICH with AS55_Q, with C1:LSC-MICH_GAIN=-3, FM4, FM5, FM8, FM10 (boost filters are turned off to have more phase margin).

2. Lock LO PHASE with BH55_Q, with C1:HPC-LO_PHASE_GAIN=6, FM5, FM8, feeding back to AS1.
  - C1:LSC-BH55_PHASE_R=136.136 deg was tuned to minimize I when AS-LO is fringing with MICH locked with an offset of 50 (we first thought 136.136 deg - 90 deg is better from 40m/17216, but today, 136.136 deg seems to work better; Reason needs to be investigated).
  - We are supposed to use C1:HPC-BH55_Q_AS1_DEMOD_I_OUT to control the LO phase to give maximum MICH signal on BHD_DIFF (40m/17170), but somehow BH55_Q without audio dither was OK to get MICH signal. Line injection at 211.1 Hz on BS was seen in BHDC_DIFF (and AS55_Q), even if we use BH55_Q to lock LO PHASE (see Attachment #2; MICH_B is BHDC_DIFF and MICH_A is AS55_Q) or BH55_Q_AS1_DEMOD_I to lock LO PHASE (with both signs). Reason needs to be investigated.
  - Audio dither was done using AS1 with excitation of 15000 counts at 281.79 Hz. C1:HPC-BH55_Q_AS1_DEMOD_PHASE=60 deg was tuned to minimize Q with injection of line at 13 Hz using LO1.

3. Handed over MICH lock from AS55_Q to 0.66 * C1:LSC-DCPD_A - 1 * C1:LSC-DCPD_B. This was done by using C1:LSC-MICH_A and MICH_B gains. C1:LSC-MICH_A_GAIN=1 was handed over to C1:LSC-MICH_B_GAIN=-1.
  - 0.66 * A - B was tuned so that BHDC_DIFF will be zero (as it supposed to be with MICH offset of zero).
  - AS55_Q and BHDC_DIFF had roughly the same optical gain at 211.1 Hz (actually, BHDC_DIFF had higher optical gain; see Attachment #2), so we used MICH_A_GAIN=1 and C1:LSC-MICH_B_GAIN=-1
  - After handing over of BHDC_DIFF, OLTF was measured. UGF was ~70 Hz (Attachment #3).

Next:
  - Investigate how to get optimal LO phase. With BH55_Q or BH55_Q + audio dithering? How to optimize demod phases?
  - How do we balance DCPD A and B? What is the effect of BHD BS being 44:56 not 50:50?
  - Measure amount of MICH signal in BHDC_DIFF with different LO phases.
  - Improve SNR in BH55.
  - It will be much simpler if we send BHDC_SUM and BHDC_DIFF to c1lsc from c1hpc, instead of sending un-unwhitened BHDC_A and B.

  17269   Tue Nov 15 17:58:00 2022 PacoConfigurationCamerasPOP camera realignment after IFO alignment

[Paco, Yuta]

I swapped the 1 inch BS and lenses along the POP beam to clear the apertures and avoid clipping this beam. The results are illustrated by the attached pictures; this was done right after Yuta had optimized IFO alignment so it's hopefully a good reference from now on. Yuta also tuned the alignment of BHDC path in ITMY table, which mostly improved the alignment to DCPD A (90-ish counts improved to 100-ish counts with ITMY single bounce).

  17268   Tue Nov 15 17:08:59 2022 PacoUpdateBHDRequest for estimates

[Yehonathan, Yuta, Paco]

We would like to estimate:

  • LO phase sensitivty (for RF55 + audio dither scheme), as a function of RF demod angle (both I and Q); not to be confused with audio dither angle.
  • LO phase sensitivity (for all schemes like in Attachment #2 of this previous post) but with some nonzero MICH offset.
  • LO phase sensitivity (for RF55 + audio dither scheme) but with the uBHDBS (44:56) values from this post.
  17267   Tue Nov 15 16:34:55 2022 alexUpdateGeneralDebian with Sensoray

I have confirmed the ability to install the sensoray drivers on Debian 11 in a virtual machine environment. I will do testing with the sensoray device on this tomorrow and if all works, begin working on code for capturing images. I will then test this out on Donatella once Tega finishes installing Debian across all computers in the coming week or so. 

  17266   Tue Nov 15 11:04:01 2022 PacoSummaryCalibrationSingle arm cal with 5 lines

YALS Hardware inspection

The ALS Cal for ITMY actuation was off by ~ 1000, so I decided I don't trust / understand what this beatnote is seeing. Then, I went in the lab to inspect things;

  1. ALS DFD and DEMOD: The demod box was off no perhaps on purpose, more likely by accident... the switch was off in the rear of the 1U box in the LSC rack... Also, the DB9 cable labeled ALS was disconnected. Fixed both these bugs and verified it worked all the way into cds.
  2. YARM Green injection: Did some re-alignment, and noted the mode was hopping a bit too much (once every couple of seconds) so I rotated the half waveplate before the green PZT steering mirrors by  ~ 8 deg and used the latter to get a GTRY transmission of > 0.320 (counts), about 75% more than last time. Finally I made sure the mode is robustly locked for several minutes.

Beatnote calibration

The factor above may be explained by the bogus signals coming into the beat fine phase channels on the ALS model. After locking the YARM with POY11, and locking the YAUX to the YARM cavity, I turned on the LSC oscillators -- all five of them see Attachment #1 for the screenshot -- and looked for the lines in the C1:ALS-BEATY_FINE_PHASE_OUT channel. Here, again the sensing output matrix was set up to actuate on ITMY, while the ETMY (control point of YARM loop) had all the output notches on. Once all lines were visible in the YAUX beatnote, I had to reduce the LSC filter gain from 0.012 to 0.011 to prevent loop oscillations... Then I recorded the gpstimes below with different conditions.

  • HEPA ON (JC Inside lab)
    • gpstime = 1352575798 to 1352576046
  • HEPA OFF (JC Inside lab)
    • gpstime = 1352576125 to 1352576216
  • HEPA OFF (JC in the control room)
    • gpstime = 1352576641 to 1352577591

Analysis

Basically, only the DARM line was recorded (DQ channs) so I modified the c1cal to store the SIG_OUT and DEMOD_I_IN1 channels for both BEATX and BEATY cal signals. This means I need to repeat this measurement. In the meantime I am also going to try and rerun calibrate the BEAT HZ transfer function.

  17265   Mon Nov 14 17:45:02 2022 yutaUpdateBHDBHD DC PD unwhitening and removing cables to c1lsc

[Paco, Yuta]

We removed splitter to route BHD DC PD signals to c1hpc and c1lsc. This was necessary to circumvent IPC error, but this is no longer necessary. Now BHD DC PD signals are ADC-ed with c1hpc, and sent to c1lsc via IPC.
We also found that BHD DC PD signals have whitening filters as described in LIGO-T2000500 (Readout board is LIGO-D1400384).
We added unwhitening filter zpk([151.9;3388],[13.81],1,"n") to C1:HPC_BHDC_A and B, based on measured whitening stage gain (see Sec 3.1 of characterization reoprt in LIGO-T2000500).
This solved the signals leaking to minus (40m/17068).

Next:
 - Modify c1hpc model to send BHD DCPD signals to c1lsc after unwhitening. (Note added on Nov 15: The same unwhitening filter is also added to C1:LSC-DCPD_A and B for now. See attached.)
 - Redo visibility measurements,

  17264   Mon Nov 14 14:52:56 2022 PacoConfigurationSUSBHD SUS Coil output balance

[JC, Paco]

We installed a steering mirror intersecting the BHD beam path and put the AS beam on the ITMY Oplev QPD (see Attachment #1 for a photo of this temporary hack) . This is done to do coil balancing of AS1/AS4, LO1/LO2. QPD sees ~ 10000 counts when the beam is centered.


[Paco, Yuta]

We follow this procedure -- but with different sensors for all BHD suspension coil output balancing.

AS1/AS4

We dither BUTT first, lock the LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign LO beam and look at the hijacked Oplev (ITMY) while dithering POS to minimize PIT and YAW couplings.


LO1/LO2

We dither BUTT first, lock thChangeset summarye LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign AS beam and look at the hijacked Oplev (ITMY) PIT/YAW residual noise while dithering POS to minimize PIT/YAW coupling.


Changeset summary

The new coil output gains are summarized in the table below:

Optic / Coil UL UR LR LL
AS1 -0.939 1.040 -1.026 0.995
AS4 -0.9785 0.9775 -1.0695 0.9745
LO1 -0.939 1.003 -1.074 0.984
LO2 -1.051 1.342 -0.976 0.631

Finally, I reverted the hacked QPD setup to restore the ITMY OPLEV.

  17263   Sat Nov 12 21:59:24 2022 AnchalFrogsComputer Scripts / ProgramsFSS SLOW servo not running

I stopped the Docker PID script and started the old python script on megatron. Instructions on how to do this are here.

On optimus I ran:

sudo docker stop scripts_PID_FSS_Slow_1

On megatron I ran:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

However, the daemon service keeps failing and restarting. So currently the FSSSlow is not running. I do not know how to debug this script.


On a side note, I tested the docker service by restarting it, and it was working. From the logs, it seems like it got stuck because it could not find C1:IOO-MC_LOCK channel which occurs when c1psl epics servers fail or get stuck. The blinker on this script runs when the script is running but it does not stop if the script gets stuck somewhere. If someone decides to use this script in the future, they would need to correct error catching so that no reply from caget looks like an error and the script restarts rather than keep trying to get the channel value. Or the blinker implementation should change in the script so that it displays a stuck state.

Quote:
 

 Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.

 

  17262   Fri Nov 11 20:59:13 2022 ChrisFrogsComputer Scripts / ProgramsFSS SLOW servo not running

The problem with trends was due to the epics data collection process (standalone_edc) that runs on c1sus. When all the FEs were rebooted earlier this week, this process was started automatically, but for some reason it hasn’t been doing its thing and sending epics data to the framebuilder. I restarted it just now, and it’s working again. Until this problem is sorted out, we need to remember to check on this process after rebooting c1sus.

Quote:

I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.

  17261   Fri Nov 11 20:01:56 2022 ranaFrogsComputer Scripts / ProgramsFSS SLOW servo not running

I was trying to debug why the NPRO PZT is all over the place, and it turns out that the new FSS SLOW script is not actually running.

The BLINKY is blinking, but the script is not running. I wasn't able to figure out how to kill the broken Docker thing, but if the code reports that its running but actually does not, we should probably just put back the old perl or python script that ran before. I don't know how to debug this current issue, but the IMC locks will be limited in length due to this servo being broken. Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.

I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.

  17260   Fri Nov 11 19:47:04 2022 ranaUpdateSUSMC SUS were overdamped: damping gains all reduced

After clicking on the extra MC1 unwhitening filter, I was going to retune the damping gains to give a Q ~ 5 for the suspension. I found it was very over damped. I also checked the other MC SUS. They were all overdamped.

A Q ~ 5 means that the amplitude of the oscillation should drop by 1/e after 5 oscillations. Most of the DOFs were damping in 1-2 cycles. This is good for lock acquisition impulses, but because it ties the suspension to the frame, it reduces the seismic isolation that we get from the pendulum. So we normally want the Q to be ~4-7. Someone more clever can figure out a better local damping servo that minimizes the overall MCF and IMC WFS signals, but that is a project that takes some thought.

  17259   Fri Nov 11 19:20:23 2022 ranaUpdateSUSMC1 OSEMs output is weird

I turned on the extra un-whitening filter (not the same as dewhitening) which Anchal has installed in the XXSEN filter banks of MC1. Seems good, so I'm leaving them on.


Anchal determined that the new satellite for MC1 was whitening, and also the old one was whitening, which made the whole thing non-white. So, I turned on the FM3 filter. I then checked that the ADCs were not saturating by looking at the spectrum of the IN1 channels (before the un-whitening). They are very far from saturating, but we should trend the ADC overflows on MC1 to make sure that this is not an issue (someone besides Tega should ask Tega how to add these to the summary pages so that not only Tega can edit summary pages).

In the attached plot, we can see that the reference trace for the unwhitened MC1 (FM1 ON, FM3 OFF) (black) sensor looks noisier than the others at 16 Hz, where we expect the suspensions to be mostly the same. This is because the analog whitening (amplification) was not being compensated properly. With FM1 and FM3 ON (RED) we can see that the spectra line up nicely below 20 Hz. Above 20 Hz the MC1 sensor is quieter than the others because the ADC noise is being reduced more.

Clearly, the other sensors could use some more whitening. If we find a reason to need lower damping noise in the future, let's remember this elog and remember that we ought to do proper signal conditioning on all our OSEMs. For now, probably doesn't matter.

  17258   Fri Nov 11 19:11:50 2022 JCUpdateGeneralWFS Whitening and Demod Boards

WFS Whitening and Demod boards were scavenged. ' iLIGO WFS cards are in big plastic boxes placed on the north wall around Section Y5 or Y6 (not under the arm). The WFS head PCBs, empty WFS housing, WFS components, I/Q demod components are at SectionY10 under the arm tube. ' - Koji . I have taken pictures of the boards and will upload them to the DCC once I find a way to add a Serial Number . (I will upload this to the eLog as a HowTo) The next step is to search for at least 2 extender boards to troubleshoot these board and find if there are any issues. We may have replace some components and retune the boards. Attachment #1 is an example of the WFS Whitening Filter and Attachment #2 is and example of the the WFS Demod Board.

If you use the Camera DO NOT remove the strap. I have also purchased lens caps for the camera, so after usage PUT THE LENS CAP BACK ON. 

  17257   Fri Nov 11 14:15:45 2022 PacoSummaryCalibrationSingle arm cal with 5 lines

I turned all the LSC oscillators on and used the digital demod for BEATYF (fine y als beat) to grab the data. For this I added notches onto SCY ETMY LSC filter banks FM6-10 to account for these lines at 30.92, 211.10, 313.31, 315.17 Hz (basically just reusing the osc models) and adjusted the sensing matrix to actuate on ITMY.

I aligned and locked YARM, and then I aligned and locked the YAUX. The lock seems pretty robust with an avg green transmission GTRY ~ 0.185 counts for TEM00.


Trying to see other lines appear on the BEATYF demod channels, but so far no luck. I scaled down the exc gain from 500 counts (snr ~ 20 at 575 Hz) and verified the notches are working. Since I am unsure of the issue here and WFS tests are happening at 4 today, I decided to take some beat data under different conditions -->

HEPA OFF and PSL Shutter Open

gpstime start = 1352244763 gpstime end = 1352245405

HEPA OFF and

PSL Shutter Closed

gpstime start = 1352245574

gpstime end = 1352246216

HEPA ON and

PSL Shutter Closed

gpstime start = 1352246240 gpstime end = 1352246882
  17256   Fri Nov 11 11:29:11 2022 AnchalUpdateSUSMC1 OSEMs output is weird

Late elog; original time Thursday, Nov 10 16:00 2022

MC1 is using a new satellite amplifier which was a whitening circuit on it with 3 Hz zero and 30 Hz pole. But to read out this signal, we use the old whitening board as it serves as the interface board with the ADC too. This is D000210 Whitening and Interface Board. This board has a switchable whitening filter which our RTS models supply GND as the switch input. It was not immediately clear to me if the GND input to this switch means whitening is ON or not.

I disconnected inputs and outputs to the whitening Board used for MC1 OSEM PDs, and I used a moku:go to measure the transfer function for the UR channel. This confirmed that whitening is turned ON on this interface board as well, which means the MC1 OSEM signals are whitened twice, while digitally we have been dewhitening only once. To fix this there are two possible solutions:

  • We turn on another identical dewhitening filter in MC1 OSEM input filter modules (a 3:30 at FM3)
  • We can change the MC1 Simulink model to stop keeping whitening on by default.
  17255   Thu Nov 10 20:46:32 2022 ranaUpdateASCIMC WFS servo diagnosis

To check out the bandwidths and cross-coupling in the WFS loops, I made a script (attached) to step the offsets around, sleeping between steps. Its also in the scripts/MC/WFS/ dir.

You can see from the steps that there is some serious cross coupling from WFS1-PIT to MC_TRANS PIT. This cross-coupling is not a disaster because we run the MC2 centering loop with such a low gain. This gain hirearchy means that you can effectively consider the IMC with the WFS loops closed to be an "open loop" plant that the MC TRANS loop is trying to control.

I've started another run at 4:40 UTC since my previous one only paused for 30 seconds after turning each offset OFF/ON. This is clearly not long enough to grab the MC_TRANS loop; although you can tell sort of how slow it is from the slope of the error signal after the step is applied.

To make the plot, I used diaggui in the time series mode, with a 3 Hz BW. I applied a 4th order Butterworth filter at 0.3 Hz to low pass the data using the foton string in the time series tool.

  17254   Thu Nov 10 18:09:28 2022 ranaUpdateSUSMC WFS settings all weird

Today I found the MC WFS settings all weird. Not only was the input slider set to zero, but the filter bank outputs were off, and also the ON/OFF buttons after the output matrix.

I think we may have been hacked, because there was not mention of this settings change in the ELOG, even though we have this scary red sign.

I am now trying to recover things as best as I can, but I'm not sure exactly which settings the hacker changed. Stay tuned...

  17253   Thu Nov 10 17:40:31 2022 PacoSummaryCalibrationCalibration Plan

Plan to calibrate single arm actuation strength

  1. Lock single arm cavity (e.g. YARM)
  2. Lock YAUX laser to arm cavity (actuation point is ETMY)
  3. With the notch on the YARM loop filter (actually on ETMY),
  4. Turn on cal line (e.g. DARM osc) to move ITMY; here the frequency is chosen to be away from 600 Hz (line harmonic) and from violin modes for ITMY (642 Hz). The lower value of 575.17 Hz was chosen to avoid demodulating noise peaks at 455 Hz and 700 Hz.
  5. Get raw YALS beatnote (we chose the demod angle of -35 deg to minimize Q).

The analysis is as follows:

  1. Get demodulated IQ timeseries for the duration of the locks before lowpass filter (C1:CAL-SENSMAT_DARM_BEATYF_I_DEMOD_I_IN1); we are also storing the raw beatnote if we want to do software demodulation.
  2. Look at the allan deviation of I and Q to establish the timescale over which our measurement is dominated by statistical uncertainty -- after this time, the uncertainty is expected to be due to systematic error / drift. In this case as shown by Attachment #1 the time is around 60.6 seconds.
  3. At this frequency and with 500 gain the ITMY coils should be actuating 7.32 pm of amplitude displacement.
  4. The minimum allan deviation does indeed predict the statistical uncertainty limited rms if we look at the power spectra of the demodulated cal line over different time periods (Attachment #2), notice I lowpassed the raw timeseries.
  5. I think the next step is to get the nominal calibration value and repeat the measurment for more than a single cal line.
  6. Roughly from the deviation plot, our fractional beatnote deviation is a proxy for the calibration uncertainty. 1.15e-16 of beatnote stability should translate to a fractional displacement stability of ~4.57e-15 at 60 seconds; giving an ultimate statistical calibration uncertainty of 0.06% at this particular frequency when averaging for this long. It might be interesting to see a calibration frequency dependent allan deviation plot.
  17252   Wed Nov 9 20:29:20 2022 AnchalUpdateSUSMC2 and MC3 set to undergo free swing test tonight

I have set a free swing test for MC2 and MC3 to trigger at 1 am tonight. The test should last for about 4.5 hrs upto 5:30 am. It will close the PSL shutter, perform the test, and open the shutter afterwards. To cancel or interrupt the test, go to rossa and do:

tmux a -t FST
ctrl+c
exit

 

  17251   Wed Nov 9 20:01:38 2022 AnchalUpdateSUSMC1 OSEMs output is weird

I took a coil to OSEM transfer function for MC1 osems  (LL, UR) today and again the slope of the transfer function was -1.4 instead of -2 as expected. I compared this with MC3 coil to osem transfer function (LL) which correctly had the slope of -2. See attachments 1 and 2 for the results. This measurement was taken with PSL shutter closed and local damping loops turned off.

As I mentioned earlier, MC1 is using new satellite amplifier box (S2100029-v2) whose transfer function data exists and was actually measured by me in 40m/15776. Using this transfer function data, and the foton 3:30 (FM1) filter, I tried to recreate the product transfer function that should happen if both filters are working correctly. Attachment 3 shows these transfer function plots. I overlayed on top of this the measured transfer function of OSEM to position displacement as done in 40m/17238 by making the magnitude equal at 1 Hz. It is suspicious how nicely the measured transfer function overlay with the satellite amplifier measured transfer function, both in magnitude and phase. I'll investigate more tomorrow.

 

  17250   Wed Nov 9 14:19:18 2022 TegaUpdateCDSfb1 OS migration

[Tega, Chris]

We migrated fb1 OS from the teststand fb1 drive to the internal 2TB RAID of fb1. We then rebooted twice to check that we no longer have the fb1 booting issue. 

The next step is to set up software RAID and backup for chiara, which we plan to complete this week. Then we would work on nodus and workstation OS upgrade next week.

  17249   Wed Nov 9 11:07:16 2022 AnchalUpdateSUSIMC test

Following configurations were kept today morning:

Start Time Stop Time HEPA PSL Shutter WFS Loops

1352046006

08:19:48 PST
16:19:48 UTC

1352050278

09:31:00 PST
17:31:00 UTC

OFF OPEN OFF

1352050393

09:32:55 PST
17:32:55 UTC

1352054538

10:40:00 PST
18:40:00 UTC

OFF OPEN ON

1352054537

10:41:59 PST
18:41:59 UTC

1352058724

11:51:46 PST
19:51:46

OFF CLOSED OFF

f2a filters with Q=10 (FM3) were turned on all IMC optics.

  17248   Wed Nov 9 07:49:59 2022 ranaUpdateSUSMC2 OSEMs calibrated using MC_F

It would be good if you can post the uncertainties with these measurements (and for generally any measurements). This is so that we can propagate that uncertainty later for other measurements. From your entry, it looks like there are something like 7 digits of precision, which would be astounding.

I suggest that we adopt the convention of reporting Uncertainty properly by number of significant figures and the parantheses notation.

  17247   Tue Nov 8 21:39:12 2022 alexSummaryGeneralSensoray & SDI Video Encoder selection

I have been looking at various replacements for the sensoray, and have found that the majority of new usb video encoders don't have drivers anymore and now just work through being embedded with video-capturing software. This means that the hardware must be used with a compatible video player such as VLC or OBS. VLC can natively be run with terminal commands, and because OBS is open source, there are packages that can be downloaded to use terminal commands to control the software as well. I am not sure to what extent the usb video encoder can then be controlled with these commands, but this seems to be the easiest method so far. I will finish picking which new unit we should purchase tomorrow, and order it through JC. 

  17246   Tue Nov 8 19:39:34 2022 AnchalUpdateSUSMC3 OSEMs calibrated using MC_F

I did the same measurement for MC3 with one difference that OSEMs report \sqrt{2} more motion than IMC cavity length change due to it being at 45 degrees. Following are the new cts2um gain values

  • UL 0.36 -> 0.39827(0.00045)
  • UR 0.36 -> 0.33716(0.00038)
  • LL 0.36  -> 0.34469(0.00039)
  • LR 0.36 -> 0.33500(0.00038)

 

  17245   Tue Nov 8 18:12:01 2022 AnchalUpdateSUSMC2 OSEMs calibrated using MC_F

I reran this measurement at low frequency 0.1016 Hz. Following were the cts2um gain changes:

  • UL 0.28510 -> 0.30408(0.00038)
  • UR 0.26662 -> 0.28178(0.00027)
  • LL 0.34861  -> 0.38489(0.00049)
  • LR 0.71575 -> 0.80396(0.00681)

Edited AG: Wed Nov 9 12:17:12 2022 : Uncertainties added by taking coherence of each channel and MC_F with excitation, using \sqrt{\frac{1-\gamma}{2 \gamma n_{avg}}} to get fractional error in ASD values I used for taking ratios(where \gammais coherence and n_{avg} is number of averages (5 in this case)), and adding MC_F ASD frac error to all sensor's frac error, and finally multiplyingit witht he ratios obtained above to get error in cts2um gain values.

RXA: I don't believe it. This is more accurate than the LIGO calibration of strain and also more accurate than the NIST calibration of laser power.

 

  17244   Tue Nov 8 16:56:33 2022 ranaUpdateAUXAUX PZT transfer function fitting + filtering

This looks really good to me. Rather than fully invert the plant, what we would like to do is now design a filter which allow this loop to have a high UGF and a high gain below 1 kHz. Anchal and Paco probably have gain requirements for this loop in the ALS-CAL paper they are writing. The loop would have the cavity transfer function, as well as the demod electronics for the green PDH loop.

In addition to the gain requirements, we would also like to have a phase margin > 30 deg, and a gain margin of > 10 dB.

 

  17243   Tue Nov 8 11:18:39 2022 RadhikaUpdateAUXAUX PZT transfer function fitting + filtering

Here I describe efforts to cancel the AUX laser PZT mechanical resonances from ~200 kHz-400kHz. While these may not be the resonances we end up wanting to suppress, I chose this region as an exercise because it contains the most significant peaks.

The PZT transfer measurement was taken on 09/06 by myself and Anchal. The Moku:Go outputted a swept-sine (1kHz - 1MHz) I sent to the AUX laser PZT. The beat note between the AUX and frequency-doubled PSL was sent to the DFD, and the I and Q channels were routed back as input to the Moku:Go. We also took a calibration transfer function of the Moku:Go, sending output 1 to inputs 1 and 2. 

Almost all of the signal was present in the I channel, so I proceeded to use the I data for fitting/next steps. After normalizing the measured frequency response by the calibration measurement (and adjusting for the calculated time delays in the loop - see [17131]), I fit the resulting data using vectfit [Attachment 1]. I supplied the function with n_poles=16, which in reality fit for 16 complex pairs of poles. This complexity of fit was not necessary to capture the 3 prominent peaks, but would likely be needed to fit any of the more heavily-damped resonances. 

I chose to invert all fitted poles between 200 kHz and 367 kHz and the corresponding fitted zeros. The result of this filter applied to the original frequency response data can be seen in Attachment 2, where the blue-shaded region contains the inverted poles/zeros. In total, 9 pairs of poles and 9 pairs of zeros were inverted. 

Next steps:

- Determine which resonances we want to suppress
- Send filter coefficients to Moku:Go (write scripts to streamline)
- Set up Moku:Go in series in loop; take TF measurement
  17242   Tue Nov 8 10:35:26 2022 AnchalUpdateSUSIMC F2A test

This time the test was succesful but I have reverted MC3 f2a filters back to with Q=3, 7, and 10. The inital part of the test is still useful though. I'm attaching amplitude spectral density curves for WFS control points and C1:IOO-MC_F_DQ in the different configurations. The shaded region is the 15.865 percentile to 84.135 percentile bounds of the PSD data. This corresponds to +/- 1 sigma percentiles for a gaussian variable. Also note that in each decade of freqeuncy, the FFt bin width is different such that each decade has 90 points (eg 0.1 Hz bin width for 1Hz to 10 Hz data, 1 Hz binwidth  for 10 Hz to 100 Hz and so on.)

The WFS control points do not show any significant difference in most of the frequency band. The differences below 10 mHz are not averaged enough as this was 30min data segments only.

C1:IOO-MC_F_DQ channel also show no significant difference in 0.1 Hz to 20 Hz. Between 20-100 Hz, we see that higher Q filters resulted in slightly less noise but the effect of the filters in this frequency band should be nothing, so this could be just coincidence or maybe the system behaves better with hgiher Q filters. In teh lower frequency band, we would should take more data to average more after shortlisting on some of these f2a filters. It seems like MC1 Q=10 (red curve) filter performs very good. For MC2, there is no clear sign. I'm not sure why MC2 Q=3 curve got a big offset in low frequency region. Such things normally happen due to significant linear trend presence in signal.

I'm not sure what other channels might be interesting to look at. Some input would be helpful.

  17241   Tue Nov 8 10:23:42 2022 AnchalUpdateSUSMC3 damping loop step responses

I tuned MC3 local damping gains by looking at step responses in the DOF bassis. The same procedure was followed as described in 40m/17133. The gains were changed as following:

  Old Gains New Gains
C1:SUS-MC3_SUSPOS_GAIN 100 200
C1:SUS-MC3_SUSPIT_GAIN 24 10
C1:SUS-MC3_SUSYAW_GAIN 8 30
C1:SUS-MC3_SUSSIDE_GAIN 125 75

Attachement 1 shows the step responsed with the old gains and attachment 2 shows the step responses with the new gains. There is considerable cross coupling between SIDE OSEM and Coil to the face DOFs (POS, PIT, YAW). I think the high SIDE gain earlier was the culprit that started ringing with the f2a filters.

I agree that POS and SIDE step responses could look better but this was the best I was able to achieve. Further attempts by others is most welcome.

I also verified running f2a filter with Q=3 and it has been stably running with no ringing for past few minutes. More long term behavior is yet to be seen.C1:SUS-MC3_SUSSIDE_GAIN

  17240   Tue Nov 8 08:57:18 2022 ranaUpdateSUSMC2 OSEMs calibrated using MC_F

this measurement is not valid because of the coil to sensor coupling that I mentioned before. This is why I suggested you make the measurement at low frequencies (like 0.1 Hz).

Quote:

MC2 OSEM outputs were calibrated today using MC_F to get the output values in microns. This was done using this diaggui file. We drive a sine wave at 13 Hz and 5000 cts at C1:SUS-MC1_BIASPOS_EXC.

  17239   Mon Nov 7 21:57:42 2022 alexUpdateGeneralSensoray

I have made little progress in getting the sensoray driver installed on Donatella. I have confirmed that it is indeed the reason why none of the hardware is working. I am now working through changes on a virtual machine that is running Scientific Linux to find something that may work. If no progress is made soon, I will ensure that software for a replacement video encoder is able to be installed before requesting we order one.

  17238   Mon Nov 7 20:00:37 2022 AnchalUpdateSUSMC1 OSEMs output is weird

Following up, I tried to do this exercise with MC1 and MC3. While MC3 shows expected minute corrections to the previous value, MC1 showed much alrger corrections which led me to investigate further. Koji suggested to take a transfer function between MC_F and the OSEM outputs for both MC1 and MC3 the same way to see if something is different. And Koji was absolutely right. MC1 MC_F to OSEM outptu transfer function has a frequency dependent value, with a slope of ~0.6. Very weird. I'm holding on to doing OSEM calibration on both MC1 and MC3 until we know better on what is happening. See attached transfer functions.

Reminder, MC1 is using new satellite amplifier box, but OSEM outputs are read through single ended PDMon outputs rather than the differential ended PD Output port, because rest of the MC1 electronics is still last generation and the whitening board for them take in single ended input.

  17237   Mon Nov 7 19:53:12 2022 AnchalUpdateSUSMC2 OSEMs calibrated using MC_F

MC2 OSEM outputs were calibrated today using MC_F to get the output values in microns. This was done using this diaggui file. We drive a sine wave at 13 Hz and 5000 cts at C1:SUS-MC1_BIASPOS_EXC. This signal is read at C1:IOO-MC_F and the C1:SUS-MC1_ULSEN_OUT and similar OSEM output channels. MC_F calibration in Hz is assumed to be correct. In diaggui, a calibration conversion of 4.8075e-14 m/Hz is added to convert MC_F signal into meters. This is then used to calibrate the OSEM outputs and necessary gain changes were done in teh cts2um filter module in all of the face OSEM input filters. Following are the new gains:

  • UL 0.36 -> 0.28510
  • UR 0.36 -> 0.26662
  • LL 0.36 -> 0.34861
  • LR 0.36 -> 0.71575

Note that this measurement was done after the coil strengths for MC2 have been balanced in 40m/17223.

  17236   Mon Nov 7 17:10:41 2022 AnchalSummaryBHDQPD installation seems like lost cause

The new QPD installation is turning out to be much more hard than it originally seemed. After finsing the cable, QPD and interface board, when I tried to use the cable, it seems like it is not powered or connected to the interface board at all. I tried both QPD ports on the QPD interface board (D990692) both none worked. I measured the output pins of IDC style connector on the interface board and they seem to have the correct voltages at the correct pins. But when I connect this to our cable and go to the other side of the cable which is a DB25, use a breakout board and see for the voltages, I see nothing. The even pins which are supposed to be connected to each other and to GND are also not connected to each other. I pulled out teh DB25 end of the cable and brought it close to the IDC end to do a direct conitnuity test and this test failed too.

I even foudn another IDC end of a spare QPD cable hanging near 1Y2, but could not find the other end of this cable either.

So moving forward, we have following options:

  • Assume the cable is bad and try to find another cable.
    • It is very hard to find these cables in the lab. Koji and I have already done one sweep.
  • Source 26 pin 2 row IDC female connector and make a ribbon cable ourselves.
    • We probably will need to buy this connector for this to work.
    • Downs has apparantely thrown away all IDC connectors.
  • Use clean room QPD that does not use this interface.
    • The QPD used in clean room tests for suspension hanging used a different board.
    • This board is just lying on the floor, mounted on one slot of a big 6U chassis.
  • Use AS WFS
    • If used in current position, it would not be useful for BHD port or tuning LO1, LO2, and AS4.
    • If taken to ITMY oplev table, we will need to source LO and opther connections right at the PD head as that is design for these PDs.
  • Use GigE camera
    • We can replace the analog camera with a GigE camera on the BHD output.
    • We will need to revide GigE camera code and medm screens for this, and run an ethernet cable to ITMY oplev table.
  • Someone verify that the cable is indeed not working as I am seeing above. If I am wrong, I would be a happier person.
  17235   Mon Nov 7 16:14:43 2022 AnchalUpdateSUSF2A filter with Q=1, 0.3 stable with MC3

I tired running for a few hours F2A filter with Q=1 and for maybe 30 min Q=0.3 on MC3 today and that keeps the suspension stable. So I'm going to put in Q=0.3 at FM1, Q=0.7 at FM2, and Q=1 filter on FM3. I am setting the test again for tonight with some modifications. Now the separate set of filters will be tried one by one on the three different optics so that we know the best Q filter for each optic. It is set to trigger at 1 am tonight in tmux sessions f2aMC1Test, f2aMC2Test, f2aMC3Test on rossa. To cancel the test or interrupt, do:

tmux a -t f2aMC1Test
ctrl+C
exit
tmux a -t f2aMC2Test
ctrl+C
exit
tmux a -t f2aMC3Test
ctrl+C
exit
  17234   Mon Nov 7 14:38:59 2022 AnchalUpdateSUSMC3 coil strengths rebalanced

I checked again today by sending excitation at POS and reading back from C1:IOO-MC_TRANS_P and C1:IOO-MC_TRANS_Y. I found that there was some POS->PIT and POS->YAW coupling remaining that I was to remove by same method. New coil gains are:

C1:SUS-MC3_ULCOIL_GAIN: 0.942
C1:SUS-MC3_URCOIL_GAIN: -1.042
C1:SUS-MC3_LRCOIL_GAIN: 1.076
C1:SUS-MC3_LLCOIL_GAIN: -0.94

 

  17233   Mon Nov 7 12:37:26 2022 KojiUpdateGeneralBorrowed the fiber tester for the OMC lab

I am borrowing the fiber illuminator / fiber tester / VisiFault for the OMC lab. It has been stored in the top drawer at the center work bench.

==> Returned

  17232   Mon Nov 7 12:02:15 2022 AnchalUpdateSUSIMC test with PSL shutter closed.

Following configurations were kept today morning:

Start Time Stop Time HEPA PSL Shutter MC1 f2a MC2 f2a MC3 f2a MC3 ringing Notes

1351879503

10:04:45 PST
18:04:45 UTC

1351879797

10:09:39 PST
18:09:39 UTC

ON OFF ON ON ON NO Found later that MC3 started ringing at 1351879797

1351879797

10:09:39 PST
18:09:39 UTC

1351881325

10:35:07 PST
18:35:07 UTC

ON OFF ON ON ON YES This is the duration when MC3 was ringing

1351881325

10:35:07 PST
18:35:07 UTC

1351882257

10:50:39 PST
18:50:39

OFF OFF ON ON ON YES We turned off HEPA filter during this time, MC3 was still ringing.

1351882257

10:50:39 PST
18:50:39 UTC

1351882346

10:52:08 PST
18:52:08 UTC

OFF OFF ON ON ON NO I noticed MC3 rining and reset f2a filter by turning it off, waiting for it to damp down and restarting it.

1351882346

10:52:08 PST
18:52:08 UTC

1351883406

11:09:48 PST
19:09:48 UTC

OFF OFF ON ON ON YES MC3 started ringing again soon.

1351883406

11:09:48 PST
19:09:48 UTC

1351885490

11:44:32 PST
19:44:32 UTC

OFF OFF ON ON OFF NO MC3 f2a filters turned off due to repeated failure.

1351885490

11:44:32 PST
19:44:32 UTC

1351887487

12:17:49 PST
20:17:49 UTC

ON OFF ON ON OFF NO Turned ON HEPA for completeness of data.

 

  17231   Mon Nov 7 11:24:05 2022 AnchalUpdateSUSF2A filters on MC1, MC2, and MC3 set to test at 1 am

This test was not successfull as IMC lost lock during the f2A filter trial. However, we do have 1 hour off data when all f2A filters were turned off in between following GPS times:

start gpstime: 1351584077

stop gpstime: 1351587677

After this gpstime, the f2A filters were turned ON for all IMC optics. After about 2000 seconds of no issues, the MC3 suspension suddenly rung up 1 Hz oscillations around 1351590720 gpstime. See attachment one for noise spectra of local damping error signals for MC3 before and after this event. See attachment 2 for time series of this event.

So, after this point, MC3 remained rung up and IMC remained unlocked, so no WFS signals are meaningful after gpstime 1351590720.

I have seen this happening out of nowhere to MC3 today too when PSL shutter was closed and only thing interacting with MC3 was the local damping loop. This suggests that some glitch event happens in MC3 which is not taken well by the f2a filter on it. The ringing goes down as soon as we turn OFF the f2a filter. The other optics show no such signs.

We'll do more tests in future to figure out the issue. For now, MC3 f2a filters are kept off. Maybe we need custom filter for MC3 rather than the design value default filter we are using right now. I'm attaching foton bode plot for MC3 f2a filters for verification that correct filters are in place.

  17230   Mon Nov 7 08:36:10 2022 JCUpdateSUSIMC out of alignment -- f2A failure

[Paco, JC]

We came in this morning and noted the IMC was grossly misaligned, with MC3 still damped but with >= 100 rms motion in all coil monitors no (a lot but not enough to trip the WD)... Turning off the WFS didn't do much so it was obviously an issue with the recent f2A output filters, so we turned all off (though only MC3 had this excess motion). After this we aligned IMC, engaged the lock and turned WFS back on.

There was no elog about f2A beyond this test scheduled to run Friday, I guess the filters were meant to stay on long term?

  17229   Fri Nov 4 15:43:05 2022 JCUpdateLab OrganizationNew Toolbox Organization

The new tool box has came in! I have spent serious time organizing these tools and making it look pretty, so please take care of it! A few things I would like to note.

  • The tool box has a power strip, so this is now where we will be charging the power tools. There is also a selected cabinet for the fully charged batteries, bits, and the power tools themselves. 
  • The cart next to the tool box had to turned 90 degrees in order to fit the tool box in. While moving this, I noticed this cart is piled with random stuff, let’s tackle this on Wednesdays clean up.
  • The tools from this tool box are specifically assigned to the VERTEX area (and the X-End until we get another toolbox.) Please return all the tools in their right tool box and cabinet after usage. 
  • The heavier duty equipment such as pipe wrenches, hammers, and power tools will remained stored here in the bottom cabinets. 

Hope you all like it!

  17228   Thu Nov 3 20:07:01 2022 AnchalSummaryBHDAS1 coil balancing required

[Anchal, Koji]

The LO phase lock that was achieved lasts for a short time because as soon as a considerable POS offset is required on AS1, the POS to PIT coupling causes the AS-LO overlap to go away. To fix this, we need to balance the coil outputs of AS1 atleast and add the f2a filters too. To follow similar method as used for IMC optics, we need a sensor for true PIT and YAW motion of AS1. Today, we looked into the possiblity of installing a QPD at BHD output path to use it for AS1, AS4, LO1, LO2, SR2, PR2 and PR3 coil strength tuning. We found a QPD which is mentioned in this elog. We found QPD interface boards setup for old MCT and MC Refl QPDs (dating before 2008). We also found the old IP-POS QPD cable between 1Y2 and BS Oplev table. We took out this cable from BS oplev end upto ITMY opleve table, put on a new DB25 connector on the ribbon cable, and connected it to the QPD on ITMY table. There is still following work to be done:

  • Move back the BHD port camera a few inches and the lends with it.
  • Put a beamsplitter in the beam going to this camera and align it to fall on the new QPD.
  • Connect the the other end of cable to QPD interface board on 1Y2.
  • Take the lemo outputs or IDC outputs from the QPD interface board to spare ADC inputs (maybe on LSC I/O chassis or SUS2 I/O chassis).
  • Make changes in RTS model to read this QPD input.
  • Enjoy balancing the coils on the 7 new suspensions.
  17227   Thu Nov 3 17:36:00 2022 AnchalUpdateSUSF2A filters on MC1, MC2, and MC3 set to test at 1 am
Quote:

 I'll setup some test of switching between different Q filters in future.

The f2A filters are set to test on IMC optics. The script used is testF2AFilters.py. The script is running on rossa in a tmux session named f2aTest. It will trigger at 1 am, Nov 4th 2022. First the script will turn off all F2A filters on IMC optics, wait for an hour, then it will try out the three F2A filter sets with different Q values, one at a time, for one hour each. So the test should last for roughly 4 hours. The gpstime stamps will be written in a logfile that can be used later to readback noise performance of IMC with different filter. The script has a try-except failsafe to revert things to original state if something fails. To stop the script from triggering or stop it during runtime, do following on rossa:

tmux a -t f2aTest
ctrl+C
exit

 

  17226   Thu Nov 3 17:01:47 2022 ChrisUpdateCDSSLwebview fixed

The simulink webview generation cronjob on megatron was not working, apparently due to a matlab license problem. I switched it to matlab 2019a (the current CDS standard), and added a script to generate medm screens from the webview. This can help with keeping hand-made screens up to date, or be a substitute for hand-made screens if the model is simple.

  17225   Thu Nov 3 16:22:11 2022 AnchalUpdateSUSMC3 coil strengths balanced

Balanced MC3 coil strengths using the same method.

Final coil strengths found:

C1:SUS-MC3_ULCOIL_GAIN: 0.942
C1:SUS-MC3_URCOIL_GAIN: -1.038
C1:SUS-MC3_LRCOIL_GAIN: 1.075
C1:SUS-MC3_LLCOIL_GAIN: -0.945

 

  17224   Thu Nov 3 16:00:58 2022 alexSummaryGeneralSensoray updates

I am currently working on getting the driver reinstalled on Donatella for the sensoray. An issue keeps arising that will not allow me to run "make" successfully in the unzipped driver folder. Will continue to remedy this.

This is why there is no light showing up on the device while plugged in. The computer does see the device, but does not show its model due to the inability for it to communicate without the driver.

 

-Alex

  17223   Thu Nov 3 14:42:57 2022 AnchalUpdateSUSMC2 coil strengths balanced

Balanced MC2 coil strengths using the same method.

Final coil strengths found:

C1:SUS-MC2_ULCOIL_GAIN: 1.074
C1:SUS-MC2_URCOIL_GAIN: -0.979
C1:SUS-MC2_LRCOIL_GAIN: 0.97
C1:SUS-MC2_LLCOIL_GAIN: -0.976

ELOG V3.1.3-