[Koji, Steve]

DC power supplies for the RF generation box are now in place. They are the top two of the 6 Sorensens in the OMC short rack next to 1X2.

We made the connections as we did for the RF distribution box, the power supplies labele, and the cables strain-relieved.

The power supply is not yet connected to the actual RF generation box. This should be done by Suresh or someone with the supervision of him.

Note:
We have two +18V supply on the short OMC rack, in total. One is for the RF source, the other is for the OMC PZTs, whitening, etc.
This is to avoid unnecessary ground loop although the grounding situation of the OMC side is not known to me.

I have checked the voltages on the connector.  They are okay and I have plugged in the Sorensen power into the RF Source.  The ground reference for the Sorensens comes from the 1X2 Rack ground reference lines on the south side of the rack. 

I looked for the OMC ground reference. Could not find one on either of the the OMC half racks.

 East arm cabinet E9 and E10

[Steve, Koji, Suresh]

   We shifted two Sorensen power supplies from the Auxiliary rack next to 1X2 to 1Y2.  And have installed them there (pic below).  The local ground reference was picked up from the racks ground reference.  A shielded cable with two twisted pairs was used to make a new power cable for the RF rack.  Since we are using three of the four conductors (+18,+28 and ground), one of them is not connected to anything.  This situation can be improved in a future iteration when, for example, we might wish to relocate the Sorensens to a different rack.

   We are still working on changing the power supply to the RF source.  Will complete this early next week

Key points of the power supply installation

• We followed the grounding configuration for KEPCO except for the signal ground connection
• AC power supply has been obtained from the local power strip. This also provides chassis earthing (for safety)
• The chassis is connected to the shieldin of the DC supply cable. The other end should be isolated.

• The low voltage side of Sorensen's DC outputs are connected in order to share the same reference  level.
• The ground level is provided from the cross connect. The cable is connected between the cross connect ground to the sorencen.
  Unlike the KEPCO case, this cable does not have the current return, but just is to define the voltage level of those Sorensens.

• New AC&DC cables have been nicely strain-relieved.

Filter and scripts setup

I copied IOO_WFS1_I filter bank to AWS_WFS1/2_I/Q filter banks to copy the dewhitening and 60comb filters. Then I turned them on.

Similarly, I copied IOO_WFS1_PIT filter bank to AWS_YARM/XARM_WFS1/2_PIT/YAW filter banks. I created a generalised script to handle all WFS on/off.hold/onfromhold operations here. I also generalized toggleWFSoffsets script to be used for measuring DC sensing matrix.

DC sensing matrix measurement

This measurement folllowed the method used by Koji in 40m/17354. The measurement is pushed here. Ntoe that when using this method, while the test finishd in ~1000 seconds, it takes dtt >20 min to retrieve the timeseries data from DQ channels. Thisis weird because cdsutils.getdata does not have this lag. If anyone knows why this is the case, it would be helpful in making this method faster.

• Locked YARM and misaligned ITMX and ETMX
• Centered the AS beam on WFS using DC value.
• Ran ASS on YARM to get to best aligned cavity state.
• Unlocked YARM and ran C1AWS_YARM_WFS_MASTER>!Actions>Correct WFS RF offsets to zero teh offsets.
• Locked YARM again and waited for >120 seconds.
• Ran python /opt/rtcds/caltech/c1/Git/40m/scripts/AWStoggleWFSoffsets.py AWS BOTH -a YARM -t 120
  • Measurement start time: 04/02/2023 22:37:00 UTC
• The offset values required for step response test above were determined by trying out values and making sure that transmission does not go down by more than 15%.
• I had to leave by 3:30 pm, so I couldn't complete the analysis of measured data.I'll post data here soon.

Additions Sun Feb 5 18:06:54 2023:

Data analysis

I got the step response data using cdsutils.getdata and measured the sensing matrix and took and inverse with error propagation. Attachment 1 page 1 shows the raw data measured. Then the data was segmented based on step response time data and a linear fit is used to get linear trend of each channel in null configuration. This is used to remove bias later while measuring the step heights in each sensor. Page 2 shows this data. Page 3 shows final detrended and normalized step response data that was used to measure the sensing matrix. It came out to be:

                                                             YARM WFS DC Sensing Matrix

        ITMY PIT         ETMY PIT         ITMY YAW         ETMY YAW
   1.94 +/- 0.02    0.83 +/- 0.07   -0.15 +/- 0.04      1.3 +/- 0.1  to WFS1 PIT
   5.62 +/- 0.05      8.8 +/- 0.2     -0.2 +/- 0.1      2.5 +/- 0.2  to WFS2 PIT
  -0.43 +/- 0.03   -1.13 +/- 0.07    1.51 +/- 0.04     -0.9 +/- 0.2  to WFS1 YAW
  -1.42 +/- 0.05     -7.1 +/- 0.2      3.3 +/- 0.1    -19.5 +/- 0.4  to WFS2 YAW

