40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 226 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  15260   Fri Mar 6 16:33:11 2020 gautamUpdateIOOExcess laser frequency noise

I did some preliminary debugging of this, and have localized the problem to the output path (after MC slow) on the IMC Servo card. Basically, I monitored the spectrum of the ALS beat frequency fluctuations under a few different conditions: 

  • With the BNC to the NPRO PZT disconnected, there is no noise. So the laser and the FSS phase correction EOM (which the ALS beat pickoff sees) are not responsible.
  • With the input to the Koji summing box disconnected, still no excess - so the summing box + Thorlabs HV driver are not responsible.
  • With the TTFSS output connected to the summing box, but with the input switch to the TTFSS box disabled (isolating the on-PSL table parts of the FSS system), still no excess.
  • With the input to the TTFSS enabled, and the BNC output of the IMC Servo card disconnected at 1X2, still no excess.
  • Finally, when I connect the BNC cable, the excess starts to show up.

Toggling C1:IOO-MC_FASTSW, which supposedly isolates the post-MC slow (a.k.a. MCL) part of the servo, I see no difference. I am also reasonably confident this switch itself works, because I can break the IMC lock by toggling it. So pending a more detailed investigation, I am forced to conclude that the problem originates in the part of the IMC servo board after the MCL pickoff. Some cabling was removed at 1X2 on Tuesday between the times when there was no excess and when it showed up, but it's hard to imagine how this could have created this particular problem.

  15261   Sat Mar 7 15:18:30 2020 gautamUpdateSUSEQ tripped some suspensions

An earthquake around 330 UTC (=730pm yesterday eve) tripped ITMX, ITMY and ETMX watchdogs. ITMX got stuck. I released the stuck optic and re-enabled the local damping loops just now.

Attachment 1: EQ_6Mar.png
EQ_6Mar.png
  15266   Wed Mar 11 18:12:53 2020 gautamSummaryPSLWFS Demod board modifications

[koji, gautam]

