40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 121 of 341  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  13770   Thu Apr 19 17:15:35 2018 gautamUpdateIOOMore IMC NBing

Summary:

Today, I repeated the coil driver noise measurement. Now, the coil driver noise curve in the noise budget plot (Attachment #1) is the actual measurement of all 12 coils (made with G=100 SR560). I am also attaching the raw voltage noise measurement (input terminated in 50ohms, Attachment #2). Note that POX11 spectrum has now been re-measured with analog de-whitening engaged on all 3 optics such that the DAC noise contribution should be negligible compared to coil driver noise in this configuration. The rows in Attachment #2 correspond to 800 Hz span (top) and full span (bottom) on the FFT analyzer.

Details:

The main difference between this measurement, and the one I did middle of last year (which agreed with the expectation from LISO modeling quite well) is that this measurement was done in-situ inside the eurocrate box while last year, I did everything on the electronics benches. So I claim that the whole mess of harmonics seen in the raw measurements are because of some electronics pickup near 1X6. But even disregarding the peaky features, the floor of ~30nV/rtHz is ~6x than what one would expect from LISO modeling (~5nV/rtHz). I confirmed by looking that the series resistance for all 3 MC optics is 430ohms. I also did the measurement with the nominal bias voltages applied to the four channels (these come in via the slow ADCs). But these paths are low-passed by an 8th order low pass with corner @ 1Hz, so at 100 Hz, even 1uV/rtHz should be totally insignificant. I suppose I could measure (with EPICS sine waves) this low-pass filtering, but it's hard to imagine this being the problem. At the very least, I think we should get rid of the x3 gain on the MC2 coil driver de-whitening board (and also on MC1 and MC3 if they also have the x3 factor).

Attachment 1: IMC_NB_20180419.pdf
IMC_NB_20180419.pdf
Attachment 2: IMC_coilDriverNoises_20180419.pdf
IMC_coilDriverNoises_20180419.pdf
  13773   Fri Apr 20 00:26:34 2018 gautamUpdateALSFibers switched out

Summary:

I think the dominant cause for the fact that we were seeing huge swing in the power coupled into the fiber was that the beam being sent in was in fact not linearly polarized, but elliptically polarized. I've rectified this with the help of a PBS. Fiber has been plugged into my polarization monitoring setup. Let's monitor for some long stretch and see if the situation has improved.

Details:

  • The new fiber mount I ordered, K6XS, arrived today. I like it - it has little keys with which all DoFs can be locked. Moreover, it is compatible with the fixed collimators which IMO is the easiest way to achieve good mode-matching into the fiber. It is basically a plug-and-play replacement for the mounts we were using. Anyways, we can evaluate the performance over the coming days.
  • I installed it on the PSL table (started work ~10pm, HEPA turned up to maximum, PSL shutter closed).
  • But even with the new rotational DoF locking feature, I saw that slight disturbances in the fiber caused wild fluctuations in my polarization monitoring setup PD outputs. This was a useful tool through the night of checking the polarization content in the two special axes - Aidan had suggested using a heat gun but shaking the fiber a bit works well too I think.
  • The PM980 fiber has an alignment key that is aligned with the slow axis of the fiber - so it is a useful alignment reference. But even by perturbing the roational alignment about the vertical by +/-15 degrees, I saw no improvement in this behavior. So I began to question my assumption that the input beam itself had clean polarization content.
  • Since my pickoff beam has gone through a QWP and two PBSs, I had assumed that the beam was linearly polarized.
  • But by putting a PBS just upstream of the input fiber coupler, I could see a beam at the S-port with an IR card (while I expected the beam to be P-polarized).
  • OK - so I decided to clean up the input polarization by leaving this PBS installed. With this modification to the setup, I found that me shaking the fiber around on the PSL table didn't affect the output polarization content nearly as dramatically as before!!yes
  • The state I am leaving it in tonight is such that there is ~100x the power in the P-polarization output monitor as the S-polarization (PER ~ 20dB). I didn't try and optimize this too much more for now, I want to observe some long term trend to see if the wild power fluctuations have been mitigated.
  • The output coupler is mounted on the inferior K6X mount, and so there is the possibility that some drift will be attributable to rotation of the output coupler in it's mount. Thermally driven length changes / time varying stresses in the fiber may also lead to some residual power fluctuations. But I don't expect this to be anywhere near the ~25% I reported in the previous elog.
  • The rejected beam from the PBS was measured to be ~300 uW. I haven't dumped this properly, to be done tomorrow.
  • HEPA turned back down to 30%, PSL enclosure closed up, PSL shutter re-opened ~0030am.
  • Note that the EX and EY fiber coupled beams are also likely subject to the same problem. We have to double check. I think it's better to have a PBS in front of the input fiber coupler as this also gives us control over the amount of light coupled into the fiber.

Power budget:

Power in Measured power (Ophir, filter OFF)
@Input coupler, before PBS 4.4 mW
P-pol content @ input coupler 4.06 mW
S-pol (rejected) from PBS 275 uW
@Output coupler 2.6 mW (MM ~65%)

 

  13775   Fri Apr 20 16:22:32 2018 gautamUpdateGeneralNodus hard-rebooted

Aidan called saying nodus was down at ~345pm. I was able to access it at ~330pm. I couldn't ssh in from my machine or the control room ones. So I went to 1X7 and plugged in a monitor to nodus. It was totally unresponsive. Since the machine wasn't responding to ping either, I decided to hard-reboot it. Machine seemed to come back up smoothly. I had trouble getting the elog started - it wasn't clear to me that the web ports were closed by default, so even though the startELOGD.sh script was running fine, the 8080 port wasn't open to the outside world. Anyways, once I figured this out, I was able to start the elog. DokuWiki also seems to be up and running now... 

  13778   Sat Apr 21 20:19:05 2018 gautamUpdateGeneralMegatron hard-rebooted

I found megatron in a similar state to that which nodus was in yesterday. Clued by the fact that MCautolocker wasn't executing the mc scripts (as was evident from looking at the wall StripTool trace), I tried ssh-ing into megatron, but was unable to (despite it being responsive to ping requests). So I went into the VEA and plugged in a monitor to megatron - saw nothing on it. With no soft reboot options available, I power cycled the machine via the front panel button. It came back up smoothly. I manually restarted the autolocker, FSSslow and EX thermal control processes (the former two with initctl, while the latter runs in a tmux session). Everything seems alright for now. Not sure how long megatron has been dead for.

  13779   Sat Apr 21 20:25:12 2018 gautamUpdateALSPSL fiber pickoff status

Seems like there is still a bit of variation in the power in the two polarizations, though it is much smaller now, at the ~5% level (see Attachment #1). Since the pattern is repeating itself over the day timescale, I think this effect is not because of rotation of the output coupler in the mount, but is in fact a temperature driven waveplate effect because of imperfect alignment at the input coupler (which itself is locked down). I'm going to rotate the input coupler by 5 degrees (old = 110 degrees, new=115degrees) to see if the situation improves...


gautam Apr 24 2pm: Steve suggested confirming the correlation by hooking up the PSL table temperature sensor. This used to be logged but since the c1psl ADC card failure, has not been recorded. Assuming the sensor and preamp still work fine, we can use the PSL diagnostic Acromag (whose channels I have hijacked to monitor polarization stability already) to at least temporarily monitor the temperature inside the PSL enclosure. I am in need of a DB25 breakout board for this purpose which I am missing right now, as soon as I obtain one, I'll hook this up...

Attachment 1: PSL-beatMouthPickoff.png
PSL-beatMouthPickoff.png
  13783   Tue Apr 24 10:10:43 2018 gautamUpdateComputer Scripts / ProgramsParticle swarm hyper parameter optimization

I'm copying and pasting Nikhil's email here as he was unable to login to the elog (but should now be able to in order to reply to any comments, and add more details about this test, motivation, methodology etc).

I did some post-processing after running the grid search. The following steps were carried out:

1) Selected those sets whose cost fun were less than a specific threshold (here 10000)

2) Next task was to see if the parameters of these good solutions had some pattern