Taking it's inverse with uncertainties supported matrix inverse function gave following output matrix to be used:

        WFS1 PIT         WFS2 PIT         WFS1 YAW         WFS2 YAW
   0.628+/-0.022   -0.031+/-0.007   -0.027+/-0.020    0.039+/-0.004  to ITMY PIT
  -0.431+/-0.020    0.146+/-0.007   -0.002+/-0.018 -0.0099+/-0.0030  to ETMY PIT
  -0.086+/-0.031    0.078+/-0.010    0.728+/-0.029   -0.029+/-0.008  to ITMY YAW
   0.097+/-0.009 -0.0377+/-0.0030    0.126+/-0.008 -0.0555+/-0.0020  to ETMY YAW

General ISS Design

Signals through the ISS are directed as follows:  an error signal is obtained by summing the ~5 V signal from the PD with a -5 V signal from a high precision voltage regulator (which is first filtered with an ~ 30 mHz low-pass Sallen-Key filter).  It is this signal that is processed/amplified by the servo. The output from the servo is then used to drive an AOM (it is not known exactly how this is done and whether or not any preamplifier/extra circuitry is necessary). The resulting modulation, hopefully, reduces fluctuations in the laser intensity incident on the PD, lowering the relative intensity noise.

Servo Design

Almost the entirety of my focus has been directed toward designing the servo portion of the ISS. Speaking in general terms, the currently proposed design consists of stages of active op-amp filters, but now the stages will have internal switches that allow them to switch between ‘flat’ gain buffers and more complicated filters with our desired behavior. Consider some Example Filter Stages where I have demonstrated a typical switching filter with the switch open and closed. When the switch is closed, the capacitor is shorted and we simply have a variable gain buffer (variable in the sense that its gain can be tuned by proper choice of the resistances) with no frequency dependence. When the switch is open, the capacitor introduces a pole at ~100 Hz and a zero at ~1 kHz.

CircuitLab has decent analysis capabilities and attached are plots generated by CircuitLab. The first plot corresponds to a frequency analysis of the voltage gain of op-amp U1 and the ‘flat’ ~20 dBV gain filter with the switch closed and the capacitor shorted. The second plot is the same frequency analysis, but now with op-amp U2 and the filter with the switch open and the capacitor introduced into signal processing. This particular combination of resistors and capacitors produce a DC gain of 60 dBV, a pole at ~100 Hz, a zero at ~10 kHz and high frequency behavior of ~constant gain of 20 dBV. In this simulation, the gain-bandwidth product of the simulated op-amp (the standard op-amp CircuitLab uses) was artificially increased in order to see more ideal behavior in the higher frequency domain.

Switches like the above can be used to add boosts to some initial filter state (which could be like the above or possibly a simple integrator to achieve high DC gain) and change it into a more complex and more useful filter state advantageous for desired noise suppression. Cascades of these switching filters could be used to create very complicated transfer function behavior. No general servo has yet been designed as the exact details of the intensity noise requirements are still being determined.

With regards to the implementation of the switches, some ‘smart’ signal will be used to trigger a switch opening and the boost being introduced to the signal processing. The switches will be opened (open corresponds to adding the boost) in a manner that maintains stability of the servo circuit. Essentially, some sort of time delay or power monitor induced signal (power from the PD output) will be used to modify the servo's behavior.

AOM

How exactly the signal will drive the AOM for correct noise suppression is unknown currently.

Pete, Alberto,

tonight we worked on the tuning of the double demod phases for the handoff of the short DOFs control signals.

Only MICH can now undergo the handoff. PRC can't make it.

Basically, we tuned the PD6 demod phase and reduced the offset in PD6_I. Then we tuned the relative gain of PD6_I and PD2_I so that the two open loop transfer function of the control loops would match. We tried that in several ways and several times but without success.

I guess we're missing to do/check something.

This afternoon I tuned the handoff script for the SRC, after that Rob eralier during the day had already adjusted that for PRC. To do that, I followed the procedure in the Wiki.

• I measured the OL transfer function of the single demod path and of the double demod path and tuned thier gains so that they matched
• I tuned the double demod pahses of PD_7 and PD_8 in order to reduce the offset in the PD_x_I signals

