I tuned the local damping gains for LO1, LO2, AS1, and AS4 by looking at step responses in the DOF basis (i.e. POS, PIT, YAW, and SIDE). The procedure was:

1. Grab an ndscope with the error point signals in the DOF basis, e.g. C1:SUS-LO1_SUSPOS_IN1_DQ
2. Apply an offset to the relevant DOF using the alignment slider offset (or coil offset for the SIDE DOF) while being careful not to trip the watchdog. The nominal offsets found for this tuning are summarized below:

3. Tune the damping gains until the DOF shows a residual Q with ~ 5 or more oscillations.
4. The new damping gains are below for all optics and their DOFs, and Attachments #1-4 summarize the tuned step responses as well as the other DOFs (cross-coupled).

Note that during this test, FM5 has been populated for all these optics with a BounceRoll (notches at 16.6, 23.7 Hz) filter, apart from the Cheby (HF rolloff) and the 0.0:30 filters.

DB9 Cables have been assorted and placed behind the Y-Arm. Long BNC Cables and Ethernet Cables have been stored under the Y-Arm. 

[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, Radhika]

The cables in USPS open box were important cables that are part of the new electronics architecture. These are 3 ft D2100103 DB15F to DB9M Reducer Cable that go between coil driver output (DB15M on back) to satellite amplifier coil driver in (DB9F on the front). These have been placed in a separate plastic box, labeled, and kept with the rest of the D-sub cable plastic boxes that are part of the upgrade wiring behind the tube on YARM across 1Y2. I believe JC would eventually store these dsub cable boxes together somewhere later.

[Anchal, Radhika]

Attachment 2: The custom cables which were part of the intermediate setup between old electronics architecture and new electronics architecture were found.
These include:

• 2 DB37 cables with custom wiring at their connectors to connect between vacuum flange and new Sat amp box, marked J4-J5 and J6-J7.
• 2 DB15 to dual head DB9 (like a Hydra) cables used to interface between old coil drivers and new sat amp box.

A copy of these cables are in use for MC1 right now. These are spare cables. We put them in a cardboard box and marked the box appropriately.
The box is under the vacuum tube along Yarm near the center.

{Paco, Yehonathan}

BHD Optics box was put into the x-arm last clean cabinet. (attachment 5)

OSEMs were double bagged in a labeled box on the x-arm wire racks. (attachment 1)

SOS Parts (wire clamps, winches, suspension blocks, etc.) were put in a box on the x-arm wire rack. (attachment 3)

2"->3" optic adapter parts were put in a box and stored on the xarm wire rack. (attachment 3)

Magnet gluing parts box was labeled and stored on the xarm rack. (attachment 2)

TT SUS with the optics were stored on the flow bench at the x end. Note: one of the TT SUS was found unsuspended. (attachment 4)

InVac parts were double bagged and stored in a labeled box on the x arm wire rack. (attachment 2)

P. P. Vaidyanathan wrote a chapter in the book "Handbook of Digital Signal Processing: Engineering Applications" called "Low-Noise and Low-Sensitivity Digital Filters" (Chapter 5 pg. 359).  I took a quick look at it and wanted to give some thoughts in case they are useful. The experts in the field would be Leland B. Jackson, P. P. Vaidyanathan, Bernard Widrow, and István Kollár.  Widrow and Kollar  wrote the book "Quantization Noise Roundoff Error in Digital Computation, Signal Processing, Control, and Communications" (a copy of which is at the 40m). it is good that P. P. Vaidyanathan is at Caltech.

Vaidyanathan's chapter is serves as a good introduction to the topic of quantization noise. He starts off with the basic theory similar to my own document on the topic. From there, there are two main relevant topics to our goals.

The first interesting thing is using Error-Spectrum Shaping (pg. 387). I have never investigated this idea but the general gist is as poles and zeros move closer to the unit circle the SNR deteriorates so this is a way of implementing error feedback that should alleviate this problem. See Fig. 5.20 for a full realization of a second-order section with error feedback.