3) I used a dimensionality reduction technique called t-SNE to project the 6 dimensional parameter space to 2 dim (for better visualization )

4) Made a scatter plot of these (see fig )

5) Used K-Means to find the clusters in this data

6) MarkerSize & Color reflect the cost fun. Bigger the marker size means better the solution.

7) Visual inspection implied cluster 5 had the best ranking points & more than any other cluster

8) These points had the following Parameter set: Workers {20,40}, SwarmSize {500}, MaxIter {500}, Self Adjustment {1}, Social Adjustment {1}, Tolerance {1e-3,1e-8} 

     See fig: for the box plot 

9) It looks like is a particular set of values rather than individual values that gives the best results.

 

Attachment 1: ClusterFminScaled.png
ClusterFminScaled.png
Attachment 2: ClusterID_5.png
ClusterID_5.png
  13784   Tue Apr 24 11:31:59 2018 gautamConfigurationALSProposed changes to EX fiber coupling

Motivation: I want to make another measurement of the out-of-loop ALS beat noise, with improved MM into both the PSL and EX fibers and also better polarization control. For this, I want to make a few changes at the EX table. 

  1. Replace existing fiber collimator with one of the recently acquired F220-APC-1064 collimators.
    • This gives an output mode of diameter 2.4mm with a beam divergence angle of 0.032 degrees (all numbers theoretical - I will measure these eventually but we need a beam path of ~5m length in order to get a good measurement of this collimated beam).
    • I believe it will be easier to achieve good mode matching into this mode rather than with the existing collimator. 
    • Unfortunately, the mount is still going to be K6X and not K6XS. 
  2. Improve mode-matching into fiber.
    • I used my measurement of the Innolight NPRO mode from 2016, a list of available lenses, and some measured distances to calculate a solution that gives theoretical 100% overlap with the collimator mode, that has beam diameter 2.4mm, located 80cm from the NPRO shutter head location (see Attachment #1).
    • The required movement of components is schematically illustrated in Attachment #2.
    • One of the required lens positions is close to the bracket holding the enclosure to the table, but I think the solution is still workable (the table is pretty crowded so I didn't bother too much with trying to find alternative solutions as all of them are likely to require optics placed close to existing ones and I'd like to avoid messing with the main green beam paths.
    • I will attempt to implement this and see how much mode matching we actually end up getting.
  3. Install a PBS + HWP combo in the EX fiber coupling path.
    • This is for better polarization control.
    • Also gives us more control over how much light is coupled into the fiber in a better way than with the ND filters in current path.
  4. Clean EX fiber tip.
  5. Dump a leakage IR beam from the harmonic separator post doubling oven, which is currently just hitting the enclosure. It looks pretty low power but I didn't measure it.
  6. Re-install EX power monitoring PD.

Barring objections, I will start working on these changes later today.

Attachment 1: EX_fiber_MM.pdf
EX_fiber_MM.pdf
Attachment 2: EX_fiber_changes.png
EX_fiber_changes.png
  13786   Tue Apr 24 18:54:15 2018 gautamConfigurationALSProposed changes to EX fiber coupling

I started working on the EX table. Work is ongoing so I will finish this up later in the evening, but in case anyone is wondering why there is no green light...

  1. EX laser shutter was closed.
  2. Disconnected EX input to the beat mouth at the PSL table in order to avoid accidentally frying the PDs.
  3. Prepared new optomechanics hardware
    • To my surprise, I found a bubble-wrapped K6XS mount (the one with locking screws for all DoFs) on the SP table. No idea where this came from or who brought it here, or how long it has been here, but I decided to use it nevertheless.
    • Prepared f = 200mm and f = -200mm lenses on traveling mounts (Thorlabs DT12, lenses are also Thorlabs, AR1064).
    • Made a slight translation of the beam path towards the north to facilitate going through the center of the mounted lenses.
    • Temporarily removed a beam dump from next to the final steering mirror before the Green REFL PD, and also removed one of the brackets between the enclosure and the table for ease of laying out components. These will be replaced later.
  4. Installed this hardware on the PSL table, roughly aligned beam path.
    • Beam now goes through the center of all lenses and is hitting the collimator roughly in the center.

To do in the eve:

  1. Clean fiber and connect it to the collimator.
  2. Optimize mode-matching as best as possible.
  3. Attenuate power using PBS and HWP so as to not damage the BeatMouth PD (Pthresh = 2mW). These are also required to make the polarizations of the EX coupled light (S-pol) and PSL (P-pol) go along the same axis of the PM fiber.
  4. Re-install temporarily removed beam dump and bracket on EX table.
  5. Re-install EX power monitoring PD.
  6. Measure beat frequency spectrum.
Quote:

Motivation: I want to make another measurement of the out-of-loop ALS beat noise, with improved MM into both the PSL and EX fibers and also better polarization control. For this, I want to make a few changes at the EX table. 

Barring objections, I will start working on these changes later today.


gautam 1245am: Fiber cleaning was done - I'll upload pics tomorrow, but it seems like the fiber was in need of a good cleaning. I did some initial mode-matching attempts, but peaked at 10% MM. Koji suggested not going for the final precisely tunable lens mounting solution while trying to perfect the MM. So I'll use easier to move mounts for the initial tuning and then swap out the DT12s once I have achieved good MM. Note that without any attenuation optics in place, 24.81mW of power is incident on the collimator. In order to facilitate easy debugging, I have connected the spare fiber from PSL to EX at the PSL table to the main EX fiber - this allows me to continuously monitor the power coupled into the fiber at the EX table while I tweak lens positions and alignment. After a bit of struggle, I noticed I had neglected a f=150mm lens in my earlier calculation - I've now included it again, and happily, there seems to be a solution which yields the theoretical 100% MM efficiency. I'll work on implementing this tomorrow..

  13789   Wed Apr 25 19:09:37 2018 gautamConfigurationALSNew look EX Fiber coupling

Summary:

I implemented most of the things outlined in my previous elog. Implementing the a la mode solution after including all lenses, I managed to achieve >90% mode-matching into the fiber. Power monitor PD has not been re-installed yet, neither has the bracket I removed. The polarization monitoring setup on the PSL table has now been hooked up to the EX fiber, let's see how it does overnight. All quoted power measurements in this elog were made with the Ophir power meter (filter off).

Details:  

Attachment #1 shows the implemented MM solution. I did not include the PBS substrate in the calculation, maybe that will help a little.

Attachment #2 shows the new layout. The beam is a little low on the PBS and HWP - I will swap these out to mounts with slightly lower height, that should improve the situation a little. There is no evidence of clipping, and the beam clears all edges by at least 3 beam diameters.

Attachments #3 and #4 show the EX fiber before and after cleaning respectively. Seems like the cleaning was successful.

Attachment #5 shows the beam incident on the coupler with on an IR card. This beam only goes through a QWP, lens, BS and 45 degree steering mirror, so I'm not sure what's responsible for the large halo around the main beam. There is significant power in the halo too - I measured 25mW right before the coupler, but if I use an iris to try and cut off the halo, the power is measured to be ~19mW.

Alignment Procedure:

  • Connect spare fiber such that I can monitor coupled power (minus fiber losses and joint loss) at EX table.
  • Use Fluke fault analyzer to align input and collimator modes coarsely.
  • Monitored coupled power continuously using Fiber Power Meter (although MM calculations were made with Ophir, this was more convenient for "Live" viewing).
  • Tweaked one available steering mirror and K6XS axes to maximize coupled power. 
  • Tweaked lens positions slightly to see if significant improvement could be made.
  • After optimizing, I measured 17.1mW coming out of the EX fiber at the PSL table. As mentioned earlier, the input power is tricky to measure given the large amount of junk light around the main mode. But I measured 18.6 mW after the iris. So this is ~95%. In any case, safe to say that we are waaaay better than the previous situation of 380uW out of 1.9mW. 
  • Added PBS and HWP to cut the incident power to 1.6mW. I measured 1.2mW on the PSL table. Probably adding the PBS screwed up the MM a bit, to be tweaked tomorrow. 
  • I had moved the Green shutter a bit during this work - as a result, the Green REFL was not making it back to the REFL PD. I remedied this, and EX Green TEM00 mode was locked to the arm. GTRX of ~0.4 was recovered, which is around the number I'm used to seeing.
Attachment 1: EX_fiber_MM.pdf
EX_fiber_MM.pdf
Attachment 2: IMG_6977.JPG
IMG_6977.JPG
Attachment 3: IMG_6972.JPG
IMG_6972.JPG
Attachment 4: IMG_6974.JPG
IMG_6974.JPG
Attachment 5: IMG_6976.JPG
IMG_6976.JPG
  13791   Thu Apr 26 11:24:50 2018 gautamConfigurationALSNew look EX Fiber coupling - pol stability

Here is a first look at the overnight stability. For the temperature, I used the calibration I found in the old psl database file, seems to give sensible results. It's only 15 hours of data plotted, so we don't see the full 24 hour temperature swing, but I think it is safe to say that for the EX fiber, the dominant cause of the "waveplate effect" is not in fact temperature drift. The polarization extinction is still better than 10dB in the entire period of observation though... I'm going to push ahead with a beat spectrum measurement, though there is room for improvement in the input coupling alignment to fiber special axes.

The apparent increase in these plots towards the end of the 15 hour period is because the lights on the PSL table were switched on.


Annoyingly, it seems like the PSL NPRO channels (which I have hijacked to do this test) do not have minute trend data directly accessible from NDS2. Not sure whether this is an NDS2 problem, or something missing in the way the channels are setup with Acromag. Probably the former, as I am able to generate minute trend plots with dataviewer. I forget whether this is the same as the infamous minute trend problem. Second trend data is available though, and is what I used to make these plots...

Attachment 1: polStab.pdf
polStab.pdf
  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
2018_04_BeatMouth_POX.pdf
Attachment 2: 2018_04_BeatMouth.pdf
2018_04_BeatMouth.pdf
Attachment 3: ALSSpecgram.pdf
ALSSpecgram.pdf
Attachment 4: ALS_ASD.pdf
ALS_ASD.pdf
Attachment 5: ALSstab.pdf
ALSstab.pdf
  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.

  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
darmEst.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
darmEst.pdf
Attachment 2: darmEst_time.pdf
darmEst_time.pdf
  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.

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

SV  ETMY optical table layout  

     as of 3-31-2016

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

  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?

 

  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.

  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.
  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..

  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...

  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 !) no

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 yes.

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
FWreboot.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):

