40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 62 of 336 Not logged in
ID Date Author Type Category Subject
13845   Tue May 15 20:51:27 2018 gautamConfigurationElectronicsMaking PLL setup more permanent

[jon, steve, gautam]

Some points which Jon will elaborate upon (and put photos of) in his detailed elog about this setup:

• PLL electronics (mixer, coupler, ZFL500HLN amplifier and DC power supply for the beatnote, SR560 servo) all reside on the newly installed lower level PSL shelf.
• Cross connect channel C1:PSL-126MOPA_126CURADJ hijacked for remote temperature control of the AUX NPRO. Note that shield of front panel BNC is ground and so even though the manual says the controller accepts +/-10V, this is not a differential input. BNC cable was routed from cross connect to PSL enclosure, MEDM slider will be setup.
• There was an SMA cable running from the VEA to the control room which we decided to use for monitoring of the beatnote amplitude on the control room analyzer. Yesterday, Steve and I routed the end of this inside the VEA, near 1X2 originally, to inside the PSL table where it is hooked up to the (20dB) coupled amplifier output. This required some work on the cable tray, we were careful but in case there is some wonkiness in some signals, perhaps this work is to blame.

We are now in a state where the PLL can be locked remotely from the control room by tweaking the AUX laser temperature . Tomorrow, Keerthana will work on getting Craig's/Johannes' Digital Frequency Counter script working here, I think we can easily implement a PLL autolocker if we have some diagostic that tells us if the PLL us locked or not.

Steve informed me that there is an acoustic hum inside the PSL enclosure which wasn't there before. Indeed, it is at ~295Hz, and is from the Bench power supply used to power the ZFL500HLN amplifier. This will have to go...

13844   Tue May 15 15:13:23 2018 KiraSummaryPEMAcromag issues

I tried calibrating the other channels today, but they still fluctuate. Sometimes they do stabilize at +/- 10V, but then suddenly drop to 5 or 6 V before climbing back up to 10. Turning the legacy off made it go only up to 6.67V. This happens for all the channels, even after doing a factory reset and recalibrating. Not sure what's happening here.

13843   Tue May 15 13:34:30 2018 SteveUpdatesafetysurf safety training

Pooja and Keirthana received 40m specific basic safety training.

13842   Tue May 15 10:42:14 2018 KojiUpdatePSLModulation depth measurement for the 3IFO aLIGO EOM and aftermath

The marconi RF output was turned on and thus the RF generator condition was restored to the nominal state on Friday 11th.

13841   Mon May 14 18:58:32 2018 KevinUpdatePonderSqueezeSqueezing with no SRM
 Quote: Note that for Signal Recycling, which is what Kevin tells us we need to do, there is a DARM pole at ~150 Hz.

To be quantitative, since we are looking at smaller squeezing levels and considering the possibility of using 5 W input power, it is possible to see a small amount of squeezing below vacuum with no SRM.

Attachment 1 shows the amount of squeezing below vacuum obtainable as a function of homodyne angle with no SRM and 5 W incident on the back of PRM. The optimum homodyne angle at 210 Hz is 89.2 deg which gives -0.38 dBvac of squeezing. Figure 2 is the displacement noise at this optimal homodyne angle and attachment 3 is the same noise budget shown as the ratio of the various noise sources to the unsqueezed vacuum.

The other parameters used for these calculations are:

• 4.5 kΩ series resistance for the ETM coils; 15 kΩ for the ITM coils
• 100 ppm transmissivity on the folding mirrors giving a PRC gain of 40
• PD quantum efficiency of 0.88

So maybe it's worth considering going for less squeezing with no SRM if that makes it technically more feasible.

Attachment 1: homodyne_heatmap.pdf
Attachment 2: displacement_noise.pdf
Attachment 3: noise_budget.pdf
13840   Mon May 14 08:55:40 2018 Dennis CoyneHowToSEIpreparation of load cell measurement at ETMX

follow up email from Dennis 5-13-2018. The last line agrees with the numbers in elog13821.

Hi Steve & Gautam,

I've made some measurements of the spare (damaged) 40m bellows. Unfortunately neither of our coordinate measurement arms are currently set up (and I couldn't find an appropriate micrometer or caliper), so I could not (yet) directly measure the thickness. However from the other dimensional measurements, and a measurement of the axial stiffness (100 lb/in), and calculations (from the Standards of the Expansion Joint Manufacturers Association (EJMA), 6th ed., 1993) I infer a thickness of 0.010 inch in . This is close to a value of 0.012 in used by MDC Vacuum for bellows of about this size.

I calculate that the maximum allowable torsional rotation is 1.3 mrad. This corresponds to a differential height, across the 32 in span between support points, of 0.041 in.

In addition using the EJMA formulas I find that one can laterally displace the bellows by 0.50 inch (assuming a simultaneous axial displacement of 0.25 inch, but no torsion), but no more than ~200 times. I might be good to stay well below this limit, say no more than ~0.25 inch (6 mm).

If interested I've uploaded my calculations as a file associated with the bellows drawing at D990577-A/v1.

BTW in some notes that I was given (by either Larry Jones or Alan Weinstein) related to the 40m Stacis units, I see a sketch from Steve dated 3/2000 faxed to TMC which indicates 1200 lbs on each of two Stacis units and 2400 on the third Stacis.

13839   Sun May 13 20:48:38 2018 johannesUpdateGeneralCDS crash

I think the root of the problem is that the /opt/rtapps/ and /cvs/cds/rtapps/ mounting locations point to the same directory on the nfs server. Gautam and I were cleaning up the /cvs/cds/caltech/target/ directory, placing the previous contents of /cvs/cds/caltech/target/c1auxex/, including database files and startup instructions in /cvs/cds/caltech/target/c1auxex_oldVME/, and then moved /cvs/cds/caltech/target/c1auxex2/, which has the channel database and initialization files for the Acromac DAQ, to /cvs/cds/caltech/target/c1auxex/.

This also required updating the systemd entries on c1auxex to point to the changed directory. While confirming that everything worked as before we noticed that upon startup the EPICS IOC complains about not being able to find the caRepeater binary. This was not new and has not limited DAQ functionality in the past, but we wanted to fix this, as it seemed to be some simple PATH issue. While the paths are all correctly defined in the user login shell, systemd runs on a lower level and doesn't know about them. One thing we tried was to let systemd execute /cvs/cds/rtapps/epics-3.14.12.2_long/etc/epics-user-env.sh initializing EPICS. It was strange that the content of that file was pointing to /opt/rtapps/epics-3.14.12.2_long/base, which is not mounted on the slow machines, so we changed the /opt/ it to /cvs/cds/, not realizing that the frontends read from the same directory (as Gautam said, /cvs/cds does not exist as a mount point on the frontend). It ended up not working this way, and apparently I forgot to change it back during clean up. But worse, never elogged it!