The second starts on page 402 and is an overview of state space filters and gives an example of a state space realization (Fig. 5.26). I also tested this exact realization a while ago and found that it was better than the direct form II filter but not as good as the current low-noise implementation that LIGO uses. This realization is very close to the current realization except uses one less addition block.

Overall I think it is a useful chapter. I like the idea of using some sort of error correction and I'm sure his other work will talk more about this stuff. It would be useful to look into.

One thought that I had recently is that if the quantization noise is uncorrelated between the two different realizations then connecting them in parallel then averaging their results (as shown in Attachment 1) may actually yield lower quantization noise. It would require double the computation power for filtering but it may work. For example, using the current LIGO realization and the realization given in this book it might yield a lower quantization noise. This would only work with two similarly low noise realizations. Since it would be randomly sampling two uniform distributions and we would be going from one sample to two samples the variance would be cut in half, and the ASD would show a 1/√2 reduction if using realizations with the same level of quantization noise. This is only beneficial if the realization with the higher quantization noise only has less than about 1.7 times the one with the lower noise. I included a simple simulation to show this in the zip file in attachment 2 for my own reference.

Another thought that I had is that the transpose of this low-noise state-space filter (Fig. 5.26) or even of LIGO's current filter realization would yield even lower quantization noise because both of their transposes require one less calculation.

Each morning now, I am going to try to align both arms and lock. Along with that, sometime at towards the end of each week, we should align the OpLevs. This is a good habit that should be practiced more often, not only by me. As for the Y Arm, Yehonathan and I had to adjust the gain to 0.15 in order to stabilize the lock.

The analog electronics units piled up along the wall was moved into 1X3B rack which was basically empty. (Attachments 1/2/4)

We had a couple of unused Sun Machines. I salvaged VMIC cards (RFM and Fast fiber networking? for DAQ???) and gave them to Tega.
Attachment 3 shows the eWastes collected this afternoon.

The PZT sweeps that we've been making to characterize the ALS-X laser should probably be discarded - the DFD was not setup correctly for this during the past few months.

Since the DFD only had a peak-peak range of ~5 MHz, whenever the beat frequency drifts out of the linear range (~2-3 MHz), the data would have an arbitrary gain. Since the drift was actually more like 50 MHz, it meant that the different parts of a single sweep could have some arbitrary gain and sign !!! This is not a good way to measure things.

I used an ezcaservo to keep the beat frequency fixed. The attacehed screenshot shows the command line. We read back the unwrapped beat frequency from the phase tracker, and feedback on the PSL's NPRO temperature. During this the lasers were not locked to any cavities (shutters closed, but servos not disabled).

For the purposes of this measurement, I reduced the CAL factor in the phase tracker screen so that the reported FINE_PHASE_OUT is actually in kHz, rather than Hz on this plot. So the green plot is moving by 10's of MHz. When the servo is engaged, you can see the SLOWDC doing some action. We think the calibration of that channel is ~1 GHz/V, so 0.1 SLOWDC Volts should be ~100 MHz. I think there's a factor of 2 missing here, but its close.

As you can see in the top plot, even with the frequency stabilized by this slow feedback (-1000 to -600 seconds), the I & Q outputs are going through multiple cycles, and so they are unusable for even a non serious measurement.

The only way forward is to use less of a delay in the DFD: I think Anchal has been busily installing this shorter cable (hopefully, its ~3-5 m long so that the linear range is more. I think a 10 m cable is too long.), and the sweeps taken later today should be more useful.

{Radhika, Paco, Yehonathan}

For educational purposes we update the XARM noise budget and add the POX11 calibrated dark noise contribution (attachment).

Behind the X arm tube

Attachment 5: RF delay line was accommodated in 1X3B. (KA)

As marked up in the photos.

Attachment 5: The electronics units removed. Cleaning half way down. (KA)

Attachment 6: Moved most of the units to 1X3B rack ELOG 17125 (KA)

Salvage these (and any other things). Wrap and double-pack nicely. Put the labels. Store them and record the location. Tell JC the location.

[Tega, JC]

We received the remaining 3 front-ends from LHO today. They each have a timing card and an OSS host adapter card installed. We also receive 3 dolphin DX cards. As with the previous packages from LLO, each box contains a rack mounting kit for the supermicro machine.