Element

Diameter [m]

Height [m]

Density [kg/m^3]

Mass [kg]

Number or fudge factor

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
40m_TMstack.JPG
  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
darmProj.pdf
Attachment 2: 37.png
37.png
Attachment 3: MCalign_20180507.png
MCalign_20180507.png
  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
IMG_6986.JPG
Attachment 2: IMG_6987.JPG
IMG_6987.JPG
  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
ITMX_stuck.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
InputBeamGone.png
Attachment 2: TTpointing.png
TTpointing.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 sad. 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
DACweirdness.png
Attachment 2: DACerror.png
DACerror.png
  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
ITMY_UL.pdf
  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
darmProj.pdf
Attachment 2: darmOLTF.pdf
darmOLTF.pdf
Attachment 3: DWcomparison.pdf
DWcomparison.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.

  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
darmProj.pdf
Attachment 2: darmOLTF.pdf
darmOLTF.pdf
Attachment 3: DWcomparison.pdf
DWcomparison.pdf
Attachment 4: DARMsuppression.pdf
DARMsuppression.pdf
Attachment 5: ControlLoop.pdf
ControlLoop.pdf
  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.232148] DXH Adapter 0 : BROADCAST - dx_user_mcast_unbind - mcgroupid=0x3
[  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]: /cvs/cds/rtapps/epics-3.14.12.2_long/modules/seq/bin/linux-x86_64/snc: Command not found
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
vertexFEs_crashed.png
  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 thingyes.

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
CDS_overview_20180513.png
Attachment 2: AS_1210293643.jpeg
AS_1210293643.jpeg
  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 laugh. 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...

  13846   Tue May 15 21:56:57 2018 gautamUpdateGeneralStack measurement setup decommissioned

