40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 287 of 335  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  13788   Wed Apr 25 17:44:39 2018 ArnoldUpdatePEMPEM Anti-Alias wiring

Related image

 

  13790   Thu Apr 26 09:35:49 2018 KevinUpdatePEMPEM Anti-Alias wiring

I wired all 32 channels going to the AA board directly to the ADC as described in the previous log. However, instead of using the old AA board and bypassing the whole circuit, I just used a breakout board as is shown in the first attachment. I put the board back in the rack and reconnected all of the cables.

The seismic BLRMs appear to be working again. A PSD of the BS seismometers is shown in attachment 2. Tomorrow I'll look at how much the ADC alone is suppressing the common mode 60 Hz noise on each of the channels.

Steve: 5 of ADC DAC In Line Test Boards [ D060124 ] ordered. They should be here within 10 days.

Attachment 1: board.jpg
board.jpg
Attachment 2: SeismometerPSD.pdf
SeismometerPSD.pdf
  13793   Thu Apr 26 19:46:26 2018 ranaUpdatePEMPID Quixote

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

  1. add the MEDM screen EPICS values to the DAQ so that we can plot those trends DONE
  2. add the out-of-loop sensor to the EX can
  3. reboot the AUX-EX so we can pick up the new channels and the fixed spelling of the old channels DONE
  4. 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: dv.pdf
dv.pdf
  13794   Thu Apr 26 20:22:21 2018 KevinUpdatePEMADC common mode rejection with new seismometer connections

Yesterday I wired the outputs from the seismometers directly to the ADC input bypassing the old AA board circuit as is described in this elog. The old circuit converted the single-ended output from the seismometers to a differential signal. Today I looked at whether 60 Hz noise is worse going directly into the ADC due to the loss of the common mode rejection previously provided by the conversion to differential signals.

I split the output from the BS Z seismometer to the new board and to an SR785. On the SR785 I measured the difference between the inner and outer conductors of the seismometer output, i.e. A-B with A the center conductor and B the outer conductor, with grounded input. At the same time I took a DTT spectrum of C1:PEM-SEIS_BS_Z_IN1. Both spectra were taken with 1 Hz bandwidth and 25 averages. The setup is shown in attachment 1.

The spectra are shown in attachment 2. The DTT spectrum was converted from counts to volts by multiplying by 2 * 10 V/32768 cts where the extra factor of 2 is from converting from single-ended to differential input. If there was common 60 Hz noise that the ADC was picking up we would expect to see less noise at 60 Hz in the SR785 spectrum measured directly at the output from the seismometer since that was a differential measurement. Since both spectra have the same 60 Hz noise, this noise is differential.

Attachment 1: setup.pdf
setup.pdf
Attachment 2: seismometerASD.pdf
seismometerASD.pdf
  13795   Thu Apr 26 23:00:42 2018 ranaUpdatePEMnew Seis temp chans

After fixing the spelling of the EX temperature readback, I also added all of the MEDM sliders to the C0EDCU.ini file (making sure to add an even number of channels). Restarted FB (after installing telnet on rossa):

telnet fb 8083

> shutdown


preferred method of posting DataViewer images: print as a SVG image (since its vectorized). Then from the command line do:

inkscape steven.svg --export-pdf=vass.pdf

Attachment 1: chans.pdf
chans.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.

  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?

  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
  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
mount.png
  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
leapsecs_read()
  Opening leapsecs.dat
  Open of leapsecs.dat failed
leapsecs_read() returning 0
frameMemRead - gpstimest = 1208844718

 

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

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

  1. add the MEDM screen EPICS values to the DAQ so that we can plot those trends DONE
  2. add the out-of-loop sensor to the EX can
  3. reboot the AUX-EX so we can pick up the new channels and the fixed spelling of the old channels DONE
  4. 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
IMG_20180501_154826.jpg
  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
IMG_20180501_152014.jpg
  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
  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.

  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.

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

  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.

  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.
 

  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
  13823   Mon May 7 20:01:14 2018 RorpheusUpdateGeneralUse anti-dewhitening + show CARMA/DARMA

What If I Told You - What If I Told You that bogus plots are fake news

example of plots illustrating DAC range / saturation

  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
  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
Cabazon4.5m79m.png
Attachment 2: 4.5Meq.png
4.5Meq.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
  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.
  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
  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).

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

  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
homodyne_heatmap.pdf
Attachment 2: displacement_noise.pdf
displacement_noise.pdf
Attachment 3: noise_budget.pdf
noise_budget.pdf
  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.

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

Pooja and Keirthana received 40m specific basic safety training.

  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
  13849   Wed May 16 21:02:22 2018 KevinUpdatePEMADC common mode rejection with new seismometer connections

As described in this elog, the ADC for the seismometers now has the signals wired directly to the ADC instead of going through an AA board or other circuit to remove any common mode noise. This elog describes one test of the common mode rejection of this setup. Guantanamo suggested comparing directly with a recent spectrum taken a few months before the new setup described in this elog.