Took finer measurements of the x-arm aux laser actuator tranfer function (10 kHz - 1 MHz, 1024 pts/decade) using the Moku.

--------------------------------------

I took finer measurements using the moku by splitting the measurement into 4 sections (10 - 32 (~10^4.5) kHz, 32 - 100 kHz, 100 - 320 kHz, 320 - 1000 kHz) and then grouping them together. I took 25 measurements of each ( + a bonus in case my counting was off), plotted them in the attached notebook, and calculated/plotted the standard deviation of the magnitude (normalized for DC offset). Could not upload to the ELOG as .pdf, but the pdf's are in the .zip file.

--------------------------------------

Next steps are to do the same stdev calculation for phase, which shouldn't take long, and to use the vectfit of this better data to create a PZT inversion filter.

[JC, Tega]

We got the 3 front-ends from LLO today. The contents of each box are:

1. FE machine
2. OSS adapter card for connecting to I/O chassis
3. PCI riser cards (x2)
4. Timing Card and cable
5. Power cables, mounting brackets and accompanying screws

The machine shop looked a mess this morning, so I cleaned it up. All power tools are now placed in the drawers in the machine shop. Let me know if there are any questions of where anything here is placed. 

@tega This looks great, thank you for putting this together.  The rack drawing in particular is great.  Two notes:

1. In "1X6 - proposed" I would move the "PEM AA + ADC Adapter" down lower in the rack, maybe where "Old FB + JetStor" are, after removing those units since they're no longer needed.  That would keep all the timing stuff together at the top without any other random stuff in between them.  If we can't yet remove Old FB and the JetStor then I would move the VME GPS/Timing chassis up a couple units to make room for the PEM module between the VME chassis and FB1.
2. We'll eventually want to move FB1 and Megatron into 1X7, since it seems like there will be room there.  That will put all the computers into one rack, which will be very nice.  FB1 should also be on the KVM switch as well.

I think most of this work can be done with very little downtime.

[Tega, Jamie]

Here is a proposal for what we would like to do in terms of reshuffling a few rack-mounted equipments for the CDS upgrade. 

• Frequency Distribution Amp - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Then disconnect power and signal cables one at a time to enable optimum rerouting for strain relief and declutter.  

• GPS Receiver Tempus LX - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Then disconnect power and signal cables one at a time to enable optimum rerouting for strain relief and declutter.

• PEM & ADC Adapter - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Disconnect the single signal cable from the rear of the ADC adapter to allow for optimum rerouting for strain relief.

• Martian Network Switch - Make a note of all connections, disconnect them, move the switch to 1X7 and reconnect ethernet cables. 

• MARTIAN NETWORK SWITCH CONNECTIONS
  #	LABEL	#	LABEL
  1	Tempus LX (yellow,unlabeled)	13	FB1
  2	1Y6 HUB	14	FB
  3	C0DCU1	15	NODUS
  4	C1PEM1	16
  5	RFM-BYPASS	17	CHIARA
  6	MEGATRON/PROCYON	18
  7	MEGATRON	19	CISC/C1SOSVME
  8	BR40M	20	C1TESTSTAND [blue/unlabelled]
  9	C1DSCL1EPICS0	21	JetStar [blue/unlabelled]
  10	OP340M	22	C1SUS [purple]
  11	C1DCUEPICS	23	unknown [88/purple/goes to top-back rail]
  12	C1ASS	24	unknown [stonewall/yellow/goes to top-front rail]

   

I believe all of this can be done in one go followed by CDS validation. Please comment so we can improve the plan. Should we move FB1 to 1X7 and remove old FB & JetStor during this work?

Attachment 1: Reshuffling proposal

Attachment 2: Front of 1X7 Rack

Attachment 3: Rear of 1X7 Rack

Attachment 4: Front of 1X6 Rack

Attachment 5: Rear of 1X6 Rack

Attachment 6: Martian switch connections

