Displaying reports 62661-62680 of 83105.Go to page Start 3130 3131 3132 3133 3134 3135 3136 3137 3138 End
Reports until 14:45, Friday 28 August 2015
H1 SEI
hugh.radkins@LIGO.ORG - posted 14:45, Friday 28 August 2015 - last comment - 14:47, Friday 28 August 2015(20992)
STS2-A returned from Quanterra--I don't know...

Attached are ASD and Coherence betwix the three corner station STS2s taken at 3am local Wednesday Thursday and Friday.  These three days look very similar.  I installed STS2-A aka HAM2 on Tuesday.  Recap:

STS2-C (HAM5) has been in place for long time.  STS2-B (ITMY) is the unit returned from Stanford replacing PEM STS2 which we were using to replace our original STS2-B which is still at Quanterra for repairs.  STS2-A returned from Quanterra after a couple months in their vault where they say there was no problem.  The A unit spent time in the BeirGarten near the ITMy unit undergoing cable and chassis swaps, see 18354 for recap but nothing was consistent.

To me, STS2-A still looks like this unit has a problem.  When I look at plots from back in May, 18354, it looks even worse now.  There was better coherence in Z and X with the other units and Y was equally poor.

RobertS--do you have an opinion?

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 14:47, Friday 28 August 2015 (20994)

Ignore the Title stating Huddle and cables switched.  Units are in home position on nominal cables.