[steve,koji,gautam]

Since we think we already know the stack mass to ~25% (i.e. 5000 +/- 1000 lbs), we decided to restore the ETMX stack. Procedure followed was:

  • Take photos of all dial indicators and spirit level. We were at ~-22 mils on all 3 indicators, with 0 being the level before we touched the stack two Fridays ago, i.e. May4.
  • Raised all four jacks installed underneat blue crossbeams in 5mil increments until we were at +25mils on all of them. At this point, there was negligible load on the load cells on top of the STACIS legs, and we could easily slide the load cells out.
  • Rotated all jack screws clockwise (i.e. moving jack screws downwards) by 270 degrees. The southeast jackscrew was rotated by an additional 360 degrees. This was to undo all the jack-screw raising we did on Friday, May 4.
  • Re-installed jacks which were present originally on the STACIS legs, taking care to center the jack as best as we could by eye on the STACIS leg, per Dennis Coyne's suggestion not to impose shear strain on STACIS legs. There were supposedly never carrying any load, and are according to Steve, are there more for safety purposes.
  • Lowered all four jacks in 5 mil steps until dial indicators read ~0. The Northwest jack resting on the STACIS leg was somehow ~0.5cm (!!) below the blue crossbeam even though the corresponding dial gauge read 0, so we raised the jack until it was barely grazing the bottom of the blue crossbeam (confirmed by looking at the point where the dial indicator started going up again). Not sure why this should have been, best hypothesis we have is that someone (one of us) changed the level of this jack while it was removed from the setup.
  • Checked that jack screws could not be turned by hand. At this point, all the load has to be resting on the jack screws, as the jacks we had installed to raise the blue crossbeams could be slid out from underneath the blue beams and hence were carrying no load.
  • Took photographs of all dial indicators, spirit level. We were satisfied that we had recovered the "nominal" stack alignment as best as we could judge with the available indicators.
  • ETMX Oplev spot had returned to the PD. ETMX watchdog was re-engaged, optic was re-aligned using SLOW bias sliders to center Oplev spot.
  • EX NPRO was turned back on, and the green beam was readily locked to a cavity TEM00 mode yes.

