We made a test with the CER unit by changing its output termination. Nominally, it runs into 50 Ohms. In the attached plot just before 70s the terminator was removed briefly and put back again. This resulted in a up-down glitch. Then, this was repeated around 80s. Between 200s and 210s the terminator was removed and replaced by a cable with clips attached to the end. The clips were then shorted repeatedly resulting in pairs of down-up glitches. Looking at alog 21789 and its second attachment we can see two up-down glitches—albeit at a much smaller scale.

Keita went out during a lockloss and started tapping at different points in the RF distribution chain of the 45.5MHz RF signal.

No effect:

• Tap at the outputs of the distribution amp
• Wiggling the large diameter cable that goes between racks

Effect similar to what we see:

• Wiggling the BNC cable connected to the unit in the CER (plot 1)
• Tapping the balun of the cable going to the PSL unit at the field rack (plot 2)

Effect much larger than what we see:

• Removing a terminator from an unused port of the distribution amp (plot 3)
• Tapping the N elbow in the cable run to the PSL unit at the field rack (plot 4)

Only the removal of the terminator was seen in both units. The other glitches were only seen by the unit which is fed by the tapped cable or connector.

The most sensitive point was the tapping of the elbow indicating a possible connector, cable or adapter problem nearby. We should probably redo the extension cable which was inserted to account for the phase delay.

Here's some plots.

It can be a factor of 8 (or 2 or 4 or 16) using DTT with NDS2 (Robert, Keita)

In the attached, the top panel shows the LLO PEM channel pulled off of CIT NDS2 server, and at the bottom is the same channel from LLO NDS2 server, both from the exact same time. LLO server result happens to be correct, but the frequency axis of CIT result is a factor of 8 too small while Y axis of the CIT result is a factor of sqrt(8)  too large.

Jonathan explained this to me:

keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo.caltech.edu L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 2
Channel                  Rate  chan_type
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          2048      raw    real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo-la.caltech.edu L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 3
Channel                  Rate  chan_type
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384   online    real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          2048      raw    real_4
L1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4

As you can see, both at CIT and LLO the raw channel sampling rate was changed from 2048Hz to 16384Hz, and raw is the only thing available at CIT. However, at LLO, there's also "online" channel type available at 16k, which is listed prior to "raw".

Jonathan told me that DTT probably takes the sampling rate number in the first one in the channel list regardless of the actual epoch each sampling rate was used. In this case dtt takes 2048Hz from CIT but 16384Hz from LLO, but obtains the 16kHz data. If that's true there is a frequency scaling of 1/8 as well as the amplitude scaling of sqrt(8) for the CIT result.

FYI, for the corresponding H1 channel in CIT and LHO NDS2 server, you'll get this:

keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo.caltech.edu H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 2
Channel                  Rate  chan_type
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          8192      raw    real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4
keita.kawabe@opsws7:~ 0$ nds_query -l -n nds.ligo-wa.caltech.edu H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ
Number of channels received = 3
Channel                  Rate  chan_type
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384   online    real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ          8192      raw    real_4
H1:PEM-CS_ACC_PSL_PERISCOPE_X_DQ         16384      raw    real_4

In this case, the data from LHO happens to be good, but CIT frequency is a factor of 2 too small and magnitude a factor of sqrt(2) too large.

Part of this that DTT does not handle the case of a channel changing sample rate over time.

DTT retreives a channel list from NDS2 that includes all the channels with sample rates, it takes the first entry for each channel name and ignores any following entries in the list with different sample rates.  It uses the first sample rate it receives ans the sample rate for the channel at all possible times.  So when it retreives data it may be 8k data, but it looks at it as 4k data and interprets the data wrong.

I worked up a band-aid that inserts a layer between DTT and NDS2 and essentially makes it ignore specified channel/sample rate combinations.  This has let Robert do some work.  We are not sure how this scales and are investigating a fix to DTT.

As followup we have gone through two approaches to fix this:

1. We created a proxy we put between DTT & NDS2 for Robert that was able to strip out the versions of the channels that we are not interested in. This was done yesterday and allowed Robert to work. This has allowed Robert to work but is not a scalable solution.
2. Jim and I investigated what DTT was doing and have a test build of DTT that allows it to present a list with multiple sample rates per channel. We have a test build of this at LHO. There are rough edges to this, but we have filed a ECR to see about rolling out a solution in this vein in production (which would include LLO).

