The communication to the dust monitors in the LVEA was lost twice today, once when the power to the Comtrol serial to Ethernet switch was lost, and once later when the software froze for an unknown reason. These times can be seen in the mode of dust monitor 11 (H0:PEM-LVEA_DST11_MODE) when it stops changing in the attached plots for today.

Attached are plots of dust counts > .5 microns during today and yesterday.

There are now two dust monitors running at end Y, both of them in the clean room for the test mass. The channel names for the particle counts > .5 microns are H0:PEM-EY_DST1_5 and H0:PEM-EY_DST2_5.

In order to investigate whether the Length modes coupling into H2 SUS ITMY M0 Top2Top Yaw transfer functions are real or noise, I've taken a high resolution (2 mHz) measurement of the same transfer function (same amplitude, BSC-ISI unlocked but undamped, ITMY M0 damping OFF, ITMY R0 damping ON).

I attach three plots for discussion. 
(1) A full-frequency-range plot measurement itself, 
(2) A zoom in on the resonance that we've been concerned with, and
(3) A plot of what cross-coupling we expect from the model (i.e. zip, nadda, zilch).

Note that neither of the first two plots are calibrated properly, but the relative amplitude should be accurate

One can see from the full-range plot that not only is the lowest Longitudinal mode present (at 0.43 Hz), but the second L mode (at 0.98 Hz) also creeps in. Regrettably, I'm now convinced that this (these) resonances are actually a measurement of physical motion, not just unlucky in coherent noise.

Now, is it a show stopper? No (yet).

A useful tip from the good Dr. Lantz: physically cross-coupled modes typically show up as pole-zero pairs, as opposed to what we see here -- just a sharp pole.

Other pertinent information: the excitation for this drive is a continuous, broad-band, white noise excitation across the measurement band, for the duration of the measurement. You'll note in the second plot attached (upper right panel), that the coherence (i.e. the measure of the *linear* coupling) between the Y drive and this particular L resonance is ~0.25, which is roughly consistent with what we know to be noise in the rest of the band. 