In the end, we managed to to give systemd the correct path definitions by explicitly calling them out in /cvs/cds/caltech/target/c1auxex/ETMXenv, to which a reference was added in the systemd service file. The caRepeater warning no longer appears.

13838   Sun May 13 17:31:51 2018 gautamUpdateGeneralCDS crash

As suspected, this was indeed a path problem. Johannes will elog about it later, but in short, it is related to some path variables being changed in order to try and streamline the EPICS processes on the new c1auxex machine (Acromag Era). It is confusing that futzing around with the slow computing system messes with the realtime system as well - aren't these supposed to be decoupled? Once the paths were restored by Johannes, everything compiled and restarted fine. We even have a beam on the AS camera, which was what triggered this whole thing.

Anyways, Attachment #1 shows the current status. I am puzzled by the red TIMING indicators on the c1x04 and c1x02 processes, it is absent from any other processes. How can this be debugged further?

 Quote: I suspect this is some kind of path problem - the EPICS_BASE bash variable is set to /cvs/cds/rtapps/epics-3.14.12.2_long/base on the FEs, while /cvs isn't even mounted on the FEs (nor do I think it should be). I think the correct path should be /opt/rtapps/epics-3.14.12.2_long/base. Why should this have changed?
Attachment 1: CDS_overview_20180513.png
Attachment 2: AS_1210293643.jpeg
13837   Sun May 13 15:15:18 2018 gautamUpdateGeneralCDS crash

I found the c1lsc machine to be completely unresponsive today. Looking at the trend of the state word, it happened sometime yesterday (Saturday). The usual reboot procedure did not work - I am not able to bring back any of the models on any of the machines, during the restart procedure, they all fail. The logfile reads (for the c1ioo front end, but they all behave the same):

[  309.783460] c1x03: Initializing space for daqLib buffers
[  309.887357] CPU 2 is now offline
[  309.887422] c1x03: Sync source = 4
[  309.887425] c1x03: Waiting for EPICS BURT Restore = 2
[  309.946320] c1x03: Waiting for EPICS BURT 0
[  309.946320] c1x03: BURT Restore Complete
[  309.946320] c1x03: Corrupted Epics data:  module=0 filter=1 filterType=0 filtSections=134610112
[  309.946320] c1x03: Filter module init failed, exiting
[  363.229086] c1x03: Setting stop_working_threads to 1
[  364.233689] Will bring back CPU 2
[  365.236674] Booting Node 1 Processor 2 APIC 0x2
[  365.236771] smpboot cpu 2: start_ip = 9a000
[  309.946320] Calibrating delay loop (skipped) already calibrated this CPU
[  365.251060] NMI watchdog enabled, takes one hw-pmu counter.
[  365.252135] Brought the CPU back up
[  365.252138] c1x03: Just before returning from cleanup_module for c1x03

Not sure what is going on here, or what "Corrutped EPICS data" is supposed to mean. Thinking that something was messed up the last time the model was compiled, I tried recompiling the IOP model. But I'm not able to even compile the model, it fails giving the error message

make[1]: Leaving directory '/opt/rtcds/caltech/c1/rtbuild/3.4'
make[1]: *** [build/c1x03epics/c1x03.c] Error 127
Makefile:28: recipe for target 'c1x03' failed
make: *** [c1x03] Error 1

I suspect this is some kind of path problem - the EPICS_BASE bash variable is set to /cvs/cds/rtapps/epics-3.14.12.2_long/base on the FEs, while /cvs isn't even mounted on the FEs (nor do I think it should be). I think the correct path should be /opt/rtapps/epics-3.14.12.2_long/base. Why should this have changed?

I've shutdown all watchdogs until this is resolved.

Attachment 1: vertexFEs_crashed.png
13836   Sat May 12 10:02:03 2018 ranaUpdateGeneralMore refinement of DARM control signal projection

Good question! I've never calculated what the resonance frequency would be if had an inductive resistor with our cable capacitance (~50 pF/m I guess).

13835   Fri May 11 19:02:52 2018 gautamUpdateGeneralMore refinement of DARM control signal projection

I was a bit hasty in posting the earlier plots. In the earlier plot, the "OLG" trace was OLG * anti dewhitening as Rana pointed out.