Attachment #1 shows the relevant parts of the schematic of the WFS demod board (not whitening board). 

  • The basic problem was that the switchable gain channels were not accounted for in the Acromag channel list 😒.
  • What this meant was that the DC gain was set to the default x100 (since the two DG211s that provide the switchable x10 and x1 gain options had their control logic pins pulled up to +5V because these pins weren't connected to any sinking BIO channel).
  • Rather than set up new connections to Acromags inside the chassis (though we have plenty of spares), Koji and I decided to make these fixed to x1 gain.
  • The actual fix was implemented as shown in the annotated schematic. There are some pictures 📷 of the PCB in the DCC entry linked above.
  • Amusingly, this board will now require a sourcing BIO unit if we want to still have the capability of switching gains.

Before removing the boards from the eurocrate: 

  • I dialled down the Kepco HV supplies
  • disconnected all the cabling to these boards after noting down cable numbers etc.

After Koji effected the fix, the boards were re-installed, HV supplies were dialled back up to nominal voltage/currents, and the PMC/IMC were re-locked. The WFS DC channels now no longer saturate even when the IMC is unlocked 👏 👏 . I leave it to Yehonathan / Jon to calibrate these EPICS channels into physical units of mW of power. We should also fix the MEDM screen and remove the un-necessary EPICS channels.

Later in the evening, I took advantage of the non-saturated readbacks to center the beams better on the WFS heads. Then, with the WFS servos disabled, I manually aligned the IMC mirrors till REFLDC was minimized. Then I centered the beam on the MC2 transmission QPD (looking at individual quadrants), and set the WFS1/2 RF offsets and MC2 Trans QPD offsets in this condition.

Quote:

WFS DC channels are saturating when the IMC is unlocked.

Attachment 1: D980233-B_Mar2020Mods.pdf
D980233-B_Mar2020Mods.pdf
  15268   Thu Mar 12 01:33:21 2020 gautamUpdateLSCResuming locking activities

It's been a while since I've attempted any locking, so tonight was mostly getting the various subsystems back together.

  • Reconnected SR785 at 1Y3 to CM board for TF measurements.
  • POX/POY locking work fine
  • Locked PRMI (no ETMs) with carrier resonant, fixed PRM and BS alignment.
  • ALS-X noise is still elevated - disconnected it from the switchable delay line and now I'm directly piping the 3dB coupled part of the beat to the LO input of the demod board. But the high freq contribution to the RMS is still ~x2-x3 of what it was in November 2019. But the noise should only depend on the other (delayed) part of the beat (the discriminant is set thus).
  • With arms POX/POY locked, checked that there was no elevated coherence between POX_I/POY_I signals between 800 Hz - 1.2 kHz, which is where I see the excess noise in the laser frequency control signal (see Attachment #1). So this suggests that the IMC locking loop suppresses the noise to a level that the arm cavities don't witness it. It's probably still worth checking this out and fixing it, but it wasn't a show stopper.
  • Transition from POX/POY lock to ALS lock was smooth - I forgot to use the POX/POY photodiodes as OOL sensors to measure the noise in this config to see if it was elevated, but anyway, I was able to push on.
  • PRMI 3f locking worked okay.
  • Main thing I wanted to check today is to try the AO transition with a bit more IN1 gain on the CM board - hypothesis being the high frequency part of the CARM signal is buried in the noise if we run with -32dB of IN1 gain. 
    • Set IN1 gain to -10dB instead.
    • In this config, I checked that with the CARM offset at 0 (CARM still under purely ALS control), the CM_SLOW path was registering ~4000 cts pk-pk, which is healthily within the ADC's range.
    • I was able to engage the CARM_B path and semi-stabilize the arm powers (after compensating for the increased IN1 gain by decreasing the CARM_B gain) and turn on the integrator.
    • However, before I could try any AO path action, the IMC loses lock - too tired to try more tonight, I'll try again tomrrow.
Attachment 1: ExcessFreqNoise_LSC.pdf
ExcessFreqNoise_LSC.pdf
  15271   Thu Mar 12 12:44:34 2020 gautamUpdateGeneralPMC got unlcoked

Of course the reboot wiped any logs we could have used for clues as to what happened. Next time it'll be good to preserve this info. I suspect the local subnet went down.

P.S. for some reason the system logs are priveleged now - I ran sudo sysctl kernel.dmesg_restrict=0 on c1psl to make it readable by any user. This change won't persist on reboot.

Quote:

I restarted the IOC but it didn't help.

I am now rebooting c1psl... That seemed to help. PMC screen seem to be working again. I am able to lock the PMC now.

  15272   Thu Mar 12 16:13:16 2020 gautamUpdatePSLTemperature sensors connected to Acromag

[jordan, gautam]

the long DB25 cable to connect the Acromag chassis to the temperature sensor interface box arrived. We laid it out today. This cable does the following:

  1. Supply the box with +/- 24 V DC from the chassis. The pin arrangement here is rather unfortunate (the +/-24 V DC and GND pins are in close proximity), so if you're not careful, you'll create a short as you plug this cable in (as we found out today). So the best practise is to power down the crate before connecting/disconnecting this cable. Jordan will label this accordingly tomorrow.
  2. Pipe the "TAMB" and "TCAV" signals, corresponding to temperature sensors mounted to the PSL table-top and reference cavity exterior respectively, to the Acromags. We found during some initial testing that the "TAMB" signal was reaching the DB25 connector on the Acromag chassis, but wasn't going to any ADC channel - this was rectified.

Both signals now show up in the EPICS channels, but are noisy - I suspect this is because the return pin of the Acromag is not shorted to ground (this is a problem I've seen on the bench before). We will rectify this tomorrow as well.

We took this opportunity to remvoe the bench supply and temporary Acromag crate (formerly known as c1psl2) from under the PSL table. While trying to find some space to store the bench supply, we came across a damaged Oscilloscope in the second "Electronics" cabinet along the Y-arm, see Attachment #1. 

After this work, I found that the IMC autolocker was reliably failing to run the mcup script at the stage where the FSS gains are ramped up to their final values. I was, however, able to smoothly transition to the low-noise locked state if I was manipulating the EPICS sliders by hand. So I added an extra 2 seconds of sleep time between the increasing of the VCO gain to the final value and the ramping of the FSS gains in the mcup script (where previously there was none). Now the autolocker performs reliably.

Attachment 1: P_20200317_153736_vHDR_On_2.jpg
P_20200317_153736_vHDR_On_2.jpg
  15273   Fri Mar 13 00:32:38 2020 gautamUpdateLSCSome progress

Finally, some RF only CARM, see Attachment #1. During this time, DARM was also on a blend of IR and ALS control, but I couldn't turn the ALS path off in ~4-5 attempts tonight (mostly me pressing a wrong button). Attachment #2 shows the CARM OLTF, with ~2kHz UGF - for now, I didn't bother turning any boosts on. PRCL and MICH are still on 3f signals.

The recycling gain is ~7-8 (so losses >200ppm), but there may be some offset in some loop. I'll look at REFL DC tomorrow.

Can we please make an effort to keep the IFO in this state for the next week or two
- it really helped tonight I didn't have to spend 2 hours fixing some random stuff and could focus on the task at hand.

Attachment 1: RFonly_CARM.png
RFonly_CARM.png
Attachment 2: CARMTF.pdf
CARMTF.pdf
  15275   Fri Mar 13 14:28:39 2020 gautamUpdatePSLAdded tees to PMC Trans and REFL

I want to monitor the PMC TRANS and REFL levels on the PSL table - previously there were some cables going to the oscilloscope on the shelf but someone had removed these. I re-installed them just now. While there, I disconnected the drive to the AOM - there must've been some DC signal going to it because when I removed the cable, the PMC and IMC transmission were recovered to their nominal levels.

  15278   Tue Mar 17 01:22:03 2020 gautamUpdateLSCLocking updates

Summary:

No real progress tonight - I made it a bunch of times to the point where CARM was RF only, but I never got to run a measurement to determine what the DARM_B loop gain should be to make the control fully RF.

Details:

  • Touched up PMC alignment.
  • There were very few BNC cables available at the rack near SW corner of the PSL table - the short BNC cables are NOT meant to be daisy chained to make long cables to run along the arm, I removed all those.
  • Restored SR785 at LSC rack for CARM TF measurements.
  • I was able to get the CARM UGF ~5 kHz, but everytime I was trying to run a DTT swept sine to measure the ratio of DARM_B_IN1 / DARM_A_IN1, the lock was lost - not sure if this is because of the excitation injected or something else.
  • I'll probably give this another shot Wednesday eve.
  15279   Wed Mar 18 21:43:26 2020 gautamUpdateVACMain vol pressure jump

There was a jump in the main volume pressure at ~6pm PDT yesterday. The cause is unknown, but the pressure doesn't seem to be coming back down (but also isn't increasing alarmingly).

I wanted to look at the RGA scans to see if there were any clues as to what changed, but looks like the daily RGA scans stopped updating on Dec 24 2019. The c0rga machine responsible for running these scans doesn't respond to ssh. Not much to be done until the lockdown is over i guess...

Attachment 1: VacPresJump.png
VacPresJump.png
  15281   Thu Mar 19 03:33:28 2020 gautamUpdateLSCMore locking updates

Some short notes, more details tomorrow.

  1. I was able to make it to CARM on RF only ~10 times tonight.
  2. Highest stable circulating power was ~200 (recycling gain ~10) but the control scheme is still not finalized in terms of offsets etc.
  3. DARM to RF transition was never fully engaged - I got to a point where the ALS gain was reduced to <half its nominal value, but IMC always lost lock.
  4. CARM loop UGF of ~5 kHz was realized. I was also able to turn on a regular boost. But couldn't push the gain up much more than this. Should probably modify the boosts on this board, their corner frequencies are pretty high.
  5. The increased FSS flakiness post c1psl upgrade is definitely hurting this effort, there are periods of ~20-30mins when the IMC just wont lock.

Attachment #1 shows time series of some signals, from the time I ramp of ALS CARM control to a lockloss. With this limited set of signals, I don't see any clear indication of the cause of lockloss, but I was never able to keep the lock going for > a couple of mins.

Attachment #2 shows the CARM OLTF. Compared to last week, I was able to get the UGF a little higher. This particular measurement doesn't show it, but I was also able to engage the regular boost. I did a zeroth order test looking at the CM_SLOW input to make sure that I wasn't increasing the gain so much that the ADC was getting saturated. However, I did notice that the pk-to-pk error signal in this locked, 5kHz UGF state was still ~1000 cts, which seems large?

Attachment #3 shows the DTT measurement of the relative gains of DARM A and B paths. This measurement was taken when the DARM_A gain was 1, and DARM_B gain was 0.015. On the basis of this measurement, DARM_B (=AS55) sees the excitation injected 16dB above the ALS signal, and so the gain of the DARM_B path should be ~0.16 for the same UGF. But I was never able to get the DARM_B gain above 0.02 without breaking the lock (admittedly the lockloss may have been due to something else).

Attachment #4 shows a zoomed in version of Attachment #1 around the time when the lock was lost. Maybe POP_YAW experienced too large an excursion?

Some other misc points:

  • It was much quicker to acquire the PRMI lock with CARM held off resonance using the 1f signals rather than 3f - so I did that and then once the lock is acquired, transfer control to 3f signals (using CDS ramptime) before zeroing the CARM offset.
  • The whole process is pretty speedy - it takes <5mins to get to the CARM on RF only stage provided the PRMI lock doesn't take too long (the transition from POX/POY to ALS sequence takes <1min).
  • I am wondering what the correct way to set the offsets for the 3f error signals is? 
  • The arm buildup is strongly dependent on the DC alignment of the PRMI - the best buildups I got were when I tweaked the BS alignment after the CARM offset was zeroed.
Attachment 1: PRFPMI_lock.png
PRFPMI_lock.png
Attachment 2: CARMTF.pdf
CARMTF.pdf
Attachment 3: DARM_AvB.pdf
DARM_AvB.pdf
Attachment 4: lockLoss.png
lockLoss.png
  15282   Tue Mar 24 19:41:57 2020 gautamUpdateWienerSeismic feedforward for MCL

Summary:

I think the feedforward filters used for stabilizing MCL with vertex seismometers would benefit from a retraining (last trained in Sep 2015). 

Details:

I wanted to re-familiarize myself with the seismic feedforward methodology. Getting good stabilization of the PRC angular motion as we have been able to in the past will be a big help for lock acquisition. But remotely, it is easier to work with the IMC length feedforward (IMC is locked more often than the PRC). So I collected 2 hours of data from early Sunday morning and went through the set of steps (partially).

Attachment #1 shows the performance of a first attempt.

  • 1 hour of data was used as a training set, and another hour to validate the trained filter.
  • All the data was downsampled to 64 Hz.
  • The number of FIR filter taps was 32 seconds * 64 Hz. 
  • Going through some old elogs, there were a number of suggestions from various people about how the training should be done
    • There was a suggestion that pre-filtering the target signal by the (inverse) actuator TF (i.e. TF from MC2 drive to MCL) is beneficial, presumably because it gives the Wiener filter fitting fewer parameters to fit.
    • There was also suggestions that some frequency-dependent weighting of the target signal should be done (e.g. by bandpassing MCL between 0.1 Hz - 10 Hz) to emphasize subtraction in this band.
    • For this particular example, in my limited paramter space exploration, I found that neither of these measures had particularly significant impact.
  • In any case, the time-domain FIR filtering seems to approach the theoretical best possible performance (based on coherence information). 
  • I have not yet checked what the theoretical limit on subtraction will be based on the seismometer noise ASD.

Attachment #2 shows a comparison between the filter used in Attachment #1 and the filters currently loaded into the OAF system. 

  • In the band where significant subtraction is possible, there is some difference in the shape of the filter.
  • Why should this have changed? I guess there are multiple possibilities - seismometer recentering, signal chain changes, ...

Attachment #3 is the asd after implementing a time domain Wiener filter, while Attachment #4 is an actual measurement from earlier today - it's not quite as good as Attachment #3 would have me expect but that might also be due to the time of the day. 

Conclusions and next steps:

On the basis of Attachments #3 and #4, I'd say it's worth it to complete the remaining steps for online implementation: FIR to IIR fitting and conversion to sos coefficients that Foton likes (prefereably all in python). Once I've verified that this works, I'll see if I can get some data for the motion on the POP QPD with the PRMI locked on carrier. That'll be the target signal for the PRC angular FF training. Probably can't hurt to have this implemented for the arms as well.

While this set of steps follows the traditional approach, it'd be interesting if someone wants to try Gabriele's code which I think directly gives a z-domain representation and has been very successful at the sites.

* The y-axes on the spectra are labelled in um/rtHz but I don't actually know if the calibration has been updated anytime recently. As I type this, I'm also reminded that I have to check what the whitening situation is on the Pentek board that digitizes MCL.

Attachment 1: IMCseisFF.pdf
IMCseisFF.pdf
Attachment 2: filterComp.pdf
filterComp.pdf
Attachment 3: oldFilter_v_proposed.pdf
oldFilter_v_proposed.pdf
Attachment 4: MCL_ff_performance.pdf
MCL_ff_performance.pdf
  15283   Wed Mar 25 15:15:55 2020 gautamUpdateVACVacuum interlock code, N2 warning update

The email address in the N2 checking script wasn't right - I now updated it to email the 40m list if the sum of reserve tank pressures fall below 800 PSI. The checker itself is only run every 3 hours (via cron on c1vac).

Quote:

I reset the remote of this git repo to the 40m version instead of Jon's personal one, to ensure consistency between what's on the vacuum machine and in the git repo. There is now a N2 checker python mailer that will email the 40m list if all the tank pressures are below 600 PSI (>12 hours left for someone to react before the main N2 line pressure drops and the interlocks kick in). For now, the script just runs as a cron job every 3 hours, but perhaps we should integrate it with the interlock process

  15287   Tue Mar 31 09:39:41 2020 gautamUpdateCDSFoton for shaped noise injections

I'd like to re-measure the transfer function from driving MC2 position to the MC_L_DQ channel (for feedforward purposes). Swept sine would be one option, but I can't get the "Envelope" feature of DTT to work, the excitation amplitude isn't getting scaled as specified in the envelope, and so I'm unable to make the measurement near 1 Hz (which is where the FF is effective). I see some scattered mentions of such an issue in past elogs but no mention of a fix (I also feel like I have gotten the envelope function to work for some other loop measurement templates). So then I thought I'd try broadband noise injection, since that seems to have been the approach followed in the past. Again, the noise injection needs to be shaped around ~1 Hz to avoid knocking the IMC out of lock, but I can't get Foton to do shaped noise injections because it doesn't inherit the sample rate when launched from inside DTT/awggui - this is not a new issue, does anyone know the fix?

Note that we are using the gds2.15 install of foton, but the pre-packaged foton that comes with the SL7 installation doesn't work either.

Update:

The envelope feature for swept-sine wasn't working because i specified the frequency grid in the wrong order apparently. Eric von Reis has been notified to include a sorting algorithm in future DTT so that this can be in arbitrary order. fixing that allows me to run a swept sine with enveloped excitation amplitude and hence get the TF I want, but still no shaped noise injections via foton 😢 

  15289   Tue Mar 31 23:54:57 2020 gautamUpdateCDSFoton for shaped noise injections

The problem is that foton does not inherit the model sample rate when launched from DTT/awggui. This is likely some shared/linked/dynamic library issue, the binaries we are running are precompiled presumably for some other OS. I've never gotten this to work since we changed to SL7 (but I did use it successfully in 2017 with the Ubuntu12 install).

Quote:

do you really mean awggui cannot make shaped noise injections via its foton text box ? That has always worked for me in the past.

If this is broken I'm suspicious there's been some package installs to the shared dirs by someone.

  15291   Thu Apr 2 15:53:01 2020 gautamUpdateASCPRMI 1f locked for collecting feedforward data

This afternoon, I kept the PRM locked for ~1hour and then measured transfer functions from the PRM angular actuators to the POP QPD spot motion for pitch and yaw between ~1pm and 4pm. After this work, the PRM was misaligned again. I will now work on the feedforward filter design.

  15296   Fri Apr 3 17:15:53 2020 gautamUpdateASCPOP angular FF filters trained and tested

Summary:
Using the data I collected yesterday, the POP angular FF filters have been trained. The offline time-domain performance looks (unbelievably) good, online performance will be verified at the next available opportunity(see update).

Details:

The sequence of steps followed is the same as that done for the MCL FF filters. The trace that is missing from Attachment #1 is the measured online subtraction. Some rough notes:

  • The "target" channels for the subtraction are the POP QPD PIT/YAW signals, normalized by the QPD sum. For the time that the PRMI was locked yesterday, the QPD readouts suggested that the beam was well centered on the QPD, but the POP QPD (OT-301) doesn't give me access to individual quadrant signals so I couldn't actually verify this.
  • I used 64s impulse time on the FIR filter for training. Maybe this is too long, but anyways, the calculation only takes a few seconds even with 64^2 taps.
  • I found that the Levinson matrix algorithm sometimes failed for this particular dataset. I didn't bother looking too much into why this is happening, the brute force matrix inversion took ~4 times longer but still was only ~5 seconds to calculate the optimal filter for 20 mins of training data sampled at 64 Hz.
  • The actuator TF was measured with >0.9 coherence between 0.3 Hz - 10 Hz and fitted, and the fit was used for subsequent analysis. Fit is shown in Attachment #2.
  • FIR to IIR fitting took considerable tweaking, but I think I got good enough fits, see Attachments #3, #4. In fact, there may be some benifit to making the shape smoother outside the subtraction band but I couldn't get IIRrational to cooperate. Need to confirm that this isn't re-injecting noise.

Update Apr 5 1145pm:

  • Attachment #1 has now been updated to show the online performance. The comparison between the "test" and "validation" datasets aren't really apple-to-apple because they were collected at different times, but I think there's enough evidence here to say that the feedforward is helping.
  • Attachment #5 shows that the POP DC (= PRC intracavity buildup) RMS has been stabilized by more than x2. This signal wasn't part of the training process, and I guess it's good that the intracavity power is more stable with the feedforward on. Median averaging was used for the spectral densities, there were still some abrupt glitches during the time this dataset was collected.
  • The next step is to do the PRFPMI locking with all of these recently retuned feedforward loops engaged and see if that helps things.
Quote:

This afternoon, I kept the PRM locked for ~1hour and then measured transfer functions from the PRM angular actuators to the POP QPD spot motion for pitch and yaw between ~1pm and 4pm. After this work, the PRM was misaligned again. I will now work on the feedforward filter design.

Attachment 1: FIRvIIR.pdf
FIRvIIR.pdf
Attachment 2: PRM_act_calib.pdf
PRM_act_calib.pdf
Attachment 3: IIR_fit_to_FIR_PIT.pdf
IIR_fit_to_FIR_PIT.pdf
Attachment 4: IIR_fit_to_FIR_YAW.pdf
IIR_fit_to_FIR_YAW.pdf
Attachment 5: POP_DC_comparison.pdf
POP_DC_comparison.pdf
  15298   Mon Apr 6 16:46:40 2020 gautamUpdateASCPOP angular FF filters trained and tested

I don't have a recent measurement of the optical gain of this config so I can't undo the loop, but in-loop performance doesn't suggest any excess in the 10-100 Hz band. Interestingly, there is considerable improvement below 10 Hz. Maybe some of this is reduced A2L noise because of the better angular stability, but there is also improvement at frequencies where the FF isn't doing anything, so could be some bilinear coupling. The two datasets were collected at approximately the same time in the evening, ~5pm, but on two different days.

Quote:

I wonder how much noise is getting injected into PRC length at 10-100 Hz due to this. Any change the PRC ERR?

Attachment 1: PRCL_comparison.pdf
PRCL_comparison.pdf
  15308   Mon Apr 20 17:49:58 2020 gautamUpdateGeneralSome housekeeping
  • Empty N2 replaced. 
  • Logged back into zita and started the StripTool traces (even though we keep the TV off nowadays).
  • c1susaux acro-crate power cycled to re-enable PRM suspension control (all other vertex optics also now respond to slow bias voltage sliders being moved).
  • c1iscaux needed a hard reboot as it wasn’t seen on martian. I power cycled the crate for good measure.
  • Marconi turned back on with correct frequency/amplitude.
  • c0rga is now seen again on martian network. I re-enabled the RGA scanning so that it takes a scan every morning at 4am. 
  • The forepumps for TP2/TP3 are noisier than I remember. The former has ~10,000 hrs on the clock. How often does the tip seal replacement need to happen?
  • HV supplies for ASX/ASY PZTs re-energized.
  • IFO re-aligned for locking.
  • c1oaf and c1daf models restarted. c1oaf required the usual start/stop/start sequence to make the DAQ errors go away, and luckily the FE didn’t crash when the model was unloaded.
  • POX/POY/PRMI 1f carrier/green locking all was smooth.
  • For some reason, the PRC angular FF filters i trained no longer do anything good (but MCL is still good). collected 20mins of PRMI 1f locked data for investigations.
Update 21 Apr 2020 1200: Looking at Attachments #1 and #2, the spectra for motion sensed by the POP QPD does indeed look very different on Apr 6 vs Apr 20. Could be some interference from Oplev loop or maybe some EPICS values didn't get reset correctly, needs more investigation. It doesn't seem reasonable to me that the plant changes by so much (spectra were taken at similar times of the day, ~5pm).
Update 22 Apr 2020 1500: As suspected, the PRM oplev was disabled for whatever reason. Re-enabling it, I recovered the good performance from two weeks ago. ✅ 
Attachment 1: fDomainWF_Apr06.pdf
fDomainWF_Apr06.pdf
Attachment 2: fDomainWF_Apr20.pdf
fDomainWF_Apr20.pdf
  15309   Wed Apr 22 13:52:05 2020 gautamUpdateDetCharSummary page revival

Covid 19 motivated me to revive the summary pages. With Alex Urban's help, the infrastructure was modernized, the wiki is now up to date. I ran a test job for 2020 March 17th, just for the IOO tab, and it works, see here. The LDAS rsync of our frames is still catching up, so once that is up, we can start the old condor jobs and have these updated on a more regular basis.

  15310   Wed Apr 22 17:29:14 2020 gautamUpdatePSLFSS debugging attempts

Summary:

On Monday, I hooked up an AG4395 to the PMC error point (using the active probe). The idea was to take a spectrum of the PMC error point every time the FSS PC drive RMS channel indicated an excursion from the nominal value. An initial look at the results don't suggest that this technique is particularly informative. I'll have to think more about a workaround, but please share your ideas/thoughts if you have some.

Also, the feature in the spectrum at ~110 kHz makes me suspect some kind of loop instability. I'll measure the IMC loop OLG at the next opportunity.

Details:

  • The PMC servo bandwidth is ~2 kHz, so above this, the PMC error point should be a faithful monitor of the PSL frequency noise, provided the sensing noise is low enough.
  • The PMC error point sensing noise is ~100nV/rtHz (I'm monitoring this straight after the Minicircuits mixer+bandpass filter that we are using as a demodulator). This corresponds to ~2 Hz/rtHz, using the ~10 MHz/V PDH discriminant calibration from January. Seems consistent with this elog.
  • I was hoping to see if there was a particular frequency band in which the noise gets elevated, and if the crossover frequency is a few kHz and the IMC servo BW is ~110 kHz, I would have expected this to be in the 10-100 kHz region. Possibly my frequency resolution isn't good enough? But with the Agilent, doing a finer grid would mean a longer measurement time, in which case the IMC might lose lock before the measurement is done.
  • But, as shown in Attachment #1, there isn't any clear evidence, from the ~20 excursions that were recorded last night. The color of the line is meant to be indicative of the average value of the PC drive RMS channel in the measurement time.
  • A significant bottleneck in this whole process is that it takes ~1 minute to initiate the GPIB measurement, and download the data. The pseudo-code I used is:
    • While the IMC is locked, watch PCdrive RMS EPICS channel's "ALARM" state, which becomes non-zero when the PCdrive RMS exceeds 1 V (this is how it is defined in the EPICS db record right now).
    • Make sure this isn't a transient feature - I do this by waiting 5 seconds and checking that the ALARM flag is still flagged.
    • Initiate a AG4395 measurement over GPIB - I use the measurement span of 1 kHz - 1 MHz with a BW/span ratio of 0.1%, 5 averages.
    • Check that the IMC is still locked (if it got unlocked while the measurement was made, presumably the measurement is garbage).
  • Is there a better monitor of the laser frequency noise? I can imagine using POX/POY which I think have a lower electronics noise floor but I'm not sure if that's true at 100 kHz and having the arms locked in addition to the IMC seems more complicated...
  • Since we are planning a laser upgrade, is this worth spending more time on? I may leave the measurement running on pianosa in a tmux session while I'm not in the lab...
Attachment 1: FSSspec.pdf
FSSspec.pdf
  15315   Fri May 1 01:49:55 2020 gautamUpdateALSASY commissioning

Summary:

It appears that the EY green steering PZTs have somehow lost their bipolar actuation range. I will check on them the next time I go to the lab for an N2 switch.

Details:

  • Yuki installed the EY green PZTs and did some initial setup of the RTCDS model. 
  • But we don't have a functional dither alignment servo yet, which is mildly annoying. So I thought I'll finally finish my SURF project.
  • There were several problems with the signal flow, MEDM screens etc.
  • I rectified these, and set up some operational scripts, burt snapshots etc in $SCRIPTS/ASY. The c1asy and c1als models were also modified, recompiled and restarted, everything appears to have come back online smoothly.
  • The LO frequencies/amplitudes, demod filter gains and demod phases were chosen to have a signal mostly in the _I quadrature of the demodulated signal when the alignment is slightly disturbed from optimal (monitored after the post-demod LPF).
  • While trying to close the integrator loops, I found that I appear to only have monopolar actuation ability (positive DAC output changes the alignment, negative DAC output does nothing).

Could be that the power outage busted something in the drive electronics. 

  15316   Fri May 1 22:44:17 2020 gautamUpdateALSASY M2 PZT damaged

I went to EY and saw that the HV power supply was only putting out 50 V and had hit the current limit of 10 mA (nominally, it should be 100 V, drawing ~7mA). This is definitely a problem that has come up after the power shutdown event, as when I re-energized the HV power supply at EY, I had confirmed that it was putting out the nominal values (the supply was not labelled with these nominal numbers so I had to label it). Or maybe I broke it while running the dither alignment tests yesterday, even though I never drove the PZTs above 50 Hz with more than 1000cts (= 300 mV * gain 5 in the HV amplifier = 1.5 V ) amplitude.

The problem was confirmed to be with the M2 PZT (YAW channel) and not the electronics by driving the M2 PZT with the M1 channels. Separately, the M1 PZT could be driven by the M2 channels. I also measured the capacitance of the YAW channels and found it to be nearly twice (~7 uF) of the expected 3 uF - this particular PZT is different from the three others in use by the ASX and ASY system, it is an older vintage, so maybe it just failed? 😔 

I don't want to leave 100 V on in this state, so the HV supply at EY was turned off. Good GTRY was recovered by manual alignment of the mirror mounts. If someone has a spare PZT, we can replace it, but for now, we just have to live with manually aligning the green beam often.

Quote:

Could be that the power outage busted something in the drive electronics. 

  15318   Tue May 5 23:44:14 2020 gautamUpdateASCIMC WFS

Summary:

I've been thinking about the IMC WFS. I want to repeat the sort of analysis done at LLO where a Finesse model was built and some inferences could be made about, for example, the Gouy phase separation b/w the sensors by comparing the Finesse sensing matrix to a measured sensing matrix. Taking the currently implemented output matrix as a "measurement" (since the IMC WFS stabilize the IMC transmission), I don't get any agreement between it and my Finesse model. Could be that the model needs tweaking, but there are several known issues with the WFS themselves (e.g. imbalanced segment gains).

Building the finesse model:

  • I pulled the WFS telescopes from Andres elogs/SURF report, which I think was the last time the WFS telescopes were modified.
  • The in-vacuum propagation distances were estimated from CAD diagrams.
  • According to my model, the Gouy phase separation between the two WFS heads is ~70 degrees, whereas Andres' a la mode simulations suggest more like 90 degrees. Presumably, some lengths/lenses are different between what I assume and what he used, but I continue the analysis anyway...
  • The appropriate power attenuations were placed in each path - one thing I noticed is that the BS that splits light between WFS1 and WFS2 is a 30/70 BS and not a 50/50, I don't see any reason why this should be (presumably it was to do with component availability). see below for Rana's comments.

Simulations:

  • The way the WFS servos are set up currently, the input matrix is diagonal while the output matrix encodes the sensing information.
  • In finesse, I measured the input matrix (i.e. response sensed in each sensor when an optic is dithered in angle). The length is kept resonant for the carrier (but not using a locking signal), which should be valid for small angular disturbances, which is the regime in which the error signals will be linear anyways.
  • Then I inverted the simulated sensing matrix so as to be able to compare with the CDS output matrix. Note that there is a relative gain scaling of 100 between the WFS paths and the MC2T QPD paths which I added to the simulation. I also normalized the columns of the matrix by the largest element in the column, in an attempt to account for the various other gains that are between the optical sensing and the digitizaiton (e.g. WFS demod boards, QPD transimpedance etc etc).
  • Attachment #1 shows the comparison between simulation and measurement. The two aren't even qualitatively similar, needs more thought...

Some notes about the WFS heads:

  • The transimpedance resistor is 1.5 kohms. With the gain stages, the transimpedance gain is nominally 37.5 kohms, and 3.75 kohms when the attenuation setting is engaged (as it is for 2/4 quadrants on each head).
  • Assuming a modulation depth of 0.1, the Johnson noise of the transimpedance resistor dominates (with the MAX4106 current noise a close second), and these heads cannot be shot noise limited when operating at 1 W input power (though of course the situation will change if we have 25 W input).
  • The heads are mounted at a ~45 deg angle, mixing PIT/YAW, but I assume we can just use the input matrix to rotate back to the natural PIT/YAW basis.

Update 215 pm 5/6: adding in some comments from Rana raised during the meeting:

  1. The transimpedance is actually done by the RLC network (L6 and C38 for CH 3), and not 1.5 kohms. It just coincidentally happens that the reactance is ~1.5 kohms at 29.5 MHz. Note that my LTspice simulation using ideal inductors and capacitors still predicts ~4pA/rtHz noise at 29.5 MHz, so the conclusion about shot noise remains valid I think... One option is to change the attenuation in this path and send more light onto the WFS heads.
    The transimpedance gain and noise are now in Attachment #2. I just tweaked the L values to get a peak at 29.5 MHz and a notch at twice that frequency. For this I assumed a photodiode capacitance of 225pF and the shown transimpedance gain has the voltage gain of the MAX4106 stages divided out. The current noise is input referred.
  2. The imbalanced power on WFS heads may have some motivation - it may be that the W/rad TF for one of the two modes we are trying to sense (beam plane tilt vs beam plane translation) is not equal, so we want more light on the head with weaker response.
  3. The 45 degree mounting of the heads is actually meant to decouple PIT and YAW.
Attachment 1: WFSmatrixComparison.pdf
WFSmatrixComparison.pdf
Attachment 2: WFSheadNoise.pdf
WFSheadNoise.pdf
  15319   Wed May 6 00:31:09 2020 gautamUpdateALSOptomechanics during CARM offset reduction

Summary:

The apparent increase in the ALS noise (witnessed in-loop, e.g. Attachment #2 here) during the CARM offset reduction may have an optomechanical origin. 

Details:

  • A simplified CARM plant was setup in Finesse - 3 mirror coupled cavity with PRM, ITM and ETM, 40m params for R/T/L used. 
  • For a sanity check, DC power buildup and coincident resonance of the PRC and arm cavity were checked. PRG and CARM linewidth also checks out, and scales as expected with arm losses.
  • To investigate possible optomechanical issues - I cut the input power to 300 mW (I estimate 600 mW incident on the PRM), set a PRG of ~20, to mimic what we have right now.
  • I drive the ITM at various CARM offsets, and measure the m/m transfer function to itself and the ETM.
  • Attachement #1 shows the results. 

Interpretation:

  • ericq had similar plots in his thesis, but I don't think the full implications of this effect were investigated, the context there was different.
  • The optomechanical resonance builds up at ~10 Hz and sweeps up to ~100 Hz as the CARM offset approaches zero, with amplification close to x100 at the resonance.
  • What this means is that the arm cavity is moving by up to 100x the ambient seismically driven dispalcements. 
  • The EX/EY uPDH servos have considerable gain at these frequencies, and so the AUX laser frequency can keep up with this increased motion (to be quantified exactly what the increase in residual is).
  • However, the ALS loop that maintains the frequency offset b/w the PSL and the AUX lasers is digitial, and only has ~20 dB gain at 30 Hz. - so the error signal for CARM control becomes noisier as we see.
  • I speculate that the multiple peaky features in the in-loop error signal are a result of some dynamical effects which Finesse presumably does not simulate.
  • The other puzzler is: this simulation would suggest that approaching the zero CARM offset from the other side (anti-spring) wouldn't have such instabilities building up. However, I am reasonably sure I've seen this effect approaching zero from both sides, though I haven't checked in the last month.
  • Anyways, if this hypothesis is correct, we can't really take advantage of the ~8pm RMS residual noise performance of the IR ALS system sadly, because of our 250g mirrors and 800mW input power
  • Possible workarounds:
    • High BW ALS - this would give us more gain at ~30 Hz and this wouldn't be a problem anymore really. But in my trials, I think I found that the IN2 gain on the CM board has to be inverted for this to work (the IN1 path and the IN2 path share a common AO path polarity, and we need the two paths to have the opposite polarity).
    • Cut the input power - this would reduce the optomechanical action, but presumably the vertex locking becomes noisier. In any case, this isn't really practical without some kind of motorized/remote-controlled waveplate for power adjustment. 

Update 415pm 5/6: Per the discussion at the meeting, I have now uploaded as Attachment #2 the force-->displacement (i.e. m/N) transfer functions. I now think these are appropriate units. For the ALS case, we could convert the m/N to Hz/N of extra frequency noise imprinted on the AUX laser due to the increased cavity motion. Is W/N really better here, since the mechanism is extra frequency noise on a beatnote, and there isn't really a PDH or DC error signal?

Attachment 1: CARMplant.pdf
CARMplant.pdf
Attachment 2: CARMplant_force2disp.pdf
CARMplant_force2disp.pdf
  15321   Thu May 7 10:58:06 2020 gautamUpdateASCIMC WFS

OK so the QPD segments are in the "+" orientation when the 40m IMC WFS heads are mounted at 45 deg. I thought "+" was the natural PIT/YAW basis but I guess in the the LIGO parlance, the "X" orientation was considered more natural.

Quote:

This is the doc from Keita Kawabe on why the WFS heads should be rotated.

  15324   Mon May 11 00:12:34 2020 gautamUpdateLSCRF only PRFPMI

Finally - Attachment #1. This plot uses 16 Hz EPICS data. All y-axes are uncalibrated for now, but TRX/TRY are normalized such that the POX/POY lock yields a transmission of 1. CARM UGF is only ~3 kHz, no boosts were turned on yet. 

Attachment #2 and Attachment #3 are phone photos of the camera images of the various ports. After some alignment work, the transmitted arm powers were ~200, i.e. PRG ~10. fwiw, this is the darkest i've ever seen the 40m dark port. c.f. 2016. Of course, the exposure time / ND filter / light levels could all have changed.

This work was possible during the daytime (~6pm PDT), but probably only because it was Sunday. The other rate limiting factor here is the franky terrible IMC duty cycle. TBH, I didn't honestly expect to get so far and ran out of time, but I think the next steps are:

  1. Turn on some sensing lines and calibrate CARM/DARM.
  2. Transition vertex control to 1f signals.
  3. Whiten DARM.
  4. Turn on some ASC for better power stabilization.
  5. Scan the CARM offset and check that we are truly on resonance
  6. Noise budget.

As usual, I would like to request that we don't change the IFO as far as possible until the BHD vent, i found it pretty difficult to get here.


Attachment #4 now shows the measured DARM OLTF when DARM is entirely on AS55_Q control. UGF is ~120 Hz and the phase margin is ~30 deg, seems okay for a first attempt. I'll now need to infer the OLTF over a wider range of frequencies by lining this measurement up with some model, so that I can undo the loop in plotting the DARM ASD.

Attachment 1: PRFPMIlock.pdf
PRFPMIlock.pdf
Attachment 2: IMG_8549.JPG
IMG_8549.JPG
Attachment 3: IMG_8548.JPG
IMG_8548.JPG
Attachment 4: DARM_OLTF.pdf
DARM_OLTF.pdf
  15326   Tue May 12 18:16:17 2020 gautamUpdateLSCRelative importance of losses in the arm and PRC

Attachment #1 is meant to show that having a T=500ppm PR2 optic will not be the dominant contributor to the achievable recycling gain. Nevertheless, I think we should change this optic to start with. Here, I assume:

  • \eta_A denotes the (average) round trip loss per arm cavity (i.e. ITM + ETM). Currently, I guess this is ~100ppm.
  • Fixed 0.5% loss from mode mismatch between the CARM mode and the PRC mode (the x-axis does NOT include this number).
  • No substrates/AR coatings inside the cavity.
  • For the nominal case, let's say the intracavity loss sums to 100 ppm.
  • For the T=500ppm PR2, I assumed a total of 550 ppm loss in the PRC.

In relaity, I don't know how good the MM is between the PRC and the arms. All the scans of the arm cavity under ALS control and looking at the IR resonances suggest that the mode-matching into the arm is ~92%, which I think is pretty lousy. Kiwamu and co. claim 99.3% matching into the interferometer, but in all the locks, the REFL mode looks completely crazy, so idk

Attachment 1: armLossVSPRCloss.pdf
armLossVSPRCloss.pdf
  15328   Tue May 12 22:47:49 2020 gautamUpdateLSCRelative importance of losses in the arm and PRC

Yes, \eta_A is the (average) round-trip loss for an arm cavity. I'd estimate this is ~100ppm currently. I edited the original elog to fill in this omission.

The RC mirror specs require some guesswork - the available specs for the Laseroptik mirrors (PR3) are for a 48 degree angle of incidence, and could be as high as 0.5 %. According to the poster, the spec is 2.6% loss inside the recycling cavity but I don't know where I got the number for the AR surface of the G&H PR2, and presumably that includes some guess I made for the MM between the PRC and the arm. Previously, assuming ~1-2% loss inside the RC gave good agreement between model and measurement. Certainly, if we assume similar numbers, a recycling gain of ~11 (200 * T_P=5.637%) is reasonable. But I think we need more data to make a stronger statement.

Quote:

Is \eta_A the roundtrip loss for an arm?

Thinking about the PRG=10 you saw:
- What's the current PR2/3 AR? 100ppm? 300ppm? The beam double-passes them. So (AR loss)x4 is added.
- Average arm loss is ~150ppm?

Does this explain PRG=10?

  15330   Thu May 14 00:21:03 2020 gautamUpdateLSCCM board boosts

Summary:

I think the boosts that are currently stuffed on the CM board are too aggressive to be usable for locking the interferometer. I propose some changes.

Details:

[CM board schematic]

[CM board transfer function measurement]

[Measurement of the AO path TF]. Empirically, I have observed that the CARM OLTF has ~90 degrees phase margin available at the UGF when no boosts are engaged, which is consistent with Koji's measurement. Assuming we want at least 30 degrees phase margin in the final configuration, and assuming a UGF to be ~10 kHz, the current boosts eat up way too much phase at 10 kHz. Attachment #1 shows the current TFs (dashed lines), as the boosts are serially engaged. I have subtracted the 180 degrees coming from the inverting input stage. The horizontal dash-dot line on the lower plot is meant to indicate the frequency at which the boost stages eat up 60 degrees of phase, which tells us if we can meet the 30 degree PM requirement.

In solid lines on Attachment #1, I have plotted the analogous TFs, with the following changes:

  • R52, R54: 1.21k --> 3.16k (changes 4 kHz zero to 1.5 kHz).
  • R61, R62: 82.5 --> 165 (changes 20 kHz zero to 10 kHz).
  • R63: 165 --> 300 (changes 10 kHz zero to 5 kHz).

These changes will allow possibly two super boosts to be engaged if we can bump up the CARM UGF to ~15 kHz. We sacrifice some DC gain - I have not yet done the noise analysis of the full CARM loop, but it may be that we don't need 120 dB gain at DC to be sensing noise limited. I suppose the pole frequencies can also be halved if we want to keep the same low frequency gain. In any case, in the current form, we can't access all that gain anyways because we can't enable the boosts without the loop going unstable.

The input referred noise gets worse by a factor of 2 as a result of these changes, but the IN1 gain stage noise is maybe already higher? If this sounds like a reasonable plan, I'll implement it the next time I'm in the lab.

Attachment 1: boosts.pdf
boosts.pdf
Attachment 2: boosts_noise.pdf
boosts_noise.pdf
  15331   Thu May 14 00:47:55 2020 gautamSummaryComputer Scripts / Programspcdev1 added to authorized keys on nodus

This is to facilitate the summary page config fines to be pulled from nodus in a scripted way, without being asked for authentication. If someone knows of a better/more secure way for this to be done, please let me know. The site summary pages seem to pull the config files from a git repo, maybe that's better?

  15335   Fri May 15 19:10:42 2020 gautamUpdateSUSAll watchdogs tripped, now restored

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

  15342   Thu May 21 15:31:26 2020 gautamUpdateComputer Scripts / ProgramsNDS2 service restarted

The service had failed at 16:09 yesterday. I just restarted it and am now able to fetch data again. 

Unrelated to this work: I restarted the httpd service on nodus a couple of times this afternoon while experimenting with the summary pages.

Quote:

Please try it out and tell me about any problems in getting fresh data.

  15343   Fri May 22 01:43:18 2020 gautamUpdateElectronicsRF electronics trouble

To test a hypothesis, I have left the PSL shutter closed. I notice significant glitches in the dark electronics offsets on all the 11 MHz photodiode I/Q demodulated input channels, which appear coherent. These are non-negligible in magnitude - for now they are uncalibrated in cts, but for an estimate, the POX11 channel shows a shift of ~20 cts (~200uV at the input to the whitening board), while the PDH fringe is ~200 cts pk2pk. A first look is in Attachment #1. The fact that it's in all the 11 MHz channels makes me suspect something in the RF chain, maybe some amplifier? I'll open the shutter tomorrow.

Attachment 1: RFPDglitches.png
RFPDglitches.png
  15347   Tue May 26 01:58:57 2020 gautamUpdateElectronicsSome electronics thoughts

A big factor in how much IFO locking activities can take place is how cooperative the IMC is.

Since the c1psl upgrade, the IMC duty cycle has definitely deteriorated. I took a measurement of the dark noise at the IMC error point with 1 Hz FFT binwidth, with all electrical connections to the IMC servo board except the Acromag and Eurocrate power disconnected. I was horrified at the prominence of 60 Hz harmonics - see Attachment #1. In the past, this kind of feature has been indicative of some error in the measurement technique - but I confirmed that the lines remain even if I unplug the GPIB box, and all combinations of floating/grounded inputs that I tried. We know for sure that there is some excess noise imprinted on the laser light post upgrade. While these lines almost certainly are not responsible for the PCdrive RMS going bonkers, surely this kind of electrical situation isn't good?

Attachment #2 shows the same information translated to frequency noise units, taking into account the complementary sensitivity function, L/(1+L) - the sum contribution of the 60 Hz peaks to the RMS is ~11.5% of the total over the entire band (c.f. 1.7 % that is expected if the noise at multiples of 60 Hz was approximately equal to the surrounding noise levels). Moreover, the measured RMS is 55 times higher than a LISO model. 

How can this be fixed?

Attachment 1: IMCsensingNoise.pdf
IMCsensingNoise.pdf
Attachment 2: IMCsensingNoise.pdf
IMCsensingNoise.pdf
  15348   Tue May 26 02:15:36 2020 gautamUpdateLSCLock acquisition portal entry

Summary:

Provided the IMC is cooperative, the input pointing isn't drifting, and the RF offsets aren't jumping around too much, the locking sequence is now pretty robust.

Details:

Most of the analysis uses data between the GPS times 1274418176 and 1274419654 that are recorded to frames.

  15349   Tue May 26 02:31:00 2020 gautamUpdateLSCLock acquisition sequence

Here, I provide some details of the sequence. Obviously, I am presenting one of the quickest transitions to the fully locked state, I don't claim that every attempt is so smooth. But it is pretty cool that the whole thing can be done in ~3 minutes.

See Attachment #1 for the labels.

  • A --- Arms are locked on POX/POY, and EX/EY lasers are also locked to their respective arms. The phase tracker outputs are averaged in preparation for transitioning control from POX/POY to ALS. 
  • B --- Aforementioned transition has been realized. CARM offset of -4 is applied. Based on this calibration, this is ~ 4 nm.
  • C --- PRM is aligned in preparation for 3f vertex locking. Between C and D, the long pause is because I also use this time to DC couple the ITM Oplev servos, which requires some averaging. 
  • D --- PRMI is locked. CARM offset reduction begins. Between D and E, I scan CARM through a resonance, and look at the necessary offset requried in the CARM_B (=RF) path. It is a mystery to me why this is required.
  • E --- Ramp CARM offset completely to 0. Twiddle CARM_A and DARM_A offsets (=ALS path) to maximize the arm transmitted powers. Between E and F, you can see that the arm powers stabilize somewhat before any RF control is engaged (more on this later), which means we are approximately in the linear regime of the CARM PDH signal, and the switchover can be effected. As I write this, I wonder if there is any benefit to normalizing the REFL_11 error signal (=CM_SLOW) by the arm transmission for a broader capture range?
  • F --- CARM_B and DARM_B (=RF) paths engaged. I ramp off the ALS servos between F and G using a 10 second ramptime.
  • G --- IFO is now under RF control, ALS control has been turned off completely.
  • H --- Rudimentary ASC is enabled. The ITMs are already running with DC coupled Oplev servos, and for the ETMs, I use the Transmon QPDs. The loop shapes/gains for this part haven't been finalized yet, but some improvement in the stability is seen.

This particular lock held for ~20 minutes so I could run some loop characterization measurements etc.

I am struggling to explain:

  1. Why POP22 goes to 0 when we zero the CARM offset? The arm length is such that the 2f fields don't experience any abrupt changes in reflectivity from the arm cavity for a wide range of offsets. This signal is the trigger signal for the PRMI LSC control - right now, I get around this problem by mixing in some amount of POP DC once the PRMI is locked. But if the lock is lost, this requires some EPICS button gynmastics to try and salvage the lock... I guess the 1f field components experience a different phase on reflection at various offsets, so maybe I should be looking at sqrt(POP22_I^2 + POP22_Q^2) instead of just POP22_I.
  2. Why is an error point offset required in the CARM RF path?
Attachment 1: PRFPMIlock_1274418200_1274418550.pdf
PRFPMIlock_1274418200_1274418550.pdf
  15350   Tue May 26 02:37:19 2020 gautamUpdateLSCDARM loop measurement and fitting

Summary:

In order to estimate the free-running DARM displacement noise, I measured the DARM OLTF using the usual IN1/IN2 prescription. The measured data was then used to fit some model paramters for a loop model that can be used over a larger frequency range.

Details:

  • Attachment #1 shows an overlay of the measured and modelled TFs.
  • Attachment #2 shows the various components that went into building up this model. 
    • The digital AA and AI filter coefficients were taken from the RTCDS code.
    • The analog AA and AI filter zpks were taken from here and here respectively.
    • CDS filters taken from the banks enabled. The 20Hz : 0Hz z:p filter in the CARM_B path is also accounted for, as have the violin-mode notches.
    • Pendulum TF is just 1/f^2, the overall scaling is unimportant because it will be fitted (in combination with the overall scaling uncertainty on the DC optical gain), but I used a value of 10 nm/f^2 which should be in the right ballbark.
    • The optical gain includes the DARM pole at ~4.5 kHz for this config.
  • With all these components, to make the measurement and fit line up, I added two free parameters - an overall gain, and a delay. 
    • NLSQ minimizer was used to find the best-fit values for these parameters.
    • I'm not sure what to make of the relatively large disagreement between measurement and model below 100 Hz - I'm pretty sure I got all the CDS filters included...
    • Moreover, I don't have a good explanation for why the best-fit delay is 400 us. One RTCDS clock cycle is onyl 60 us, and even with an extra clock cycle for the RFM transfer, I still can't get up to such a high delay...

In summary, the UGF is ~150 Hz and phase margin is ~30 deg. This loop would probably benefit from some low-pass filter being turned on.

Attachment 1: DARM_TF.pdf
DARM_TF.pdf
Attachment 2: DARM_TF_breakdown.pdf
DARM_TF_breakdown.pdf
  15351   Tue May 26 03:01:35 2020 gautamUpdateLSCCARM loop

Summary:

I am able to realize ~8 kHz UGF with ~60 degrees of phase margin on the CARM loop OLTF (combination of analog and digital signal paths).

Details:

  • Attachment #1 shows the measured OLTF.
  • The measurement is made by using the "EXC A" bank on the CM board, with an SR785. With this technique, the measurement will be poor where the loop gain is high, as the excitation will be squished. Nevertheless, we can estimate the behavior in those regimes by using a model, and fitting it to the regions where the measurement is valid (in this case, above ~1 kHz).
  • This measurement was made with IN1 Gain = +4 dB, AO gain = 0 dB, and IMC IN2 gain = 0 dB.
  • The regular boost has been enabled, but no super-boosts yet, mainly because I think they consume too much phase close to the UGF. 
  • The modeling/fitting of this, including a more thorough characterization of the crossover, will follow...
Attachment 1: CARM_OLTF.pdf
CARM_OLTF.pdf
  15352   Tue May 26 03:06:59 2020 gautamUpdateLSCPRFPMI sensing matrix

Summary:

The response of the PRFPMI length degrees of freedom as measured in the LSC PDs was characterized. Two visualizations are in Attachment #1 and Attachment #2.

Details:

  • The sensing matrix infrastructure in the c1cal model was used.
  • The oscillator frequencies are set between 300 - 315 Hz.
  • Notch filters at these frequencies were enabled in the CDS filter banks, to prevent actuation at these frequencies (except for CARM, in which case the loop gain is still non-negligible at ~300 Hz, this correction has not yet been applied).
  • Mainly, I wanted to know what the DARM sensing response in AS55_Q is. 
    • The measurement yields 2.3e13 cts/m. This is a number that will be used in the noise budget to convert the measured DARM spectrum to units of m/rtHz.
    • We have to multiply this by 10/2^15 V/ct, undo the 6dB whitening gain on the AS55_Q channel, and undo the ~5x gain from V_RF to V_IF (see Attachment #4 of this), to get ~0.69 GV/m from the RFPD.
    • The RF transimpedance of AS55_Q is ~550 ohms, and accounting for the InGaAs responsivity, I get an optical gain of 1.8 MW/m. Need to check how this lines up with expectations from the light levels, but seems reasonable.
    • Note that T_SRM is 10%, we dump 70% of the output field into the unused OMC, and there is a 50/50 BS splitting the light between AS55 and AS110 PDs. Assuming 90% throughput from the rest of the chain, we are only sensing ~1.3 % of the output DARM field.
  • Apart from this, I can also infer what the matrix elements / gains need to be for transitioning the PRMI control from 3f to 1f signals. To be done...
  • I found these histograms in Attachment #2 to be a cute way of (i) visualizing the variance in the magnitude of the sensing element and (ii) visualizing the separation between the quadratures, which tells us if the (digital) demod phase needs to be modified.
    • The sensing lines were on for 5 minutes (=300 seconds) and the FFT segment length is 5 seconds, so these histograms are binning the 60 different values obtained for the value of the sensing element.
    • The black dashed lines are "kernel density estimates" of the underlying PDFs
    • I haven't done any rigorous statistical analysis on the appropriateness of using this technique for error estimation, so for now, they are just lines...
Attachment 1: PRFPMI_20200524sensMat.pdf
PRFPMI_20200524sensMat.pdf
Attachment 2: PRFPMI_20200524sensMatHistograms.pdf
PRFPMI_20200524sensMatHistograms.pdf
  15353   Tue May 26 03:26:58 2020 gautamUpdateLSCPreliminary noise budget

Summary:

This isn't meant to be a serious budget, mainly it was to force myself to write the code for generating this more easily in the future.

Details:

  • DARM OLTF model from here was used to undo the loop to convert the in-loop measurement to a free-running estimate.
  • The AS55 PD channels were whitened to reduce the effect of ADC noise.
  • To measured channel was 'C1:LSC-DARM_IN1_DQ'.
    • Some care needs to be taken when applying the conversion from counts to meters using the sensing element measured here.
    • This is because the sensing matrix measurement was made using the response in the channel 'C1:LSC-AS55_Q_ERR_DQ'.
    • Between 'C1:LSC-DARM_IN1_DQ' and 'C1:LSC-AS55_Q_ERR_DQ' there is a scalar gain of 1e-4, and a z:p = 20:0 filter.
    • These have to be corrected for when undoing the loop, since the measurement point is 'C1:LSC-DARM_IN1_DQ'. 
  • The "Dark noise" trace was measured with the PSL shutter closed, but all CDS filters up to 'C1:LSC-DARM_IN1_DQ' enabled as they were when the DARM measurement was taken.
  • It would be interesting to see what the budget looks like once the DARM loop gain has been turned down a bit, some low-pass filtering is enabled, and the vertex DoFs are transitioned to 1f control which is hopefully lower noise.
Attachment 1: PRFPMI_NB.pdf
PRFPMI_NB.pdf
  15355   Tue May 26 14:32:44 2020 gautamUpdateLSCArm transmission RIN

Summary:

The measured RIN of the arm cavity transmission when the PRFPMI is locked is ~10x in RMS relative to the single arm POX/POY lock. It is not yet clear to me where the excess is coming from.

Details:

Attachment #1 shows the comparison.

  • For the PRFPMI lock, the ITM Oplev Servos are DC coupled, and the ETM QPD ASC servos are also enabled.
  • Admittedly, the PD used in the POX/POY lock case is the Thorlabs PD while when the PRFPMI is locked, it is the QPD.
  • I found that there isn't really a big difference in the RIN if we normalize by the IMC transmission or not (this is what the "un-normalized" in the plot legend is referring to).  A scatter plot of TRX vs TRY and TRX/MCtrans vs TRY/MCtrans have nearly identical principal components. 
  • To convert to RIN, I divided the ocmputed spectra by the mean value of the data stream. For the POX/POY lock, the arm transmission is normalized to 1, so no further manipulation is required.
  • The spectra are truncated to 512 Hz because the IMC sum channel is DQ-ed at 1 kHz, but because of the above bullet point, in principle, I could calculate this out to higher frequencies.
Attachment 1: armRIN.pdf
armRIN.pdf
  15356   Tue May 26 16:00:06 2020 gautamUpdateLSCPower buildup diagnostics

Summary:

I looked at some DC signals for the buildup of the carrier and sideband fields in various places. The results are shown in Attachments #1 and #2.

Details:

  • A previous study may be found here.
  • For the carrier field, REFL, POP and TRX/TRY all show the expected behavior. In particular, the REFL/TRX variation is consistent with the study linked in the previous bullet.
  • There seems to be some offset between TRX and TRY - I don't yet know if this is real or just some PD gain imbalance issue.
  • The 1-sigma variation in TRX/TRY seen here is consistent with the RMS RIN of 0.1 evaluated here.
  • For the sideband powers, I guess the phasing of the POP22 and AS110 photodiodes should be adjusted? These are proxies for the buildup of the 11 MHz and 55 MHz sidebands in the vertex region, and so shouldn't depend on the arm offset, and so adjusting the digital demod phases shouldn't affect the LSC triggering for the PRMI locking, I think.
  • Based on this data, the recycling gain for the carrier is ~12 +/- 2, so still undercoupled. In fact, at some points, I saw the transmitted power exceed 300, which would be a recycling gain of ~17, which is then nearly the point of critical coupling. REFLDC doesn't hit 0 because of the mode mismatch I guess.
Attachment 1: PRFPMIcorner_DC_1274419354_1274419654.pdf
PRFPMIcorner_DC_1274419354_1274419654.pdf
Attachment 2: PRFPMIcorner_SB_1274419354_1274419654.pdf
PRFPMIcorner_SB_1274419354_1274419654.pdf
  15361   Thu May 28 18:36:45 2020 gautamUpdateLSCArm transmission RIN

I agree, I think the PRC excess angular motion, PIT in particular, is a dominant contributor to the RIN. Attachments #1-#3 support this hypothesis. In these plots, "XARM" should really read "COMM" and "YARM" should really read "DIFF", because the error signals from the two end QPDs are mixed to generate the PIT and YAW error signals for these ASC servos - this is some channel renaming that will have to be done on the ASC model. The fact that the scatter plot between these DoFs has some ellipticity probably means the basis transformation isn't exactly right, because if they were truly orthogonal, we would expect them to be uncorrelated?

  • In the corner plots, I am plotting the error signals of the ASC servos and the arm transmission. POP feedback is not engaged, but some feedback control to the ETMs based on the QPD signals is engaged.
  • In the coherence plot, I show the coherence of the ASC error signals with the POP and TR QPD based error signals, under the same conditions. The coherence is high out to ~20 Hz.

I guess what this means is that the stability of the lock could be improved by turning on some POP QPD based feedback control, I'll give it a shot.

Quote:

- PRC TT misalignment (~3Hz)

Don't can you check the correlation between the POP QPD and the arm RIN

Attachment 1: PRFPMIcorner_ASC_PIT_1274419354_1274419654.pdf
PRFPMIcorner_ASC_PIT_1274419354_1274419654.pdf
Attachment 2: PRFPMIcorner_ASC_YAW_1274419354_1274419654.pdf
PRFPMIcorner_ASC_YAW_1274419354_1274419654.pdf
Attachment 3: PRFPMIcorner_ASC_coherence_1274419354_1274419654.pdf
PRFPMIcorner_ASC_coherence_1274419354_1274419654.pdf
  15364   Wed Jun 3 01:34:53 2020 gautamUpdateLSCLock acquisition update portal

Highlights:

  • With better ASC servos implemented, I think the lock stability has been improved. 
  • Arm transmission of ~350 was stably maintained (PRG~20, overcoupled). It went as high as 410, so this is now very close to the highest (~425) I've ever managed to get.
  • I was trying to get the vertex transitioned to 1f control but it remains out of reach for now.  The noise at ~100 Hz is dominated by MICH-->DARM coupling (as judged by coherence, I haven't yet done the broadband noise injection characterization). I figured I'd try the 1f transition before thinking about feedforward.
  • The biggest problems remain flaky electronics (poor IMC duty cycle, jumping RF offsets, newly glitchy seismometer, ...)

Details:

  15365   Wed Jun 3 01:40:13 2020 gautamUpdateElectronicsMore electronics woes

There were many locklosses from the point where the arm powers were somewhat stabilized. Attachments #1 and #2 show two individual locklosses. I think what is happening here is that the BS seismometer X channel is glitching, and creating a transient in the angular feedforward filter that blows the lock. The POP QPD based feedback loop cannot suppress this transient, apparently. For now, I get around this problem by boosting the POP QPD feedback loop a bit, and then turning the feedforward filters off. The fact that the other seismometer channels don't report any transient makes me think the problem is either with the seismometer itself, or the readout electronics. The seismometer masses were recently recentered, so I'm leaning towards the latter.

I didn't explicitly check the data, but I am reasonably certain the same effect is responsible for many PRMI locklosses even with the arms held off resonance (though the tolerance to excursions there is higher). Pity really, the feedforward filters were a big help in the lock acquisition...

Attachment 1: glitchySeis2.png
glitchySeis2.png
Attachment 2: glitchySeis3.png
glitchySeis3.png
  15366   Wed Jun 3 01:46:14 2020 gautamUpdateLSCCARM loop

Summary:

The CARM loop now has a UGF of ~12 kHz with a phase margin of ~60 degrees. These values of conventional stability indicators are good. The CARM optical gain that best fits the measurements is 9 MW/m.

I've been working on understanding the loop better, here are the notes.

Details:

Attachment #1 shows a block diagram of the loop topology.

  • The "crossover" measurement made at the digital CARM error point, and the OLG measurement at the CM board error point are shown.
  • I've tried to include all the pieces in the loop, and yet, I had to introduce a fudge gain in the digital path to get the model to line up with the measurement (see below).

Attachment #2 shows the OLGs of the two actuation paths.

  • Aforementioned fudge factor for the digital path is included.
  • For the AO path, I assumed a value of the PDH discriminant at the IMC error point to be 13 kHz/V, per my earlier measurement. 
  • I trawled the elog for the most up-to-date info about the IMC servo (elog9457, elog13696, elog15044) and CM board, to build up the model. 

Attachment #3 and #4 show the model, overlaid with measurements of the loop OLG and crossover TF respectively.

  • No fitting is done yet - the next step would be to add the delay of the CDS system for the digital path, and the analog electronics for the AO path. Though these are likely only small corrections.
  • For the crossover TF - I've divided out the digital filters in the CARM_B filter bank, because the injection is made downstream of it (see Attachment #1).
  • There is reasonably good agreement between model and measurement.
  • I think the biggest source of error is the assumed model for the IMC OLTF.

Attachment #5 shows the evolution of the CARM OLG at a few points in the lock acquisition sequence.

  • "Before handoff" corresponds to the state where the primary control is still done by the ALS leg, but the REFL11 signal has begun to enter the picture via the CARM_B path.
  • "IN2 ramped" corresponds to the state where the AO path gain (=IN2 gain on the IMC servo board) has been ramped up to its final value (+0 dB), but the overall loop gain (=IN1 gain on the CM board) is still low. So this is preparation for high bandwidth control. Typically, the arm powers will have stabilized in this state, but ALS control is still on.
  • "Pre-boost" corresponds to an intermediate state - ALS control is off, but the low frequency boosts have not yet been enabled. I typically first engage some ASC to stabilize things somewhat, and then turn on the boosts.
  • "Final" - self explanatory.

Next steps:

Now the I have a model I believe, I need to think about whether there is any benefit to changing some of these loop shapes. I've already raised the possibility of changing the shape of the boosts on the CM board, with which we could get a bit more suppression in the 100 Hz - 1kHz region (noise budget of laser frequency noise --> DARM required to see if this is necessary). 

Attachment 1: CM_loop_topology.pdf
CM_loop_topology.pdf
Attachment 2: CARM_TFs.pdf
CARM_TFs.pdf
Attachment 3: CARM_OLTF.pdf
CARM_OLTF.pdf
Attachment 4: CARM_xover.pdf
CARM_xover.pdf
Attachment 5: CARM_OLG_evolution.pdf
CARM_OLG_evolution.pdf
  15367   Wed Jun 3 02:08:00 2020 gautamUpdateLSCPower buildup diagnostics

Attachments #1 and Attachments #2 are in the style of elog15356, but with data from a more recent lock. It'd be nice to calibrate the ASDC channel (and in general all channels) into power units, so we have an estimate of how much sideband power we expect, and the rest can be attributed to carrier leakage to ASDC.

On the basis of Attachments #1, the PRG is ~19, and at times, the arm transmission goes even higher. I'd say we are now in the regime where the uncertainty of the losses in the recycling cavity - maybe beamsplitter clipping? is important in using this info to try and constrain the arm cavity losses. I'm also not sure what to make of the asymmetry between TRX and TRY. Allegedly, the Y arm is supposed to be lossier.

Quote:

This is very interesting. Do you have the ASDC vs PRG (~ TRXor TRY) plot? That gives you insight on what is the cause of the low recycling gain.

Attachment 1: PRFPMIcorner_DC_1275190251_1275190551.pdf
PRFPMIcorner_DC_1275190251_1275190551.pdf
Attachment 2: PRFPMIcorner_SB_1275190251_1275190551.pdf
PRFPMIcorner_SB_1275190251_1275190551.pdf
  15368   Wed Jun 3 02:14:32 2020 gautamUpdateASCPRC ASC improves arm transmission RIN

Summary:

I implemented an ASC servo for the PRC, with the POP QPD as a sensor, and the PRM as the actuator. This has improved the stability of the lock (longer locks are possible), and also reduced the RIN of the arm transmission.

Details:

Attachment #1 shows the in-loop error signal suppression, and some out-of-loop monitors (POP22 and POPDC).

  • To practise and get some workable servo settings, I locked the PRMI with carrier resonant (no ETMs).
  • Then, I compare the beam motion witnessed by the POP QPD with and without the feedback loop enabled.
  • I also look at the spectra of the POPDC and POP22 signals, as out-of-loop proxies, to get an estimate of how much noise is being injected out of band.
  • In this toy study, both the in-loop and out of loop monitors show good performance.
  • However, when repeating the same diagnostics with the PRFPMI locked, I note that while the in-loop suppression looks good, POPDC and POP22 report elevated noise, relative to the PRMI carrier case.
  • I don't have a comparison to the PRFPMI locked with the feedback disabled, because of stability reasons. Plus, for the PRMI, the angular feedforward loops were engaged, but for the PRFPMI traces, they were disabled.
  • Nevertheless, the arm RIN goes down by ~2.5 in RMS, so this is doing something good.

Attachment #2 compares the arm transmission RIN with the PRFPMI locked, with and without PRC ASC. The 3 Hz bump is definitely squished, but I think we can do better yet. 

Attachments #3-5 are in the style of elog15361. No Oplev signals yet, I'll add them soon.

I guess what this means is that the stability of the lock could be improved by turning on some POP QPD based feedback control, I'll give it a shot

Attachment 1: PRC_ASCsignals.pdf
PRC_ASCsignals.pdf
Attachment 2: armRIN_PRC_ASC.pdf
armRIN_PRC_ASC.pdf
Attachment 3: PRFPMIcorner_ASC_PIT_1275190251_1275190551.pdf
PRFPMIcorner_ASC_PIT_1275190251_1275190551.pdf
Attachment 4: PRFPMIcorner_ASC_YAW_1275190251_1275190551.pdf
PRFPMIcorner_ASC_YAW_1275190251_1275190551.pdf
Attachment 5: PRFPMIcorner_ASC_coherence_1275190251_1275190551.pdf
PRFPMIcorner_ASC_coherence_1275190251_1275190551.pdf
  15370   Wed Jun 3 11:20:19 2020 gautamUpdateDetCharSummary pages

Summary:

The 40m summary pages have been revived. I've not had to make any manual interventions in the last 5 days, so things seem somewhat stable, but I'm sure there will need to be multiple tweaks made. The primary use of the pages right now are for vacuum, seismic and PSL diagnostics.

Resources:

Caveats:

  • Intermittent failures of cron jobs
    • The status page relies on the condor_q command executing successfully on the cluster end. I have seen this fail a few times, so the status page may say the pages are dead whereas they're actually still running.
    • Similarly, the rsync of the pages to nodus where they're hosted can sometimes fail.
    • Usually, these problems are fixed on the next iteration of the respective cron jobs, so check back in ~half hour.
  • I haven't really looked into it in detail, but I think our existing C1:IFO-STATE word format is not compatible with what gwsumm wants - I think it expects single bits that are either 0 or 1 to indicate a particular state (e.g. MC locked, POX and POY locked etc). So if we want to take advantage of that infrastructure, we may need to add a few soft EPICS channels that take care of some logic checking (several such bits could also be and-ed together) and then assume either 0 or 1 value. Then we can have the nice duty cycle plots for the IMC (for example).
  • I commented out the obsolete channels (e.g. PEM MIC channels). We can add them back later if we so desire.
  • For some reason, the jobs that download the data are pretty memory-heavy: I have to request for machines on the cluster with >100 GB (yes 💯GB) ! of memory for the jobs to execute to completion. The frame-data certainly isn't so large, so I wonder what's going on here - is GWPy/GWsumm so heavy? The site summary pages run on a dedicated cluster, so probably the code isn't built for efficiency...
  • Weather tab in PEM is still in there but none of those channels mean anything right now.
  • The MEDM screenshot stuff is commented out for now too. This should be redone in a better way with some modern screen grab utilities, I'm sure there are plenty of python based ones.
  • There seems to be a problem with the condor .dag lockfile / rescue file not being cleared correctly sometimes - I am looking into this.
ELOG V3.1.3-