*IM4 is currently at p=-3867, y=-615, this is within the expected alignment window required for IM4 to aim the beam into the IFO.

Morning Commissioning:

Rotation Stage: 

--- motion has changed, so speeds in programs that control the stage need to be change

--- feature to watch out for: stuck in busy, requires "abort" to end

--- setting home as minimum - requires rotating the optics in the rotation stage mount, not a priority

Guardian - new states need to be verified as safe

EY SEI is drifting

--- working on filters and other electronic signals

--- UW crew is coming tomorrow to do a mechanical alignment

Site Activities:

- Bubba/Chris - LVEA - 3IFO racks

- Fil - LVEA - temperature sensors BSC1 and BSC3

 Morning Meeting

- Laser is down through tomorrow

- LVEA is laser safe

- using time to look for noise sources

Subsystems:

- computers will be down today, for an unknown amount of time

- tomorrow morning, ALL CR machines are being rebooted, now the routine is to reboot every Tuesday Morning

- contact CDS if you have questions about specific workstations

Vacuum:

- bake ovens are down, fix is in the works

- beam tube: baking the RGA in the Vertex, which is a 48 hours bake, starting today, so going until Wednesday

Work Permits:

- closed:

--- Bubba, patch and paint

--- Bubba, Mx Inst Air

--- Jammie, Guardian upgrade main process

--- Kawabe, escort film crew

--- TJ, Guardian addition, Hardware injection node, ChrisB

OpLev Trends for past 7 days.

(see also alog 26902)

I measured the PUM coild driver noise of the ITMs at the coil driver output.

Bottom line: 

 - All 8 chammels (4 ITMX & 4 ITMY) show the same nosie. 

 - There is significant pickup in the cable running from driver to coil. This corresponsds to the 10msec bursts every 100msec mentioned in alog 26902)

 - This pick-up leads to 10Hz and harmonics.

 - There is some residual pickup of the same signal in the coil driver, but significantly less.

 - above 10kHz there is a huge amount of junk flying around (10uV/rtHz and more !)

The 4 traces in the plots correspond to

Blue: Coil driver output, terminated with 50Ohm.

Red: Coil driver output, with cable and coil attached.

Yellow:  Only cable and coil attached. Coil driver disconneced.

Purple: Measurement noise. (Only terminted breakout box)

Attached are 

plot 1: 0-200Hz (for example ITMY coil 3)

plot 2 & 3: 0-100kHz (for example ITMY coil 1 & 4) Note the 3kHz line - it corresponds to a 100cts 3kH length drive, resuling in about +-2ct at the ADCs.

Matt, Jenne

On Thursday (Apr 28) at about 6:20pm local, while Rick and Keita were in the PSL, Jenne and I made some measurements of the ISS first loop PDs.  Rick told us that there was no light on the ISS PDs at the time of our measurement, so we were hoping to get a dark spectrum to compare with the ones that Sheila and I took on the 24th and to add to the ones that Peter took.  I took a bunch of photos of the results, but later wasn't sure of the state of affairs for each photo, so I went out again today to get a better organized set of measurements.  At present, there is no light on the ISS PDs, so this is a DARK noise measurement.  The aim here is to get high-frequency (10kHz - 10MHz) noise measurements which are complementary to the ones taken by Even and Stefan on Friday using the digital system.

I started by cabling-up a readout system which included a fast o'scope, an SR785 for sub-100kHz spectra, and an RF analyzer for MHz spectra.  To avoid loading the OP27 outputs with 50 Ohms, I made a Pomona box with a 4.7kOhm resistor and 33nF cap in series for the RF path.  When loaded with 50 Ohms (by the RF analyzer) this gives -40dB of attenuation and a 1kHz high-pass.  (The 100 Ohm output impedance of the ISS board or ISS PD doesn't cause problems.)

The first 2 pictures show the output of the PDA monitor from the ISS board.  The same 36.6kHz rep-rate noise bursts that Sheila and I saw are present, though they don't look clipped the way they did when the system was running.  In the RF spectrum, these bursts appear as a comb of lines spread from ~100kHz to ~1.5MHz with a 36.56kHz spacing.  There was nothing interesting above 2MHz.

