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.

GV1 made uncharacteristic "clunk" at cam-over 

Purge air left isolated from vented volumes overnight

We performed the final test stand alignments for the BSC08 Quad today.  Pitch was adjusted on the ITM and the ITM/CP gap was measured and the parallelism set.

• ITM pitch: ~35 µrad up
• ITM/CP parallelism (±0.25mm spec = ±5'3" of angle = ±1.47 mrad)
  • CP pitch: ~364 µrad up
  • CP yaw: ~2.04 mrad left
    • After discussing with Dennis, it was decided that we would not adjust the CP yaw
• ITM/CP gap: 19.96mm
• ITM pitch (after CP adjustments): ~54 µrad up

This was the last of the test stand alignments.  The cartridge has now been handed off to the testers to complete required tests before the cartridge install.

After the primary Initial Alignment calcs, moves, adjustments had been made, Betsy removed many SUS or IAS things from the Optical Table this morning and handed it back to SEI.  We ended up adding 7-1/4kg (~16lbs) to Stage2 to re-balance.
Our lock/unlock motion is within specification so we hand the Cartridge Assembly back to SUS/IAS for final tweaking before testing.

Jim/Hugh

J. Garcia, J. Kissel

Jeff G.'s taken another round of measurements after the following:
- 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

Results look really good!

More analysis to come, but I attached the results. This chain has had no where near as much trouble as the main chain; any problems that we did have were focused on the stiffness of the reaction cabling. It looks like what we have in place now has been consistent and like the model for the past two measurements. As long as nothing changes (other than locking and unlocking before and after the cartridge install) I approve this chain!@

I have removed the H1 PSL dust monitor and unplugged the external vacuum pump for it in the mechanical room.

Non-final podded seismometers were being used for testing on our completed HAM assembly. Last week a horizontal unit wasn't functioning correctly, it would respond to large inputs but damp very quickly. I thought this would most likely be caused by a mass that was uncentered. Luckily for us this particular seismometer was going back to Livingston anyway, so Vincent and I popped the vacuum pod and removed the GS-13. While doing this I noticed the crossbar on one edge was noticeably looser than the others and was most likely due to a kinematic foot backing up the threaded rod. This tilt would be enough to rail the seismometer's mass.

While the can was off the base plate Vincent and I double checked the flexures to see if any of them had loosened or broken, but they were all in good shape. Since we don't have an angle bracket to re-level the horizontal GS-13s to the base plate I hoped that the top of the seismometer was perpendicular enough to the mass to level from that. With the GS-13 back on the base plate and a precision level on top of the GS-13 I adjusted the kinematic feet to obtain a level (again hopefully perpendicular) within 80-90 seconds. Then I locked down the jam nuts and hand tightened the crossbars. After sealing the top hat back onto the base plate I realized I probably should have taken pictures, then I freaked out and wondered if I unlocked the mass. After reinstalling the pod onto HAM 1 Vincent checked the refurbished GS-13's frequency response to the others and everything looked good.

This definitely seemed to be an issue with either a loose jam nut or an insufficiently tightened crossbar. These testing seismometers saw quite a bit of abuse with how much they had been removed and reinstalled but extra care should be paid attention to these feet as having to deal with a bad GS-13 in vacuum will be a significantly larger headache.

J. Kissel, B. Shapiro, J. Garcia

After some mechanical adjustments on H2 SUS ITMY M0 made by the assembly team, 

- F1 flag dis- and re- assembly at TOP stage
- Moving mass forward on UIM
- Recovering UIM and PUM signals, aligning flags,

Jeff G. has taken another set of transfer functions to asses how we did (Last Tuesday, 2011-11-29). In summary, the main chain looks better (but still not great -- Pitch as usual) but not as good as we'd like. We believe there are several issues going on:
- 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)
- 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)
- 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.
- 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)