I caused a lockloss by moving TMSX too quickly while doing this test.  

I also spent some time earlier in the day (durring maintence recovery) to do some excitations on TMS and the End station ISIs to investigate the noise that seems to come from TMSX.  An alog with results will be coming soon. 

The script finished right before an EQ knocked us out of lock.  Attached are results, we can decide if we are keeping these decouplings durring the maintence window.

The three changes made by the script which I would like to keep are ETMX pit, ETMY yaw, and ITMY pit.  These three gains are accepted in SDF.  Since we aren't going to do the other work described in the WP, this is now finished. 

All the results from the script are:

ETMX pit changed from 1.263 to 1.069 (1st attachment, keep)

ETMX yaw reverted (script changed it from 0.749 to 1.1723 based on the fit shown in the second attachment)

ETMY pit reverted (script changed it from 0.26 to 0.14 based on the 3rd attachement)

ETMY yaw changed from -0.42  to -0.509, based on fit shown in 4th attachment

ITMX no changes were made by the script, 5th +6th attchments

ITMY pit (from 1.37 to 1.13 based on 7th attachment, keep)

ITMY yaw reverted (changed from -2.174 to -1.7, based on the 8th attachment which does not seem like a good fit)

By the way, the script that I ran to find the decoupling gains is in userapps/isc/common/decoup/run_a2l_vII.sh  Perhaps next time we use this we should try a higher drive amplitude, to try to get better fits.

I ran Hang's script that uses the A2L gains to determine a spot position (alog 19904), here are the values after running the script today. 

I also re-ran this script for the old gains, 

So the changes amount to +0.4 mm in the horizontal direction on ETMY, -0.9 mm in the vertical direction on ETMX, and -1.1mm in the vertical direction on ITMY.  

Please be aware that in my code estimating beam's position, I neglected the L2 angle -> L3 length coupling, which would induce

an error of l_ex / theta_L3, 

where l_ex is the length induced by L2a->L3l coupling when we dither L2, and theta_L3 is the angle L3 tilts through L2a->L3a.

Sorry about that...

The 109s delay is a little higher than expected, but not to strange.  I'm not sure where DMT marks the time, as the start/mid/end of the minute it outputs.

The 30s sample rate of the DMT to EPICS IOC is configurable, but was chosen as a good sample rate for a data source that produces data every 60 seconds.

It should also be noted that at least at LHO we do not make an effort to coordinate the sampling time (as far as which seconds in the minute) that happen with the DMT.  So the actual delay time may change if the IOC gets restarted.

EDITED TO ADD:

Also, for this channel we record the GPS time that DMT asserts is associated with each sample.  That way you should be able to get the offset.

The value is available in H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC_GPS

Hang, Evan

We measured the input-referred voltage noise of the summing node and common-mode boards.

• We terminated the input of the SNB that receives REFL9Q (INA2). INA1 was disabled. On the CMB, IN1 was enabled with -22 dB, and IN2 was disabled. The 40 Hz / 4 kHz boost was engaged. The fast gain was 7 dB.
• We measured the noise at the output of the CMB fast output.
• We then took the TF from SNB INA2 to CMB fast out. This is sufficient to get the input referred noise.

According to this estimate, the CARM loop is not shot noise limited; rather, at 1 kHz the noise is about a factor of 3 in ASD above shot noise.

I looked back at the CARM sensing noise data I took (on 12 Aug) using the new gain distribution: 0 dB SNB gain, −13 dB CMB common gain, 0 dB CMB fast gain, and 107 ct/ct digital MCL gain.

[For comparison, the old CARM gain distribution was 0 dB SNB gain, −20 dB CMB common gain, 7 dB CMB fast gain, and 240 ct/ct digital MCL gain.]

☞ For those looking for a message in this alog: something about the current frequency noise budgeting doesn't hang together. The projection based on the CARM sensing noise and the measured CARM-to-DARM coupling TF suggests a CARM-induced DCPD sum noise which is higher than what can be supported by coherence measurements.

