40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 227 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  15164   Tue Jan 28 15:39:04 2020 gautamConfigurationComputersSluggish megatron?

There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.

  15165   Tue Jan 28 16:01:17 2020 gautamUpdateIOOIMC WFS servos stable again

With all of the shaking (man-made and divine), it was a hard to debug this problem. Summary of fixes:

  1. The beam was misaligned on the WFS 1 and 2 heads, as well as the MC2 trans QPD. I re-aligned the former with the IMC unlocked, the latter (see Attachment) with the IMC locked (but the MC2 spot centering loops disabled).
  2. I reset the WFS DC and RF offsets, as well as the QPD offsets (once I had hand-aligned the IMC mirrors to obtain good transmission).

At least the DC indicators are telling me that the IMC locking is back to a somewhat stable state. I have not yet checked the frequency noise / RIN.

Attachment 1: QPD_recenter.png
QPD_recenter.png
  15167   Tue Jan 28 17:36:45 2020 gautamConfigurationComputersLocal EPICS7.0 installed on megatron

[Jon, gautam]

We found that the caput commands were taking much longer to execute on megatron than on pianosa (for example). Suspecting that this had something to do with the fact that megatron was using EPICS binaries from the shared NFS drive which were compiled for a much older OS, I installed the latest stable release of EPICS on megatron. The new caput commands execute much faster. I also added the local EPICS directory to the head of the $PATH variable used by the MC autolocker and FSS Slow scripts, so that they use the new caput command. But mcup is still slow - maybe my new path definition isn't picked up and it is still using the NFS binaries? To be looked into...

Quote:

There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.

  15171   Wed Jan 29 00:27:13 2020 gautamUpdateComputer Scripts / Programsmcup / mcdown modified

To fix the apparent slowness of execution of the caput commands on megatron, I changed the "ewrite" macro in the mcup and mcdown scripts to use ezcawrite instead of caput. The old lines are simply commented out, and can be reverted to at any point if we so desire. After these changes, we saw that both scripts complete execution much faster.

  15172   Wed Jan 29 00:29:43 2020 gautamUpdateLSClocking 2020

The goal tonight was to go through the locking scripts to see if I could recover the state from November 2019, when I could have the arm lengths controlled by ALS, and sit at zero CARM offset with the PRMI remaining locked and the arm powers fluctuating between 0-300. The IR-->ALS transitions went smoothly tonight, and the PRMI locking was also fairly robust when the CARM offset was large, but was less good when reduced to 0. Nevertheless, it is good to know that the system can be restored to the state it was late last year. Next step is to figure out how to keep the PRMI locked and get the AO path engaged, this was what I was struggling with before the new year.

Attachment 1: PRFPMI_2020Jan.png
PRFPMI_2020Jan.png
  15179   Thu Jan 30 17:41:10 2020 gautamUpdatePSLErrant FSS_INOFFSET change

You can trend the data for the past few hours and see what the appropriate value. I think these tests should only be done when whoever is running a test is in the lab.

P.S. I was surprised that the IMC didn't lose lock when this step was applied. I manually stepped this voltage between +/- 10 V and didn't see any response in the FSS readbacks. Either the channel doesn't work, or there is a divide by 40 in the physical circuit or something...

Quote:

A script I was testing errantly set C1:PSL-FSS_INOFFSET => 10 V at about 5:30 pm. I manually reverted the channel value to 0, but I don't know what the value was initially. Someone please check this value if there are problems locking the FSS.

  15181   Fri Jan 31 16:04:30 2020 gautamUpdateIOOInput pointing drift

One factor which hampers locking efforts is the apparent drift of the input beam into the IFO. Over timescales of ~1 hour, I have noticed that the spot on the AS camera drifts significantly (~1 spot size) in pitch. The IPPOS QPD bears out this observation, see Attachment #1. The IMC WFS control signals do not show a correlated drift, hence my claim that the TTs are to blame.