After that the SRC could get locked with the double demod signals. the open loop transfer function emasurement on the PRC loop showed that it was nearly unstable. Rob reduced a little its gain to improve the stability.

The DD handoff is now working and we can get back to locking the interferometer.

Rana, Alberto, Pete

We have the DD handoff nominally working.  Sometimes, increasing the SRC gain at the end makes MICH get unstable.  This could be due to a non-diagonal term in the matrix, or possibly because the DRM locks in a funky mode sometimes. 

To get the DD handoff working, first we tuned demod phases in order to zero the offsets in the PD signals handed-off-to.  Based on transer function measurements, I set the PRC PD6_I element to 0.1, and set the PD8_I signal to 0, since it didn't seem to be contributing much.  We also commented out the MICH gain increase at the end of the DD_handoff script.

It could still be more stable, but it seems to work most of the time.

I had trouble getting the SRC handoff from SD to DD to work.  I tried different gains, flipping the PD7 & 8 demod phases by 180 degrees, and messing with the output matrix to reduce cross-couplings in the state with MICH & PRC on DD and SRC on SD.  Eventually I decided to try to make the DRM matrix diagonalization work. 

It does, mostly.  The handoff is now stable, and the loops all have UGFs around 100Hz.  So, tonight anyways, it's possible to run senseDRM and then loadDRMImatrixData.m and run the resulting tdswrite command, and have a working handoff.  I had to eliminate a few PDs (PD5 & PD10) to get it to work properly. 

It would be nice if this script would measure all the PDs and allow individual setting of loop UGFs and measurement frequencies. 

alberto, pete

We worked on tuning the DD handoff tonight.  We checked the DD PD alignments and they looked fine.  First I tuned the 3 demod phases to minimize offsets.  Then I noticed that the post-handoff MICH xfer function needed an increase in gain to look like the pre-handoff xfer function (which has a UGF of about 25 Hz).  I increased the MICH PD9_Q gain from 2 to 7 in the input matrix.   But, the handoff to PRC still failed, so tomorrow we will try to find out why.

In the plot, ref0 is before MICH handoff, and ref1 is after MICH handoff.  There is also a PRC trace (before PRC handooff).

I added an MEDM screen for the DFD to the GREEN screen. It is displayed in the attached screen shot.

This screen is located in: /cvs/cds/rtcds/caltech/c1/medm/c1gfd/C1GFD_DFD.adl

This is a plot showing the old filters and the new ones we added this morning.

The new ones have a Cheby for AC coupling below 10 Hz and then a 500 Hz LP after the mixer. The LP frequency has been increased so that we can use this signal in a feedback loop to the ETM with a ~100 Hz UGF.

 Here is the spectrum of the input into the DFD (a 234.5Hz sine wave, 0.5 Vpp) and the spectrum and RMS of the LP output. The linewidth of the input signal is clearly much less than 0.1Hz, where as the RMS noise (above 2mHz) is approximately 0.2Hz and the main contributions are clearly the harmonics of the 234.5Hz signal.

Joe injected a 234.567 etc. Hz sine wave into the excitation channel in the DFD INPUT filter. The spectrum of the output of the LP filter with the new filter is shown below with the RMS calculated from 300Hz down to 1mHz - see first attachment. The RMS is equal to about 2.5Hz. (Incidentally, the RMS is very much higher (slightly less than 400Hz - see second attachment) if you calculate it from 7kHz down to 1mHz). 

I've been thinking a bit about what the ideal cable length / delay time for the upgraded ALS beatbox should be. Here are some thoughts, but no conclusions yet. 

If you're not running your beatbox mixer in compression, there are two competing effects when you change the cable length. At first, more delay gives better sensitivity, but this does not go on to infinity, because cable attenuation eventually kills your signal. It turns out that the ideal length can be derived to be whatever length gives you 20/ln(10) = -8.7dB of attenuation. Frank found this out in PSL ELOG 825, and I found an HP document that derives this (and other useful DFD math) to the wiki, here.

In PSL ELOG 826, Frank calculated this ideal length for a 160MHz carrier in various kinds of cables. 

However, this is not the end of the story. In the case of the DFD, we actually benefit from operating the mixer in compression, as makes our sensitivity less sensitive to flucuations in the beat amplitude. In this situation, the HP doc states "For maximum sensitivity, more delay can be added until the signal level out of the delay line is 8.7dB below the phase detector (mixer) compression point." I'm not sure I really understand the logic behind this statement, though. 