I attached four plots for your perusal. All are M0 TOP to TOP transfer functions.
(1)allquads_111130_H2SUSITMY_ALLM0_TFs.pdf 
Comparison between nominal model (BLUE) previous main chain measurements (ORANGE), and current main chain measurements (BLACK). Note that 2011-11-19 measurements of V and R are missing, because the M0RT OSEM had failed. We see hear, as before, that the degrees of freedom (besides Pitch) all line up quite well with the model, implying that the majority of the dynamics in the suspension are free and well. 
(2)2011-11-29v2011-11-19_H2SUSITMY_M0_P-P_TF.pdf 
Zoom Comparison between nominal Fiber model, the first 2011-11-19 measurement, and the current 2011-11-29 measurement. Here, we see the good news that the severe cross-coupling between L and P has been reduced, but not to what we expect from the model (and from what we've seen on metal builds).
(3)2011-11-29v2011-11-19_H2SUSITMY_M0_P-L_TF.pdf 
Model, 2011-11-29, and 2011-11-19 Pitch to Longitudinal cross coupling (compared against 2011-11-29 and 2011-11-19 Pitch to Pitch), quantifying the reduction.
(4)2011-11-29v2011-11-19_H2SUSITMY_M0_P-P_TF_modelcomp.pdf 
Comparison between models with parameters varied, in order to try to explain what might be happening with the dynamics and the yellow flags mentioned above. I've tried moving around two parameters that we believe might effect the dynamics as we've seen (motivated by physical differences). 

     fiber = Nominal Model, with h1 = 0 mm, and both dn and d1 = 1 mm
     fiber_h1plus5mm = Modified model, with h1 = +5 mm
     fiber_dnd1plus1mm = Modified model, with dn and d1 = 2 mm (break off points are further away from the vertical center of mass, dn increased in +Z, d1 is increased in -Z)
     fiber_fiber_h15mm_dnd11mm = Modified model, with both h1 = +5mm, and dn=d1=2mm

Again, we suspect that h1 is offset because there's a good fraction of the ballast mass on the HR side of the UIM, and we suspect the d's concerning the UIM might be off, because they (a) affect the two modes that are the most different in the model, and (b) these d's are adjustable, and are defined by blade tip heights a physical parameter difficult to mail down. One can see that, though both parameters effect the dynamics differently, the combination of the two explain the measurement quite well, specifically offsetting the horizontal center of mass at the UIM explains some of the high-frequency cross-coupled length resonances.

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

Our best guess up to this point as to where the remaining cross-coupling is originating from is that F1 is not driving as much as we think. The idea being that we intend drive equally in (F2+F3) and F1, and because either the F1 (a) electronics, or (b) the OSEM coil-magnet pair results in less drive in F1, there is an imbalance in the drive, and (F2+F3) ends up driving more, which means that Length is excited more than expected.

Things I'm looking into in order investigate this claim:
- Looking at F1 response in a Length drive, compared against models. The thought is perhaps the monolithic is more susceptible to this particular flaw, so comparisons against metal builds may not be as enlightening, but we can check anyways. If there's a large discrepancy, this would indicate that the sensing part of the OSEM is at fault.
- Comparing Pitch / F1 response to reaction chains. The TOP and UIM masses are identical between the two chains, and should therefore have the same mass. Further, the total mass of the two chains is identical. This means at high frequency, above the resonances, where the transfer function should be just as a free mass (F = m a, or T = I a), the chains should be the same.

Measurements we can do in order to better identify the problem
- Measure the OSEM basis (F1 to F1, F2 to F2, etc) transfer functions, and compare against the model (~2 hours of measurement, 1 days worth of analysis). If the F1 to L check doesn't turn up anything, then if this comparison with model shows something strange, then we know it's the actuator side of the OSEM that's failing.
- Measure the F1 response at DC (at a few different drive levels, using offsets in the COILOUTF banks), then replace the OSEM with a new OSEM from "off the shelf," and perform the same measurement. (1/2-a-day of measurement, 1/2-a-day of analysis) If there's any change, you know it was the bad OSEM. If there's no change, then we know the OSEM coil-magnet pair is OK, and it's some further flaw upstream in the electronics. 
- If the OSEM turns out not to the be the problem, we can drive equal amounts of digital signal from the DAC, and measure the response at the mock in-vacuum feedthrough. (1/2-a-day of measurement, 1/2-a-day of analysis).