Adjusting the PMC length lockpoint to lock closer to the center of the resonance made some intensity noise in the PMC transmission disappear.

The fact that injection into PMC length loop results in a huge AM at the same frequency means that there's a big length offset somewhere.

I tried to adjust the length offset using K1:PSL-PMC_MIXER_OFS. First screenshot shows the PMC_OUT_DQ and PMC_REFL_DC_OUT_DQ with the initial offset value of 2.8mV when 100Hz injection was enabled.

I had to max out the offset to 20mV to almost eliminate the first order coupling (2nd attachment, same 100Hz injection) but I feel as if I need somewhat more range.

After this adjustment, I disabled the injection and did A->B->A->B test of the PMC transmission power (3rd attachment). Red and green are with the good offset (20mV), blue and brown are with the initial offset (2.8mV). Big humps at both sides of 60Hz peak (~54Hz and ~66Hz-ish if I just eyeball them), some lines (e.g. 59-ish Hz, two lines between 100 and 120 Hz, a huge line at 200-something Hz and some others), and a broad bump between 300 and 400Hz disappeared. There might be differences below 20Hz but I'm not sure.

Anyway, I wonder where this offset is from, probably it's worth measuring the effect of RFAM by unlocking PMC, adjust the offset until e.g. PZT output is minimized, then block the light coming to PMC and repeat the process.

I was bothered that there was a very strong 100Hz amplitude noise in the IMC transmission, and it turns out that it's visible in K1:LAS-POW_PMC_OUT_DQ as well as K1:LAS-POW_PMC_REFL_DC_OUT_DQ (1st attachment). Note that this 100Hz thing is totally dominating the RMS.