Lastly, Koji mentioned the fact that the splitter in the demod board does not split at exactly 90 degrees, making the trajectory in the IQ plane an ellipse. This means that if the beat signal is moving around the ellipse a lot, or even wrapping around it, we can suffer from some nonlinear signal conversion. Also, if the raw DFD sensitivity is very high, the free swinging mirrors will cause the signal to swing around faster than the phase tracker can keep up. This should be easy to avoid, however; I doubt we will use so much cable that the beat would move by so much. 

I intend to take all of this into account when picking a cable length! Jessica is going to help us make a nice box for them, too. 

This afternoon, I had a fruitful conversation with Rich Abbott about various kinds of cables.

I've sent an email to Steve to ask him to buy 2 x 50m LMR-195 cables, with male SMA connectors. Rich highly recommends these for their polyethylene insulation, which makes them less microphonic and less susceptible to thermal expansion, low loss, and multi-ply bonded foil shielding.

50m means that the peak to peak mixer output swing corresponds to about a MHz. 1nV of mixer output noise looks like ~6mHz frequency noise, for a Level 3 mixer appropriately driven. As a comparison, the lowest our in-loop green PDH error signals get is 0.1Hz/rtHz. 

The cable attenuation should be around 4.2dB at 50MHz, and 7.3dB at 150MHz, according to the data sheet. Thus, we should not be in the regieme where we are losing sensitivity to the attenuation. 

By my rough geometric estimation, these two should fit in the 2U box I got ahold of today fine. Jessica is designing the front panel. 

We currently have ~30m of RG-408 and RG-142 as our delay lines. 

[Anchal, Paco]

We measured DFD AM coupling; it seems to be minimum at higher RF input and low modulation depths as expected.

To do this, we set up Moku:Lab for AM ext with a spare DAC channel (C1:BAC-SPARE_CH14_OUT) which we send a swept sine excitation using diaggui. We vary the carrier level, and the modulation depth (every time we changed the level, we run the phaseUGF.py script to allow the phase tracker to adjust its loop gain properly). Attachment #1 shows the results, showing the finite bandwidth effect of the phase tracker as well as the mean magnitudes of the AM coupling below 100 Hz. This measurement and the script live in

What this means for ALS calibration:

It seems the residual AM coupling for a typical RF input level from our ALS beatnote corresponds to the couplings of ~ 2 Hz/V. This means that if the RF input level is fluctuating by 100mV, our residual beat frequency fluctuations only move by 200 mHz. This is not the case when the arms are locked... there the beat level stability is closer to 1 mV (so 2 mHz coupling to the phase tracker). Under previous SNR conditions, our lines are typically at a few 100 Hz of amplitude, with a noise floor comparable to a few 100 mHz (SNR ~ 100s), so AM coupling seems not to be statistically limiting for 0.1% calibration.

Next:

• To further reject this residual coupling, it may be worth balancing the demodulated IQ amplitudes, by using the digital gains "C1:ALS-BEATX_FINE_Q_GAIN, C1:ALS-BEATX_FINE_I_GAIN".
• For now, this effect (and its frequency dependence above 300 Hz) can probably be neglected for ALS calibration purposes.

I took transfer function measurement of DFD AM coupling using noise excitation.

Noise excitation setup

Noise is injected using C1:BAC-SPARE_CH14_EXC using awggui which is filtered by a foton filter to simulate the real beatnote RF amplitude noise measured by taking quadrature sum of C1:ALS-BEATY_FINE_I_OUT and C1:ALS-BEATY_FINE_Q_OUT. See attachment 1.

The DAC output is connected to MP1 at CH1. MP1 is set to run in waveform generation mode with following settings:

• Carrier frequency: 45 MHz
• Carrier Level: 500 mVpp
• No offset or phase offset
• Amplitude modulation ON
  • Modulation slope: 100%/V
  • Source Input: Ch1

The AWGUI is set to excite C1:BAC-SPARE_CH14_EXC using settings mentioned in attachment 2.

With this setup, the RF amplitude noise is simulated with MP1 and DAC excitation.

Transfer function measurement

With AWGGUI running as mentioned above, I simply used diaggui in spectrum mode for channels C1:BAC-SPARE_CH14_EXC and C1:ALS-BEATY_FINE_PHASE_OUT_HZ. The second channel is already calibrated into Hz, and the first channel is in counts. To convert it into voltage of amplitude fluctuation, I first converted DAC excitation to voltage by assuming 16 bit DAC with +/- 10 V range, this gives conversion constant of 10/2**15 V/cts. Then since MP1 is doing 100%/V AM modulation, for 500 mVpp RF level, this means 0.25 V/V AM modulation. Multiplying these two together gives, 7.6294e-5 V/cts. I put this number in teh diaggui calibration for C1:ALS-BEATY_FINE_PHASE_OUT_HZ.