Photos 3-5 show the result of disconnecting the input.  The noise bursts go away, but since most of the noise is above 100kHz, the SR785 spectrum looks pretty similar (just the peak at 36.6kHz is gone).  The result was similar when I terminated the PDA input on the ISS board with 50 Ohms.  This, and what follows, appears to exonerate the ISS servo board.

Photos 6-8 show the result of placing a 100Hz low-pass in the line coming from the PSL to the PDA input.  The idea here is to attenuate the MHz content on the signal path by > 60dB so that we can see what is on the ground.  The pomona box I used was something that Stefan made for his coil driver measurements: 1.6kOhm and 1uF.  This may not be the optimal way of doing this, but if the RF were all on the signal side it would go away... which it did not.  The RF is much smaller (factor of ~5), but still clearly visible in the time series and the RF spectrum.

Finally, photos 9 and 10 show the output of PDA directly from the PSL.  While qualitatively similar to the monitor output shown in photos 1 and 2, it has more RF junk.  The sub-100kHz spectrum also has a lot more content in this configuration, and while watching it I noticed that there were features moving around with time.  (I made a video, but I can't post it to the log.  Ask me if you want it.)  This smells like RFI to me.

ETMY HWS python code testing is in progress on H1HWSEY. Depending on the power supply currently installed for the EY HWS, there may be a 57Hz line on low-noise DARM (see https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=4559)

I made a break-out board that allows connecting Rai's 1nV/rtHz pre-amp to the coil driver output (without acting as antenna...).

A preliminary look at the noise out of the ITMX PUM coil driver is:

- We have a 10Hz comb, due to  ~10msec duration bursts every 100msec. THis seems to be picked up radiatively - the dominant contribution is actually coming from the cable to the coil (i.e. it is present even with the coil driver disconnected, measuring the voltage across the coil)

- The noise out of the coil driver, terminated with 50Ohm right after the breakout box, is ~2.8nV/rtHz at 15Hz.

- With the coils connected, between the 10Hz comb, I get roughly 20nV/rtHz. However that noise was somewhat fluctuating.  Assuming all test masses have ~ the same noise, that will increase the current 24W GWINC curve by ~x2 below 30Hz, but it is a little short of explaining our noise.

- THere is also a significant amount of noise above ~10kHz - presuimable from the same 10msec bursts - more to come.

Jamie, Kiwamu, Nutsinee

TCS_ITMX(Y)_CO2_PWR nodes are ready to go. We have made the NOMINAL_LOCKED_CO2_LEVEL state dependent of the IFO power. The only thing I have not had a chance to test is the NOMINAL_LOCKED_CO2_LEVEL state at different IFO power (Tested when PSL power = 0 W but I don't see anything that could go wrong). I added two lines of code in DOWN state of the ISC_LOCK guardian to let it tell the TCS nodes where to go but left it commented out (line 415 and 416). Similar for COIL_DRIVERS state (line 2796 and 2797). When ready to commission TCS, make ISC_LOCK manage the TCS nodes and uncomment those lines. The PRE_HEATING power has been set to 0.5 for CO2X and 0.3 for CO2Y according to Aidan's alog.

Matt, Daniel, Patrick, Vern, Kiwamu,

We have spent a day trying to improve the behavior of the PSL rotation stage. Its performance is much better now (the angle accuracy is about several mdeg). We identified two major issues as follows which are now fixed.

• The glitch issue (rotation stage goes backward at the beginnig of  a rotation action for a short period)
• The accuracy issue (accuracy of the terminal angle is only as good as 0.1 deg)

In contrast, we started having a (new) minor issue where occasionally the rotation stage does not exit the busy mode on its own. If this happens a user should manually hit the abort button to terminate the busy state.

[Some details]

First of all, we discovered that the size of the glitch scaled with the size of the error (or the residual) that the previous rotation action has left. This lead us to the conclusion that the accuracy of the rotation stage was not good enough and the PID parameter needed some tuning. In addition, we discovered that the maximum motor velocity was set to a too high value. We were using only a very small fraction of the maximum velocity (0.1 % of the maximum nominally). Ideally, this should not impact on the performance at all, but we guessed that this caused some nasty numerical rounding error or something similar when calculating the output integer value for driving the stage. Indeed, decreasing the maximum motor velocity from 3600 to 100 drastically improved the terminal angle precision by more than a factor of 10. So the terminal angle is now as accurate as ~mdeg with a repeatable bias of 70 counts or so.

Also, we noticed that the acceleration and deceleration times were set with respect to the maximum velocity, rather than to the requested velocity. As we decreased the motor maximum velocity, the acceleration and deceleration became more apparent. (Did we change some other parameters relating to the acceleration and deceleration ?)

In order to further improve the accuracy, Daniel and Vern installed an additional load resistor of 50 Ohm in the path that drives the motor. Because we made multiple changes at the same time, unfortunately it was unclear how much this improved the resulting angle accuracy. Nevertheless, according to the drive monitor, it is now able to stably and continuously drive the motor without stopping multiple times during a rotation action. So we think this additional load helped the overall performance somewhat.

We then tuned up the PID parameter again. After all, the P-factor (aka Kp) happened to be back to the default value of 200. The I-value (aka Ki) is currently 20, while the default value was 2. However, we found that Ki did not really change the behavior, this value seems fine for now.

Kyle, Joe D.  

We removed the dying and obsolete iLIGO SRS RGA from VBOC and installed the latest/greatest aLIGO Pfeiffer Prisma Plus yesterday -> Today we took it for a test drive in both Faraday and Multiplier modes and it looks great.  This should have been done a long time ago.  The data finally looks normal!  We are baking this new RGA over the weekend -> VBOC should be available for Bake Loads by mid week.  
i
We are planning to rebuild VBOD's SRS RGA in the VPW and are considering baking it "nude" to expedite its clean-up.  We will also be replacing the RGA-tree isolation valve so VBOD will be out all of next week and perhaps longer.  

C. Cahillane

This aLOG should be the final uncertainty aLOG, at least for calibration between 5 Hz and 1000 Hz. I have generated many plots illustrating the uncertainty budgets, I will try to let them speak for themselves by explaining them one by one in order.
Whenever I have needed to choose a GPSTime for a plot, I have chosen 1135136350.

Plot 1: This is the classic analytic Response Function Error +- Uncertainty plot.  As usual, I have plotted R_C02/R_C03 to make the plot legible so you can see the systematic errors left uncorrected by C02.

Plot 2: This is a numerically-generated Monte Carlo uncertainty budget, as shown by the light-blue lines.  To generate the MC response functions, we sample from the posterior for each of the 14 parameters making up our response function, and then plot this "new" response as a series of light dots.  The light-blue lines represent the 68% confidence intervals of our numerical budget.  I have plotted the (dark) analytic budget on top here so we can compare the numerical and analytic uncertainty budgets.

Plot 3: I have quantified each parameter's individual contribution to our total uncertainty budget and error budget.  First we see the magnitude and phase uncertainty budgets themselves, then the uncertainty components plots, then the error components.  The error components are found by calculating the completely corrected "nominal" response function C03, then artificially removing a single component's systematic error and recalculating the response function for comparison with the nominal.

Plot 4: These spectrograms quantify our systematic error over all of O1.  The blue lines represent Sept 14, Oct 12, and Dec 26.

Plot 5: These spectrograms quantify our statistical uncertainty over all of O1.

Plot 6: These spectrograms quantify our "1 sigma maximum deviation" over all of O1.  What is 1 sigma maximum deviation?  It is the max of the absolute value of systematic error +- 1 sigma statistical uncertainty.  So if Error = -4% and Unc = +-3%, then the max deviation = max(abs(-4% +- 3%)) = 7%.  Apparently, many astro searches are incapable of correctly handling calibration error vs calibration uncertainty.  I must discourage ignoring this difference.  The green dots signify the time and frequency of maximum maximum deviation.

Plot 7: Percentile Plots.  I have taken the response error +- uncertainty spectrograms and compressed them into a convenient frequency plot illustrating the calibration spread over time.  The 68 percentile line, for instance, shows where the response error +- uncertainty lines were for 68% of the run time.  I have done this for percentiles 68%, 95%, and 99%.

For LLO, see LLO aLOG 25950