Here is an update of how fitting the resonances is going - I've been modifying parameters by hand and seeing the effect on the fit. Still a work in progress. Magnitude is fitting pretty well, phase is very confusing. Attempted vectfit again but I can't constrain the number of poles and zeros with the code I have and I still get a nonsensical output with 20 poles and 20 zeros. Here is a plot with my fit so far, and a zip file with my moku data of the resonances and the code I'm using to plot.

I have now added code/data to my github repository. (it's the little victories)

I tried to lock the Y/X arms to take some noise budget. However, we noticed that TRX/Y were oscillating coherently together (by tens of percent), meaning some input optics, essentially PR2/3 are swinging. There was no way I could do noise budgeting in this situation.

I set out to debug these optics. First, I notice side motion of PR2 is very weakly damped .

The gain of the side damping loop (C1:SUS-PR2_SUSSIDE_GAIN) was increased from 10 to 150 which seem to have fixed the issue. Attachment 1 shows the current step response of  the PR2 DOFs. The residual Qs look good but there is still some cross-couplings, especially when kicking POS. Need to do some balancing there.

PR3 fixing was less successful in the beginning. I increased the following gains:

C1:SUS-PR3_SUSPOS_GAIN: 0.5 -> 30

C1:SUS-PR3_SUSPIT_GAIN: 3 -> 30

C1:SUS-PR3_SUSYAW_GAIN: 1 -> 30

C1:SUS-PR3_SUSSIDE_GAIN: 10 -> 50

But the residual Q was still > 10. Then I checked the input matrix and noticed that UL->PIT is -0.18 while UR->PIT is 0.39. I changed UL->PIT (C1:SUS-PR3_INMATRIX_2_1) to +0.18. Now the Q became 7. I continue optimizing the gains.

Was able to increase C1:SUS-PR3_SUSSIDE_GAIN: 50 -> 100.

Attachment 2 shows the step response of PR3. The change of the entry of the input matrix was very ad-hoc, it would probably be good to run a systematic tuning. I have to leave now, but the IFO is in a very misaligned state. PR3/2 should be moved to bring it back.

[Paco, Chris Stoughton, Leo -- remote]

This morning Chris came over to the 40m lab to help us get the RFSoC board going. After checking out our setup, we decided to do a very basic series of checks to see if we can at least get the ADCs to run coherently (independent of the DACs). For this I borrowed the Marconi 2023B from inside the lab and set its output to 1.137 GHz, 0 dBm. Then, I plugged it into the ADC1 and just ran the usual spectrum analyzer notebook on the rfsoc jupyter lab server. Attachment #1 - 2 shows the screen captured PSDs for ADCs 0 and 1 respectively with the 1137 MHz peaks alright.

The fast ADCs are indeed reading our input signals.

Before this simple test, we actually reached out to Leo over at Fermilab for some remote assistance on building up our minimally working firmware. For this, Chris started a new vivado project on his laptop, and realized the rfsoc 2x2 board files are not included in it by default. In order to add them, we had to go into Tools, Settings and add the 2020.1 Vivado Xilinx shop board repository path to the rfsoc2x2 v1.1 files. After a little bit of struggling, uninstalling, reinstalling them, and restarting Vivado, we managed to get into the actual overlay design. In there, with Leo's assistance, we dropped the Zynq MPSoC core (this includes the main interface drivers for the rfsoc 2x2 board). We then dropped an rf converter IP block, which we customized to use the right PLL settings. The settings, from the System Clocking tab were changed to have a 409.6 MHz Reference Clock (default was 122.88 MHz). This was not straightforward, as the default sampling rate of 2.00 GSPS was not integer-related so we had to also update that to 4.096 GSPS. Then, we saw that the max available Clock Out option was 256 MHz (we need to be >= 409.6 MHz), so Leo suggested we dropped a Clocking Wizard block to provide a 512 MHz clock input for the rfdc. The final settings are captured in Attachment # 3. The Clocking Wizard was added, and configured on its Output Clocks tab to provide a Requested Output Freq of 512 MHz. The finall settings of the Clocking wizard are captured in Attachment #4. Finally, we connected the blocks as shown in Attachment #5.

We will continue with this design tomorrow.

Some more measurements of the PZT resonances (now zoomed in!) I'm adjusting parameters on our model to try and fit to it by hand a bit, definitely still needs improvements but not bad for a 2-pole 2-zero fit for now. I don't have a way to get coherence data from the moku yet but I've got a variety of measurements and will hopefully use the standard deviation to try and find a good error prediction...

[Yehonathan, Paco]

This morning, while attempting to align the IFO to continue with noise-budgeting, we noted the XARM lock was not stable and showed glitches in the C1:LSC-TRX_OUT (arm cavity transmission). Inspecting the SUS screens, we found the ULSEN rms ~ 6 times higher than the other coils so we opened an ndscope with the four face OSEM signals and overlay the XARM transmission. We immediately noticed the ULSEN input is noisy, jumping around randomly and where bigger glitches correlated with the arm cavity transmission glitches. This is appreciated in Attachment #1.

Signal chain investigation

We'll do a full signal investigation on ITMX SUS electronics to try and narrow down the issue, but it seems the glitches come and go... Is this from the gold satamp box? ...

We measured the TF of the X-arm laser PZT using the Moku so we can begin fitting to that data and hopefully creating a digital filter to cancel out PZT resonances. 

-------------------------------------------------------------

We calculated the DFD calibration (V/Hz) using:

Vrf = 0.158 mV (-6 dBm), Km = 1 (K_phi = Km*Vrf), cable length = 45m,  Tau = cable length/(0.67*3*10^8 m/s) ~ 220 ns. 

We've taken some preliminary data and can see the resonances around 200-300 kHz.

---------------------------------------------------------

Next steps are taking more data around the resonances specifically, calibrating the data using the DFD calibration we calculated, and adjusting parameters in our model so we can model the TF.

[JC, Tega, Chris]

After moving the test stand front-ends, chiara (name server) and fb1 (boot server) to the new rack behind 1X7, we powered everything up and checked that we can reach c1teststand via pianosa and that the front-ends are still able to boot from fb1. After confirming these tests, we decided to start the software upgrade to debian 10. We installed buster on fb1 and are now in the process of setting up diskless boot. I have been looking around for cds instructions on how to do this and I found the CdsFrontEndDebian10page which contains most of the info we require. The page suggests that it may be cleaner to start the debian10 installation on a front-end that is connected to an I/O chassis with at least 1 ADC and 1 DAC card, then move the installation disk to the boot server and continue from there, so I moved the disk from fb1 to one of the front-ends but I had trouble getting it to boot. I decided to do a clean install on another disk on the c1lsc front-end which has a host adapter card that can be connected to the c1bhd I/O chassis. We can then mount this disk on fb1 and use it to setup the diskless boot OS.

A new tool box has been placed at the Y-end! Each drawer has its label so PLEASE put the tools back in their correct location. In addition to this, Each tool has its assigned tool box, so PLEASE RETURN all tools to their designated tool box. The tools can be distinguished by a writing or heat shrink which corresponds to the color of the tool chest or location. Photo #2 is an example of how the tools have been marked.

Each toolbox from now on will contain a drawer for the folllowing: Measurements, Allen Keys, Pliers and Cutters, Screwdrivers, Zipties and Tapes, Allen Ball Drivers, Crescent Wrenches, Clamps, and Torque Wrenches/ Ratchets.

[Tega, JC]

Moved the rack to the location of the test stand just behind 1X7 and plan to remove the other two small test stand racks to create some space there.  We then mounted the c1bhd I/O chassis and 4 front-end machines on the test stand (see attachment 1).

Installed the dolphin IX cards on all 4 front-end machines: c1bhd, c1ioo, c1sus, c1lsc. I also removed the dolphin DX card that was previously installed on c1bhd.

Found a single OneStop host card with a mini PCI slot mounting plate in a storage box (see attachment 2). Since this only fits into the dual PCI riser card slot on c1bhd, I swapped out the full-length PCI slot OneStop host card on c1bhd and installed it on c1lsc, (see attachments 3 & 4).

for damping and OL loops, we typically don't measure the TF like this because it takes forever and we don't need that detailed info for anything. Just use the step responses in the way we discussed at the meeting 2 weeks ago. There's multiple elog entries from me and others illustrating this. The measurement time is then only ~30 sec per optic, and you also get the cross-coupling for free. No need for test-point channels and overloading, just use the existing DQ channels and read back the response from the frames after the excitations are completed.

I made measurements of old optics OLTF today. I have reduced the file sizes of the plots and data now. It is interesting that it is allowed to read 9 channels simultaneously from c1mcs or c1sus models, even together. The situation with c1su2 is a bit unclear. I was earlier able to take measurements of 6 channels at once from c1su2 but not I can't read more than 1 channel simultaneously. This suggests that the limit is dictated by how much a single model is loaded, not how much we are reading simultaneously. So if we split c1su2 into two models, we might be able to read more optics simultaneously, saving time and giving us the ability to measure for longer.

Attached are the results for all the core optics. Inferences will be made later in the week.

Note: Some measurements have very low coherence in IN2 channels in most of the damping frequency region, these loops need to be excited harder. (eg PIT, POS, YAW, on ITMs and ETMs).

When Juan and I were working on the suspension measurement, I found that CHA didn't settle down well.

I inspected and found that CHA's + input seemed broken and physically flaky. For Juan's measurements, I plugged + channels (for CHA/B) and used - channels as an input. This seemed work but I wasn't sure the SR functioned as expected in terms of the noise level.

We need to inspect the inputs a bit more carefully and send it back to SRS if necessary.

How many SR785's do we have in the lab right now? And the measurement instruments like SR785 are still the heart of our lab, please be kind...

The setup was (at least partially) cleared.

[Anchal, Tega]

As a first step to characterize all the local damping loops, we ran an open loop transfer function measurement test for all BHD optics, taking transfer function using band-limited (0.3 Hz to 10 Hz) gaussian noise injection at error points in different degrees of freedom. Plots are in the git repo. I'll make them lighter and post here.

We have also saved coherence of excitation at the IN1 test points of different degrees of freedom that may be later used to determine the cross-coupling in the system.

The test ran automatically using measSUSOLTF.py script. The script can run the test parallelly on all suspensions in principle, but not in practice because the cdsutils.getdata apparently has a limitation on how many real-time channels (we think it is 8 maximum) one can read simultaneously. We can get around this by defining these test points at DQ channels but that will probably upset the rtcds model as well. Maybe the thing to do is to separate the c1su2 model into two models handling 3 and 4 suspensions. But we are not sure if the limitation is due to fb or DAQ network (which will persist even if we reduce the number of testpoints on one model) or due to load on a single core of FE machines.

The data is measured and stored here. We can do periodic tests and update data here.

Next steps:

• Run the test for old optics as well.
• Fit the OLTF model with the measured data, and divide by the digital filter transfer function to obtain the plant transfer function for each loop.
• Set maximum noise allowed in the local damping loop for each degree of freedom, and criteria for Q of the loop.
• Adjust gains and or loop shape to reach the requirements on all the suspensions in a quantitative manner.
• (optional) Add a BLRMS calculation stream in SUS models for monitoring loop performance and in-loop noise levels in the suspensions.
• More frequency resolution, please. (KA)

The overlapping plot of the calibrated error and control signals gives you an approximately good estimation of the freerun fluctuation, particularly when the open-loop gain G is much larger or much smaller than the unity.
However, when the G is close to the unity, they are both affected by "servo bump" and both signals do not represent the freerun fluctuation around that frequency.

To avoid this, the open-loop gain needs to be measured every time when the noise budget is calculated. In the beginning, it is necessary to measure the open-loop gain over a large frequency range so that you can refine your model. Once you gain sufficient confidence about the shape of the open-loop gain, you can just use measurement at a frequency and just adjust the gain variation (most of the cases it comes from the optical gain).

I am saying this because I once had a significant issue of (project-wide) incorrect sensitivity estimation by omitting this process.

TL;DR: When the laser has good lock, the OLTF moves up and the UGF moves over!

-----------------------------------------------------------

Figured out with Paco yesterday that when the laser is locked but kind of weakly (mirrors on the optical table sliiightly out of alignment, for example), we would get a UGF around 5 kHz, but when we had a very strong lock (adjusting the mirrors until the spot was brightest) we would get a UGF around 13-17 kHz. Attached are some plots of us going back and forth (you can kind of tell from the coherence/error that the one with the lower UGF is more weakly locked, too). Error on the plots is propagated using the coherence data (see Bendat and Piersol, Random Data, Table 9.6 for the formula). 

-------------------------------------------------------------

Want to take data next week to quantitatively compare optical gain to UGF!

{Yuta, Yehonathan}

We wrote a notebook found on Git/40m/measurements/LSC/FPMI/NoiseBudget/FPMISensitivity.ipynb for calculating the MICH, DARM (currently XARM), CARM (currently YARM) sensitivities in the FPMI lock which can be run daily.

The IN and OUT channels of each DOFs are measured at a certain GPS time and calibrated using the optical gains and actuation calibration measured in the previous post.

Attachment shows the results.

It seems like the UGFs for MICH and DARM (currently XARM) match the ones that were estimated previously (100Hz for MICH, 120Hz for DARM) except for CARM for which the UGF was estimated to be 250Hz and here seems to be > 1kHz.

Indeed one can also see that the picks in the CARM plot don't match that well. Calculation shows that at 250Hz OUT channel is 6 times more than the IN channel. Calibrations for CARM should be checked.

MICH sensitivity using REFL55 at high frequencies is not much better than what was measured with AS55.

DARM sensitivity at 10Hz is a factor of a few better than the single arm lock sensitivity.

Now it is time to do the budgeting.

we want to be able to run SimPlant on the teststand, test our new controls algorithms, test watchdogs, and any other software upgrades. Ideally in the steady state it will run some plants with suspensions and cavities and we will develop our measurement scripts on there also (e.g. IFOtest).

TL;DR: Got the x-arm aux laser locked again and took more data - my fit on my transfer functions need improvement and my new method for finding coherence doesn't work so I went back to the first way! See attached file for an example of data runs with poor fits. First one has the questionable coherence data, second one has more logical coherence. (ignore the dashed lines.)

------------------------------------------------------------------------------------

• The aux laser on the x-arm was still off after the power shutdown, so Paco and I turned it back on, and realigned the oplev of the ETMX - initial position was P = -0.0420, Y = -5.5391.
• Locked the x-arm and took another few runs - was calculating coherence by I/Q demodulation of the buffers and then recombining the I/Q factors and then taking scipy.signal.coherence(), but for some reason this was giving me coherence values exclusively above 0.99, which seemed suspicious. When I calculated it the way I had before, by just taking s.s.coherence() of the buffers, I got a coherence around 1 except for in noisy areas of the data where it dropped more significantly, and seemed to be more correlated to the data. So I'll go back to using that way.
• I also think my fits are not great - my standard error of the fits (calculated using the coherence as weight, see Table 9.6 of Random Data by Piersol and Bendat for the formula I'm using) are enormous. Now that I have a good idea that the UGF is between 1 - 15 kHz, I'm going to restrict my frequency band and try to fit just around where the UGF would be. 

--------------------------------------------------------------------------------

To do:

• Reduce frequency band and take more data
• Get fit with better standard error, use that error to calculate the uncertainty in the UGF!

- Disk full

I updated the configuration file '/etc/logrotate.d/rsyslog' to set a file sise limit of 50M on 'syslog' and 'daemon.log' since these are the two log files that capture caget & caput terminal outputs. I also reduce the number of backup files to 2.

- Vacuum gauge

The XGS-600 can handle 6 FRGs and we currently have 5 of them connected. Yes, having a spare would be good. I'll see about placing an order for these then.

FPMI related
- Better suspension damping HIGH
 - Investigate ITMX input matrix diagonalization (40m/16931)
 - Output matrix diagonalization
 * FPMI lock is not stable, only lasts a few minutes for so. MICH fringe is too fast; 5-10 fringes/sec in the evening.
- Noise budget HIGH
 - Calibrate error signals (actually already done with sensing matrix measurement 40m/17069)
 - Make a sensitivity curve using error and feedback signals (actuator calibration 40m/16978)
 * See if optical gain and actuation efficiency makes sense. REFL55 error signal amplitude is sensitive to cable connections.
- FPMI locking
 - Use CARM/DARM filters, not XARM/YARM filters
 - Remove FM4 belly
 - Automate lock acquisition procedure
- Initial alignment scheme
 - Investigate which suspension drifts much
 - Scheme compatible with BHD alignment
 * These days, we have to align almost from scratch every morning. Empirically, TT2 seems to recover LO alignment and PR2/3 seems to recover Yarm alignment (40m/17056). Xarm seems to be stable.
- ALS
 - Install alignment PZTs for Yarm
 - Restore ALS CARM and DARM
 * Green seems to be useful also for initial alignment of IR to see if arms drifted or not (40m/17056).
- ASS
 - Suspension output matrix diagonalization to minimize pitch-yaw coupling (current output matrix is pitch-yaw coupled 40m/16915)
 - Balance ITM and ETM actuation first so that ASS loops will be understandable (40m/17014)
- Suspension calibrations
 - Calibrate oplevs
 - Calibrate SUSPOS/PIT/YAW/SIDE signals (40m/16898)
 * We need better understanding of suspension motions. Also good for A2L noise budgeting.
- CARM servo with Common Mode Board
 - Do it with single arm first

BHD related
- Better suspension damping HIGH
 - Invesitage LO2 input matrix diagonalization (40m/16931)
 - Output matrix diagonalization (almost all new suspensions 40m/17073)
 * BHD fringe speed is too fast (~100 fringes/sec?), LO phase locking saturates (40m/17037).
- LO phase locking
 - With better suspensions
 - Measure open loop transfer function
 - Try dither lock with dithering LO or AS with MICH offset (single modulation)
 - Modify c1hpc/c1lsc so that it can modulate BS and do double demodulation, and try double demodulation
- Noise Budget HIGH
 - Calibrate MICH error signal and AS-LO fringe
 - Calibrate LO1, LO2, AS1, AS4 actuation using ITM single bounce - LO fringe
 - Check BHD DCPD signal chain (DCPD making negative output when fringes are too fast; 40m/17067)
 - Make a sensitivity curve using error and feedback signals
- AS-LO mode-matching 
 - Model what could be causing funny LO shape
 - Model if having low mode-matching is bad or not
 * Measured mode-matching of 56% sounds too low to explain with errors in mode-matching telescope (40m/16859, 40m/17067).

IMC related
- WFS loops too fast (40m/17061)
- Noise Budget
- Investigate MC3 damping (40m/17073)
- MC2 length control path

Juan and I built an analog setup to measure some transfer functions of the MOS suspension. The setup is blocking the lab way around the PD test bench.
Excuse us for the inconvenience. It will be removed/cleared by the end of the week.

[Tega, Yuta]

I keep getting confused about the purpose of the teststand. The view I am adopting going forward is its use as a platform for testing the compatibility of new hardware upgrade, instead of thinking of it as an independent system that works with old hardware.

The initial idea of clearing 1X7 cannot be done for now, because I missed the deadline for providing a detailed enough plan before Monday power up of the lab, so we are just going to go ahead and use the new rack as was initially intended and get the latest hardware and software tested here.

We mounted the DAQ, subnet and dolphin IX switches, see attachement 1. The mounting ears that came with the dolphin switch did not fit and so could not be used for mounting. We looked around the lab and decided to used one of the NavePoint mounting brackets which we found next to the teststand, see attachment 2.

We plan to move the new rack to the current location of the teststand and use the power connection from there. It is also closer to 1X7 so that moving the front-ends and switches to 1X7 should be straight forward after we complete all CDS upgrade testing.

- Disk Full: Just use the usual /etc/logrotate thing

- Vacuum gauge

I rather feel not replacing P1a. We used to have Ps and CCs as they didn't cover the entire pressure range. However, this new FRG (=Full Range Gauge) does cover from 1atm to 4nTorr.

Why don't we have a couple of FRG spares, instead?

Questions to Tega: How many FRGs can our XGS-600 controller handle?