This created the transfer function measurement attached in attachment 3.

The measurement resulted in roughly 2kHz/V AM to frequency coupling in DFD + phase tracker setup. The previous measurement with coherent sinusoidal excitation was exactly a factor of 1000 less than this, so I believe I might have made some error in calibrating or there could be an error in the previous elog. Please check my calculations. But a solid thing to note is the coherence measured below 1Hz. I'll do more sophisticated analysis on weekdays.

I also think that coherence was low because of low excitation. We should redo this test with more noise power to get good coherence in all frequency band to have good idea of what would happen to ebatnote RF amplitude noise at all frequencies.

Mon Jan 23 11:47:23 2023 Adding Attachment 4:

I realised that with the noise excitation setup set to mimic real beatnote amplitude noise with very low frequency noise as it is seeded with Moku:Pro, the measured frequency noise by the DFD+Phase Tracker setup at C1:ALS-BEATY_FINE_PHASE_OUT_HZ is an indicator of how much RF amplitude noise of beatnote contribute to the frequency noise measured by DFD+Phase tracker. Attachment 4 is the spectrum measured during this measurement.

Both the TF measurement and the noise measurements are useful, but the nosie measurement is much more meaningful. Since we expect the main coupling to be incoherent, what we really want is a noise budget style measurement:

1. Measure the FM noise spectrum with only a single sine wave into the Moku.
2. Same as #1, but with the AM noise added as you already did.
3. Estimate the noise budget contribution by doing PSD subtraction, and then scale that by the excitation magntiude. This will be the contribution of beat amplitude noise to the measured calibration.

[Anchal, Yehonathan]

I laid down another temporary cable from Xend to 1Y2 (LSC rack) for also measuring the Q output of the DFD box. Then to get a quick measurement of these long cable delays, we used Moku:GO in oscillator mode, sent 100 ns pulses at a 100 kHz rate from one end, and measured the difference between reflected pulses to get an estimate of time delay. The other end of long cables was shorted and left open for 2 sets of measurements.

I-Mon Cable delay: (955+/- 6) ns / 2 = 477 +/- 3 ns

Q-Mon Cable delay: (535 +/- 6) ns / 2 = 267 +/- 3 ns

Note: We were underestimating the delay in I-Mon cable by about a factor of 2.

I also took the opportunity to take a delay time measurement of DFD delayline. Since both ends of cable were present locally, it made more sense to simply take a transfer function to get a clean delay measurement. This measurement resulted with value of 197.7 +/- 0.1 ns. See attached plot. Data and analysis here.

[Anchal, Paco]

We updated the LSC model to use the amplitude as a normalization (analogous to what happens in OpLevs). For reference Attachment #1 shows the previous model detail, and Attachment #2 shows the updated one. We then built, restarted and ran the model to realize the phase tracker gain can now be set once and for all assuming we still have a simple integrator and 2 kHz of phase tracker bandwidth. Doing this results in the ALS residual noise shown in Attachment #3. Compared against the reference spectra, the improvement is modest but not as great as what the moku had.

We ran ITMY actuation calibration using this infrastructure; to do this we lock arm cavities to PSL, lock AUX lasers to arm cavities, turn on our five lines and read back the demodulated signals from the beatnote as it goes through DFD + phase tracker. The results are summarized in Attachment #4. This time we correctly accounted for all known sources of statistical and systematic uncertainties (including a recently  measurement of the AUX loop gain),

how about the other idea of downloading the I & Q channels and doing the analysis offline? I'm curious if its better or worse. How could the Moku possibly be better?

Another idea is to use the frequency divider and then directly digitize. I believe someone tried that a few years ago, but not sure how good it was.

I did offline analysis with the available data. We were only saving signals at 2048 Hz rate, so analysis can not be done on 1.4 kHz line. See attached plot for the difference in the two analysis.

We are aiming to prepare a realtime system deployable calibration method, that's why we were using phase tracker. Note that the calibration results with phase tracker have been compensated for any lack of gain due to phase tracke limited bandwidth, open loop gain of aux loop or remaining suppression from YARM loop despite the notches.

About the moku, we think that something is wrong in connection of moku output to ADC. We see the same cal line heights in the moku app in ipad but after going through ADC, we see about 10 times less line heights and 10 time sles noise floor too. But when we stick a marconi split between DFD and moku, we see the same results, so we are not sure what is wrong with it but it is not trustworthy. Maybe the order of magnitude noise reduciton is because of this factor of 10 that happens when it reads beatnote. To be solved in future, we will carry on with DFD for now.