H1 CAL (AOS, CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 13:34, Friday 28 August 2015 (20991)
LHO Pcal EndX and EndY calibration measurements were taken (analysis to follow)

Travis S, Darkhan

Yesterday, Aug 27, 2015, we took Pcal end-station calibration measurements at both end-stations. The measurement procedure is described in T1500063 (-v5).

The following steps from the procedure have been completed at both end-stations:

Rough numbers from MEDM screen logged into the record sheet (provided in appendix A of T1500063) suggest that RxPD and TxPD calibrations as well as optical efficiencies of Pcal beams at LHO EY did not change significantly compared to numbers from calibration on 2015-05-22, however we saw ~1 - 2 % drop in the optical efficiency of Pcal beams at LHO EX compared to measurement taken on 2015-05-20.

Calibration results will be reported after completing the last part of the calibration procedure, running Matlab scripts that acquire data and calculate responses of TxPD and RxPD:

Record sheet papershots are attached to this alog.

Images attached to this report
H1 ISC
nutsinee.kijbunchoo@LIGO.ORG - posted 11:48, Friday 28 August 2015 (20988)
Lockloss at SWITCH_TO_QPD

Jenne, Nutsinee

There was a suspecious lockloss at SWITCH_TO_QPD at 17:50 UTC. We went through lockloss plots and found ASC-MICH was unstable right before the lockloss.

Images attached to this report
H1 SUS (CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 10:48, Friday 28 August 2015 (20987)
Loaded H1 SUS ETMY Filter Coefficients
J. Kissel, D. Barker

Dave found that H1SUSETMY L3 LOCK L FM 2 (which has and remains OFF all throughout lock acquisition and lownoise) had been changed by Evan from compensating for the ESD driver's low pass filter (which is now done in the H1 SUS ETMY L3 ESDOUT $(QUADRANT) FM2/FM7 banks) to some other filter, and sadly did not name it so it shows up (appropriately) as "Unknown." I;m not sure what his intent was with this filter, but because is OFF all the time, I loaded the coefficients so that the model doesn't have a "modified filter coefficients" message which sets off all sorts of SysAdmin alarms.

I'll find out from Evan what his intent, and probably clean it up later.
Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 10:41, Friday 28 August 2015 (20986)
Status of front end code

the attached files show the current status of the front end code.

Non-image files attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 10:34, Friday 28 August 2015 (20984)
CDS model and DAQ restart report, Thursday 27th August 2015

ER8 Day 11. No restarts reported

H1 General
thomas.shaffer@LIGO.ORG - posted 08:00, Friday 28 August 2015 (20979)
Ops Owl Shift Summery

(All times UTC)

Summery:

Evan and Stefan were working on recentering the AS WFS when I arrived. When they were done, Evan cleared out his changes in the SDF aside from some ASC diff that occurred from dark offset scripts. I accepted the ODC Master changes from alog 20915.

Guardian brought the IFO into a full lock really quick, Evan added some DCPD Whitening, and it has stayed in lock since.

Locking:

H1 General
thomas.shaffer@LIGO.ORG - posted 04:00, Friday 28 August 2015 - last comment - 10:39, Friday 28 August 2015(20980)
Intent Bit set

Itbit set at 10:48 UTC with long lock hopes.

Comments related to this report
thomas.shaffer@LIGO.ORG - 04:13, Friday 28 August 2015 (20981)

HWS SLED IX is ON

eleanor.king@LIGO.ORG - 10:19, Friday 28 August 2015 (20983)

Having the HWS SLED on should not effect the interferometer, I added this into the guardian because we don't want the SLED running indefinately, but it is easy to turn it on and forget.  If the warning message is confusing we could remove it, or move it to a less obtrusive place.

jameson.rollins@LIGO.ORG - 10:39, Friday 28 August 2015 (20985)

Presumably this check is coming from the DIAG_MAIN node.  I think the important principle for that node should be that all the diagnostic checks should be actionable, in other words someone should get out of their chair and deal with whatever the notification is to make the notification stop.  If the plan is to leave the HWS SLED on, or it's not critical to shut it off, then it should be removed from DIAG_MAIN.

Maybe we can add a second DIAG node for not immediately actionalbe diagnostics, but my guess it that it will just be ignored, since by definition nothing there will be critical.

H1 ISC
evan.hall@LIGO.ORG - posted 02:47, Friday 28 August 2015 (20976)
90 MHz AS WFS centering again

Stefan, Evan

We made another attempt at using 90 MHz to center WFS AS B.

This time we turned up the whitening gain to 45 dB, which gave a healthy number of counts on each quadrant. We then redid our dark offsets, which were significant at this whitening gain. [We actually redid the dark offsets for all the REFL and AS WFS signals using the script in the userapps repo.]

Then in DRMI, we phased each quadrant to put most of the power in I. At this point we saw that the centering signals provided by these 90 MHz quadrants (pitch and yaw) were slightly different than the dc centering signals for AS B, so we switched the centering over to these signals (a relative gain of −0.003 is required between these 90 MHz signals and the dc signals). Things seemed fine in DRMI (the sideband buildups all changed slightly, but it was hard to say whether they were better or worse), but when we tried the CARM reduction sequence, the new centering ran away on the DARM WFS step.

So instead, we went to full lock at 2 W with the old centering scheme and switched over again to the new 90 MHz AS B centering. Things again seemed fine.

We weren't quite sure what to do about the BS/SRM matrix elements. In the end we tried using AS B 36 I&Q only to control these loops (i.e., no mixture with AS A 36), and this was fine at 2 W, but we lost lock immediately when trying to power up.

H1 AOS (CAL)
craig.cahillane@LIGO.ORG - posted 00:34, Friday 28 August 2015 (20974)
Strain Uncertainty Carpet Plots Developments
C. Cahillane, D, Tuyenbayev

In a previous alog alog 20946 I showed preliminary carpet plots of ER7 strain uncertainty based on changes in the calibration parameters |kappa_tst|, φ_kappa_tst, |kappa_pu|, φ_kappa_pu, kappa_C, f_c.
Here are some updated plots.  (Plots 1 - 6)

The data is now low-noise, and is dewhitened.  This gives much nicer, more accurate results.
I have been working to reproduce Darkhan's carpet plots from T1500422.  The method he uses to find error in Delta_L_ext is as follows:

delta Delta_L_ext =  C_true / (1 + G_true)     
                             ------------------------------
                                        C / (1+G)

where C_true and G_true are the quantities where kappa_tst, kappa_C, and f_c are varied.

The method I use to find error in strain is:

delta strain = (1 / C_true) * d_err + A_true * d_ctrl
                      ----------------------------------------------
                                  (1 / C) * d_err + A * d_ctrl

Plot 7 is Darkhan's method of computing error from changes in kappa_tst reproduced by me.
Plot 1 is my method of computing error from changes in |kappa_tst|.  They should be the same.  They aren't.

We are searching for potential reasons behind the structure found in Darkhan's plot.  Something odd may be going on at the UGF of the CLG, causing the low magnitude error near 65 Hz and low phase error near 35 Hz.
My plot, on the other hand, has no low error region in phase, in fact it has a maximum near 35 Hz, and has a tilted low magnitude error region between 30 and 40 Hz.

I am investigating this difference now.
Non-image files attached to this report
LHO General
patrick.thomas@LIGO.ORG - posted 00:12, Friday 28 August 2015 (20971)
Ops Evening Summary
23:00 (16:00) Darkhan and Travis at end Y running PCAL measurements. Leo running charging measurements for ETMX.
23:36 (16:36) Kiwamu to electronics room to measure transfer function of whitening filter
23:40 (16:40) Evan to CER to run measurement with network analyzer
23:41 (16:41) Darkhan and Travis done at end Y, moving to end X
00:09 (17:09) Nutsinee to TCS X to take picture of control box
00:15 (17:15) Nutsinee back
00:44 (17:44) Evan done, Leo done
01:18 (18:18) Travis and Darkhan done at end X
01:37 (18:37) Travis and Darkhan back

02:13 (19:13) Kiwamu and I start locking
Trouble locking on DRMI
Ran through initial alignment starting with CHECK_IR
Lost lock engaging ASC WFS in LOCK_DRMI, Kiwamu had to revert phase settings for AS 36
Lock loss on bounce mode
03:17 (20:17) h1fw2 crashed and restarted
04:48 (21:48) Locked on Low Noise, Darkhan running calibration measurements

05:22 (22:22) Darkhan done, Stefan and Evan starting wiggling cables test
05:26 (22:26) Kiwamu to CER to clean up previous work
Kiwamu is back
06:22 (23:22) h1fw2 crashed and restarted
07:00 (00:00) handing off to TJ, Evan and Stefan are investigating RF

Other
end Y dust alarms
smelled a lot of smoke in hallway, went up to roof, didn't spot any fires
H1 CAL (CAL, CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 23:50, Thursday 27 August 2015 (20972)
Comparison between DAC and ADC DuoTone Timing Signals for DARM-Relavent IO Chassis
J. Kissel, K. Kawabe

Similar to what is shown and briefly mentioned in LLO aLOG 18406, I've done a comprehensive transfer function study between the DAC and ADC Duotone timing signals from the following IO chassis:
h1lsc0 (which houses the ADC for the OMC DCPDs),
h1susex & h1susey (which house the DACs for the ETM QUADs)
h1iscex & h1iscey (which house the ADC for the PCAL RXPDs)
h1oaf0 (which receives the DARM_ERR and DARM_CTRL channels from the OMC model over IPC)
Recall that these Duotone signals are merely *checks* on the system that is actually providing the time signals for the DAC / ADC cards, which is the 1 PPS signal from the local timing fanout in the building (which in in turn receives its 1 PPS from the timing master in the corner station which is GPS synchronized). The results indicate that -- although there is a few tens of micro-second offset between all of these front-ends, they appear to not *differ* by more than a few hundred nano-seconds, and typical in the tens of nano seconds. This is consistent with what Shivaraj found when making the comparison between his l1iscex and l1iscex against l1oaf0. Recall that our requirement is that the timing uncertainty is no greater than 25 [us], so at least the DuoTone signals between each IO chassis fall in well-below this. What we would need to do to confirm that the actual front end timing is to then compare this DuoTone against the "digital world" 1 PPS, as Keita has done for the ADC and DAC DuoTone signals for all of the above mentioned chassis in LHO aLOG 20962. His aLOG also indicates a ~100 [ns] difference between chassis, on top of the ~7 [us] offset.

So far, so good in timing land.

Details:
---------
For all measurements, I used h1lsc0 ADC and DAC duotone singals as the reference (TF denominator), and the others as the response (TF numerator). Below are the results for the phase relationship between each at 960 [Hz] (the results are the same within the precision stated for the 961 [Hz] line):
          xxxx ADC      xxxx DAC      xxxx ADC     xxxx DAC
          --------      --------      --------     --------
          LSC0 ADC      LSC0 ADC      LSC0 DAC     LSC0 DAC

h1lsc0       n/a         -26.42        +26.42         n/a
h1susex    +5.14         -21.27        +26.45       +5.14
h1susey    +5.13         -21.28        +26.44       +5.13
h1iscex   +0.008         -21.29        +26.45       +5.13
h1iscey   +0.028         -21.27        +26.47       +5.14
h1oaf0    -0.013         -21.34        +26.43       +5.07

which we can turn in to an equivalent delay (or advance) between the two front end timing signals, with 1e6 * (pi/180) * phase_deg * / (2*pi*961 [Hz])
          xxxx ADC      xxxx DAC      xxxx ADC     xxxx DAC
          --------      --------      --------     --------
          LSC0 ADC      LSC0 ADC      LSC0 DAC     LSC0 DAC
            [us]          [us]         [us]          [us]
h1lsc0       n/a         -76.4         76.4          n/a
h1susex     14.9         -61.5         76.5          14.9
h1susey     14.8         -61.6         76.5          14.8
h1iscex     0.023        -61.6         76.5          14.8
h1iscey     0.081        -61.5         76.6          14.9
h1oaf0     -0.038        -61.7         76.5          14.7

Templates live in 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/Timing/
2015-08-27_H1LSC0_to_CALCS_DuoTone_TFs.xml
2015-08-27_H1LSC0_to_ISCEND_DuoTone_TFs.xml
2015-08-27_H1LSC0_to_SUSEND_DuoTone_TFs.xml
of which I attach an example.
Images attached to this report
H1 SYS
jameson.rollins@LIGO.ORG - posted 17:50, Thursday 27 August 2015 - last comment - 11:56, Friday 28 August 2015(20967)
new EXCITATION_OVERVIEW screen

New EXCITATION_OVERVIEW screen has been created:

$USERAPPS/sys/common/medm/EXCITATION_OVERVIEW.adl

Hopefully this can help in tracking down excitations that could be preventing the system from entering READY:

The two columns show the front-end excitation monitors (FEC, left) and the ODC monitors (ODC, right).

NOTE: ONLY ODC monitors count towards OBSERVATION READY at the moment.

The FEC monitors are there for reference, and for completeness.

The EXCITATIONS box in the OBSERVATION_OVERVIEW screen now contains a link to this screen.

Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 11:56, Friday 28 August 2015 (20989)

I updated this screen to remove the PEM_M* and ODC_MASTER checks, and added the missing CAL_EY.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 15:21, Thursday 27 August 2015 - last comment - 03:46, Friday 28 August 2015(20961)
changing RF phase in HAM6 racks.

Evan, Sheila

While the IFO was down for some calibration measurements, we made another attempt at phasing AS36. 

We first redid the dark offsets, this was an important step.  Then we locked the bright michelson with 22 Watts of input power. 

We steered the beam onto each quadrant of AS_A by maximizing the DC counts, then phased 36 to minimize Q.  There were several things that made this seem much more promising than any of our previous attempts to phase these WFS:

Both of these things are firsts for these WFS as far as I'm aware, so this seemed like real progress.  

We started to do the same procedure for AS_B 36, but after we phased the first quadrant the phase jumped.  Kiwamu was in the rack working on the calibration measurements of the DC PDs at this time and reported that he had plugged a signal into the patch panel.  After this I looked at the A signals again, and they did not make sense any more. I tried repeating the procedure above for A, and found that the phases needed to minimize Q with the light maximized on each quadrant had changed by -15, -10, 0, and -20 degrees for quadrants 1,2,3,4.  

It seems like we need to make a thorough check of the HAM6 racks before we continue trying to make sense of AS WFS.  

Just for the record the momentarily sane phasings were:

segment phase (degrees)
1 -155
2 -175
3 -165
4 -158
Comments related to this report
evan.hall@LIGO.ORG - 03:46, Friday 28 August 2015 (20978)

Stefan and I did a wiggling test of the cables in the HAM6 rack while the interferometer was locked.

We watched AS90I, AS45Q, and all the quadrants of the AS WFS (36 and 45 MHz). The only thing we saw was a 5% fluctuation in AS90I in response to the 90 MHz LO cable being wiggled. [Although once the beam diverter is closed and the AS90 signal is attenuated, the response to wiggling is much stronger—something like 20% to 40% fluctuation.]

H1 ISC
jenne.driggers@LIGO.ORG - posted 21:30, Wednesday 26 August 2015 - last comment - 00:52, Friday 28 August 2015(20939)
Template to decide if OMC DCPD extra whitening is okay

I have created a DTT template that makes it easier to decide when it's okay to turn on more OMC DCPD whitening.

Evan wrote an alog some time ago about the new OMC DCPD whitening on/off guardian states (alog 20578), and Cheryl and Evan made some notes on when it's okay to go to these new states (alog 20787).

As of right now, the guardian will automatically turn on one stage of whitening, but we get better high frequency noise performance if we add a second stage.  However, if some mode (eg. a violin mode) is rung up, then we can't add the second stage of whitening without being in danger of saturating the ADC.  So.  The new DTT template should help decide when it's okay to add the second stage.

The template is /ligo/home/ops/Templates/dtt/DCPD_saturation_check.xml (screenshot below). The template should be run after we have arrived at NOMINAL_LOW_NOISE for the main lock sequence.  If the dashed RMS lines are below the green horizontal line, it's okay to add the second stage of whitening.  

To engage the second stage of DCPD whitening:

Open the full list of guardian states for the OMC_LOCK guardian, and select "ADD_WHITENING". It will take a minute or two, and automatically return to the nominal "READY_FOR_HANDOFF" state.

Images attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 16:17, Thursday 27 August 2015 (20965)

could you explain the math & logic a little bit more?

I would have thought that an RMS of 3000 cts is as high as we want to go. Increasing the RMS by a factor of 10 would make it so that its always saturating = not OK. Or isn't this IN1 channel the real ADC input?

evan.hall@LIGO.ORG - 00:52, Friday 28 August 2015 (20975)

Yes, 3000 ct rms = 8500 ct pkpk = too many counts to add a second stage of whitening.

We run with about 10 mA dc on each DCPD, which shows up as 13000 ct or so of dc on the IN1 channels. That means we have something like 19000 ct of headroom before the ADCs saturate on the high side (+32 kct). Assuming the ac fuzz is symmetric about the mean, saturation will certainly occur if the ac is greater than 38000 ct pkpk with two stages of whtening, or 3800 ct pkpk with one stage of whitening.

That's why the criterion I've been using for turning on a second stage of whtening is to look at the IN1 channels and verify that the ac is less than 3000 ct pkpk, or 1000 ct rms when there is only one stage of whitening on. If we find the DCPDs saturating too often with two stages, we should be even more restrictive.

H1 ISC
daniel.sigg@LIGO.ORG - posted 19:02, Wednesday 26 August 2015 - last comment - 03:30, Friday 28 August 2015(20930)
RF AM at 45.5MHz

Evan Stefan Daniel

The second EOM driver was installed in the CER using the 9MHz control and readback channels. The first attached plot shows the DAQ readback signals. Both drivers show the similar noise levels for the in-loop and out-of-loop sensors. They are also coherent with each other as well as ASC-AS_C! The in-loop noise is clearly below which would indicate that the signal is suppressed to the sensor noise. The measured out-of-loop noise level is also a factor of 4 higher than the setup in the shop.

The second plot shows the same traces but this time the ifr is feeding the EOM driver in the CER. As expected its out-of-loop noise level is now consistent with measurements in the shop and no longer coherent with the unit in the PSL.

We were starting to suspect that we are looking at down-converted out-of-band noise...

Non-image files attached to this report
Comments related to this report
evan.hall@LIGO.ORG - 03:24, Thursday 27 August 2015 (20950)

Using a network analyzer, we took the following measurements:

  • rf spectrum of 45.5 MHz from harmonic generator + distribution amplifier in CER,
  • rf spectrum of 45.5 MHz from IFR in CER,
  • rf spectrum of 45.5 MHz from spare harmonic generator in the EE shop,
  • rf spectrum of 9.1 MHz from OCXO + distribution amplifier in CER,
  • audio-band spectrum of out-of-loop RAM readback of EOM driver, using harmonic generator as 45.5 MHz source, and
  • audio-band spectrum of out-of-loop RAM readback of EOM driver, using IFR as 45.5 MHz source.

The first four of these are shown in the attached plot [the OCXO has been multiplied by 5 in frequency for the sake of comparison]. The message is that the 45.5 MHz in the IFO distribution system has huge, broad wings out to 2 MHz away from the carrier. These are not seen on the IFR, the harmonic generator on the bench, or the 9.1 MHz in the distribution system.

Although the EOM driver still works to suppress some of the RFAM below 50 kHz, the broad wings still contribute significantly to the rms; most of it is accumulated above 200 kHz offset from the carrier. This is shown in the second attachment.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 03:30, Friday 28 August 2015 (20977)

I looked again at some rf spectra in the CER.

These peaks appear on every output of the harmonic generator, even when it is not driving any distribution amplifiers (just a network analyzer).

These peaks also appear even when the harmonic generator is driven by +12 dBm of 9.1 MHz from an IFR (not from the OCXO + distribution amplifier).

This suggests we should focus on the harmonic generator or its power supply.

H1 ISC
evan.hall@LIGO.ORG - posted 10:13, Friday 14 August 2015 - last comment - 12:07, Friday 04 September 2015(20526)
Sensing noises in the OMC DCPDs

This entry is meant to survey the sensing noises of the OMC DCPDs before the EOM driver swap. However, other than the 45 MHz RFAM coupling, we have no reason to expect the couplings to change dramatically after the swap.

The DCPD sum and null data (and ISS intensity noise data) were collected from an undisturbed lock stretch on 2015-07-31.

Noise terms as follows:

The downward slope in the null at high frequencies is almost certainly some imperfect inversion of the AA filter, the uncompensated premap poles, or the downsampling filter.

Non-image files attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 12:07, Friday 04 September 2015 (21214)

* What is the reasoning behind the updated suspension thermal noise plot?

* Its weird that cHard doesn't show up. At LLO, cHard is the dominant noise from 10-15 Hz. Its coupling is 10x less than dHard, but its sensing noise is a lot worse.

evan.hall@LIGO.ORG - 10:59, Wednesday 19 August 2015 (20680)

I remade this plot for a more recent spectrum. This includes the new EOM driver, a second stage of whitening, and dc-lowpassing on the ISS outer loop PDs.

This time I also included some displacement noises; namely, the couplings from the PRCL, MICH, and SRCL controls. Somewhat surprising is that the PRCL control noise seems to be close to the total DCPD noise from 10 to 20 Hz. [I vaguely recall that the Wipfian noise budget predicted an unexpectedly high PRCL coupling at one point, but I cannot find an alog entry supporting this.]

Non-image files attached to this comment
evan.hall@LIGO.ORG - 14:33, Friday 21 August 2015 (20758)

Here is the above plot referred to test mass displacement, along with some of our usual anticipated displacement noises. Evidently the budgeting doesn't really add up below 100 Hz, but there are still some more displacement noises that need to be added (ASC, gas, BS DAC, etc.).

Non-image files attached to this comment
evan.hall@LIGO.ORG - 16:25, Monday 24 August 2015 (20832)

Since we weren't actually in the lowest-noise quad PUM state for this measurement, the DAC noise from the PUM is higher than what is shown in the plot above.

If the updated buget (attached) is right, this means that actually there are low-frequency gains to be had from 20 to 70 Hz. There is still evidently some excess from 50 to 200 Hz.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 13:04, Friday 28 August 2015 (20990)

Here is a budget for a more recent lock, with the PUM drivers in the low-noise state. The control noise couplings (PRCL, MICH, SRCL, dHard) were all remeasured for this lock configuration.

As for other ASC loops, there is some contribution from the BS loops around 30 Hz (not included in this budget). I have also looked at cHard, but I have to drive more than 100 times above the quiescient control noise in order to even begin to see anything in the DARM spectrum, so these loops do not seem to contribute in a significant way.

Also included is a plot of sensing noises (and some displacement noises from LSC) in the OMC DCPDs, along with the sum/null residual. At high frequencies, the residual seems to approach the projected 45 MHz oscillator noise (except for the high-frequency excess, which we've seen before seems to be coherent with REFL9).

Evidently there is a bit of explaining to do in the bucket...

Non-image files attached to this comment
evan.hall@LIGO.ORG - 10:06, Friday 04 September 2015 (21210)

Some corrections/modifications/additions to the above:

  • I updated the optical gain and DARM pole using the pcal like at 331.9 Hz; from this line I find the transfer function from the TX PD into DCPD sum is (1.69 − 1.59i) mA/pm, which works out to an optical gain of 3.19 mA and a DARM pole of 353 Hz. I think Kiwamu may have a different number from his pcal sweep, so there might be some reconciliation to do.
  • I now compensate the extra 10 kHz pole that Kiwamu found in the readout chain of the DCPDs.
  • I remade the quantum noise curve for 23 W, and with a more realistic estimate of the losses. In addition to the 87 % quantum efficiency, I include 14 % readout losses that Lisa has already tabulated: we expect 96.5 % transmission through the OFI, 93 % transmission through the OMC, 99% reflection from OM3, and (according to Dan) 97 % mode matching into the OMC. This results in a quantum noise curve that is 6.6×10−20 m/Hz1/2 at 1 kHz. The DARM pole predicted by GWINC is 360 Hz or so (slightly higher than what I extracted from pcal).
  • Previously, I had tuned the arm losses in GWINC to give a recycling gain of 40 W/W. In light of Sheila's analysis, this is too optimistic; usually our recycling gains are more like 36 to 37 W/W. In GWINC, this amounts to tuning the arm losses to 90 ppm (per arm), which gives a gain slightly in excess of 37 W/W.
  • The null stream is 5 % – 7 % higher than the GWINC curve, so either some parameter is mistuned or we need to be looking for some extra readout loss.
  • I replaced the GWINC suspension thermal noise curve with a (hopefully) more accurate curve that I got from Sheila.
  • I replaced the oscillator noise trace (which was flat in DCPD photocurrent) with a trace based on the TF that Stefan and I took. I still assume the underlying noise contribution is flat in RIN, at a level of 3.5×10−8 mA/Hz1/2. This trace will become less relevant since the excess oscillator noise now appears to be gone.
  • I added gas noises. Squeeze film damping was calculated after T0900582 using the nominal parameters (our end station gauges read 1×10−8 torr, and I've assumed the dominant species is molecular hydrogen). For residual gas, I again assume the species is molecular hydrogen, and the arm pressure is taken to be 5×10−9 torr (which is a rough average of the arm gauges).
  • The ASC trace contains only the dHard and BS loops. I drove in cHard, but even after driving far, far above the ambient noise floor I could not make excess noise appear in DARM.

Of course, the budgeted noises don't at all add up from 20 Hz to 200 Hz, so we are missing something big. Next we want to look at upconversion and jitter noises, as well as control noise from other ASC loops.

Non-image files attached to this comment
Displaying reports 62661-62680 of 83105.Go to page Start 3130 3131 3132 3133 3134 3135 3136 3137 3138 End