☞ Second attachment: As expected, the noise (referred to the input of the SNB) is lower; at 40 Hz, it is about 350 nV/Hz^1/2. However, we are not really shot-noise (or dark-noise) limited anywhere.

☞ Third attachment: I am also including the CARM-to-DARM coupling TF from a few weeks ago. This TF was taken by injecting into the CARM excitation point and measuring the response in OMC DCPD sum, using the old CARM gain distribution. Then I referred this TF to the SNB input by multiplying by the SNB gain (0 dB), the CMB common gain (−20 dB), and the CMB common boost (40 Hz pole, 4 kHz zero, ac gain of 1).

This gives a coupling which is flat at 1.0×10⁻² mA/V, transitioning to 1/f² around 250 Hz. Or, to say it in some more meaningful units:

• Assuming a REFL9Q demodulation coefficient of 2900 V/W, this implies a flat power coupling of 3.4×10⁻⁶ mA/W above 250 Hz, rising like 1/f² below that.
• Assuming a CARM optical gain of 13 W/Hz and an optical pole of 0.48 Hz, this implies a 1/f frequency coupling above 250 Hz, a 1/f³ coupling below 250 Hz, and an overall magnitude of 6.2×10⁻⁵ mA/Hz at 1 kHz.
• Stated in terms of phase coupling (Stefan's favorite), the magnitude of the CARM optical plant is 6.2 W/rad above the cavity pole, which implies a flat phase coupling of 6.2×10⁻² mA/rad above 250 Hz, rising like 1/f² below that.

☞ Synthesis of the above: based on the measurements described above, at 40 Hz we expect a coupling into the DCPD sum of 350 nV/Hz^1/2 × 0.4 mA/V = 1.4×10⁻⁷ mA/Hz^1/2, which is very close to the overall DCPD sum noise of 3.2×10⁻⁷ mA/Hz^1/2.

But what is wrong with this picture? If 1.4/3.2 = 44 % of the DCPD sum noise comes from CARM sensing noise, we should expect a coherence of 0.44² = 0.19 between the DCPD sum and the CARM error point.

☞ First attachment: The coherence between the CARM error point and the DCPD sum is <0.01 around 40 Hz. Now, it is almost certainly the case that not all of the CARM error point noise is captured by LSC-REFL_SERVO_ERR, since this channel is picked off in the middle of the CMB rather than the end. Conservatively, if we suppose that LSC-REFL_SERVO_ERR contains only dark noise and shot noise, this amounts to 180 nV/Hz^1/2 of noise at 40 Hz referred to the SNB error point, or 0.72×10⁻⁷ mA/Hz^1/2 referred to the DCPD sum. This would imply a coherence of 0.05 or so.

☞ What is going on here?: Four possibilities I can think of are:

• I've overestimated the sensing noise.
• I've overestimated the CARM-to-DARM coupling TF.
• I've made an algebra mistake somewhere.
• LSC-REFL_SERVO_ERR is corrupted by noise that is not in the CARM loop.

☞ A word about noise budgeting: In my noise budget, there was a bug in my interpolating code for the CARM-to-DARM TF, making the projection too low below 100 Hz. With the corrected TF, the projected CARM noise is much higher and begins to explain the mystery noise from 30 to 150 Hz. However, given that the above measurements don't really hang together, this is highly speculative.

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes through some unity-gain op-amps and then directly into the ADC. So I don't think we have much chance of seeing the 180 nV/Hz^1/2 of shot/dark noise above the 4 µV/Hz^1/2 of the ADC.

According to the CMB schematic and the vertex cable layout, the CARM error point monitor goes a gain of 200 V/V and then directly into the ADC. So the 180 nV/Hz^1/2 of shot/dark noise appears as 36 µV/Hz^1/2 at the ADC. But as Daniel pointed out, this should be heavily suppressed by the loop. For comparison, the ADC's voltage noise is 4 µV/Hz^1/2.

For the sake of curiosity, I'm attaching the latest noise budget with the corrected CARM-to-DARM coupling TF. However, I note again that this level of frequency noise coupling is not supported by the required amount of coherence in any of our digitally acquired channels. Additionally, this level of frequency noise coupling is not seen at Livingston, although they've done a better job of TCS tuning than we have. I would not be surprised to find out that this coupling is somehow an overestimate.