Last night I took ITMY calibration data using MICH with AS55_Q. Adding that to the same plot. The error bars are probably underestimate with the MICH calibration method due to systematics not taken into account. For this measurement, MICH was locked with low UGF of 20 Hz to avoid all lines in MICH loop. Notches at the line frequencies were also put in. MICH OLTF was measured and any possible suppression of lines has been compensated for (very small). Note that error bars are present for DFD method too, but they are too small in this scale.

MICH calibration did not independently verify the higher actuation strength found by DFD methods at higher frequencies. For an ideal pendulum, the calibration constants should ahve been freqeuncy independent. It does see higher calibration constant values at 500 Hz and 1.4 kHz lines, but with a lot of noise. See attachment 2 for the calibration in real time, but this plot is bit messy. For the three lower frequency lines, DFD+Phase tracker and DFD with offline analysis match in their estimates , there is a significant mismatch at 500 kHz line and we do not have data for doing this for 1.4 kHz line.

I modified the analysis to correct for any affects due to Anti-Aliasing or Anti-Imaging filters, and I also found a insignificant error on how I was undoing the suppression due to MICH loop in the MICH data. I also propagated the calibration in MICH method better. Attached are the updated results. The upward swing is still present.

Also, last night, Koji and I looked into any frequency dependent deviation in sensing arm length between POY11 and BEATY_PHASE (using DFD+Phase tracker) This was done by locked the YARM to the main laser and locking YAUX to the YARM, sending excitationa at C1:SUS-ETMY_POSCAL_EXC and taking transfer function between C1:LSC-YARM_IN1 and C1:ALS-BEAT_Y_FINE_PHASE_OUT. This transfer function was flat upto about 600 Hz and the deviation from there to 2000 Hz was expected based on limited bandwidth of the phase tracker. I don't have the plot to attach, someone should redo this quick measurement to save the data.
Interestingly, the same measurement when done with  C1:LSC-DARM_IN1 in FPMI configuration did not show a flat response. This is can mean that the DARM strain relationship with the beatnote frequency deviation is not a simple constant factor and/or depends on DARM or CARM OLTFs. I leave my remarks on this project here for the baton to be picked up by others in future. I unfortunately only have this much time to contribute to FPMI calibration.

[Paco, Anchal] Log from yesterday work around 1Y2 rack; note that while this work was ongoing, TT2 position drifted slowly and misaligned the IFO input over the course of less than an hour. I suspect the DB9 breakout board and temporarily present components noted below may have introduced a floating ground in 1Y2, making the TT coil drivers misbehave. To support this claim, we noted that after removing the breakout board the drift disappeared!

We calibrated the DFD discriminant as a function of RF input level. The configuration was as follows:

1. Break out IQ demod board RF output (in the rear chassis on 1Y2), looking at Ch1 board outputs (for BEATX). The two differential outputs were broken into two BNCs (pairs 1,6 and 2,7 for Q and I respectively), and fed into the Moku:Lab. A Marconi 2023A was used as a VCO, with FM ext mode enabled and a FreqDVN (modulation slope) of 200 kHZ / Vrms (1 Vrms = 1.41 Vp = 0.705 Vpp). The FM ext input on the Marconi was sourced by the OUT1 of Moku:Lab, and the IQ demod outputs were connected to IN1 and IN2 on Moku:Lab.
2. After measuring the TF using a swept sine, I verified that the frequency response was flat up to 150 kHz (Marconi cuts FM ext at 275 kHz), so I switched to the oscilloscope instrument and setup OUTPUT to a 211.1 Hz sine wave, 1.41 Vpp to dither the 40 MHz by +- 100 kHz.
3. Using the arbitrary math function in Moku:Lab Scope, I computed the DFD output magnitude = sqrt(I**2 + Q**2), and measured its mean over 3 seconds.

The results are summarized in Attachment #1.

Summary:

There are no unexpected red-flags in the performance of the DFD electronics. The calibration factors for the digital phase tracker system are 71.291 +/- 0.024 deg/MHz for the X delay line and 70.973 +/- 0.024 deg/MHz for the Y delay line, while the noise floor for the frequency noise discrimination is ~0.5 Hz/rtHz above 1 Hz (dominated by ADC noise).

Details:

1. Attachment #1 - This observation is what motivated my investigation.
   •  found that for certain beat frequencies between the PSL + EX lasers, the frequency noise reported by the DFD system was surprisingly low.
   • The measurement condition was: EX laser frequency locked to the arm cavity length by the uPDH servo at EX, arm cavity length locked to PSL frequency via POX locking.