Here are the updated ones, and a cartoon (Attachment #5) of the loop topology I assumed. I've excluded things like violin filters, AA/AI etc. The overall gain scaling I mentioned in the previous elog amounts to changing the optical sensing response in this cartoon. I now also show the DARM suppression (Attachment #4) for this OLG and the DARM linewidths for RSE. I don't think the conclusions change.

Note that for Signal Recycling, which is what Kevin tells us we need to do, there is a DARM pole at ~150 Hz. I assume we will cancel this in the digital controller and so can achieve a similar OLG shape. This would modify the control signal spectrum a little around 150Hz. But for a UGF on the loop of ~150 Hz, we should still be able to roll-off the control signal at high frequencies and so the RMS shouldn't be dramatically affected.

Steve is looking into acquiring 4.5kohm Vishay Wirewound resistors with 1% tolerance. Plan is to install two in parallel (so that we get 2kohm effective resistance) and then snip off one once we are convinced we won't have any actuation range issues. Do these look okay? They're ~\$1.50ea on mouser assuming we get 100. Do we need the non-inductive winding?

 Quote: I think "OLG" trace is not labeled right; it would be good to see the actual OLG in addition to whatever that trace actually is.
Attachment 1: darmProj.pdf
Attachment 2: darmOLTF.pdf
Attachment 3: DWcomparison.pdf
Attachment 4: DARMsuppression.pdf
Attachment 5: ControlLoop.pdf
13834   Fri May 11 18:17:07 2018 gautamUpdateDetCharAUX laser PLL setup

[koji, gautam]

As discussed at the meeting earlier this week, we will use some old *MOPA* channels for interfacing with the PLL system Jon is setting up. He is going to put a sketch+photos up here shortly, but in the meantime, Koji helped me identify a channel that can be used to tune the temperature of the Lightwave NPRO crystal via front panel BNC input. It is C1:PSL-126MOPA_126CURADJ, and is configured to output between +/-10V, which is exactly what the controller can accept. The conversion factor from EPICS value to volts is currently set to 1 (i.e. EPICS value of +1 corresponds to +1V output from the DAC). With the help of the wiring diagram, we identified pins 3 and 4 on cross-connect #J7 as the differential outputs corresponding to this channel. Not sure if we need to also setup a TTL channel for servo ENABLE/DISABLE, but if so, the wiring diagram should help us identify this as well.

The cable from the DAC to the cross-connect was wrongly labelled. I fixed this now.

13833   Fri May 11 13:58:42 2018 ranaUpdateGeneralMore refinement of DARM control signal projection

I think "OLG" trace is not labeled right; it would be good to see the actual OLG in addition to whatever that trace actually is.

Based on the first plot, however, my conclusion is that:

1. we don't need the passive isolator to reduce the control signal; the control signal is dominated by f < 10 Hz.
2. we should still look into isolators for the reduction of the f > 50 Hz stuff, just to make the overall DARM sensitivity better. But this does not have to be pneumatic since we no longer need 10 Hz isolation. It can instead be a solid piece of rubber to give us a ~20-30 Hz resonance. That would still give us a factor of 5-10 improvement above 100 Hz.
3. In this case, we only need a mass estimate of the end chamber contents with an accuracy of ~25%. If we think we have that already, we don't need to keep doing the jacks-strain gauge adventure.
13832   Fri May 11 11:47:33 2018 johannesSummaryPEMAcromag issues

The replacement Acromag we scooped from the West Bridge E-Shop does actually seem to work, although we thought it was broken - at first it was just outputting zeros, but after I did the calibration procedure, applying +10 V and -10 V, respectively, it was reporting voltage correctly, over the full range. I don't know why the factory settings would be messed up, but it had been out of the box before. I did this only with channel 7, so you need to calibrate channels 0-6 and confirm that they indeed also work properly.

13831   Thu May 10 14:13:22 2018 gautamUpdateGeneralMore refinement of DARM control signal projection

Summary:

1. It seems that after a x10 increase in the coil driver resistance, we will have enough actuation range to control (anti de-whitened) DARM without saturating the DAC.
2. The Barry puck doesn't seem to help us much in reducing the required RMS for DARM control. If this calculation is to be believed, it actually makes the RMS actuation a little bit higher.

See Attachment #1 for the projected control signal ASDs. The main assumption in the above is that all other control loops can be low-passed sufficiently such that even with anti-dewhitening, we won't run into saturation issues.

DARM control loop:

• I'm now calculating the DARM control signal in counts after factoring into account a digital DARM control loop.
• The loop shape is what we used when the DRFPMI was locked in Oct 2015.
• I scaled the overall OLTF gain to have a UGF around 200Hz.
• The breakdown of how the DARM loop is constructed is shown in Attachment #2.

De-whitening and Anti-De-whitening:

• The existing DW shape in the ITM and ETM signal chains has ~80dB attenuation around 100 Hz.
• Assuming ~5uV/rtHz noise from the DAC, 60dB of low-passing gets us to 5nV/rtHz. With 4.3kohm series resistance, this amounts to ~1pA/rtHz current noise (compared to ~3pA/rtHz from the Johnson noise of the series resistance). Actually, I measured the DAC noise to be more like ~700nV/rtHz at 100 Hz, so the current noise contribution is only 0.16pA/rtHz.
• This amounts to getting rid of the passive filter at the end of the chain in the de-whitening board.
• Attachment #3 shows the existing and proposed filter shapes.

It remains to add the control signals for Oplev, local damping, and ASC to make sure we have sufficient headroom, but given that current projections are predicting using up only ~1000cts of the ~23000cts (RMS) available from the DAC, I think it is likely we won't run into saturations. Need to also figure out what the implication of the reduced actuation range will be on handling the locking transient.

Attachment 1: darmProj.pdf
Attachment 2: darmOLTF.pdf
Attachment 3: DWcomparison.pdf
13830   Thu May 10 11:38:19 2018 gautamUpdateGeneralITMY UL

Looking at Steve's plot, I was reminded of the ITMY UL OSEM issue. The numbers don't make sense to me though - 300um of DC shift in UL with negligible shifts in the other coils should have made a much bigger DC shift in the Oplev spot position.

Attachment 1: ITMY_UL.pdf
13829   Thu May 10 08:45:16 2018 SteveUpdateGeneral4.5M eq. Cabazon, CA

20180508 4:49am Cabazon earth quake 4.5M at 79 miles away.  ETMX is in load cell measurment condition.

 Quote: There was an earthquake, all watchdogs were tripped, ITMX was stuck, and c1psl was dead so MCautolocker was stuck. Watchdogs were reset (except ETMX which remains shutdown until we finish with the stack weight measurement), ITMX was unstuck using the usual jiggling technique, and the c1psl crate was keyed.

Attachment 1: Cabazon4.5m79m.png
Attachment 2: 4.5Meq.png
13828   Wed May 9 19:51:07 2018 gautamUpdateGeneralInput beam misaligned

As suspected - the problem was with the TTs. I tested the TT signal chain by driving a low frequency sine wave using AWG and looking at the signal on an o'scope. But I saw nothing, neither at the AI board monitor point, nor at the actual coil driver mon point. I decided to look at the IOP testpoints for the DAC channels, to see if the signals were going through okay on the digital side. But the IOP channels were flatlined, as viewed on dataviewer (see Attachment #1). This despite the fact that the DAC output monitor screen in the model itself was showing some sensible numbers, again see Attachment #1.

Looking at the CDS overview screen, there were no red flags. But there was a red indicator sneakily hidden away in the IOP model's CDS status screen, the "DAC" field in the state word is red. As Attachment #2 shows, a change in the state word is correlated with the time ASDC went to 0.

Note that there are also no errors on the c1lsc frontend itself, judging by dmesg. I want to do a model restart, but (i) this will likely require reboots of all vertex FEs and (ii) I want to know if any CDS experts want to sniff for clues to what's going on before a model restart wipes out some secret logfiles. I'm a little confused that the rtcds isn't throwing up any errors and causing models to crash if the values are not being written to the registers of the DAC. It may also be that the DAC card itself is dead . To re-iterate, all the EPICS readbacks were suggesting that I am injecting a signal right up to the IOP.

Quoting from the runtime diagnostics note:

NOTE: As V2.7, if this error is detected, the IOP will output zero values to all DAC modules, as a protective measure. Only method to clear this is to restart the IOP and all applications on that computer
Attachment 1: DACweirdness.png
Attachment 2: DACerror.png
13827   Wed May 9 17:30:04 2018 gautamUpdateGeneralInput beam misaligned

There is no beam going into the IFO at the moment. There was definitely a spot on the AS camera after I restored the suspensions yesterday, as you can see from the ASDC level in Attachment #1. But at around 2pm Pacific yesterday, the ASDC level has gone to 0. I suspect the TTs. There is no beam on the REFL camera either when PRM is aligned, and PRM's DC alignment is good as judged by Oplev.

Normally, I am able to recover the beam by scanning the TTs around with some low frequency sine waves, but not today. We don't have any readback (Oplev/OSEM) of the TT alignment, and the DC bias values havent jumped abnormally around the time this happened, judging by the OUT16 monitor points (see Attachment #2). The IMC was also locked at the time when this abrupt drop in ASDC level happened. Unfortunately, we don't have a camera on the Faraday so I don't know where the misalignment is happening, but the beam is certainly not making it to the BS. All the SOS optics (e.g. BS, ITMX and ITMY) are well aligned as judged by Oplev.

Being debugged now...

Attachment 1: InputBeamGone.png
Attachment 2: TTpointing.png
13826   Tue May 8 11:41:16 2018 gautamUpdateGeneralIFO maintenance

There was an earthquake, all watchdogs were tripped, ITMX was stuck, and c1psl was dead so MCautolocker was stuck.

Watchdogs were reset (except ETMX which remains shutdown until we finish with the stack weight measurement), ITMX was unstuck using the usual jiggling technique, and the c1psl crate was keyed.

Attachment 1: ITMX_stuck.png
13825   Tue May 8 10:24:10 2018 KiraSummaryPEMplan for this week

Here are a few things I will be working on:

• Design PCB boards for the heater circuit and temperature sensor circuits [by wednesday]
• Order the front panel I've designed for the seismometer block [today]
• [next week?] install the new Acromag when it comes
13824   Tue May 8 00:40:51 2018 gautamConfigurationALSBeathMouth pulled out of PSL table

Summary:

I did some more BeatMouth characterization. My primary objective was to do a power budget. Specifically, to measure the insertion loss of the mating sleeves and of the fiber beam splitters. All power numbers quoted in this elog are measured with the fiber power meter. Main takeaways:

• Measured insertion loss of all mating sleeves, which are ADAFCPMB2, are in agreement with the < 1dB spec. 1 dB in power is ~20%.
• But there is large variance in the above number, between different supposedly identical connectors.
• Measured insertion loss from input port to coupled ports of the fiber beamsplitters are slightly larger than spec (~3.5dB), when measured after mating the fiber beamsplitter (which has Hi1060 flex fiber) and PM980 fiber (which is what brings light to the BeatMouth).
• But measured insertion loss when mating is between Hi1060 flex fiber ends is more in line with the expected value of ~3.5dB.
• Isolation of fiber beam splitters seems to match the spec of >55dB.

Results:

• I used the fiber bringing 416uW of IR light from EY for this test.
• Insertion loss was measured by injecting the fiber light at one port and measuring the transmitted power at various other ports.
• In order to couple the fiber power meter across a single mating sleeve, I used a short (~1m) patch cable from newport (F-SY-C-1FCA). Technically, this is single mode fiber with the correct type of connector, FC/APC, but is not PM.
• See Attachment #2 for the labeling of the connectors which is how I refer to them in the table below.
• Lest there be confusion, I use the definition of insertion loss  $\mathrm{Insertion ~loss [dB] }=10\mathrm{log_{10}}(\frac{P_{in}}{P_{out}})$.
Mating Sleeve # Insertion loss [dB]
1 0.38
2 0.65
3 0.71
4 0.43
5 0.95
6 0.79
7 0.5

Remarks / Questions:

1. Is there any way to systematically reduce the insertion loss? Like getting a better mating part?
2. Question for the fiber experts: How do we deal with the unused port of the beam-splitters? Right now, they are just capped. But as you can see in Attachment #1, the caps certainly don't block all the light. What are the implications of back-scattered light into the fiber on the ALS noise? I guess the beamsplitter itself has the spec'd 55dB directivity, so do we not care about this?
Attachment 1: IMG_6986.JPG
Attachment 2: IMG_6987.JPG
13823   Mon May 7 20:01:14 2018 RorpheusUpdateGeneralUse anti-dewhitening + show CARMA/DARMA

example of plots illustrating DAC range / saturation

13822   Mon May 7 16:23:06 2018 gautamUpdateGeneralDARM actuation estimate

Summary:

Using the Wiener Filter estimate of the DARM disturbance we will have to cancel, I computed how the control signal would look like for a few scenarios. Our DACs are 16-bit, +/-10V (i.e. +/-32,768cts-pk, or ~23,000cts RMS). We need to consider the shape of the de-whitening filter to conclude whether it is feasible to increase the series resistance by x10 or not.

Some details:

Note that in this first computation, I have not considered

• Actuation range required by other loops (e.g. local damping, Oplev etc).
• At some point, I need to add the 2P/c radiation pressure disturbance as well.
• The control signal is calculated assuming we are actuating equally on both ETMs (but with opposite phase).
• RMS computation is done from 30 Hz downwards, as above 30 Hz, I think the estimate from the previous elog is not true seismic displacement.
• De-whitening filters (or digital whitening), which will be required to suppress DAC noise at 100Hz.
• DARM loop shape, specifically low-pass to avoid sensing noise injection. In this calculation, I just used the pendulum transfer function.

While doing this calculation, I have accounted for the fact that right now, the analog de-whitening filters in the ETM drive chain have a x3 gain which we will remove. Actually this is an assumption, I have not yet measured a transfer function, maybe I'll do one channel at EY to confirm. Also, the actuator gains themselves need to be confirmed.

As I was looking at the coil driver schematic more closely, I realized that there are actually two separate series resistances, one for the fast controls path, and another for the DC bias voltage from the slow ADCs. So I think we have been underestimating the Johnson noise of the coil drivers by sqrt(2). I've also attached screenshots of the IFOalign and MCalign screens. The two  ITMs and ETMX have pitch DC bias values that are compatible with a x10 increase of the series resistance. But even so, we will have ~3pA/rtHz per coil from the two resistances.

gautam 8pm May8: Seems like I had confirmed the x3 gain in the EX de-whitening board when Johannes and I were investigating the AI board offset.

Attachment 1: darmProj.pdf
Attachment 2: 37.png
Attachment 3: MCalign_20180507.png
13821   Mon May 7 15:27:28 2018 gautamUpdateSUSStack measurement expectation

[steve,gautam]

We tried to estimate what the load cell measurement should yield. Here is the weight breakdown (fudge factor for Al table is to try and account for tapped holes):

### Dim in inches

Table 1.22 0.08 2700.00 240.07 0.85 Dia=48", thickness=3"
Stack leg 0.36 0.13 8000.00 100.85 9 Dia=14", thickness=5"
Base plate 1.37 0.05 8000.00 600.18 1 Dia=60",thickness=2"
Base rods 0.10 1.83 8000.00 118.55 2 Dia=4", length=6ft
Stuff on table       100.00
Blue beams       100.00

Total [kg]       2149.01
Total [lbs]       4835.28

• Steve pointed out that there is some material removed from the stack legs for stability (hollows into which the viton springs fit). These countersinks have dimensions of diameter=2", height=1.75". So if we assume each leg has 10% less mass, the total weight becomes ~4600lbs.
• I think we will need to use one more load cell (i.e. total 4) for this measurement (we have more load cells, just need to setup one more controller).
• Steve is looking into acquiring some low profile jacks to deal with the fact that we only have limited travel range on the overall stack height because of the bellows.
• A useful document, from which we pulled some numbers (which also look reasonable using estimated dimensions and density calculations): P952005
Attachment 1: 40m_TMstack.JPG
13820   Mon May 7 11:46:07 2018 gautamUpdatePEMFW parameter update

As part of investigation into this issue, Jonathan Hanks pointed out that the "minute trends" being recorded by our system were actually only being recorded every 120 seconds (a.k.a. 2 minutes). He had fixed the appropriate line in the parameter file, but had not restarted the FW processes. I had restarted it on Friday. (but failed to elog it !)

To check if this made any difference, I pulled 1 hour of "minute trend" data for the PSL table temperature channel from ~1 hour ago, and compared the number of datapoints against a 1 hour minute trend time series from 2 May. I've put the display with # of datapoints (for an identical length of time) from before [left] and after [right] the restart next to the plots in Attachment #1. Seems like we are getting minute trends written every 60 seconds now, as it should be .

The unavailability of trends from nodus is a separate issue for which JH has suggested another fix, to be elogged separately.

 Quote: for whatever reason, I am unable to get minute or second trends from nodus for any channels (IMC, PEM, etc) since the reboot. has there been some more recent FB failure or is this still a bug since last years FB catastrophe?
Attachment 1: FWreboot.png
13819   Sat May 5 22:32:07 2018 KojiUpdatePSLModulation depth measurement for the 3IFO aLIGO EOM

The 3IFO EOM was formerly tuned as the H2 EOM, so the resonant frequencies are different from the nominal aLIGO ones.

PORT1: 8.628MHz / 101 +/- 6 mrad_pk/V_pk
PORT2: 24.082MHz / 41.2 +/- 0.7 mrad_pk/V_pk
PORT3: 43.332MHz / 62.2 +/- 4 mrad_pk/V_pk

9MHz modulation is about x2.4 better than the one installed at LHO.
24MHz modulation is about x14 better. (This is OK as the new 24MHz is not configured to be resonant.)
45MHz modulation is about x1.4 better.

13818   Sat May 5 20:30:21 2018 KojiUpdatePSLModulation depth measurement for the 3IFO aLIGO EOM and aftermath

Caution: Because of this work and my negligence, the RF output of the main Marconi for the IFO modulation is probably off. The amplifier (freq gen. box) was turned on. Therefore, we need to turn the Marconi on for the IFO locking.

I worked on my EOM m easurement using the beat setup. As there was the aux injection electronics, I performed my measurement having tried not to disturb the aux setup. The aux Marconi, the splitted PD output, and an open channel of the oscilloscope were used for my purpose. I have brought the RF spectrum analyzer from the control room. I think I have restored all the electronics back as before. I have re-aligned the beat setup after the EOM removed. Note that the aux NPRO, which had been on, was turned off to save the remaining life of the laser diode.

13817   Fri May 4 21:17:57 2018 gautamConfigurationALSBeathMouth pulled out of PSL table

I have been puzzled about the beat note level we get out of the BeatMouth for some time.

• The beat PD used is the Menlo FPD310.
• But the version we have is an obsolete version of the product, for which a manual is hard to find.
• Hence, I don't know the transimpedance/electrical characteristics of this PD.
• The optical damage threshold of the PD is quoted as 2mW, which is a number I have been careful not to exceed.
• But I've felt that the beat amplitude level we get out of this PD is far too low considering the amount of DC optical power (as measured with a fiber power meter) incident on the PD.
• After some emailing and online hunting, I've gathered some numbers for the PD which are now on the wiki.
• The fiber beam splitters we use inside the BeatMouth don't have PM fibers. There are 3 such splitters inside the BeatMouth. So the overlap efficiency on the PD is unknown.
• But even so, the beat levels I was seeing were too low.

I have pulled the box out in order to re-characterize the DC power levels incident on the PD, and also to change the gain setting on the PD to the lower gain which is more compatible with the level of optical power we have going into the BeatMouth. The modern catalog for the FPD310 (see wiki) suggests that the maximum output voltage swing of the PD is 1Vpp driving a 50ohm load. With 50% overlapping efficiency between the PSL and AUX beams, and 400 uW of optical power from each beam, I expect an output of 0.5Vpp. Even with perfect overlap, I expect 0.8Vpp. So these numbers seem reasonable.

I also plan to check the scaling of electrical beat amplitude to optical power for a couple of levels to see that these scale as expected...

13816   Fri May 4 19:06:28 2018 ranaConfigurationElectronicsAUX-PSL PLL Implementation & Characterization

this doesn't make much sense to me; the phase to frequency conversion (mixer-demod to PZT ) should give us a 1/f loop as Johannes mentioned in the meeting. That doesn't agree with your loop shape.

How about give us some more details of the setup including photos and signal/power levels? And maybe measure the LB1005 TF by itself to find out what's wrong with the loop.

13815   Fri May 4 18:59:39 2018 gautamUpdateSUSStack measurement ongoing

[SV,KA,RXA,GV]

The stack weight measurement is going on at EX. ETMX watchdog is shutdown. Area is off limits over the weekend until the test is finished.

Not related to this work, but the dog clamps used on the EX table have to be re-positioned such that the clamping force is better distributed. The 2" beam splitter mount used to pick off a portion of the EX NPRO beam to the fiber has to be rotated. Also, there was a M6.9 EQ in Hawaii while we were doing this work it seems..

13814   Fri May 4 13:24:56 2018 Jon RichardsonConfigurationElectronicsAUX-PSL PLL Implementation & Characterization

Attached are final details of the phase-locked loop (PLL) implementation we'll use for slaving the AUX 700 mW NPRO laser to the PSL.

The first image is a schematic of the electronics used to create the analog loop. They are curently housed on an analyzer cart beside the PSL table. If this setup is made permanent, we will move them to a location inside the PSL table enclosure.

The second image is the measured transfer function of the closed loop. It achieves approximately 20 dB of noise suppression at low frequencies, with a UGF of 50 kHz. In this configuration, locks were observed to hold for 10s of minutes.

Attachment 1: PLL_Schematic.pdf
Attachment 2: PLL_AUX-PSL_40m.pdf
13813   Thu May 3 20:29:39 2018 gautamConfigurationElectronicsPSL-Aux. Laser Phase-Locked Loop

Some notes about the setup and work at the PSL table today, Jon can add to / correct me.

• All equipment for the phase locking now sit on a cart that is on the west side of the MC beam tube, near ITMX chamber.
• Cables have been routed through the space between the PSL enclosure and the optical table.
• HEPA was turned up for this work, now it has been turned down to the nominal level of 30%.
• Alignment into the PMC had degraded a bit - I tweaked it and now MC transmission is up at ~15600 which is a number I am used to. We still don't have a PMC transmission monitor since the slow ADC failure.
13812   Thu May 3 12:19:13 2018 gautamUpdateCDSslow machine bootfest

Reboot for c1susaux and c1iscaux today. ITMX precautions were followed. Reboots went smoothly.

IMC is shuttered while Jon does PLL characterization...

Now relocked.

13811   Thu May 3 12:10:12 2018 gautamConfigurationGeneralAS port laser injection

I think we need AS55 for locking the configuration Jon suggested - AS55 I and Q were used to lock the SRMI previously, and so I'd like to start from those settings but perhaps there is a way to do this with AS110 I and Q as well.

 Quote: What signals are needed for the Guoy phase measurement? Is AS 110 sufficient, or do we need AS55?

13810   Thu May 3 10:40:43 2018 johannesConfigurationGeneralAS port laser injection

Instead of trying to couple the fiber output into the interferometer, I'm doing the reverse and maximize the amount of interferometer light going into the fiber. I set up the mode-matching solution shown in attachment #1 and started tweaking the lens positions. Attachment #2 shows the setup on the AS table. After the initial placement I kept moving the lenses in the green arrow directions and got more and more light into the fiber.

When I stopped this work yesterday I measured 86% of the AS port light coming out the other fiber end, and I have not yet reached a turning point with moving the lenses, so it's possible I can tickle out a little more than that.

It occured to me though that I may have been a little hasty with the placement of the mirror that in attachment #2 redirects the beam which would ordinarily go to AS55. For my arm ringdown measurements this doesn't matter, I could actually place it even before the 50/50 beamsplitter that sends light onto AS110 and double the amount of light going into the IFO. What signals are needed for the Guoy phase measurement? Is AS 110 sufficient, or do we need AS55?

Attachment 1: mm_solution_AStable.png
Attachment 2: AStable_beampath.pdf
13809   Thu May 3 09:56:42 2018 SteveHowToSEIpreparation of load cell measurement at ETMX

[ Dennis Coyne'  precision answer ]

Differential Height between Isolators

According to a note on the bellows drawing (D990577-x0/A), the design life of the bellows at ± 20 minutes rotational stroke is 10,000 cycles. A 20 minute angular (torsional) rotation of the bellows corresponds to 0.186" differential height change across the 32" span between the chamber support beams (see isolator bracket, D000187-x0/B).

Another consideration regarding the bellows is the lateral shear stress introduced by the vertical translation. The notes on the bellows drawing do not give lateral shear limits. According to MDC's web page for formed bellows in this size range the lateral deflection limit is approximately 10% of the "live length" (aka "active length", or length of the convoluted section). According to the bellows drawing the active length is 3.5", so the maximum allowable lateral deflection should be ~0.35".

Of course when imposing a differential height change both torsional and lateral shear is introduced at the same time. Considering both limits together, the maximum differential height change should be < 0.12".

One final consideration is the initial stress to which the bellows are currently subjected due to a non-centered support beam from tolerances in the assembly and initial installation. Although we do not know this de-centering, we can guess that it may be of the order of ~ 0.04". So the final allowable differential height adjustment from the perspective of bellows stress is < 0.08".   Steve:  accumulated initial stress is unknown.  We used to adjust the original jack screws for IFO aligment in the early days of ~1999. This kind of adjustment was stopped when we realized how dangereous it can be. The fact is that there must be unknown amount of accumulated initial stress. This is my main worry but I'm confident that 0.020" change is safe.

So, with regard to bellows stress alone, your procedure to limit the differential height change to <0.020" is safe and prudent.

However, a more stringent consideration is the coplanarity requirement (TMC Stacis 2000 User's Manual, Doc. No. SERV 04-98-1, May 6, 1991, Rev. 1), section 2, "Installation",which stipulates < 0.010"/ft, or < 0.027" differential height across the 32" span between the chamber support beams. Again, your procedure to limit the differential height change to < 0.02" is safe.

Centered Load on the STACIS Isolators

According to the TMC Stacis 2000 User's Manual (Document No. SERV 04-98-1, May 6, 1991, Rev. 1), section 2, "Installation", typical installations (Figure 2-3) are with one payload interface plate which spans the entire set of 3 or 4 STACIS actuators. Our payload interface is unique.

Section 2.3.1, "Installation Steps": "5. Verify that the top of each isolator is fully under the payload/interface plate; this is essential to ensure proper support and leveling. The payload or interface plate should cover the entire top surface of the Isolator or the entire contact area of the optional jack."

section 2.3.2, "Payload/STACIS Interface": "... or if the supporting points do not completely cover the top surface of each Isolator, an interface plate will be needed."

The sketch in Figure 2-2 indicates an optional leveling jack which appears to have a larger contact surface area than the jacks currently installed in the 40m Lab. Of course this is just a non-dimensioned sketch. Are the jacks used by the 40m Lab provided by TMC, or did we (LIGO) choose them? I beleive Larry Jones purchased them.

A load centering requirement is not explicitly stated, but I think the stipulation to cover the entire top surface of each actuator is not so much to reduce the contact stress but to entire a centered load so that the PZT stack does not have a reaction moment.

From one of the photos in the 40m elog entry (specifically jack_screw.jpg), it appears that at least some isolators have the load off center. You should use this measurement of the load as an opportunity to re-center the loads on the Isolators.

In section 2.3.3, "Earthquake Restraints" restraints are suggested to prevent damage from earth tremors. Does the 40m Lab have EQ restraints? Yes, it has

Screw Jack Location

I could not tell where all of the screw jacks will be placed from the sketch included in the 40m elog entry which outlines the proposed procedure.

The sketch indicates that the load cells will be placed on the center of the tops of the Isolators. This is good. However while discussing the procedure with Gautam he said that he was under the impression that the load cell woudl be placed next to the leveling jack, off-center. This condition may damage the PZT stack. I suggest that the leveling jack be removed and replaced (temporarily) with the load cell, plus any spacer required to make up the height difference. Yes

If you have any further question, just let me know.

Dennis

Dennis Coyne
Chief Engineer, LIGO Laboratory
California Institute of Technology
MC 100-36, 1200 E. California Blvd.

13808   Thu May 3 00:42:38 2018 KevinUpdatePonderSqueezeCoil driver contribution to squeezing noise budget

In light of the discussion at today's meeting, Guantanamo and I looked at how the series resistance for the test mass coil drivers limits the amount of squeezing we could detect.

The parameters used for the following calculations are:

• 4.5 kΩ series resistance for the ETM's (this was 10 kΩ in the previous calculations, so these numbers are a bit worse); 15 kΩ for the ITM's
• 100 ppm transmissivity on the folding mirrors giving a PRC gain of 40
• PD quantum efficiency of 0.88

Since we need to operate very close to signal recycling, instead of the current signal extraction setup, we will need to change the macroscopic length of the SRC. This will change the mode matching requirements such that the current SRM does not have the correct radius of curvature. One solution is to use the spare PRM which has the correct radius of curvature but a transmissivity of 0.05 instead of 0.1. So using this spare PRM for the SRM and changing the length of the SRC to be the same as the PRC we can get

• 0.63 dBvac of squeezing at 205 Hz for 1 W incident on the back of PRM
• 1.12 dBvac of squeezing at 255 Hz for 5 W incident on the back of PRM

This lower transmissivity for the SRM also reduces the achievable squeezing from the current transmissivity of 0.1. For an SRM with a transmissivity of 0.15 (which is roughly the optimal) we can get

• 1 dBvac of squeezing at 205 Hz for 1 W incident on the back of PRM
• 1.7 dBvac of squeezing at 255 Hz for 5 W incident on the back of PRM

The minimum achievable squeezing moves up from around 205 Hz at 1 W to 255 Hz at 5 W because the extra power increases the radiation pressure at lower frequencies.

13807   Wed May 2 21:39:33 2018 gautamConfigurationALSIR ALS for EY

The new K6XS mounts I ordered have arrived. I want to install one of them at the Y-end. I can't find a picture of the current layout but it exists as there is a hardcopy affixed to the ETMY chamber door, Steve, can we dig this up and put it in the wiki? In any case, the current beam going into the fiber is the pickoff from the post-SHG harmonic separator. I'd like to change the layout a bit, and use a pickoff before the doubling oven, but looking at the optical table, this seems like a pretty involved task and would probably require large scale optical hardware rearrangement. In any case, the MM of the green beam into the Y-arm is <50%, so I would like to redo that as well. Does anyone know of a measurement of the mode from the Lightwave NPRO that is installed at EY? I think Annalisa is the one who installed this stuff, but I can't find an actual NPRO mode measurement in her elog thread.

Found it: elog4874, elog8436. I updated the laser inventory page to link the lasers in use to the most recent mode measurements I could find on the elog. I guess ideally we should also link the AM/PM response measurements.

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

as of 3-31-2016

The oplev path was optimized with AR coated lenses and new He/Ne laser Jan 24, 2017

13806   Wed May 2 10:03:58 2018 SteveHowToSEIpreparation of load cell measurement at ETMX

Gautam and Steve,

We have calibrated the load  cells. The support beams height monitoring is almost ready.

The danger of this measurment that  the beams height changes can put shear and torsional forces on this formed (thin walled) bellow

They are designed for mainly axial motion.

The plan is to limit height change to 0.020" max

0, center oplev at X arm locked

1, check that  jack screws are carrying full loads and set height indicator dials to zero ( meaning: Stacis is bypassed )

2, raise beam height with aux leveling wedge  by 0.010"  on all 3 support point and than raise it an other 0.005"

3, replace levelling wedge with load cell that is centered and shimmed.     Dennis   Coyne pointed out that the Stacis foot has to be loaded at the center of the foot and formed bellow can shear at their limits.

4, lower the support beam by 0.005" ......now full load on the cells

Note: jack screw heights will not be adjusted or  touched.......so the present condition will be recovered

 Quote: We could use similar load cells   to make the actual weight measurement on the Stacis legs. This seems practical in our case. I have had bad experience with pneumatic Barry isolators. Our approximate max compression loads are 1500 lbs on 2 feet and 2500 lbs on the 3rd one.

Attachment 4: DSC01009.JPG
Attachment 5: jack_screw.jpg
Attachment 6: ETMX_NW_foot_STACIS.pdf
13805   Tue May 1 19:37:50 2018 gautamUpdateGeneralDARM actuation estimate

Here is an updated plot - the main difference is that I have added a trace that is the frequency domain wiener filter subtraction of the coherent power between the L_X and L_Y time series. I tried reproducing the calculation with the time domain wiener filter subtraction as well, using half of the time series (i.e. 5 mins) to train the wiener filter (with L_X as target and L_Y as witness), but I don't get any subtraction above 5 Hz on the half of the data that is a test data set. Probably I am not doing the pre-filtering correctly - I downsampled the signal to 1 kHz, weighted it by low passing the signal above 40 Hz and trained the Wiener filter on the resulting time series. But this frequency domain Wiener filter subtraction should be at least a lower bound on DARM - indeed, it is slightly lower everywhere than simply taking the time domain subtraction of the two data streams.

To do:

• Re-measure calibration numbers used.
• Redo calculation once the numbers have been verified.

Putting a slightly cleaned up version of this plot in now - I'm only including the coherence-inferred DARM estimate now instead of the straight up time domain subtraction. So this is likely to be an underestimate. At low (<10 Hz) frequencies, the time domain computation lines up fairly well, but I suspect that I am getting huge amounts of spectral leakage (see Attachment #2) in the way I compute the spectrum using scipy's filtering routine (once the Wiener filter has been computed). Note that Attachment #2, I didn't break up the data into a training/testing set as in this case, we just care about the one-off offline performance in order to get an estimate of DARM.

The python version of the wiener filter generating code only supports [b,a] output of the digital filter, an sos filter might give better results. Need to figure out the least painful way of implementing the low-noise digital filtering in python...

Attachment 1: darmEst.pdf
Attachment 2: darmEst_time.pdf
13804   Tue May 1 15:23:18 2018 KiraUpdatePEMnew ADC channel setup issue

[Kira, Johannes]

I connected up the channels for the ADC Acromag a while back and we were planning to install it today so that we could set up a new channel for the out of loop sensor. Unfortunately, the Acromag seems to be broken. We connected up a precision 10V voltage to one of the channels, but the Acromag read out ~7V and it kept fluctuating. Even after calibration, we still got the same result. When enabling the legacy support, we got ~11V. But when we measured the voltage at the screw terminals with a multimeter and it showed 10V, so the issue is not with the wiring. All of the channels have this same issue. We will be ordering more Acromags soon, so hopefully we'll be able to set up the channel soon. I've attached a picture of the Acromag along with the front panel with the channels labeled

Attachment 1: IMG_20180501_152014.jpg
13803   Tue May 1 11:15:19 2018 KiraUpdatePEMPID Quixote

I added an out of loop sensor to the can by placing the lab temperature sensor inside the can. I'm not sure which channel is logging this temperature though. I also noticed that the StripTool still had the old misspelled name for the temperature readout so I fixed that as well.

I've attached a picture of the setup.

 Quote: Increased the Integral gain (from -1 to -4) on the EX temperature controller. This didn't work a few weeks ago, but now with the added P gain, it seems stable. Daily temperature swings are now ~3x smaller. Notes for Kira on what we need to do tomorrow (Friday): add the MEDM screen EPICS values to the DAQ so that we can plot those trends DONE add the out-of-loop sensor to the EX can reboot the AUX-EX so we can pick up the new channels and the fixed spelling of the old channels DONE Re-install EX seismometer and hook up seismometer channels to PEM DAQ so we can start testing its performance. For those who are flabbergasted by the way I calibrated the TEMP_MON channel from volts to deg C, here's how: XMgrace->Data->Transformations->Geometric Transforms... use the 'scale' and 'translate' fields to change the slope and offset for calibration in the obvious ways

Attachment 1: IMG_20180501_154826.jpg
13802   Tue May 1 08:04:13 2018 Jon RichardsonConfigurationElectronicsPSL-Aux. Laser Phase-Locked Loop

[Jon, Gautam, Johannes]

Summary: In support of making a proof-of-concept RF measurement of the SRC Gouy phase, we've implemented a PLL of the aux. 700mW NPRO laser frequency to the PSL. The lock was demonstrated to hold for minutes time scales, at which point the slow (currently uncontrolled) thermal drift of the aux. laser appears to exceed the PZT dynamic range. New (temporary) hardware is set up on an analyzer cart beside the PSL launch table.

Next steps:

- Characterize PLL stability and noise performance (transfer functions).

- Align and mode-match aux. beam from the AS table into the interferometer.

- With the IFO locked in a signal-recycled Michelson configuration, inject broadband (swept) AM sidebands via the aux. laser AOM. Coherently measure the reflection of the driven AM from the SRC.

- Experiment with methods of creating higher-order modes (partially occluding the beam vs. misaligning into, e.g., the output Faraday isolator). The goal is identify a viable techinque that is also possible at the sites, where the squeezer laser serves as the aux. laser.

The full measurement idea is sketched in the attached PDF.

Attachment 1: IMG_2553.jpg
Attachment 4: src_gouy_phase_v3.pdf
13801   Mon Apr 30 23:13:12 2018 KevinUpdateComputer Scripts / ProgramsDataViewer leapseconds

I was trying to plot trends (min, 10 min, and hour) in DataViewer and got the following error message

Connecting.... done
mjd = 58235
Opening leapsecs.dat
Open of leapsecs.dat failed

thoough the plots showed up fine after. Do we need to fix something with the leapsecs.dat file?

13800   Mon Apr 30 15:36:18 2018 KiraUpdatePEMfinal setup sketch

I've attached a sketch of how the panel will be mounted. We should make a small rectangular box that would raise the panel from the block by 1 cm or so to allow the cables to fit into the hole in the block without getting bent. It also has to be airtight so maybe having a thin layer of rubber between the mount and block would be good.

Attachment 1: mount.png
13799   Sun Apr 29 22:53:06 2018 gautamUpdateGeneralDARM actuation estimate

Motivation:

We'd like to know how much actuation is required on the ETMs to lock the DARM degree of freedom. The "disturbance" we are trying to cancel is the seismic driven length fluctuation of the arm cavity. In order to try and estimate what the actuation required will be, we can use data from POX/POY locks. I'd collected some data on Friday which I looked at today. Here are the results.

Method:

• I collected the error and control signals for both arm cavities while they were locked to the PSL.
• Knowing the POX/POY sensing response and the actuator transfer functions, we can back out the free running displacements of the two arm cavities.
• I used numbers from the cal filters which may not be accurate (although POX sensing response which was recently measured).
• But the spectra computed using this method seem reasonable, and the X and Y arm asds line up around 1 Hz (albeit on a log scale).
• In this context, $L_X$ is really a proxy for $|f_X - f_{MC}|$ and similarly for L_Y so I think the algebra works out correctly.
• I didn't include any of the violin mode/AA/AI filters in this calculation.
• Having calculated the arm cavity displacements, I computed "DARM" as L_y- L_x and then plotted its asd.
• For good measure, I also added the quadrature sum of 4 optics' displacement noise as per the 40m GWINC model - there seems to be a pretty large discrepancy, not sure why.

If this approach looks legit, I will compute the control signal that is required to stabilize this level of disturbance using the DARM control loop, and see what is the maximum permissible series resistance we can use in order to realize this stabilization. We can then compare various scenarios like different whitening schemes, with/without Barry puck etc, and look at coil driver noise levels for each of them.

Attachment 1: darmEst.pdf
13798   Fri Apr 27 18:42:02 2018 ranaUpdatePEMnew Seis temp chans

for whatever reason, I am unable to get minute or second trends from nodus for any channels (IMC, PEM, etc) since the reboot. has there been some more recent FB failure or is this still a bug since last years FB catastrophe?

13797   Fri Apr 27 16:55:31 2018 gautamUpdateGeneralEY area access blocked

Steve was calibrating the load cells at the EY table with the crane - we didn't get through the full procedure today, so the area near the EY table is kind of obstructed. The 100kg donut is resting on the floor on the North side of the EY table and is still connected to the crane. There are stopper plates underneath the donut, and it is still connected to the crane. Steve has placed cones around the area too. The crane has been turned off.

13796   Fri Apr 27 01:36:02 2018 gautamConfigurationALSIR ALS noise performance

Summary:

My goal was to do some further characterization of the IR ALS system tonight. With POX as an OOL sensor, I measured an RMS displacement noise of  8 pm with the arm under ALS control. I calculated the CARM linewidth to be 77 Hz (=10.3 pm) for the 40m parameters, assuming 30ppm arm loss. Fuurthermore, this number is 3x better than the 24 pm RMS quoted in the Izumi et. al. paper. Of course I am quoting the best results from my efforts tonight. Conclusions:

1. [Attachment #1] --- With XARM locked using POX, the ALS beat noise (i.e. Phase Tracker output noise) lines up well with the reference we have been using for some time now (and indeed, is better in some places).
2. [Attachment #2] --- With the arm locked on ALS and POX as an OOL sensor, I measured performance comparable to this measurement we did sometime last year. Anomalies in this measurement and the one above were what precipitated the IMC noise investigation.
3. [Attachment #3] --- The above two attachments are not the whole story. During the day, I get significantly worse performance (so much so that I couldn't even do the handoff to ALS control). But in 5 minutes of measurement, the ALS noise seems quite stationary.
4. [Attachment #4] --- This is really the same as Attachment #2, but I wanted to overlay some vlines. Maybe this is a clue to some 60 Hz / ground loop issues, but the RMS has significant contribution from these harmonics. Tmrw, I will add the old measurement overlaid to this plot (and for what its worth, the Izumi et. al. spectrum as well).
5. [Attachment #5] --- With the arm under ALS control, I was able to maintain the lock for a solid hour (and more as I write up this elog). Somehow inkscape screwed up the fonts, but main point here is that TRX is stable to within 10% throughout the observation time.

Since the stability and noise seemed quite good, I decided to collect some arm scan data to give to our modeSpec SURFs to practice fitting (which is the short dip in TRX in Attachment #4). Although after the discussion with Rana today, I think it may be that we want to do this measurement in reflection and not transmission, and look for a zero crossing in the PDH signal. In any case, I was able to scan 7 FSRs without any issues. I will upload the data to some git repo. GPS start time is 1208850775, sweep was 3mins long.

I think the next step here is to noise-budget this curve. At least the DFD noises

Attachment 1: 2018_04_BeatMouth_POX.pdf
Attachment 2: 2018_04_BeatMouth.pdf
Attachment 3: ALSSpecgram.pdf
Attachment 4: ALS_ASD.pdf
Attachment 5: ALSstab.pdf
ELOG V3.1.3-