I am able to correct this misalignment by moving TT1 in pitch (see Attachment #2, which shows some signals from a ~1 hour PRMI lock, during which time the pointing drifted, and I corrected it by moving TT1 pitch). Assuming the problem is purely TT1 pitch drifting, this corresponds to 3mm / 6m ~500urad of shift in 1 hour - seems very large. The fact that the drift is only present in pitch and doesn't really show up in yaw makes me think the problem is likely mechanical (unless the voltage to the top two coils is drifting relative to the bottom, but no LR drift, which would be very coincidental). At the moment, this is just an annoyance, but it'd be good for this problem to be fixed.

I haven't yet figured out how to make ndscope export these plots to SVG preserving the dark color theme, hence the weird light axes...

Attachment 1: IPdrift.pdf
IPdrift.pdf
Attachment 2: IPdrift_PRMI.pdf
IPdrift_PRMI.pdf
  15182   Fri Jan 31 16:57:09 2020 gautamUpdateGeneralMetal PMC parts

Jon brought over a box of parts for constructing the metal PMCs. I have stored it along the Y-arm, on top of the green optics cabinet.

I didn't do an exhaustive inventory check, but the following are the rough contents of the box:

  • 41 deg AoI flat mirrors, R=99% @ 1064nm --- 11 pcs
  • 6.8 deg AoI curved mirrors --- 5 pcs
  • PZTs --- 3pcs
  • Metal PMC body --- 2 pcs
  • "Baked PZT endcaps" --- 3 pcs
  • Ball bearings, clamps, misc hardware

I didn't inspect the optics but since we have so many, I am hoping we can find 3 good quality ones for one cavity at least. We should check that the geometry is suitable for our RF sideband frequencies.  

  15185   Tue Feb 4 02:13:02 2020 gautamUpdateLSCLocking updates

Summary:

The CARM-->RF transition remains out of reach. No systematic diagnosis scheme comes to mind.

Details:

  • Config is PRFPMI, SRM is misaligned macroscopically.
  • PRMI can easily be locked with 3f signals while CARM is offset from resonance. Aided by DAFI, I turned on the PR violin filter in the BS output section to prevent it from ringing up, making the lock much more robust.
  • When the CARM offset is reduced
    • POP22 level dips and sometimes goes negative - i don't see this in my simple simulations. POP22 is the trigger signal for MICH/PRCL loops, so to prevent the PRMI lockloss, I mix in some POPDC into the trigger matrix element.
    • Once the circulating power exceeds ~10, the ALS noise apparently increases.
    • The arms "buzz" through resonance, but the power fluctuation is nearly 0-200 in TRX/TRY, corresponding to several CARM linewidths, but all the out-of-loop ALS noise measurements have me believe that we are close to the CARM linewidth in noise. So we should only see ~factor of 2 fluctuation in power.
    • The RF error signal for CARM (=REFL 11) doesn't show any features that i can use to aid the transition / diagnose what is going on systematically.
  • Koji suggested changing the actuation for CARM from MC2 to the ETMs, and check if the MC OSEMs witness the excess motion at small CARM offsets
    • The ALS transition is scripted, so I had to make a modified version that accommodates this changed actuation scheme.
    • The usual CARM-->MC2 matrix element is -1. 
    • The frequency actuation strength of MC2 is ~3x that of the ETMs. Additionally, ETMX has 5x the series resistance of ETMY. So I used the output matrix elements shown in Attachment #1 so as to get the same loop UGF with the same loop gains elsewhere in the chain. Confirmed the actuation strength is the same using the sensing matrix infrastructure and comparing line heights.
    • Attachment #2 shows the measured UGF - both CARM and DARM look okay to me.
  • With this new ALS output matrix actuation scheme, I was able to make it to PRMI + arms on zero offset a couple of times tonight, but the drifting input alignment makes the PRMI lock not so robust anymore.

TBC. Mercifully at least the shaker stayed still tonight.

Attachment 1: modifiedOutMat.png
modifiedOutMat.png
Attachment 2: OLTFs.pdf
OLTFs.pdf
  15188   Wed Feb 5 16:35:12 2020 gautamUpdateLSCDiagnosis plan

The goal is to try and identify the source of the excess ALS noise as the CARM offset is reduced. The idea is to look at the MC_F spectrum (or the IMC error point) in a few conditions:

  1. Regular CARM --> MC2 actuation scheme, PRMI locked on 3f signals, CARM held off resonance.
  2. Regular CARM --> MC2 actuation scheme, PRMI locked on 3f signals, CARM held on resonance.
  3. Alternate CARM --> 7.5*ETMX + 1.5*ETMY, PRMI locked on 3f signals, CARM held on resonance.
  4. Control arms in X/Y basis, lock PRMI on 3f signals and bring the arms into resonance individually, look for excess ALS noise.

#1 vs #2 is like a control experiment, we expect to see the excess noise imprinted on the MC length and hence in MC_F (provided the sensing noise is low enough). #2 vs #3 will be informative of something like backscatter to the PSL increasing the frequency noise. #2/3 vs #4 will help isolate the problem to an individual arm's AUX PDH loop or some optomechanical effect.

I was looking back at some spectra from the last couple of nights but I don't really have an apple-to-apple comparison in the various actuation schemes (some ALS loops were engaged/disengaged), so I'll do a more systematic test tonight. Already, it looks like MC_F is not a good candidate to look for the excess frequency noise, I don't really see a big difference between conditions #1 and #2. According to this, we are looking for an increase at the level of a few 100Hz/rtHz @ ~40 Hz, wheras MC_F is much noisier.

Attachment 1: ALSnoise.pdf
ALSnoise.pdf
  15191   Thu Feb 6 01:16:58 2020 gautamUpdateLSCDiagnosis results

Summary:

I did some more detailed tests to see if I could isolate where the excess ALS noise at low CARM offset is coming from, by measuring the spectrum of the IMC error point (in loop). The results, shown in Attachment #1 and #2, are inconclusive.

Details:

Since MC_F didn't show any signatures of elevated noise, I decided to hook up an SR785 to the A excitation bank TEST1 input of the IMC servo board to monitor the in-loop error signal. I initially took a few measurements spanning 800 Hz in frequency, and to my surprise, I found that there was elevated noise in the frequency band we see an increase in the ALS noise, even when the CARM feedback goes to the ETMs (so the IMC cavity is in principle isolated from the main interferometer). This is Attachment #1. So I re-took a couple of measurements (this time only for the case of CARM feedback to the ETMs), with a 200 Hz frequency span, and found no significant noise elevation. This is Attachment #2. I am led to conclude that the IMC error point level changes over time for reasons other than the CARM offset - it'd be nice to have a spectrogram of the IMC error point and compare excursions relative to the median level over a few 10s of minutes, but we don't have this data stream digitized by the CDS system - maybe I will hijack the MC_L channel temporarily to record this data stream. It seems a waste that we're not able to take full advantage of the measured <10pm RMS noise of the IR ALS system.

Attachment 1: IMCspec_ALS.pdf
IMCspec_ALS.pdf
Attachment 2: IMCspec_ALS_smallSpan.pdf
IMCspec_ALS_smallSpan.pdf
  15192   Thu Feb 6 01:25:50 2020 gautamUpdateLSCLocking updates

Summary:

I managed to partially stabilize the arm citculating powers - they stay in a region in which the REFL 11 signal is hopefully approximately linear and so I can now measure some loop TFs and tweak the transition appropriately. 

Procedure:

The main change I made tonight was to look at the REFL11 signal as I swept the ALS CARM offset through 0. I found that the maximum arm powers coincided with a non-zero REFL11 signal value (i.e. a small CARM offset was required at the input to the CARM_B filter bank). Not so long ago, I had measured the PM/AM ratio for 11 MHz to be ~10^5 - so it's not entirely clear to me where this offset is coming from. Then, I was able to turn on the integrator (z:p = 20:0) in the CARM_B filter bank while maintaining high POP_DC. At this point, I ramped up the IN2 gain on the IMC servo board (= AO path), and was able to further stabilize the power. 

Attachment #shows this sequence from earlier in the evening. Note that in this state, both ALS and IR control of CARM is in effect. The circulating power is fluctuating wildly - partly this is probably the noisy ALS control path, but there is also the issue of the (lack of) angular control - although looking at the transmon QPDs and the POP QPD signals, they seem pretty stable.

The next step will be to try and turn off the ALS control path. Eventually, I hope to transition DARM control to AS55 as well. But at this point, I can at least begin to make sense of some of the time series signals, and get some insight into how to improve the lock.

Quote:

No systematic diagnosis scheme comes to mind.

Attachment 1: semiStableArms.png
semiStableArms.png
Attachment 2: armAngStability.png
armAngStability.png
  15195   Fri Feb 7 02:24:24 2020 gautamUpdateLSCSome short notes

[koji, gautam] 

Plots + interpretation tomorrow.

  • CM_Slow path can be used to stabilize the arm powers somewhat but the AO crossover remains out of reach.
  • The REFL11 (=CARM_B) path offset has to be manually determined - we found that it can change by ~20% depending on the alignment, which maybe isn't surprising given that the mode shapes seen at POP, REFL and AS look like Rorschach inkblots.
  • We saw TRX/TRY regularly hit ~150, and at times even 200 (= recycling gain of ~10). Though any conclusive statement about the PRG can only be made once the lock is stabilized.
  • I was able to take a few CARM loop TFs with an SR785 hooked up at 1Y2. Despite ramping up the AO gain, we saw no effect at high frequencies in the TF shape (the phase bubble continued to roll off at ~100 Hz and there was no visible phase lead even as the AO gain was increased). It has to be estimated what the expected crossover gain is from the experiment with the high BW POY locking (taking into account the net difference in optical gain between POY for single arm and REFL for the full IFO).
  • The fact that I was able to hold the high BW POY lock makes me think that the IMC servo board's IN2 input (and indeed the rest of the IMC locking loop) is functioning as expected. But maybe this board will benefit from a detailed checkout like Koji did for the CM board.

Getting closer... To facilitate this work, I made some convenience scripts that can be run from the CM MEDM screen.

  15199   Fri Feb 7 15:00:16 2020 gautamUpdateLSCMore high BW POY experiments

To study the evilution of the AO path TFs a bit more, I've hooked up POY11_Q Mon to IN1 of the CM board. I will revert the usual setup later in the evening.

Update 1730: I've returned the cabling at 1Y2 to the nominal config, and also reverted all EPICS settings that I modified for this test. Y-arm POY locking works. Attachment #1 shows the summary of the results of this test - note that the AO gain was kept fixed at +5dB throughout the test. I have arbitrarily trimmed the length of the frequency vector for some of these traces so that the noisy measurement doesn't impede visual interpretation of the plots so much. At first glance, the performance is as advertised. I basically followed the settings I had here to get started, and then ramped up various gains to check if the measured OLTF evolved in the way that I expected it to. The phase lead due to the AO path is clearly visible.

Some important differences between this test and the REFL11 blending is (i) in the latter case, there will also be a parallel loop, CARM_A, which is effecting some control, and (ii) the optical gain of CARM-->REFL11_I is much higher than L_Y-->POY. So the initial gain settings will have to be different. But I hope to get some insight into what the correct settings should be from this test. I think IMC servo IN2 gain and AO gain slider on the CM board are degenerate in the effect they have, modulo subtle effects like saturation.

One possibility is that the gain allocation I used yesterday was wrong for the dynamic range of the CARM error signal. In some initial trials today, when I set the CM board IN1 gain to -32dB (as in the case of attempting the CARM RF handoff) and compensated for the reduced POY PDH fringe amplitude by increasing the digital gain for the CM_Slow path, I found that there was no phase advance visible even when I ramped up the IMC IN2 gain to +10dB. So, for the CARM handoff too, I might have to start with a higher CM board IN_1 gain, compensate by reducing the CM_Slow digital gain even more, and then try upping the IMC IN2 gain.

P.S. When the excitation input to the CM board was enabled in order to make TF measurements, I saw significant increase in the RMS of the error signal. Probably some kind of ground loop issue.

Attachment 1: AO_TFs.pdf
AO_TFs.pdf
  15202   Mon Feb 10 10:07:20 2020 gautamUpdatePSLPMC re-locked

I found the PMC unlocked this morning. It was re-locked using the usual procedure. I feel like this has been happening more frequently in the last month than before. In the past, the cause seems to have been the PZT voltage drifting too close to one of the rails - however, in this case, it looks like an IMC unlock event is what triggered the PMC lockloss (admittedly the PZT voltage was somewhat close to the rail). It would be good if someone can re-connect the PMC Transmission photodiode, it was a useful diagnostic channel we had working fine before the ringdowns started.

I also tweaked the input pointing into the PMC and ran the WFS DC offset relief script.

Attachment 1: PMCunlock.png
PMCunlock.png
  15208   Wed Feb 12 12:13:37 2020 gautamUpdateLSCAO path attempts

Summary:

  1. The PRFPMI can be controlled by a mix of ALS and RF signals and circualting arm powers > 100 can be maintained for several tens of minutes at a stretch.
  2. The complete RF handoff still cannot be realized - I need to study the AO path crossover more carefully to understand what exactly is wrong and what needs to be done to rectify the problem.

Measurements:

Over the last couple of days, I've been trying to see if I can measure the phase advance due to the AO path - however, I've been unable to do so for any combination of CM board IN1 gain and MC Servo board IN2 gain I've tried. Yesterday, I tried to understand the loop shapes I was measuring a little more, and already, I think I can't explain some features.

Attachment #1 shows the TF measured (using SR785, and the EXC_A bank of the CM board) when the CM Slow path has been engaged.

  • All CARM control in this state is digital.
  • For the CM Slow path, the digital filter includes a pole at 700 Hz, pole at 5 kHz and zero at 120 Hz (the latter two for coupled cavity pole compensation).
  • In this conditions, the arm powers are somewhat stable at ~150, but still there are fluctuations of the order of 50%.
  • The "buzzing" as the arms rapidly go in and out of resonance is no longer present though.
  • The UGF of the hybrid REFL11+ALS loop is ~200 Hz, with ~45 deg of phase margin.
  • Turning off the MC2 violin filters gives some phase back. But I don't really understand the flattening of the TF gain between ~250-500 Hz.

Attachment #2 shows error signal spectra for the in-loop PRFPMI DoFs, for a few different conditions.

  • Engaging the REFL11 digital path smooths out the excess noise in the ~30-50 Hz band, which is consistent with the fact that the arm powers stabilize somewhat.
  • However, there is some gain peaking around ~400 Hz.
  • This is in turn imprinted on the vertex DoFs, making the whole system's stability marginal.

I believe that a stable crossover is hopeless under these conditions.

Next steps:

  1. Account for the measured OLTF, understand where the flattening in the few hundred Hz region is coming from.
  2. Repeat the high BW POY experiments, but with the simulated coupled cavity pole - maybe this will be a closer simulation to the PRFPMI transition.
Attachment 1: CARM_OLTF.pdf
CARM_OLTF.pdf
Attachment 2: PRFPMI_errSigs.pdf
PRFPMI_errSigs.pdf
  15209   Thu Feb 13 01:47:39 2020 gautamUpdateALSFast ALS - delay line prep

A few years ago, Koji and I setup a delay line phase shifter, which can be used to impart a (switchable) delay to a signal path. Since we talked about reviving the fast (= high bandwidth) ALS control scheme at the meeting, I reminded myself of the infrastructure available.

  • Schematic
  • Comprehensive note on theory of operation / performance.
  • Past elog threads - #11603 and #11604.
  • Attachment #1 - my modification to the ALS screen to add a slider that controls the channel C1:LSC-BO_1_0_SET. The label is a bit misleading for now - elog11604 tells you the conversion between this slider value and the actual delay in nanoseconds, but I couldn't get a soft channel set up that correctly FLNKed to this record. In the process of trying to do so, I edited the C1_ISC-AUX_ALS.db file, and also restarted the modbus and latch processes on c1iscaux a few times.
  • Attachment #2 - frequency dependent loss for some representative delays. At ~200 MHz, I find the measured loss to be > 8dB, which is ~2dB more than what the D. Sigg note tells me to expect. This is rather a lot of loss, but I guess it's okay. Measurement cable loss was calibrated out with the AG4395A.
  • Attachment #3 - confirmation of constantness of delay as a function of frequency, for some representative delays. The "undelayed" setting corresponds to a fixed delay of ~4 nsec, which is consistent with what the D. Sigg note tells me to expect. Once again, I calibrated out the delay of the measurement setup using the AG4395A.

For a beat note in the regime 10-100 MHz, we should have plenty of range in this module to add a delay such that we zero one quadrature of the ALS DFD output (for a linear error signal). 

I then proceeded to connect the single-ended front panel BNC corresponding to the ALS_X_I DFD channel to the IN2 input of the CM board (this would be what we use for high bandwidth ALS feedback). The conventional ALS system uses the differential output from a rear-panel D-sub, so in principle, both systems could run in parallel. I confirmed that I could see a signal when the IN2 path on the CM board was engaged (monitored using ndscope at the CM_Slow output), and that this signal stabilized when the green laser was locked to the X-arm length, which itself was slaved to the PSL frequency using the usual POX locking scheme. I have not yet routed the LO leg of the ALS_X beat through the delay line phase shifter - see next elog for details.

Update about the ALS MEDM screen slider: the trick was to change the OMSL field of the C1:LSC-BO_1_0 channel to "closed_loop" instead of "supervisory". Once this is done, the DOL value of the same channel can be set to the soft channel C1:ALS-DelayCalc, which sets the 16 bit binary string that controls the delay. Because arbitrary delays are not possible, I think it's more natural for the user to interact with this 16-bit binary string rather than the actual delay itself. So the MEDM screen has been slightly modified from what is shown in Attachment #1.

Attachment 1: delaySlider.png
delaySlider.png
Attachment 2: delayLineLosses.pdf
delayLineLosses.pdf
Attachment 3: delayLineCal.pdf
delayLineCal.pdf
  15210   Thu Feb 13 02:07:26 2020 gautamUpdateLSCAO path transfer function measurement

Summary:

I measured the transfer function of the AO path, and think that there are some features indicative of a problem somewhere in the IMC locking loop.

Details:

Regardless of the locking scheme used, high bandwidth control of the laser frequency relies on the fact that the laser frequency is slaved to the IMC cavity length with nearly zero error below ~50 kHz (assuming the IMC loop has a UGF > 100 kHz). In my single arm experiments, I didn't know what to make of the ripples that became apparent in the measured OLTF as the AO gain was ramped up.

Tonight, I measured the TF of the "AO path", which modifies the error point of the IMC, thereby changing the laser frequency. 

  • An SR785 was used to make the measurement.
  • The signal was injected at the "EXC B" input on the CM board.
  • The CM_SLOW path was disabled, AO gain = 0dB, IMC IN2 gain = 0dB.
  • Between "EXC B" and the IMC error point (which I measured at TP1A on the IMC board), we expect that there are 2 poles at ~ 6 Hz, and one pole at ~ 11 Hz.

Attachment #1 shows the result of the measurement. 

  • This measurement should be the "Closed Loop Gain" [= 1/(1+L) where L is the open loop gain] of the IMC locking loop. For comparison, I've overlaid the inferred CLG from a measurement of the IMC OLG I made in Jun 2019. The magnitude lines up quite well, but the phase does not 🤔 
  • Above 10 kHz, the measurement is as I expect it to be.
  • However, between 1 kHz and 10 kHz, I see some periodic features every 1 kHz, which I don't understand. In the IMC OLTF, these would be sharp dips in the OLTF gain.
  • I was careful not to overdrive the servo, so I believe these features are not a measurement artefact.
  • Combing through past elogs, I couldn't really find any measurements of the IMC OLTF in the 1 kHz - 10 kHz band.
  • I decided to measure the spectrum of the IMC error point (with no excitation input), to see if that offered any additional insight. Attachment #2 shows the result - again, periodic features at ~ 1 kHz intervals.

I didn't use POX / POY as a sensor to confirm that this is real frequency noise, I will do so tomorrow. But it may be that realizing a stable crossover is difficult with so many features in the AO path.

Previous thread with a somewhat detailed characterization of the IMC loop electronics.

Attachment 1: AOpathTF.pdf
AOpathTF.pdf
Attachment 2: IMCinLoop.pdf
IMCinLoop.pdf
  15212   Fri Feb 14 00:53:50 2020 gautamUpdateALSFast ALS - more setup

In the process of setting up some cabling at 1Y2, I must've bumped a cable to the c1lsc expansion chassis. Anyways, the c1lsc models crashed. I ran the reboot script around 530pm PDT. Usual locking behavior was recovered after this. The work at 1Y2 was:

  • Ran a cable from X Beat power splitter ("LO" leg of the analog delay line) to variable delay line. 
  • Ran cable from delay line to demodulator's LO input.
  • Set up the SR785 for some CM board TF measurements.

The IN2 to CM board was already connected to I single ended output of the ALS X demodulator. The ~100 Hz UGF digital locking using the CM_SLOW path is straightforward but I didn't have any success with the AO path tonight. I wonder how high BW this lock can be made without injecting a ton of noise into the IMC loop, given that the EX uPDH only has ~ 10 kHz UGF.

Attachment #1 shows the spectra of the ALS signal 

  • The two "CM Slow" traces are the digitized "SLOW" output of the common mode board, whose IN2 is connected to the demodulated I output of the analog delay line.
  • The delay in the LO line of the analog delay line is adjusted to zero the DC value of this signal to best effort.
  • These spectra are measured with the arm cavities POX/POY locked, and the EX laser locked to the arm cavity using the end PDH box.
  • I simultaneously monitor the output of the digital phase tracker servo, and scale the CM Slow signal such that the spectra line up. The scaling factor required was to multiply the CM_SLOW signal x10 (CM board IN2 gain was set to +6dB, to account for the x2 gain in going from single ended to differential inside the ALS demodulator box).
  • One puzzline feature is why switching on the ADC whitening makes the ALS spectrum noisier (even though it clearly changes the digitization noise floor). There is a peak that appears at ~ 8 kHz with the whitening on, and it may also be downconverted noise from some peak at higher frequencies I guess (if the AA isn't sharp enough). 

Attachment #2 is an OLTF measurement.

  • In the blue trace, the arm length is controlled by using the CM Slow signal as an error signal, applying feedback to IMC length via MC2.
  • In the red trace, I turned the digital MC2 violin notches off, and added upped the IMC IN2 gain to -12 dB (AO gain slider = 0dB).
  • This was as high as I could go before the PC drive RMS began to go crazy.
  • But still, there isn't any significant phase advance.
  • It is possible I need to tack on a low-pass filter to prevent noise injection at higher frequencies...
Attachment 1: CMSlow_ALSnoise.pdf
CMSlow_ALSnoise.pdf
Attachment 2: OLTFmeas.pdf
OLTFmeas.pdf
  15214   Fri Feb 14 14:52:41 2020 gautamUpdateALSALS OOL noise with arms locked

Unlikely, the alignment was probably just not good. I restored the alignment and now the arms can be locked to IR frequency.

Quote:

Even though we were not able to lock the the IR beat (by enabling LSC) during the day possibly because of increased seismic activity

  15227   Wed Feb 26 22:05:06 2020 gautamUpdateIOOIMC checks

Today, I did the following tests (and so was touching electronics/cables at/around 1X2):

  • Measured the IMC OLTF.
  • Measured the TF from injection at IN2 to response at the IMC error point (T-eed the I out of the IMC demodulator as there is no longer a monitor point available).
  • Measured the IMC in loop error signal with 0.25 Hz resolution from DC-2kHz.
  • Confirmed that the IMC IN2 (a.k.a. AO path) gain slider performs as advertised. This is a useful test to run post Acromag switchover on Friday.

Results to follow.

After this work, I reverted the EPICS channels to the usual values. The IMC can be locked.

  15228   Wed Feb 26 22:09:52 2020 gautamSummaryBHDProjected IFO noise budget, post-BHD upgrade

The quantum noise curves here are not correct. c.f. amplitude quadrature noise budget.

  15229   Wed Feb 26 23:50:51 2020 gautamUpdateIOOIMC checks

In the style of the KA characterization of the CM board, the AO path gain EPICS slider (IN2) of the IMC servo board was stepped by 1 dB through the full available range of -32 dB to +31 dB. For each value of the requested gain, I measured the TF from the injected signal (to IN2) to TP1A on the IMC servo board. I used the BNC connector for this test, whereas we use the LEMO connector for the AO path. The source was tee-d off at the SR785 side, with one leg going to IN2 of the IMC servo board, and the other going to CH1A of the SR785. TP1A of the IMC board was connected to CH2A of the SR785. 

Attachment #1 - Measured gain vs requested gain.

  • When debugging the CM board, it was this kind of test that revealed the faulty latch ICs.
  • -12 dB to -11 dB gain step looks anomalous, but overall the trend seems linear.
  • I was confused by why there should be a discontinuity at this stage of the gain stepping - seems like the scanning script I use changes the SR785 excitation amplitude at this point (from 300mV to 100mV). But why should the size of the excitation signal change the magnitude of the transfer function? Is this indicative of some loading issue?
  • There is an overall offset between the requested gain and measured gain of ~2-3 dB. This seems large.
  • There is nothing in the schematic which would have me expect this - there is a 1/2 divider at the positive input of the differential receiving stage, but this just cancels out the non-inverting gain of x2.

Attachment #2 - Frequency dependent transfer functions

  • There seem to be two families of curves - they correspond to <-12 dB and >-12 dB.
  • The feature at 90 kHz is strange - need to look at the schematic to see what this could be.

The motivation here is to try and figure out why I cannot engage the AO path smoothly in the CARM handoff part of lock acquisiton. I plan to use this information to do some loop modeling and project laser frequency noise coupling in various stages of the lock acquisition process.

Attachment 1: sliderCal.pdf
sliderCal.pdf
Attachment 2: AO_inputTFs.pdf
AO_inputTFs.pdf
  15230   Thu Feb 27 15:50:37 2020 gautamUpdateElectronicsFSS box power cable removed

In 1X1, there is a box labelled "FSS REF" below a KEPCO HV supply. This box had a power cable that wasn't actually connected to any power. I removed said cable.

  15231   Thu Feb 27 17:50:36 2020 gautamUpdatePSLc1psl setup setup

[many people]

in prep for the install tomorrow, we did the following:

  • Install the c1psl Supermicro in the 1X2 rack (Attachment 1). To make room we removed the anti-image filter and mounted it on the OMC rack.
  • Set up a local workstation (monitor+mouse+keyboard) for the Supermicro so we can do some local testing (Attachment 2).
  • Clear up the immediate area around the 1X1/1X2 rack, setup a cart for the Acromag.
  • Make sure there are sufficient adaptor boards cables (DB37, DB15, DB9, DB25, ethernet) etc available at the cart.
  • Label cables, connect on Acromag chassis end (Attachment 3).
  • Keep some large (A3) printouts of the channel mapping handy by the cart.
  • made sure we have open fuse-able DIN rail connectors for +/-15 V DC and +/-24 V DC for the Acromag box (we are waiting on some thinner gauge cabling for the 24V supply, once that arrives, we will power the box from the Sorensens. For now, they are powered by bench supplies on the cart).
  • made sure c1psl1 (still this name for the Supermicro) is ssh-able.

Barring objections, tomorrow (Friday 28 Feb 2020) morning I will commence the switch (I still want to work on the IFO tonight).

Attachment 1: 20200227_173535.jpg
20200227_173535.jpg
Attachment 2: 20200227_173454_HDR.jpg
20200227_173454_HDR.jpg
Attachment 3: 20200227_172659.jpg
20200227_172659.jpg
  15232   Thu Feb 27 17:59:02 2020 gautamUpdateLSCSome AO thoughts

While my checks of the AO signal path have thrown up some unanswered questions, I don't think there's any evidence in those measurements to suggest the AO crossover can't be realized. Thinking about it today though - I was wondering if it could be that the IN1 gain slider of the CM board is configured optimally. Looking back at some data, when the ALS CARM offset is zeroed, the CM_SLOW digitized data has a peak-to-peak range of ~200 cts. This is paltry. One possibility is that as I am upping the AO path gain, I'm simply injecting the electronics noise of the CM board into the IMC error point. I'd say it is safe to up the IN2 gain by 20dB to -12 dB, in which case the peak-to-peak would be ~2000 cts, still only 10% of the ADC range. It'll be straightforward to re-scale the CARM_B loop gain to account for this. Let's see if this helps.

I'd also like to measure the spectrum of the REFL11_I signal in a few different states. I think I should be able to do this using the OUT2 of the CM servo board. These are the things to try tonight:

  • Try CARM RF handoff with CM_SLOW gain starting at -12dB instead of -32dB.
  • Measure spectrum of REFL11_I when it is in the linear range.
  15233   Thu Feb 27 22:45:40 2020 gautamUpdateALSALS noise high

There was some UNELOGGED work at EX today. The DFD outputs were also hijacked for loss measurement. Unclear who the culprit was, but there is now a broad noise bump centered around ~180 Hz in the ALS X noise curve, which certainly wasn't there yesterday. Maybe let's keep the few working systems working, it is annoying to have to deal with these auxiliary issues every night. I'll push ahead with locking, hopefully the ALS noise is "good enough".

Attachment 1: ALSnoise.pdf
ALSnoise.pdf
  15234   Fri Feb 28 08:05:22 2020 gautamUpdatePSLc1psl setup setup

And so it begins.

Quote:

Barring objections, tomorrow (Friday 28 Feb 2020) morning I will commence the switch

  15235   Fri Feb 28 10:04:41 2020 gautamUpdatePSLc1psl setup setup

Summary:

There are several problems evident already.

  1. Several EPICS database entries were missing. WTF.
  2. After fixing the missing entries, the PMC could be locked. However, the IMC could not be locked.
  3. I think the FSS Interface card is not configured correctly.

For now, I've returned the old c1psl connections, the PMC and IMC are both locked. Need to do some debugging on the bench.

  15236   Fri Feb 28 19:37:18 2020 gautamUpdatePSLNew c1psl installed
  1. The new c1psl Acromag crate is now interfaced to the Eurocrate electronics in 1X1 (formerly VME c1psl) and 1X2 (formerly c1iool0).
  2. The PMC and IMC can be locked. We will investigate stability / duty cycle over the weekend.
  3. There were a few issues with the wiring - specifically, the worng kind of Acromag BIO unit (sourcing, whereas we want sinking) was used for the FSS board switches. Once Jordan fixed this issue, the IMC could be locked.
  4. I began to do the detailed tests of the IMC Servo card channels - there may be some issues with the boost stages, but I ran out of time yesterday, so tbc Monday.

On Monday, we will remove the old c1psl and c1iool0 machines from the electronics rack and install the Acromag crate in a more permanent way. We will also clean up some of the old cabling and cross connects, althoug the situation seems so complicated (some cross connects are also used by the rtcds c1ioo expansion chassis) that I am inclined not to remove any cables.

The area around 1X1/1X2 has a lot of dangling cables and general detritus. Be careful if you are walking around there. We will clean up on monday.

  15237   Mon Mar 2 16:14:47 2020 gautamUpdateCDSsome target directory cleanup

$TARGET_DIR = /cvs/cds/caltech/target

  • $TARGET_DIR/c1psl and $TARGET_DIR/c1iool0 moved to $TARGET_DIR/preAcromag_oldVME/
  • $TARGET_DIR/c1psl1 moved to $TARGET_DIR/c1psl 
  • $TARGET_DIR/c1psl/*.service and $TARGET_DIR/C1_PSL.cmd modified - i executed :%s/c1psl1/c1psl/g in vim.
  • $TARGET_DIR/preAcromag_oldVME/c1psl/autoBurt.req and $TARGET_DIR/preAcromag_oldVME/c1iool0/autoBurt.req catenated into $TARGET_DIR/c1psl/autoBurt.req. The first snapshot at 16:19 has been verified.

It remains to (Jon is taking care of these)

  • add a line to modbusIOC.service on the new c1psl machine that restores the latest burt snapshot on startup (this necessitated installation of a debian jessie libXp6 package on our debian buster machine because our shared EPICS is soooooooooooooo oooooooold)
  • change the hostname from c1psl1 to c1psl
  • update martian.hosts
  15238   Mon Mar 2 16:29:40 2020 gautamUpdateElectronicsc1psl VME crate removed, Acro-crate installed

[JV, JWR, YD, GV]

  • The old c1psl VME crate, and all the ribbon cables connected to it were removed from 1X1. They are presently dumped in the office area - we will clear these in the next few days, once the c1iool0 crate also gets removed from the rack.
  • The Acromag crate was capped on the top and bottom, had ears bolted on, and was installed on support rails in the newly cleared up space.
  • The strange orientation of the crate (with the intended backside facing the front of the rack) is to facilitate easy access to the "spare" channels we have in this box, e.g. for a future ISS or laser amplifier.
  • Remaining connections to make are (these will be done tomorrow along with the extrication of the c1iool0 VME crate):
    • PMC trans PD
    • FSS RMTEMP 
    • PSL shutter
    • 2W Mephisto diagnostic connector
    • 24 V DC from Sorensens via DIN connector (we are waiting on a new power cable to arrive).
Attachment 1: c1psl.pdf
c1psl.pdf
  15239   Mon Mar 2 16:35:12 2020 gautamUpdateCDSc1psl test status

Channel list with test status
== Test Status ==

[done] Lock PMC and IMC
[done] IMC Servo board test
[done] IMC LO Det Mon channel check
[0th order] WFS quadrant DC mon
[none] WFS I/F monitors
[0th order] WFS attenuators
[none] IOO QPD channels
[done] FSS readbacks 
[done] PMC readbacks


Some more detailed elogs about the individual tests will follow.

Basically, I have characterized the IMC Servo board in detail. The summary finding is that the IN2 (=AO gain) slider needs to be investigated. 

All other channels need to be verified in a more thorough fashion than my basic checks which were just to guarantee the core interferometer functionality, which is important to me.

  15240   Mon Mar 2 19:32:41 2020 gautamUpdateCDSc1rfm errors

Had to reboot both end machines and the c1rfm model to get the TRX and TRY signals to the LSC models. Now both arms can be locked using POX/POY respectively.

Attachment 1: RFMerrors.png
RFMerrors.png
  15242   Tue Mar 3 17:20:14 2020 gautamUpdateElectronicsMore cabling removed

Jordan and I removed another 10 kg of cabling from 1X2. The c1iool0 crate now has all cabling to it disconnected - but it remains in the rack because I can't think of a good way to remove it without disturbing a bunch of cabling to the fast c1iool0 machine. We can remove it the next time the vertex FEs crash. Cross connects have NOT been removed - we will identify which cross connects are not connected to the fast system and trash those. 

Do we want to preserve the ability to use the PZT driver in 1X2?

  15245   Tue Mar 3 19:11:48 2020 gautamUpdateLSCSome locking prep
  • Re-aligned and locked the arm cavities for IR and green.
  • Re-set trans normalization because after the c1iscex and c1iscey reboots, these didn't come back to the old values.
  15247   Wed Mar 4 11:16:37 2020 gautamUpdatePSLPMC realignment

I realigned the input pointing into the PMC this morning. Usually, the way I do this is to minimize any discernible mode structure in the PMC reflection CCD image. Today, I noticed that making the DC reflection go down also makes the DC transmission go down. Possibilities:

  • we are sampling slightly different spots inside the PMC cavity which change the buildup by ~2-3%.
  • we are misaligned on the transmission/reflection photodiode.
  • ??
Attachment 1: PMCrealignment.png
PMCrealignment.png
  15248   Wed Mar 4 12:25:11 2020 gautamUpdateCDSBIO1 on c1psl is dead

There was some work done on the Acro crate this morning. Unclear if this is independent, but I found that the IMC servo board IN1 slider doesn't respond anymore, even though I had tested it and verified it to be working. Patient debugging showed that BIO1 (and only that acromag unit with the static IP 192.168.114.61) doesn't show up on the subnet in c1psl. Hopefully it's just a loose network cable, if not we will switch out the unit in the afternoon. 

Jon is going to make a python script which iteratively pings all devices on the subnet and we will put this info on an MEDM screen to catch this kind of silent failure.

  15249   Wed Mar 4 16:18:31 2020 gautamUpdateElectronicsMore cabling removed

After discussing with Koji, I removed the PZT driver and associated AI card from the Eurocrate at 1X2. The corresponding backplane connectors were also removed from the cross connects. An additional cable going from the DAC to IDC adaptor on 1X2 was removed. Finally, some cables going to the backplane P1 and P2 connectors for slots in which there were no cards were removed. 

Finally, there is the IMC WFS whitening boards. These were reconfigured in ~2016  by Koji to have (i) forever whitening, and (ii) fixed gain. So the signals from the P1 connector no longer have any influence on the operation of this board. So I removed these backplane cables as well.

Some pics attached. The only cross connect cabling remaining on the south side of 1X2 is going to the fast BIO adaptor box - I suspect these are the triggered fast whitening switching for the aforementioned WFS whitening board. If so, we could potentially remove those as well, and remove all the cross connects from 1X1 and 1X2.

Update 1720: indeed, as Attachment #2 shows, the RTCDS BIO channels were for the WFS whitening switching so I removed those cables as well. This means all the xconnects can be removed. Also, the DAC and BIO cards in c1ioo are unused.

Quote:

Do we want to preserve the ability to use the PZT driver in 1X2?

Attachment 1: 1X2EuroBefore.JPG
1X2EuroBefore.JPG
Attachment 2: IOO.png
IOO.png
  15250   Wed Mar 4 16:54:43 2020 gautamUpdateCDSc1auxex temporarily disconnected

To debug a problem with the new c1psl (later elog), we needed a Supermicro EPICS server that was using the shared EPICS/modbus/asyn binaries rather than a local install. Of those available in the lab (c1iscaux, c1vac, c1susaux being the others), this was the only one which uses the shared install. So I 

  • turned the slow bias voltages to 0
  • shutdown the watchdog
  • disconnected the Acromag crate in 1X9 from the 192.168.114.xxx subnet at the supermicro end
  • connected a test ADC to the local subnet using a different ethernet cable (leaving the original one dangling)
  • ran some software tests to see if we could open up a communication line to the test ADC using modbus without any errors being thrown
  • removed the test ADC and restored the ethernet connection.

At which point Jon reset the software end, I restored the slow bias voltage and re-enabled the local damping. The optic seems to have damped okay. The Oplev spot is back in ~center of the QPD and the green beam can be locked to a TEM00 mode (so the alignment is okay - the IR beam is unavailable while c1psl issues are being sorted but I judge that things are back to the nominal state now).

  15251   Wed Mar 4 20:42:53 2020 gautamUpdateElectronicsC1PSL acromag crate is sitting on the floor

Jon is going to write up the details of todays adventures. But the C1PSL Acromag chassis is sitting on the floor between the IMC beamtube and the 1X1 electronics rack, and is very much a trip hazard. Be careful if youre in that area.

  15254   Thu Mar 5 11:27:48 2020 gautamUpdateElectronicsC1PSL acromag crate is no longer sitting on the floor

[jordan, gautam]

The C1PSL crate has now been installed in a more permanent way in the rack.

  • Top and bottom covers were re-attached after work yesterday.
  • +/- 24 V DC and +15 V DC power connectors were screwed on for better robustness (I had removed the fuse for the -24V supply as part of debugging yesterday, this was reconnected).
  • PSL diagnostics DB 25 cable was re-run appropriately over the cable tray and connected to the unit.
  • The chassis sits on some rails - these rails are mounted to the rack using rack nuts but that means the ears on the Acromag chassis no longer line up with any rack nut slots, and so the chassis is not bolted on to the rack.
  • We also took this opportunity to remove the c1iool0 VME chassis from 1X2 - given that the DAC and BIO cards of c1ioo (rtcds system) are unused, I felt comfortable disconnecting them and that made the removal relatively easy. The CDS overview MEDM screen reports no errors after this work.

After this work, I disabled logging and restarted the modbus service (and copied the current version of the systemd service file to the target directory for backup). The PMC and IMC lock alright. The system is now ready to be tested in-situ. I will separately continue my IMC Servo board tests in the evening.

One thought about how to protect against this kind of silent failure - how about we always run the modbus service with logging enabled, and then send out a warning email and stop the service if the logfile size suddenly blows up (which is characteristic of when the communications process dies)? This should be done in addition to the ping-ing of the individual IPs.

Regarding the burt-restore step that the systemd service runs after starting up the IOC - this is not even that useful, at least in the way it is currently setup (restore the "latest" burt snapshot file). If the maintenance takes >1hour as it often does, the "latest" snapshot for the system under maintenance is just garbage. So either the burt-restore should be for a "known good time" (dangerous because this will require frequent updates of the systemd service every time we find a new safe state) or we should just do it manually (my preference). Then there is no need to install custom packages on the server machine. Anyway, for now, I have not commented this step out.

Jordan is going to take pictures of all the electronics racks and update the relevant wiki pages.

Quote:

Jon is going to write up the details of todays adventures. But the C1PSL Acromag chassis is sitting on the floor between the IMC beamtube and the 1X1 electronics rack, and is very much a trip hazard. Be careful if youre in that area.

  15257   Thu Mar 5 19:51:14 2020 gautamUpdateElectronicsIMC Servo board being tested

I am running some tests on the IMC servo board with an extender card so the IMC will not be locking for a couple of hours.

  15258   Fri Mar 6 01:12:10 2020 gautamUpdateElectronicsIMC Servo IN2 path looks just fine

It seems like the AO path gain stages on the IMC Servo board work just fine. The weird results I reported earlier were likely a measurement error arising from the fact that I did not disconnect the LEMO IN2 cable while measuring using the BNC IN2 connector, which probably made some parasitic path to ground that was screwing the measurement up. Today, I re-did the measurement with the signal injected at the IN2 BNC, and the TF measured being the ratio of TP3 on the board to a split-off of the SR785 source (T-eed off). Attachments #1, #2 shows the result - the gain deficit from the "expected" value is now consistent with that seen on other sliders.

Note that the signal from the CM board in the LSC rack is sent single-ended over a 2-pin LEMO cable (whose return pin is shorted to ground). But it is received differentially on the IMC Servo board. I took this chance to look for evidence of extra power line noise due to potential ground loops by looking at the IMC error point with various auxiliary cables connected to the board - but got distracted by some excess noise (next elog).

Attachment 1: AO_inputTFs_5Mar.pdf
AO_inputTFs_5Mar.pdf
Attachment 2: sliderCal_5Mar.pdf
sliderCal_5Mar.pdf
  15259   Fri Mar 6 01:19:19 2020 gautamUpdateIOOExcess laser frequency noise

Summary:

Sometime between 1PM and 6PM on Tuesday, excess laser frequency noise shows up in MCF at around 800 Hz, as shown in Attachment #1. Sigh.

Details:

While I show the MCF spectrum here, I confirmed that this noise is not injected by the IMC loop (with the PSL shutter closed, and the IMC servo board disconnected from the feedback path to the NPRO, the PMC error and control points still show the elevated noise, see Attachment #2). I don't think the problem is from the PMC loop - see Attachment #3 which is the ALS beat out-of-loop noise with the PMC unlocked (the PSL beam doesn't see the cavity before it gets to the ALS setup, and we only actuate on the cavity length for that loop, so this wasn't even really necessary).

Was there some work on the PSL table on Tuesday afternoon that can explain this

Attachment 1: MCF.pdf
MCF.pdf
Attachment 2: ExcessFreqNoise.pdf
ExcessFreqNoise.pdf
Attachment 3: ALSnoise.pdf
ALSnoise.pdf
  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.

ELOG V3.1.3-