However, the lower right panel shows the OSEM basis response of F2 and F3 to Y (in PHASE); the sensors that compose this DOFs Euler basis signal. Here, (though it's tough to see with the black cursor overlayed -- sorry) the sensors are identically in phase, implying real longitudinal motion.

Why don't I think this is a show stopper (yet)? We have found from experience that moving around these suspensions, after locking and unlocking, that these sharp cross couplings come and go. Case and point -- we don't have a smoking gun of what might have happened between the 2011-11-19, 2011-11-29, and 2011-12-02 measurements that might have caused such a gradual increase in coupling, except for *better* aligning the chains. Further, I expect that the coupling will be significantly reduced once we take a similar measurement with damping loops ON (we'll be sure to confirm this of course) -- which is the default "plant" upon which we'll apply ISC control loops (if there are any at this stage). 

But most importantly, let's just see what we get after we install the cartridge. We'll have to lock and unlock the suspension, and will have to do another round of BOSEM centering (in and out, not necessarily laterally). We may get lucky and the coupling may be reduced, or we could get unlucky and have much worse coupling. Further, we have yet to use what's in our digital back-pocket: diagonalizing the drive using sensors. This may help as well. From what I've seen of the remaining degrees of freedom, I'm confident that the suspension's mechanical system is behaving well.

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

Data for this measurement can be found here:
{SusSVN}/sus/trunk/QUAD/H2/ITMY/SAGM0/Data/20111207_1700_H2SUSITMY_M0_Mono_Y_0p002to50Hz_TF.xml

   The EE shop found no gross problems with the staging building satellite box (see aLOG #1845), which was showing a noise spike at 55Hz on channel 1 and generally elevated noise levels on channel 3. Dave did find a couple of questionable solder joints, so he gave the box a going over and re-soldered connections as necessary. This removed all noise issues with this satellite box. A second satellite box was also showing some noise around 55Hz on channel 2. Dave in the EE shop re-soldered the connections in this satellite box, which also removed the noise. Both boxes are back in the test stand and functioning normally

- Removal of section of Y-Arm beam tube in LVEA for IAS alignment

- Preparing for BSC8 ITMY,FMY cartridge installation

- Cleaning ongoing throughout LVEA West Bay

- Videography ongoing in LVEA

- SUS fiber welding at EY (EY now has restricted access)

- FMCS network repairs ongoing

- iLIGO H1 DAQ shut down (except for h1adcusus, h1adcupem, h1adcuex, h1adcuey)

- Dust levels high (red zone) throughout day in vertex and west bay area of LVEA due to vacuum and cleaning activity

(Corey, Eric, Greg, Jim, Mitch)

We have disassembled HAMISI#1 (which has an Optical Table S/N #004), and have been putting it back together for the last couple of weeks (HAMISI#3 is on the other Test Stand and is being tested by Hugo).  We are now at a point where we can start taking inventory of various parts for the assembly.  [Except for GS13's, we don't have GS-13's for this assembly]

Unfortunately, we failed to note some s/n's until after they were installed and they are in a state where getting their s/n's is just not possible (this is especially the case for the Flexures).  I looked at the original Pre-Integration document for HAMISI#1 when it was made back in June '10, but I wasn't able to find Flexure information there either.

With that, here is inventory information thus far:

Spring S/N's

Forgot to check S/N's for the Springs before the Optics Table was installed, but were able to see their numbers with the use of an inspection mirror.

• Corner 1:  22
• Corner 2:  12
• Corner 3:  5

Flexure S/N's

These Flexures were not assembled consistently convenient, in that 2of3 Flexures were installed upside-down (meaning, scribed s/n's are on the bottom of the Flexures and are now not very visible).  Tried using a mirror and flashlight to view the Flexures from under Stage1, but the Flexures are fairly high up, and the scribe marks are also hard to read.  With that, we can only say we have "best guesses" at s/n's for Corner 1 & 3.

• Corner 1:  50? (best guess)
• Corner 2:  13
• Corner 3:  25? (best guess)

Actuator S/N's:

There were no issues with installing the Actuators.  They are all torqued down to Stage1, and are not connected to Stage0.

Corner 1:

• Horiz:  48
• Vert:  52

Corner 2:

• Horiz:  60
• Vert:  61

Corner 3:

• Horiz:  62
• Vert:  65

Sensor Head S/N's:

I'm a little confused at the inventory of the Sensors.  Looking at the document above, it looks like the order of the Sensors was V1,H1,V2,H2,V3,H3.  But we've apparently had a model change and have an order similar to the BSC:  H1,V1,H2,V2,H3,V3 (HAMISI#3 is already set like this).  However when I looked at the Sensor Assys, I saw that the Sensors were mounted in this order:  V1,H1,H2,V2,H3,V3 (!)

Not sure where this mix-up occurred, but I went ahead and swapped the Corner1 CPS's in their mounts so that we now have the correct order of:  H1,V1,H2,V2,H3,V3.  I did not make any change to the Boards in the rack, and the CPS's all match their Board.

Only able to install the horizontal CPS's.  The Target/dowel pin & the Target Mount is a tight connection, and it was found that some of these were very tight and needed alcohol to lubricate them.  This is not desirable for the Vertical CPS's because there's potential for alcohol to drip down on to the Target Face, and cause a "stain".  So, we decided to hold off installing these Sensors, and ream out the Target Mounts.

On the topic of marred Target Faces, we have found that most of our Target Faces are far from pristine.  There are noticeable marks from use of teflon to measure gaps, and just various marks from handling.  One of the Target Faces had some deep divets on it, and we decided to pull this Target Face out of use.  Hope marks on other Target Faces aren't detrimental to future operation.

At any rate, here is the inventory for CPS:

Corner 1:

• Horiz:  11979
• Vert:  11991

Corner 2:

• Horiz:  11986
• Vert:  12017

Corner 3:

• Horiz:  12033
• Vert:  12038

GS13's S/N's:

Not available since we have no GS13's.

Current State:

We have also installed payload on this ISI, and it has been floated.  We are now in the process of shimming the Lockers. 

I've re-arranged the TOP input and output orders in the 
${RTCDSROOT}/userapps/release/sus/x1/models/x1susquad.mdl
to obey the new convention, as per the latest version of the schematic, D080273. Any future QUADs attached to this test stand should have its TOP stages (M0 and R0) cabled up according to T1100327.

I've also modified the foton file (to include compensation filters for L1 and L2, that disappeared during the re-build process), which lives in
${RTCDSROOT}/chans/X1SUSQUAD.txt
but has now been copied to
${RTCDSROOT}/userapps/release/sus/x1/filterfiles/X1SUSQUAD.txt

Further, I've modified the framebuilder's .ini file, such that all OSEMINF_*_OUT_DQ channels are stored in the frames (and removed/"un-stored" some unnecessary DAMP_*_OUT_DQs). This file lives in
${RTCDSROOT}/chans/daq/X1SUSQUAD.ini
but has now been copied to
${RTCDSROOT}/userapps/release/sus/x1/daqfiles/X1SUSQUAD.ini

All three files, the .mdl, .txt, and .ini, are commited to the userapps SVN as of rev 1554.

I've confirmed that all sensor channels are functional, the frame builder is green, and data can be taken via DTT in real time and the past. Whether the channel rearrangement was successful, is yet to be determined by actually plugging in OSEMs (but I'm 90% sure it worked).

Details:

- logged into bisbee / bscteststand2, and made sure the running version of the model had been committed to the svn (it had).
- svn up'd my local copy.
- Modified simulink model according to D080273, committed as a part of repo version 1552.
- svn up'd bisbee's copy
- logged into bscteststand2, used "cdsCode" alias to cd to proper build directory
- "make x1susquad" -- wait patiently for all the useful stuff, then all the garbage to pass by
- "make install-x1susquad" -- make sure I see at *least* two active channels -- but there was only two. Somehow the make process blew away whatever 
- The most recent .ini file with more than two channels? X1SUSQUAD_111128_104742.ini. Go figure. 
- cp /opt/rtcds/tst/x1/chans/daq/archive/X1SUSQUAD_111128_104742.ini /opt/rtcds/tst/x1/chans/daq/X1SUSQUAD.ini
- run inicheck on X1SUSQUAD.ini, seems to be OK, 72 active channels
- Restart framebuilder:
	- controls@suswork1:/opt/rtcds/tst/x1/chans/daq/$ telnet bscteststand2 8087
          Trying 10.11.0.26...
          Connected to bscteststand2.
          Escape character is '^]'.
          daqd> shutdown
          OK
          Connection closed by foreign host.
          controls@suswork1:/opt/rtcds/tst/x1/chans/daq/$
- Check frame builder status after restart,
$ caget X1:DAQ-DC0_X1SUSQUAD_STATUS
X1:DAQ-DC0_X1SUSQUAD_STATUS 8192
 (This is 0x2000) 
- Hit DAQ Reload on GDS_TP screen, then restarted frame builder, worked this time
$ caget X1:DAQ-DC0_X1SUSQUAD_STATUS
X1:DAQ-DC0_X1SUSQUAD_STATUS 0
 (This is 0x0, and green)
- restarted newly installed fronted process, by logging into bscteststand2, and running
controls@bscteststand2 ~ $ startx1susquad
(Did this while watching GDS_TP screen, and hit the BURT button as soon as it became visible in order to trigger daqd, etc.)
- Found warning of "modified IIR file" on GDS_TP screen. Looked around, didn't see anything abnormal. Reloaded anyways. Found that L1 and L2 stages OSEMINFs were now missing.
- Added filters via copy and paste in foton, and reloaded coefficients.
- cp ${RTCDSROOT}/chans/X1SUSUQUAD.txt ${RTCDSROOT}/userapps/release/sus/x1/filterfiles/
  committed to SVN under rev 1553.
- Checked that OSEMINF_*_OUT_DQ channels were stored in frames via DTT. L1 and L2 stages were not stored, so modified .ini file to store L1_OSEMINF_*_OUT_DQs. Hit DAQ reload on GDS_TP, and restarted frame builder.
- cp ${RTCDSROOT}/chans/daq/X1SUSUQUAD.ini ${RTCDSROOT}/userapps/release/sus/x1/daqfiles/
  committed to SVN under rev 1554.
- Confirmed that all OSEMINF_*_OUT_DQs can be measured real time, using 
/ligo/svncommon/SusSVN/sus/trunk/electronicstesting/AOSEM/noise/2011-12-06-01/AOSEM_Batch_Data.xml
- Confirmed that all OSEMINF_*_OUT_DQs can be measured in the past (10 minutes), using 
/ligo/svncommon/SusSVN/sus/trunk/electronicstesting/AOSEM/noise/2011-12-06-01/AOSEM_Batch_Data.xml

Good to go!
  

The problems with h2fw0 are more than it crashing every few hours. Some times it also glitches its framed data written to disk with a 16Hz square wave. Since this effect seems random on restart, the problem appears and disappears as h2fw0 restarts itself.

The problem is not seen in the secondary frame writer h2fw1 (whose data is served by h2nds1). Therefore for now we should only use h2nds1 to get archived frame data (h2nds1 is now the default NDS for dtt).

h2fw0's problem is only with data written to frames, any real-time testpoints or DQ channels obtained from h2nds0 do not show this noise.

We will investigate the problem further today.

Dave and Jim

PeterK, JanP, MichaelR, RickS

Yesterday, we made some final parameter measurements for the H1 PSL, inspected the pump fiber surfaces, then shut down and began dismantling the H1 PSL.

As of last evening, the pump fibers have been pulled back to the H1 Laser Diode Room, the electronics racks have been partially gutted, and we are beginning to remove components from the table.

Right now we are focusing on the components that we will reuse for the H1 aLIGO PSL.

We expect this process to continue into next week, partly because we want to spend as much time as possible working with JanP on the H2 PSL this week, which is his last before heading back to Germany on Friday.

We will post the measurement and inspection results shortly.

This afternoon the ETMy PUM glass mass was loaded into the Lower Structure marked in the fiber welding cleanroom at EY. The ETMy optic is at the end station and will be loaded tomorrow morning. Setting the mass positions relative to each other and the structure, and setup of the fiber equipment will likely continue through Wed, with welding hopefully starting sometime Thursday.

J. Garcia, J. Kissel

Today while trying to troubleshoot the FMY Damping Loops, a strange high-frequency noise was evident in the time-series signals via a dataviewer session.  A spectra of the H2:SUS-FMY_OSEMINF_*_OUT_DQ channels reveals a strange 75Hz peak in only the F1, F2, and F3 channels.  The added mystery is the fact that these channels share a physical cable with the *FMY_OSEMINF_SD_OUT channel.  We assume this is purely electronic noise arising from one of the boxes in the racks and not due to physical motion. This may also explain the added jitter in the OSEM input signals indicated by the dial indicators on the medms.  Attached is a power spectra of the *FMY_M1_OSEMINF_*_OUT_DQ and *ITMY_M0_OSEMINF_*_OUT_DQ channels with the 75Hz peak not apparent in the ITMY channels.  Investigations to ensue.

This peak is also not evident in the *ITMY_L1_OSEMINF_*, *ITMY_L2_OSEMINF_*, or *ITMY_R0_OSEMINF_*_OUT_DQ channels.  Plots for L1, L2, and R0 attached in the second pdf.

During noise testing, in the Staging Building, of the AOSEMs I found a noise spike on channel 1 and generally elevated noise levels on channel 3 on one of the satellite boxes (for M0F1-M0SD S/N 32007-14). I have removed the box to have it checked. 

A glitch in the EY timing chain in the computer users room caused all EY frontends to glitch. I remotely power cycled the EY front ends, but managed to glitch the entire DAQ when rebooting h2seib6 (that is the only one which caused the glitch). Matt then made a change to the TMSY MASTER model to add the guardian part and we rebuilt and restarted h2sustmsy with the new model. The ini file was changed today, so we reverted back to the previous one sans the all-channels-as-comment-lines.

J. Garcia, J. Kissel

Now that we finally have a functional system with centered OSEMs at all stages for the H2 SUS ITMY and H2 SUS FMY, we've changed the watchdog values to be more stringent (as in actually protecting the system). See aLOG 1264 for details on the three types of watchdogs.
 
For all OSEM stages on both suspensions, we've set the limits as

OSEM DC LO: 100
OSEM DC HI: 30000

Justification: The DC watchdog watches the raw ADC inputs of the OSEMs. The possible range should be between 0 cts (when the flag is completely blocking the LED) and the open light current, close to the ADC limit of 32768. During normal operation, the OSEMs should be centered to around 15000 counts, and typically do not move +/- ~5000 from the centered position. However, at some point, adding a DC offset, or losing the bouyancy of the SUS in vacuum, (for example) may cause this center position to change. So, we pad the extremes a little bit, and go with the above values.


OSEM AC: 20000

Here, there's not too much experience with this value, but typical undamped RMS velocities are something around 1000 cts, and during drives something like 10000 cts. So, we'll continue to think about what a good value for this is.


ACTUATOR: 80000

Here the OSEMs don't have the drive strength to really do any damage, and we have a 18 bit DAC, so 120000 cts to play with. Typical levels for damped system are ~2000 cts, and for drive during transfer functions, around ~10000 cts.

Finally -- remember that the safest state for the suspension is to have damping loops ON. So we want the watchdog to trip only on super extreme cases. This is why it may seem we're being gracious with our thresholds.

B. Bland
Reports from Garcia and Vincent from last night are that the FMy BOSEMs look unhealthy.  In fact, one of the satellite boxes is without power.  So, Richard is looking into why this is "broken". 

J. Garcia, J. Kissel

Jeff G.'s took a round a M0 transfer functions last Friday night, after the same changes:

- The BSC-ISI is floating!
- After all (er most?) of IAS adjustments have been made
- Stiffening elements have been put on
- Vibration absorbers have been put on
- L1 (UIM) and L2 (PUM) OSEMs have been aligned, and masses have been re-balanced accordingingly

It appears as though the F1 problems we were having, which raised all sorts of flags during the last set of measurments (2011-11-29), have continued to be less of a problem. To recap, the list was:
- The dynamics are different from the model, because the d's between the top stage and the UIM stage (parameters dn and d1) are not dead on. (yellow flag)
     Still true, but still only a yellow flag. It could (and most likely) just be that the model is incorrect d values from the "as built" suspension.
- The large offset in the UIM ballast mass (i.e. having it fully forward (HR side)), is causing that stage's horizontal center of mass to be offset from the center line of the suspension (represented by h1). (yellow flag)
     This cross coupling reduced from 2011-11-19 to 2011-11-29, and now is further reduced in the 2011-12-02 measurements. My guess is that whatever IAS work was done to get th test mass aligned in pitch, as well as what re-balancing had to be done after the L1 and L2 flags were installed helped move the center of mass back (or at least more) in-line with the center line of the suspension.
- The overall magnitude of the Pitch transfer functions are a ~50% lower than the model. (yellow flag) This may just be the accuracy of the measurement calibration factor.
       This also appears to be restored. Perhaps for the same alignment reasons as above
- There is an excessive amount of Longitudinal coupling into Pitch. This has been reduced with Travis flag dis- and re- assembly, but some cross coupling still remains. (red flag)
       Related to the second point, and again has reduced what may be negligible coupling.

HOWEVER, what *has* that has been steadily increasing is the cross-coupling of Longitudinal (the lowest modes) into Yaw. I will elevate this only to a yellow flag, because at that frequency, we only are taking data at a 0.01 Hz resolution, so there's a single data point. The data quality around these points is not awesome, so it could just be measurement noise on this data point. However, after looking at the phase comparison between F2 and F3 for these measurements (Yaw to Yaw drive), the two sensors for the past three measurements are in phase at that frequency, implying common mode motion between the two sensors -- i.e. longitudinal motion.

Attached are plots of dust counts > .5 microns.