Jason, Kiwamu,

PR3 oplev has not been properly behaving. We don't know when it ran into the issue. We will take a close look in the next maintenance Tuesday as we are suspecting a bad QPD and/or bad electronics.

[Cross-coupling issue]

Currently the symptoms are that:

• Moving the PR3 suspension in pitch shows a large cross coupling to yaw (more than 50%) and the same is true when moving the suspension in yaw.
• When each segment receives equal amount of light, segment 2 seems to respond much lesser than everyone else to the suspension angular motion.

At this point, we are not sure if this is due to a bad QPD segment or some kind of electrtonics issue.

[Dip switch confusion]

Independently of the cross-coupling issue, we found that a dip switch for the seg3 whitening filter had been set differently than the rest of three segments. We thought this would fix the cross coupling issue at the begginig, but switching it to the position that everyone else have been did not solve the issue because the cross-coupling behavior which is described above arose in turn. It is unclear how long the dip swtich has been in this configuration. Note that the last maintenance activity on PR3 was performed almost a month ago (on 7th of this April, alog 17722)

Changing WP #5182 -> had intended to bake out BSC6 RGA for 24 hours starting today but will bake in 4 hour increments over the next few maintenance days instead -> As such, pump cart at BSC6 will only run during maintenance periods. 

After the guardian states were rekeyed during the March SUS guardian revamping (alog 17259), the SUS_GUARDIAN_STATES_OVERVIEW_CUST.adl screen has been incorrectly displaying the SUS GRD status.  Today I fixed this and now the status lights accurately represent what state the SUS GRD is in.

ALS build against RCG2.9.2 [WP5183]

Jeff, Jim:

h1alse[x,y] models were built against RCG Tag2.9.2 and restarted. No DAQ restart was required. RCG version number on the GDS_TP screens is 4002 for this build.

DAQ reconfiguration [WP5184]

Jeff, Jim, Dave:

The DAQ was restarted at the following local times: 07:24, 07:25, 09:58, 11:39

The first two restarts were to apply the new INI files if they had been updated (they had not). The first raised DAQ errors on certain front ends, the second was to see if they could be cleared.

The third was to apply the new H1BROADCAST.ini and H1EDCU_HWS.ini files. Again certain front ends needed their mx-streams restarted.

It was then found that dataviewer would not show any fast channels in the signal selection list, and the slow channels were not quite correct. Jim tracked this down to a badly formed line in my updated H1EDCU_HWS.ini file. I have forgotten to put a close-square-bracket at the end of one channel. This was corrected and the fourth DAQ restart applied the fix (this time no frontends were DAQ glitched).

Take home message, always run inicheck on new ini files.

Guardian Reboots:

Jamie, Betsy, Jeff, Dave:

we rebooted the h1guardian0 machine twice this morning. First was to see what the load averages start with after a reboot (answer, 7 after 1 hour running). The second was to apply Jamies newer version of guardian.

prior version (guardian, ezca) = 1390,443

new version = 1445:474

On Saturday, I was able to get some data on the effect of different blend filters on DARM.  It looks like we probably don't want to be using the 45mhz blends, or they need some re-working to reduce their low frequency performance. The attached plots are DARM  from 2 lock stretches on Saturday. This is the CAL CS DELTAL spectra, which Jeff helped  me calibrate, hopefully he'll explain in a comment. Blue traces are both end stations with 45mhz blends, orange traces are both end stations with 90 mhz blends, black is the ground. Ground was pretty similar between the 2 cases, range was similar, though slightly higher with the 90mhz blend, possibly better alignment? First plot is .01 hz to 3 hz, where most of the action is, the second plot is 1hz to 100hz.

The first plot  shows the 90 mhz blend does as well as the 45mhz blend down to .3 hz, then does a factor of several worse until ~50mhz, where the gain peaking on the 45mhz blend causes more motion.  Above 1 hz the 90mhz blend shows more RMS, I'm not sure of the cause, but there are features visible in the second plot at about 8-15hz that I don't understand. But they are probably not due to the blend change.

J. Kissel, D. Barker, B. Weaver

After the first reboot of the guardian machine this morning, all SEI chambers except HAM3 came up as expected: the SEI manager and ISI / HPI subordinates are coded to be smart enough to figure out what state the platforms are actually in and restore to that state upon initialization. HAM3's ISI subordinate did not. I was able to identify it because the HAM3 SEI manager was complaining that it's subordinate's request had changed. The solution was to simply by-hand change the request to HIGH_ISOLATED.

No big problem here, just want to start recording the outcomes of reboots so we can address any systematic issues. Note this did *not* happen on the second guardian machine reboot today.

Jason, Kiwamu,

We revisted the calibration of the oplev on ETMX and ETMY which showed calibration error of a factor of a few (alog 18218). In fact, they alll had underestimated the suspension angle by roughtly a factor of two. Here is a summary table of the calibration factors:

We also updated the SDF so that these new values are already reflected. Note that the number I updated yesterday was not accurate enough (alog 18218) since I was using the misaligned ETMX. We calibrated it again with the aligned suspension. I attach the measurement data nad fitting codes as a zip file.

Replaced QPD Whitening Filter Chassis S1101595 with S1101628. Keita reported 900 count DC offset on segment 2. 

Similar to yesterday's plot but I've added MICH SRCL & PRCL

See the attached three panel for all the three building Pressures coherence to trhe IFO control signals.

Corner Station had coherence approaching 0.7 with Mich at ~20mHz, everything else is less.

WP #5164

Replaced dataviewer and command line nds tools to remove warning message about communication protocol version being unexpected.

WP #5170

Update control room GDS tools to version 2.16.17.2-1, includes awgstream (compiled against new gds libraries, no code change).

This change fixes printing to files in diaggui and foton, gives the user the ability to set very small numbers in awggui, fixes a minor bug in allowed sample rates in foton. 

For the more obscure changes, foton can be used for non-aLIGO filter development involving non-standard sample rates (using a command line option).  In diag and diaggui, multiple broadcast addresses can now be specified as a comma-separated list in the LIGO_RT_BCAST environment variable.  Also in awggui, awgstream, diag and diaggui, setting testpoints can be restricted to specific models.

Comparison between the control channels used for the signal recycling cavity (SRC) alignment, H1 and L1:

Both IFOs use a AS port, 36 MHz WFS to control SRM alignment, though H1 uses WFS B and L1 uses WFS A. I don't know if this difference is arbitraty or reflects some real difference in sensing. Both IFOs use the AS port QPD, AS_C, to control the alignment of SR2, though H1 also feeds this signal to the SRM, to decouple the action of this loop (SRC2) from the SRC1 loop.

The other thing to notice is that the DoF (degree-of-freedom) naming between the H1 and L1 is swapped. This is just unfortunate and should be fixed.