(If you unlock PMC, PMC_OUT does get smaller, but there's still something, maybe this is a straight-shot? See the 2nd attachment where orange and black are when PMC is unlocked.)

At 2023/Sep/06 05:57:37 UTC or 14:57:37 JST (3rd plot), somebody started injecting something from high-frequency down to 100Hz repeatedly.

The scan setting was changed several times but we've never had an excitation-free time since then as if the excitation got stuck at 100Hz.

Stefan disabled K1:PSL-PMC_TEST2_ON and 100Hz was gone (4th attachment).

(Ushiba-san found that the strange IN2 leakage-like phenomenon he reported above was due to the SERVO_IN2GAIN_OFS_COMP that works even when IN2 input is off. I manually zero-ed all non-zero components of K1:IMC-SERVO_IN2GAIN (1st attachment GAIN-26 to GAIN-32) and OUT2 didn't respond to IN2 gain when IN2 was disabled.)

Summary:

I scanned the IN2 gain of the IMC board while the IMC was locked and measured the error point offset. Based on that, I set K1:IMC-SERVO_IN2GAIN to -16dB (6dB down from -10dB) to minimize the offset, and K1:LSC-CARM_SERVO_FASTGAIN to +11dB (6dB up from +5dB) to compensate.

After these changes I don't see any meaningful jump in IMC QPDA quadrants when enabling IN2.

In the future, we must change the frontend such that SERVO_IN2GAIN_OFS_COMP works only when IN2 input is turned ON. That way, we can use the feature to compensate for the electronics offset for all gains, we don't have to worry about this.

Details:

With offset compensation for IN2 disabled, I scanned the IN2 gain while the IMC was locked, and looked at OUT2 (2nd attachment). Just by looking at it, -16dB seems to be the sweet spot (3rd attachment, which is just a zoomed-in view of 2nd attachment). Note that I couldn't go more than 15dB as the offset becomes so big IMC would lose lock . Also note that IN1 gain (not IN2 gain) was 11dB during the scan.

Just to list a few numbers:

For now, I set K1:IMC-SERVO_IN2GAIN to -16dB (from the original -10) and K1:LSC-CARM_SERVO_FASTGAIN to 11dB (from the original 5dB). IMC QPD1 quadrants don't respond to IN2 enabling any more (4th attachment). Victory! Let's hope that this won't saturate the FAST out of the CARM board.

After the scan, SERVO_IN2GAIN_OFS_COMP table was reverted back (by manually punching numbers in).

In the future, if we change the frontend such that SERVO_IN2GAIN_OFS_COMP works only when IN2 is enabled, we can use that feature to counter whatever offset coming from IN2 path and we can freely choose the gain w/o worrying about offsets. The scan was already done (239 sec starting 2023/Sep/08 00:01:34 UTC) so you can use that. Just in case nobody looks at the data before it's lost from the disk, I saved the dtt template as /users/kawabe/IMC_IN2_scan.xml.

Summary:

Is 5mV jump in the IMC error point reasonable? The answer is it's not totally unreasonable though we have to be unlucky.

In the worst case (all AD829 opamps for the IN2 buffer, differential->single conversion and whitening stages have the maximum 1mV input offset voltage and they all add up in the same sign), the offset would be ~7.5mV for the IN2 gain of -10dB.

As such, the problem seems to be that the IMC error signal is too small before IN2 is added. If we can reduce the analog gain for the NPRO PZT drive path (e.g. by a factor of 2 or 4), reduce the FAST gain, increase the IN1 gain and e.g. increase the FAST gain of CARM board at the same time, it would be good (but you'll reduce the range of the PZT control, which may or may not impact the locking).

Another mitigation strategy, though not a great one, is to increase IN2 gain (K1:IMC-SERVO_IN2GAIN, -10dB as of now) and decrease  CARM FAST gain (K1:LSC-CARM_SERVO_FASTGAIN, +5dB as of now) at the same time to keep the total gain for CARM->IMC path constant, and search for a combination that minimizes the offset. For example, if you set the K1:IMC-SERVO_IN2GAIN to -8dB, the worst case IN2 offset coming from the IMC board opamps themselves self would be 3.6mV, not 10mV.

Details:

IMC servo board is https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=3567. I looked at the circuit diagram with Kamiizumi-san and Tomura-san.

IN2 chain upstream of the IN2 summation point comprises the differential receiver (1st attachment), differential->single ended conversion (1st opamp on the 2nd attachment), whitening stages (2nd and 3rd attachment) and the buffer (last opamp of the 3rd attachment).

All opeamps are AD829 with 1mV or smaller input offset voltage. Diff receiver output offset is up to 2mV, diff->single adds another 2mV, these cannot be bypassed so they will produce up to 4mV of offset at the output of the diff->single converter. That will be amplified according to the whitening stages (i.e. if the whitening gain is -10dB, up to 4mV will become up to 4mV*10^(-10/20)=1.3mV in the output of the last opamp in the 3rd attachment).

Likewise, each whitening stage with negative dB (-16dB, -8dB) will produce up to 1mV in the output of the opamp, which will go through the gain stages downstream.

Each whitening stage with positive dB (16dB, 4dB, 2dB, 1dB) will produce up to 1mV times the gain of that stage in the output of the opamp (e.g. for 8dB stage, it will be 1mV*10^(16/20)=2.5mV), which will go through the gain stages downstream.

Final buffer in the chain will produce up to 1mV.

The offset will of course depend on the whitening gain (as well as the input offset voltage of opeamps involved). As such, you can change IN2 gain while monitoring OUT2 and see which gain will produce a better offset.

With -10dB gain, -16dB, 4dB and 2dB stage will be used. In this case the offset would be 4mV*10^(-10/20) + 1mV*10^(6/20) + 1mV*10^(6/20) + 1mV*10^(2/20) + 1mV ~ 7.5mV in the worst case.

With -16dB gain, it would be 4mV*10^(-16/20) + 1mV + 1mV ~ 2.6mV in the worst case. With -8dB gain it would be up to 3.6mV.

That there should be up to 1mV offset coming from the HPF output of the CARM FAST path into IN2 of IMC board, too, but that offset won't depend on CARM FAST gain.

Summary:

All IMC QPD1 quadrants jump by non-negligible amount when IN2 of the IMC board is enabled, even though they don't kick ASC as hard as it used to because the jumps are well balanced. I confirmed that this common jump in WFS quadrants is quantitatively consistent with the jump in the IMC length signal.

What was done:

For the length error point jump, I used OUT2 of IMC servo board (which is connected to IN1).

In the first attachment, left is the same plot as shown in the "after demod phase was adjusted" screenshot in https://klog.icrr.u-tokyo.ac.jp/osl/?r=26638, but the right plot shows the transfer function from OUT2 to each quadrant at the injection frequency of 10Hz. Everything is within 90+-2dB range and out of phase.

OTOH, if you look at the second attachment (which is the same thing as the 2nd attachment in the parent alog), OUT2 jumped by ~+5mV while all QPDA1 I error signals jumped in negative direction by ~160 counts or so, i.e. the DC jump ratio is -160/5e-3=-32000, i.e. 90dB and out of phase.

Summary:

Some additional notches seem to have been accidentally added to ITMX MN T damping filter when Aso/Kawabe replaced 21.4Hz and 22.8Hz notches with a single bandstop filter to block 23Hz oscillation (https://klog.icrr.u-tokyo.ac.jp/osl/?r=26557). It's quite likely that this is a result of copy/paste job. Anyway, this made a heavy impact on the damping phase for MN T damping loop at 1.5Hz, causing the slow oscillation.

Removing unnecessary notches from T immediately made things get back to normal.

Details:
In the firstAttachment, 1.5Hz oscillation wasn't there until ~2023/Aug/31 13:45:00 JST (04:45:00 UTC). Prior to that, a big 23Hz oscillation was present, which was completely squashed after Aso/Kawabe inserted 21-24Hz bandstop filter to L, P, T and Y ITMX MN T damping filters (-5D20h22m mark).

Ushiba and Kawabe looked at ITMX MN T damping filter before Aso-Kawabe mod (04:34:00 UTC) and after 1.5Hz oscillation appeared (04:46:00 UTC), and it turns out that the bandstop is NOT the only difference, there were three additional (seemingly unnecessary) notches at 1.67, 2.14 and 2.49Hz after Aso-Kawabe mod (2nd attachment, middle). We removed these additional notches (2nd attachment right).

After the removal, 1.5Hz oscillation was gone. In the 3rd attachment, green -> before Aso/Kawabe, blue -> after, red -> now.

Other MN T damping filters changed by Aso/Kawabe:

ITMX_MN_DAMP_L, P and Y filter were changed w/o error (i.e. replaced two notches with a single bandstop, no unnecessary notch added, no necessary notch removed).

R-> no change, V-> no damping.

IMC WFS (QPD1) demode phase was off by ~45deg for all quadrants.

What was done: Injected a 10Hz signal into DGCARM_EXC (which is connected to EXCB of Summing node?) which is routed to CARM servo board which is routed to MC servo board In2. We're basically making frequency modulation on laser which should be detected in I-phase for IMC WFS. Demod phase was changed to roughly minimize Q phase. Before the measurement, IMC ASC was turned off, IMC servo IN2 gain was set to 0dB (nominally -10) and the awg amplitude was set to 100. After the measurement IN2 gain was set back to -10dB.

1st attachment -> before the demod phase adjustment of IMC QPD1. All quadrants were off by ~45deg.

2nd attachment -> after the demod phase adjustment.

Demod phase adjustment and/or Ushiba san's manual alignment using IP1 PZT seems to have helped.

1st attachment shows the state of things before today's work. IMC servo IN2 is turned on (left bottom), IMC servo error point changed by 5mV or so (top right), and all quadrants of WFS moved in the same direction in I-phase (left middle), i.e. this is a length-like signal not alignment. However, quadrants are not perfectly balanced in RF. If you look at the quadrants closely, red (I1) and yellow(I3) were well balanced before the IN2 is turned on, but yellow got larger (more negative) than red after. Likewise, purple (I2) got more negative than green (I4) after. This resulted in non-zero YAW error, which was integrated until it hit the limiter (top left green). IMC transmission/reflection went down/up because of this. Also, with the ASC on, when we change K1:IMC-SERVO_OFS_COM_CALI_OFFSET by 5 or 6mV we see the exact same thing though I don't have a plot for that.

When we turned on the IN2 while IMC ASC was off, there was a small change in IMC transmission/reflection but not as large as this.

After adjusting the demod phase (2nd attachemnt), the change in the IMC servo error point is the same as before, but the kick to the WFS got much smaller. There's still length-like jump to WFS quadrants, but they're well balanced even after the kick and the impact to the ASC is much, much smaller.

I was wrong about the YAW control being the cause of railing DAC for MN coil, it seems to have been L signal at 26Hz.

MN EUL2OSEM matrix elements for H1/Y and H2/Y are opposite in sign but so are the coil gains (K1:VIS-ETMX_MN_COILOUTF_H1_GAIN=+1 and K1:VIS-ETMX_MN_COILOUTF_H2_GAIN=-0.977). Large differential signal in H1 and H2 COILOUTF means Length (common before the COILOUTF filter), not Yaw. It's L signal that saturated the DAC, I'm a KAGRA rookie after all.

Anyway, the DAC for H1 and H2 (used both for Y and L) railed, and the ETMX started tilting.

I looked at K1:VIS-ETMX_MN_DAMP_[LVTRPY]_OUT_DQ channels and they don't seem to be particularly noisy before the DAC railing (3rd row from the top).

However, if you look at MN_SUMOUT_L_OUT_DQ, we see two bursts of ~26Hz (left, 4th from the top) as large as 1600cts pp. EUL2OSEM matrix elements for L to H1 and L to H2 are both -0.5, but there's a 40dB Anti-DW gain at 26Hz, therefore this length signal alone should have reached 1600/2*100=80000cts pp, OTOH the DAC range is 64kpp, so that was large enough to rail both of the coils.

You could argue that you can see something like 26Hz in MN_DAMP_L and MN_DAMP_T but they don't have the same burst pattern as MN_SUMOUT_L_OUT_DQ. OTOH DARM_IN1 has a similar burst pattern. Could this be a precursor of ~30Hz oscillation that Aso san was talking about?

One of the lock loss patterns we've had since yesterday is that the ETMX is kicked in YAW, green power in X decreases to almost zero, at which point everything goes to hell.

We had a number of these today, too, so I looked at relevant signals. According to Miyoki san, this happened during the transition from ENGAGE_PRMI_3F to PRMI_3F_LOCKED.

In the attached, EX TM oplev shows that the EX started to move in YAW at around -7m18s250ms mark (left, 3rd from top, yellow trace), and GRX started to go down at the same time. By the time GRX reached zero-ish, ETMX has moved by 4.4urad.

If you look at the coil output of TM (middle, 3rd from the top) and its overflow counters (right bottom), you can see that nothing railed. Ditto for IM (right, 3rd from the top) and overflow conters (right, 2nd from the top).

However, MN H1 and H2 coil output (left bottom) seemed to have exceeded +-32k counts and the overflow counters (middle bottom) jumped up to 2k overflows/sec and 300 overflows/sec, respectively. Note that overflow conter is calculated once per second, so it should be showing the oveflow count of the previous second.

Railing is due to YAW control because, as you can see, H1 and H2 moved in the oppoisite directions. (However, since H1 and H2 are also used for length control, at that point MN L control should have failed completely, too.) After the railing of DAC, ETMX moved and moved and finally the GRX reached zero-ish.

I don't know why the YAW control signal got large enough to rail MN DAC, though.

I also have some questions as to why PRCL and MICH signals look so bad and glitchy after PRM is aligned. Is this normal?

Aso-san's explanation is correct, but you might be confused as "P" is reflected by TFP and "S" transmitted in his diagram, which is contrary to what all polarizing beam splitters do including TFP.

This is because Aso-san's "P" and "S" are relative to the PMC beam plane or the table plane (i.e. vertical is S, horizontal is P) but TFP is angled vertically, not horizontally. Reflection of the first TFP goes down toward the table surface, is caught by a steering mirror inside the TFP housing and comes out horizontally. I couldn't find an assembly drawing (there's a drawing for each housing part: D1808563) but I attached a drawing for aLIGO TFP assy which seems to be basically the same as KAGRA's.
 
This means that S for PMC is P for TFP, therefore transmitted, and P for PMC is rejected.