2. To investigate further, I disconnected the output of the NF1611 PDs going to the ZHL-3A amplifiers on the PSL table (after first blocking the PSL light so that the PDs aren't generating any RF output).
   • An RF function generator (IFR2023B) was used to generate an RF signal to mimic the ALS beat signal.
   • I used a power splitter to divide the signal power equally between the two DFD paths.
   • The signal level on the Marconi was set to -5 dBm, to mimic the nominal power level seen by the DFD system.
   • I then performed two tests - (i) to calibrate the Phase Tracker output to deg / MHz and (ii) to measure the frequency noise reported by the DFD system for various signal frequencies.
   • Test (i): sweep the marconi frequency between 10 MHz - 200 MHz, measure the I and Q channels for each phase tracker servo, and figure out the complex argument of the signal using the arctangent. A linear polynomial was fit to the measured datapoints to extract the desired slope.
   • Test (ii): Sample frequencies uniformly distributed between 20 MHz - 80 MHz (nominal range of ALS beat frequencies expected). Reset the phase tracker servo gain, clear the output histories, wait for any transients to die out, and then collect the phase tracker servo output for 1 minute. Compute the FFT to figure out the frequency noise.
   • Attachment #2: Shows the phase tracker calibration, i.e. the results of Test (i). I took this opportunity to update the EPICS calibration fields that convert phase tracker servo output to Hz, the correction was ~7%. These numbers are consistent with what I measured previously - but the updated values weren't registered with SDF so everytime the LSC model was restarted, it reverted to the old values.
   • Attachment #3: Shows the spectra for the various measurements from Test (ii).
   • Attachment #4: Shows the gain of the phase tracker servo as a function of the RF signal frequency. This is a proxy for the signal strength, and the observed trend suggests that the signal power seen after digitization of the demodulated delay line output goes down by ~20% at 80 MHz relative to the level at 20 MHz. Seems reasonable to me, given frequency dependent losses of the intervening electronics / cabling.

Conclusion and next steps:

I still don't know what's responsible for the anomalously low noise levels reported by the ALS-X system sometimes. Next test is to check the EX PDH system, since on the evidence of these tests, the problem seems to be imprinted on the light (though I can't imagine how the noise becomes lower?).

Summary:

1. The DFD noise floor is ~0.5Hz/rtHz at 100Hz (see Attachment #2).
2. I cannot account for the measured noise floor of the DFD system. The Marconi noise and the AA noise contributions should be neglibible at 100Hz.
3. This SURF report would lead me to believe that the delay line cable length is 50m. But my calibration suggests it is shorter, more like 40m (see Attachment #1). I had made some TF measurements of the delay sometime ago, need to dig up the data and see what number that measurement yields.

Details and discussion: (diagrams to follow)

• Delay line linearity was checked by driving the input with Marconi, waiting for any transient to die down, and averaging the I and Q inputs to the phase tracker servo (after correcting for the daughter board TF) for 10 seconds. The deg/MHz response was then calculated by trigonometry. Not sure what to make of the structure in the residuals, need to think about it.
• DFD noise was checked by driving the DFD input with a Marconi at 50MHz, RF level = 8dBm, which are expected parameters for nominal ALS operation. In this configuration, I measured the spectrum of the phase tracker output. I then used the calibration factor from the above bullet to convert to Hz/rtHz.
• The electronics noise contribution of the daughter board was calibrated to Hz/rtHz by using the Marconi to drive the DFD input with a known FM signal (mod depth ~0.05), and using the SR785 to measure the power of the FM peak. This allows one to back out the V/Hz calibration constant of the delay line. I tweaked the carrier frequency until the ratio of power in I channel to Q channel (or the other way around) was >20dB before making this measurement.
• I have no proof - but I suspect that the whole host of harmonics in the noise spectrum is because the 1U AA chassis sits directly on top of some Sorensen power supplies. These Sorensens power the frequency distribution box in the LSC rack, so the simplest test to confirm would be to turn off the RF chain, and then Sorensens, and see if the peaky features persist.

A couple of months ago, I took 21 measurements of the delay line transfer function. As shown in Attachment #2, the unwrapped phase is more consistent with a cable length closer to 45m rather than 50m (assuming speed of light is 0.75c in the cable, as the datasheet says it is).

Attachment #1 shows the TF magnitude for the same measurements. There are some ripples consistent with reflections, so something in this system is not impedance matched. I believe I used the same power splitter to split the RF source between delayed and undelayed paths to make these TFs as is used in the current DFD setup to split the RF beatnote.

The forthcoming Acromag c1susaux is supposed to use the backplane connectors of the sus euro card modules.

However, the backplane connectors of the vertex sus coil drivers were already used by the fast switches (dewhitening) of c1sus.

Our plan is to connect the Acromag cables to the upper connectors, while the switch channels are wired to the lower connector by soldering jumper wires between the upper and lower connectors on board.

To make the lower 96pin DIN connector available for this, we needed DIN 41612 (96pin) shroud. Tyco Electronics 535074-2 is the correct component for this purpose. The shrouds have been installed to the backplane pins of the coil driver circuit D010001. The shroud has the 180deg rotation dof. The direction of the shroud was matched with the ones on the upper connectors.

The PCB board of the adapter for DIN 96pin to DSUB37 conversion (single DSUB version) was delivered yesterday and I quickly soldered the connectors.

They are ready for use and stored in a JLCPCB cardboard box on a pile of acromag stuff. (Note that the lacel is written on the box with Sharpie)

I installed 6 of these in 1Y2. Three were for PD INTF #1-3, and I used three more for the AS110, REFL11, and REFL33 Demod board FEs, where the strain-reflief of the DC power cables to the Eurocrate was becoming a problem. So now there are only 4 units available as spares.

Once the strain-relieving of the Dsub cabling to 1Y3 is done, we can move ahead with testing. I'd like to put this to bed this week if possible.

I set up an action cam (DJI OSMO Pocket) and brought it back to the 40m. The kit is now placed in the control room cabinet together with the Canon DSLR.

I might have left the USBC chaging cable at home this time. Will bring it back next time.-> The cable was returned to the kit on Oct 23rd.

[C1:DMF-SEIS_1]
[C1:DMF-SEIS_2]
[C1:DMF-SEIS_3]
[C1:DMF-LINE_1]
[C1:DMF-LINE_2]
[C1:DMF-LINE_3]
[C1:DMF-MC_1]
[C1:DMF-MC_2]
[C1:DMF-MC_3]

We found that DMF/ was not an SVN working copy, so I wiped out the SVN version, imported the on-disk copy, moved it to DMFold/ and then checked out the SVN version.

We can delete DMFold/ whenever we are happy with the SVN copy.

I (think I) restarted DMF.  It's on Mafalda, running in matlab (not the complied version which Rana was having trouble with back in the day).  To start Matlab, I did "nohup matlab", ran mdv_config, then started seisBLRMS.m running.  Since I used nohup, I then closed the terminal window, and am crossing my fingers in hopes that it continues to work.  I would have used Screen, but that doesn't seem to work on Mafalda.

 Just kidding. That plan didn't work.  The new plan: I started a terminal window on Op540, which is ssh-ed into Mafalda, and started up matlab to run seisBLRMS.  That window is still open. 

Because Unix was being finicky, I had to open an xterm window (xterm -bg green -fg black), and then ssh to mafalda and run matlab there.  The symptoms which led to this were that even though in a regular terminal window on Op540, ssh-ed to mafalda, I could access tconvert, I could not make gps.m work in matlab.  When Rana ssh-ed from Allegra to Op540 to Mafalda and ran matlab, he could get gps.m to work.  So it seems like it was  a Unix terminal crazy thing. Anyhow, starting an xterm window on Op540m and ssh-ing to mafalda from there seemed to work.

Hopefully this having a terminal window open and running DMF will be a temporary solution, and we can get the compiled version to work again soon.

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

I've brought 4 DO-32L-PE cards from WB for BHD upgrade for Jon.

I have added a DQ block to the sus_single_control library part.  This means that all sus models will automatically generate DQ channels based on what is specified in this doc block:

#DAQ Channels

SUSPOS_IN1
SUSPIT_IN1
SUSYAW_IN1
SUSSIDE_IN1
ULSEN_OUT
URSEN_OUT
LRSEN_OUT
LLSEN_OUT
SDSEN_OUT
OLPIT_IN1
OLYAW_IN1
OLSUM_IN1

So for instance, for BS will have the following DQ channels:

C1:SUS-BS_SUSPOS_IN1_DQ
C1:SUS-BS_SUSPIT_IN1_DQ
...

etc.  The channels names modified by the activateDQ.py script after install are still modified appropriately.

This is now the place where we should be maintaining DQ channels.

I have copied over the complete frame files from two DRFPMI lock acquisitions + locks to /frames/archive. The data should be safe from the wiper script here.

One, under the subfolder DRFPMI_Mar29_cal is the lock where the CAL-DARM channel is properly calibrated at GPS time 1143274087.

The other lock, under DRFPMI_MAR29_nocal, does not have the calibration set up yet, but was a much quicker acquistion (<2 min from ALS acquisition to DRFPMI) and longer lock (~8min).