Today I took a spectrum (attachment 1) of C1:PEM-MIC_2 (Ch17) and C1:PEM-MIC_3 (Ch18) with input to the ADC terminated with 50 Ohms. These are two of the channels plotted in the previous spectrum, though I don't know how that plot was normalized. It's clear that there are now strong 60 Hz harmonic peaks that were not there before, so this new setup does have worse common mode rejection.

Attachment 1: ADC_noise.pdf
ADC_noise.pdf
  13850   Wed May 16 21:47:17 2018 KevinUpdatePEMSeismometer Noise Spectra

Earlier today Kira and I reconnected the EX seismometer. I just took some spectra of all three seismometers, shown in the attachments, to compare with past data and to do a rough check of the calibration.

This elog has a spectra from 2010 (GUR1 is now EY) and this elog has one for BS at lower frequencies from 2017. Note that the EX seismometers now have strong peaks that are not at 60 Hz harmonics. Other than these peaks, these old spectra roughly match up with the ones taken today, so the callibration is still roughly the same. I couldn't find any old data for EX (GUR2) though so I don't know for sure that these peaks weren't there before.


gautam 20180517 0930: In 2017, Gur2 (now EX) looked like this. Still peaky, but the peaks seem shifted in frequency. Steve also informed me that the Gur1 and Gur2 cables were swapped n times, so perhaps we shouldn't read too much into that.

Attachment 1: BS_vel.pdf
BS_vel.pdf
Attachment 2: EX_vel.pdf
EX_vel.pdf
Attachment 3: EY_vel.pdf
EY_vel.pdf
  13851   Thu May 17 09:14:38 2018 SteveUpdateGeneralStack measurement setup decommissioned

The final set-up of stack measurment with 3 load cells and 4 leveling wedge mounts as Atm 1

Sensor voltages BEFORE and AFTER this attempt.

Attachment 1: Load_Cell_Measurement_Set_Up.jpg
Load_Cell_Measurement_Set_Up.jpg
Attachment 2: ETMX_stack_up_down.png
ETMX_stack_up_down.png
  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.

  13859   Thu May 17 15:38:19 2018 KiraUpdatePEMtest setup with seismometer

I've moved my setup to the actual seismometer. I attached the temperature sensor to the seismometer (attachment 1) with duct tape, though this is temporary. I will be monitoring the temperature fluctuations of the seismometer for a whole day then take the can off and repeat the test. The can isn't clamped down so the insulation isn't perfect, so I'd expect to see some noticeable fluctuations even with the can on. I've also labeled the long cable for the temperatuse sensor readout (attachments 2 and 3). There will also be an out of loop sensor added in later, but for this test since I am not running the loop it doesn't matter which sensor I monitor. Attachment 4 is a picture of the current setup.

Attachment 1: IMG_20180517_144420.jpg
IMG_20180517_144420.jpg
Attachment 2: IMG_20180517_145754.jpg
IMG_20180517_145754.jpg
Attachment 3: IMG_20180517_151956.jpg
IMG_20180517_151956.jpg
Attachment 4: IMG_20180517_145121.jpg
IMG_20180517_145121.jpg
  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
  13861   Fri May 18 07:41:01 2018 steveUpdateSUSclipping ITMX oplev

The ITMX oplev still clipping

Quote:

The ITMX oplev beam is clipping. It will be corected with locked arm

 

 

  13862   Fri May 18 09:13:41 2018 PoojaUpdateSUSColored GigE image

To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.

 

Attachment 1: Image__2017-11-14__08-25-13_100k100g1V_colored.png
Image__2017-11-14__08-25-13_100k100g1V_colored.png
Attachment 2: Image__2017-11-14__08-25-13_100k100g1V.tiff
  13864   Fri May 18 14:33:34 2018 KiraUpdatePEMtest setup with seismometer

Here is the result of my test. I think I'll leave the can on over the weekend because there's a long period of time where the seismometer heated up by 0.8 degrees so I can't fully see the fluctuations over a full 24 hour period.

Attachment 1: seis_temp_can_on.png
seis_temp_can_on.png
  13866   Fri May 18 19:10:48 2018 keerthanaUpdateGeneralCode for adjusting the oscillator frequency remotly

Target: Phase locking can be acheived by giving a scan to the oscilator frequency. This frequency is now controlled using the knobe on the AM/FM signal generator 2023B. But we need to control it remotely by giving the inputs of start frequency, end frequency and the steps.

The frequency oscilator and the computer is connected with the help of GPIB Ethernet converter. The IP address of the converter I used is '192.168.113.109' and its GPIB address is 10.

I could change the oscilator frequency by changing the input frequency with the help of the code I made (Inorder to check this code, I have changed the oscilator frequency multiple times. I hope it didn't create trouble to anyone). Now I am trying to make this code better by adding certain features like numpy, argument parse etc, which I will be able complete by next week. I am also considering to develop the code to have a sliding system to control the oscillatory frequency.

For record: The maximum limit of frequency which i changed upto is 100MHz.

 

Attachment 1: frequency_set.jpg
frequency_set.jpg
ELOG V3.1.3-