I will upload the photos to the PICASA page and post the link here later.

Quote:
 

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.

 

  13847   Tue May 15 22:11:38 2018 gautamUpdateGeneralIFO maintenance

Since there have been various software/hardware activity going on (stack weighing, AUX laser PLL, computing timing errors etc etc), I decided to do a check on the state of the IFO.

  • c1susaux, c1aux and c1iscaux crates were keyed as they were un-telnet-able.
  • Single arm locking worked fine, TT alignment was tweaked (as these had drifted due to the ADC failure in c1lsc) to maximize Y arm transmission using the dither servos.
  • Arms weren't staying locked for extended periods of time. I particularly suspected ITMX, as I saw what I judged to be excess motion on the Oplev.
  • @Steve - ITMX and BS HeNes look like they are in need of replacement judging by the RIN (although the trend data doesn't show any precipitous drop in power). If we are replacing the BS/PRM Oplev HeNe, might be a good time to plan the inejction path a bit better on that table.
  • RIN in Attachment #1 has been normalized by the mean value of the OL sum channel. There is now a script to make this kind of plot from NDS in the scripts directory (as I found it confusing to apply different calibrations to individual traces in DTT).
Attachment 1: OL_RIN_2018_05_15.pdf
OL_RIN_2018_05_15.pdf
Attachment 2: OLsums.png
OLsums.png
  13848   Wed May 16 18:52:50 2018 gautamConfigurationElectronicsPLL mysteries solved

[Koji, Gautam]

Summary:

As I suspected, when the SR560 is operated in 1 Hz, first order LPF mode, the (electronic) transfer function has a zero at ~5kHz (!!!).

Details:

This is what allowed the PLL to be locked with this setting with UGF of ~30kHz. On the evidence of Attachment #3, there is also some flattening of the electrical TF at low frequencies when the SR560 is driving the NPRO PZT. I'm pretty sure the flattening is not a data download error but since this issue needs further investigation anyway, I'm not reading too much into it. I fit the model with LISO but since we don't have low frequency (~1Hz) data, the fit isn't great, so I'm excluding it from the plots.

We also did some PLL loop characterization. We decided that the higher output range (10Vp bs 10Vpp for the SR560) of the LB1005 controller means it is a better option for the PLL. The lock state can also be triggered remotely. It was locked with UGF ~ 60kHz, PM ~45deg.

We also measured the actuation coefficient of the NPRO laser PZT to be 4.89 +/- 0.02 MHz/V. Quoted error is (1-sigma) from the fit of the linear part of the measured transfer function to a single pole at DC with unknown gain. I used the "clean" part of the measurement that extends to lower frequencies for the fit, as can be seen from the residuals plot. Good to know that even though the LDs are dying, the PZT is still going strong :D.

Remaining loop characterization (i.e. verification of correct scaling of in loop suppression with loop gain etc.) is left to Jon.

Measurement schemes:

  1. OLG (Attachment #1) was measured using the usual IN1/IN2 technique.
  2. PZT calibration (Attachment #2) was measured by injecting an excitation at the PLL control point.
    • The ratio of the PLL error point (Volts) to Excitation (Volts) was measured using the SR785.
    • The error point was calibrated by looking at the PLL open loop Vpp (corresponds to pi radians of phase shift).
    • Dividing the fitted gain of the phase->Frequency conversion by the error point calibration, we get the PZT actuation coefficient. 

Some other remarks:

  1. In the swept-sine mode, the SR785 measures transfer functions by taking the ratio of complex FFT values of its inputs at the drive frequency. So the phase in particular is a good indicator of whether the measurement is coherent or not.
  2. In all these measurements, the PLL gain is huge at low frequencies, and hence, the excitation is completely squished on propagating through the loop. E.g. a 10mV excitation is suppressed by a factor of ~60dB = 1000 to 10uV, and if the analyzer autoRange is set to UpOnly, it is easy to see how this is drowned at the IN1 input. This is why the measurements lose coherence below ~1 kHz.
  3. It is easy to imagine implementing an EPICS servo that offloads the DC part of the LB box control signal to the SLOW frequency input on the Lightwave controller. This would presumably allow us to extend the lock timescales. We can also easily implement a PLL autolocker.
  4. Preliminary investigation of the SR560 situation suggests that individual filter stages can only achieve a maximum stopband attenuation of 60dB relative to the passband. When we cascade two stages together, 120dB seems possible...
Attachment 1: PLLanalysis.pdf
PLLanalysis.pdf
Attachment 2: PZTcal.pdf
PZTcal.pdf
Attachment 3: SR560_funkiness.pdf
SR560_funkiness.pdf
  13852   Thu May 17 11:56:37 2018 gautamUpdateGeneralEPICS process died on c1ioo

The EPICS process on the c1ioo front end had died mysteriously. As a result, MC autolocker wasn't working, since the autolocker control variables are EPICS channels defined in the c1ioo model. I restarted the model, and now MCautolocker works.

  13860   Thu May 17 18:05:01 2018 gautamUpdateSUSSR785 near 1X5

I'm working near 1X5 and there is an SR785 adjacent to the electronics rack with some cabling running along the floor. I plan to continue in the evening so please leave the setup as is.

During the course of this work, I noticed the +15V Sorensen in 1X6 has 6.8 A of current draw, while Steve's February2018 label says the current draw is 8.6A. Is this just a typo?

Steve: It was most likely my mistake. Tag is corrected to 6.8A


I'm still in the process of electronics characterization, so the SR785 is still hooked up. MC3 coil driver signal is broken out to measure the output voltage going to the coil (via Gainx100 SR560 Preamp), but MC is locked.

Attachment 1: B55CE985-B703-4282-B716-3144957C7372.jpeg
B55CE985-B703-4282-B716-3144957C7372.jpeg
  13863   Fri May 18 14:18:03 2018 gautamConfigurationElectronicsBasic MEDM Control Screen setup

I setup a basic MEDM screen for remote control of the PLL.

The Slow control voltage slider allows the frequency of the laser to be moved around via the front panel slow control BNC.

The TTL signal slider provides 0/5V to allow triggering of the servo. Eventually this functionality will be transferred to the buttons (which do not work for now).

The screen can be accessed from the PSL dropdown menu in sitemap. We can make this better eventually, but this should suffice for initial setup.

Attachment 1: AUX_PLL_CTRL.png
AUX_PLL_CTRL.png
  13870   Sun May 20 23:43:50 2018 gautamUpdateIOOCoil driver noise re-measurement

Summary:

In the IMC actuation chain, it looks like the MC1/MC3 de-whitening boards, and also all three MC optics' coil driver boards, are showing higher noise than expected from LISO modeling. One possible candidate is thick film resistors on the coil driver boards. The plan is to debug these further by pulling the board out of the Eurocrate and investigating on the electronics bench.

Why bother? Mainly because I want to see how good the IR ALS noise is, and currently, the PSL frequency noise is causing the measurement to be worse than references taken from previous known good times.

Details:

Sometime ago, rana suggested to me that I should do this measurement more systematically.

  • Attachments #1, #2 and #3 show noise measurements in various conditions for MC1, MC2 and MC3 respectively.
  • In the above three attachments, I stitched together multiple spans from the SR785, and so the bin-width is different. The data is downloaded from the analyzer normalized by the bin-width (PSD units).
  • The roll-off at ~800Hz in the orange trace for MC1 and MC3 is consistent with an 800 Hz LPF that was used for anti-image filtering from the old 2 kHz era.
  • While it may look like the analog de-whitening isn't being switched on in some of these plots, I confirmed by transfer function measurement that it is indeed switching.
  • Data used to make these plots are in Attachment #4. Unfortunately, the code requires some of my personal plotting librariesno and so I'm not uploading it.
  • Sketch of measurement setup is shown in Attachment #5. It is not indicated in the schematic, but the SR560 was operated in battery mode for this measurement.
  • For MC1, I did the additional measurement of terminating the LEMO input to the coil driver and measuring (what should have been) just the coil driver electronics noise. But this measurement doesn't look very clean, and hence, the decision to pull the board out to continue debugging.
  • While at 1X6, Rana tightened the LEMO connectors going to MC1. We should opportunistically do MC2 and MC3 as well.
  • Some changes to be made:
    • Thick film ---> thin film.
    • Reroute HPF-ed back-plane Vmon output to the front panel LEMO.

I've now restored all the wiring at 1X6 to their state before this work.

Attachment 1: MC1_coilDriver.pdf
MC1_coilDriver.pdf
Attachment 2: MC2_coilDriver.pdf
MC2_coilDriver.pdf
Attachment 3: MC3_coilDriver.pdf
MC3_coilDriver.pdf
Attachment 4: MC_coilDriverNoises.tgz
Attachment 5: ActuationChainNoiseMeas.pdf
ActuationChainNoiseMeas.pdf
  13871   Mon May 21 10:15:35 2018 gautamUpdatePEMtest setup with seismometer

I guess it's fine for now while we are still finalizing the setup at EX, but we should eventually line up the seismometer axes with the IFO axes. Is there a photo of the orientation of the seismometer pre heater can tests? If not, probably good to make some sort of markings on the granite slab / seismometer to allow easy lining up of these axes...

  13873   Mon May 21 15:34:19 2018 gautamConfigurationElectronicsChannel hijacking history

Since we've been hijacking channels like there is no tomorrow for the AUX-PLL setup, I'm documenting the channel names here. The next time c1psl requires a reboot, I'll rename these channels to something more sensible. To find the channel mapping, Koji suggested I use this. Has worked well for us so far... We've labelled all pairs of wires pulled out of the cross connects and insulation taped the stripped ends, in case we ever need to go back to the original config.

Previously unused C1PSL Channels now used for AUX PLL

Channel name AI/AO Function
C1:PSL-126MOPA_126CURADJ AO Slow temperature control
C1:PSL-FSS_RFADJ AO Servo trigger TTL
C1:PSL-126MOPA_126PWR AI PLL error signal monitor
C1:PSL-126MOPA_DMON AI PLL control signal monitor
C1:PSL-FSS_PHCON AO

To mitigate integrator railing

  13878   Tue May 22 17:26:25 2018 gautamUpdateIOOMC1 Coil Driver pulled out

I have pulled out MC1 coil driver board from its Eurocrate, so IMC is unavailable until further notice. Plans:

  1. Thick film --> Thin Film
  2. AD797 --> Op27
  3. Remove Pots in analog actuation path.
  4. Measure noise
  5. Route HPF signal (UL DAQ Mon) to front panel. I think we should use the SMA connectors. That way, we have DC and AC voltage monitors available for debugging.

If there are no objections, I will execute Step #5 in the next couple of hours. I'm going to start with Steps 1-4.

  13880   Tue May 22 23:28:01 2018 gautamUpdateIOOMC1 Coil Driver pulled out

This work is now complete. MC1 coil driver board has been reinstalled, local damping of MC1 restored, and IMC has been locked. Detailed report + photos to follow, but measurement of the noise (for one channel) on the electronics workbench shows a broadband noise level of 5nV/rtHz (yes) around 100Hz, which is lower than what was measured here and consistent with what we expect from LISO modeling (with fast input terminated with 50ohm, slow input grounded).

Quote:

I have pulled out MC1 coil driver board from its Eurocrate, so IMC is unavailable until further notice.

 

  13883   Wed May 23 17:58:48 2018 gautamUpdateIOOMC1 Coil Driver pulled out
  • Marked up schematic + photo post changes uploaded to DCC page.
  • There was a capacitor in the DAQ monitor path making a 8kHz corner that I now removed (since the main point of this front panel HPF monitor point is to facilitate easy coil driver noise debugging, and I wanted to be able to use the SR785 out to high frequencies without accounting for an additional low pass). Transfer function from front panel LEMO input to front panel LEMO monitor is shown in Attachment #1.
  • Voltage noise measured at DB25 output (with the help of a breakout cable and SR560 G=100) with front panel LEMO input terminated to 50ohm, Bias input grounded, and pin1 of U21A grounded (i.e. watchdog enabled state) is shown in Attachment #2. This measurement was taken on the electronics bench.
  • Inside the lab (i.e. coil driver board plugged into eurocrate), the noise measured in the same way looks identical to what was measured in elog13870.
  • I tried repeating the measurement by powering the board using an bench power supply and grounding the bias input voltage near 1X6, and the strange noise profile persists. So this supports the hypothesis that some kind of environmental pickup is causing this noise profile. Needs more investigation. 

In any case, if it is indeed true that the optic sees this current noise, the place to make the measurement is probably the Sat. Box. Who knows what the pickup is over the ~15m of cable from 1X6 to the optic.

Quote:

Detailed report + photos to follow

 

Attachment 1: MC1_monitorTF.png
MC1_monitorTF.png
Attachment 2: MC1_ULnoise.pdf
MC1_ULnoise.pdf
  13885   Thu May 24 10:16:29 2018 gautamUpdateGeneralAll models on c1lsc frontend crashed

All models on the c1lsc front end were dead. Looking at slow trend data, looks like this happened ~6hours ago. I rebooted c1lsc and now all models are back up and running to their "nominal state".

Attachment 1: c1lsc_crashed.png
c1lsc_crashed.png
  13886   Thu May 24 13:06:17 2018 gautamConfigurationALSDFD noises

Summary:

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

Details and discussion: (diagrams to follow)

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

Summary:

  • DC light power incident on beat PD is ~400uW from the PSL and ~300uW from EX.
  • These numbers are consistent with measured mating sleeve and fiber coupler losses.
  • However, I measure an RF beatnote of 80mVpp (= -18dBm). This corresponds to a mode matching efficiency of ~15%, assuming InGaAs efficiency of 0.65A/W.

I find this hard to believe.

Details:

  • I took this opportunity to clean the fiber tips on the PSL table going into the BeatMouth.
  • PSL light power going into the BeatMouth is 2.6mW. Of which ~400uW reaches the Beat PD (measured using my new front panel monitor port).
  • Similarly, 1mW of EX light reaches the PSL table, of which ~300uW reaches the Beat PD.
  • The RF amplifier gain is 20dB, and RF transimpedance is 50 ohms.
  • Using the (electrical) 20dB coupled port on the front panel, I measured a beat signal with 8mVpp. So the actual beat note signal is 80mVpp.

Discussion:

As I see it, the possibilities are:

  1. My measurement technique/calculation is wrong.
  2. The beat PD is broken has optoelectronic different that is significantly different from specifications.
  3. The non-PM fiber lengths inside the beat box result in ~15% overlap between the PSL and EX beams. Morever, there is insignificant variation in the electrical beat amplitude as monitored on the control room analyzer. So there is negligible change in the polarization state inside the BeatMouth.

I guess #3 can be tested by varying the polarization content of one of the input beams through 90 degrees.

  13890   Thu May 24 20:31:03 2018 gautamConfigurationALSDFD noises

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

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

Quote:
 

I had made some TF measurements of the delay sometime ago, need to dig up the data and see what number that measurement yields.

Attachment 1: TF_X_mag.pdf
TF_X_mag.pdf
Attachment 2: TF_X_phase.pdf
TF_X_phase.pdf
ELOG V3.1.3-