B. Bland, J. Kissel, T. Sadecki

Before we started the second round of testing, Betsy and Travis, under the advice of Joe O'Dell, wanted to make an adjustment to the blade spring tip heights of the M1 mass on BSFM01. Here was the story up to this point:
- Initial transfer functions showed several resonances much higher than expected, which implied the M1 suspension points ("d's") were off, and that therefore the M1 blade spring tips were too high. 
- The tips were then lowered a little bit (about ~mm), and no effect was observed.
- The tips were then lowered a good deal (several mm), which finally showed results where resonances were returning to the expected values. However, the tip lowering was done qualitatively so it was unclear exactly how far the tips had been lowered. Further, this caused the remainder of the chain to be significantly lower than modeled.
- BSFM01 was taken down (to be replaced by a QUAD).

However -- the story is little bit more complicated that this (see attached .pdf that demonstrates the story): The blade tip is ideally flat, from base to tip. However, because of the short geometry of these blades, (which, when unloaded, are highly curved) they are in reality a little bit curved up at the tip. Further, the procedure up to this point had been to physically measure the type height from a location that was *not exactly* at the blade tip, using gauge blocks placed physically on the blades (see E1000686). If the tip curves up *further past* the measurement point, then it is not representative of the actual tip height. Finally, though the gauge block as little mass, one still might imagine its presence on the blade spring influencing the measurement.

Now that BSFM01 was back up on the Assembly Test Stand, the plan of attack is two-fold. Re-adjust the blade tip heights back to the nominal height, but using a different reference point for measurement: a gauge block resting on the M1 base plate (with M1 locked down in its nominal position), exactly in front of the blade tip suspension point (again, see attachment). According to Joe's calculation, the distance between the the M1 base plate and M1 blade spring tip, with the suspension is under load and free, should be 26.6 mm.

The adjustment has been done; all four blade tips have been adjusted to have this height with respect to the M1 base plate. 

Now on to measurements, to see whether the results are promising!

The dust monitor set for location 4 in the LVEA has been moved into the clean room over the northernmost suspension test stand in the west bay of the LVEA.

(Eric A., Jim W., Ken M., Mike V., Vincent L., Rich M.)

BSC Vertical GS-13 Chamber #098, Seismometer LV719

This unit was not working when first used at LHO.  After failing to free the mass by repeated light impacts on the chamber, the Pod was opened and the seismometer inspected.  

Results:
Given a displacement and allowed to come to rest, the mass moved to the bottom of the seismometer and remained there.  All flexures were in good repair, and the mass springs seemed to be in a correct configuration.  The damping gaskets on the mass springs were in contact.  The mass was brought back into its correct position by adjusting the spring knobs.  The seismometer was tested and seen to produce an acceptable signal.  It was re-podded, and placed back onto the BSC-ISI.  

More inspection will be done once the Pod is sent back to LLO.

Testers had DAC problems yesterday and were unable to get outputs.  As noted by the SUS team a lot of time was spent looking into this as thought SUS and ISI were related.  They were not.  The AI chassis on the ISI test stand had a blown -15V regulator thus not powering the boards and signals could not pass through.  We fixed the Inductor in question and I was able to see outputs once again.

(Corey, Eric, Jim, Mike V.)

BSCISI #2

Much of today consisted of dealing with large plates.  Basically all the remaining plates for the #2 Assy were brought down from the VPW to the Staging Bldg  (this involved lots of shufflin' & flippin').

The top facing & bottom facing plates of the Optics Table were torqued together.  The Optics Table was then connected to Stage0 (note, the Stage0 Blade Post bolts still need to be torqued [waiting on a wrench]).

Work will now begin on assembling Walls for Stage1, and helicoiling/dowel pinning to the Stage1 Floor and Stage2 Mid-plate.

Subassemblies

(1) Stage0-1 Flexure was assembled.

While opening a gate valve at the Y mid station we believe that an isolated ion pump volume (~1 liter at a few torr) was released into the tube. Pressure in the tube came to the 10^-6 torr range but is back on the way down. Pressure is currently 1^-7 torr at the mid station and 1^-6 at the end station as the gas sloshes about. The pumping is from the Mid station.
Note that this is not a leak.

D. Barker, J. Batch, J. Kissel, R. Lane

After gleefully and boldly declaring victory yesterday on the upgrade to RCG 2.1.5, the CDS gods had to smite us a little bit, just be sure we still new who was boss. 

Executive summary: 
After some wild goose chases, we achieved the following results for BSFM01 and the X1 SUS Electronics Test Stand (bscteststand2): 
 - The BSFM is running on RCG 2.1.5, with associated GDS software
 - The watchdog behaves as expected
 - We are able to drive OSEM coils in all degrees of freedom using awggui, and measure the response with OSEM sensors in dataviewer and DTT.
 - We are able to retrieve frame builder data from the past.

Lessons Learned:
 - Exceeding the a reasonable amount of the test points (~6) is still bad thing, and can cause all sorts of mysterious badness.
 - Therefore when looking at real-time data, whenever possible we should use frame builder channels (_DQ channels)
 - A good, full, healthy power-cycle of the front end and I/O chassis is never a bad idea after upgrading the RCG and associated software.

Detailed breakdown of today's activities:
 - Robert "prepared" the BSFM using /ligo/svncommon/SusSVN/sus/trunk/BSFM/Common/MatlabTools/Load_BSFM_MEDM_Values.m, in order to restore matrix values, filter bank states, and offsets. (WIN!)
 - While trying to un-trip the watchdog, we discovered a few bugs in the BSFM watchdog front end code and MEDM screens, and fixed them. (WIN!)
 - Discovered some small, but strange noise in *some* of the test point channels -- not a show stopper (WIN!)
 - Once watchdog was reset-able, we attempted to drive small offsets out to the OSEM Coils, using the OSEM Sensors as our figure of merit, without success. However, it appeared that drives made out to the last possible visible point in digital land (i.e. the IOP DAC output channels)
 - Went out onto to the floor to further diagnose the problem by measuring the the voltage coming out of the Anti Imaging Chassis, and our suspicions from the OSEMs were confirmed: no voltage was coming out of the Anti-imaging Chassis. While performing this test we noticed some of the indicator lights on the GDS_TP screens were red (specifically the ones identifying that the user model acknowledges the existence of a DAC card).
 - Somehow, our CDS woes infected the SEI Electronics Test Stand as well, and they *also* found that they could not excite anything out of there DAC.
 - Assuming this was some mysterious flaw in RCG 2.1.x (SUS is at 2.1.5 and SEI is at 2.1.4), we went running to the CDS team. After trying a power cycle of the entire rack, and looking around to see if the timing crates common to botyh systems had anything to do with it (the conclusion was "maybe...?") SUS was able to finally get *some* signals out. Who knows why, our best guess is the power cycling of the rack (though this doesn't solve the same problem for SEI)
 - While attempting to get *other* signals to drive, we discovered craziness in the test points in dataviewer (some with huge digital waveforms, others with just a fixed spike, others displaying rediculously huge numbers), and when the same channels were measured in DTT, the were absent (as though the signal were a bunch of NaNs or something). Again to the CDS crew!
 - After a few minutes of noodling around, we found that our test points were *all* engaged (as read out by the GDS_TP screen), and our channel datarate had exceeded the allotted 2 MB/sec. Remembering the good 'ol "diag -l" > "tp clear *" method of clearing all test points, this magically alleviated the test point craziness. Note that this *did not* remove the small, 89Hz harmonics noise in the L and T TEST excitation channels. 
 - I then moved back to this morning's original goal, make sure that all degrees of freedom can drive, and that drive can be measured by the corresponding sensors. This was a success. The subentry below details how I performed that test, and shows the results.

- Delivery for Apollo in the morning to warehouse
- Kyle at BSC10 to prepare for unlocking of H1-ETMY
- H1-ETMY unlocked
- Electrical inspector on site
- Gregorio Tellez at MY for tests
- Richard replaced phone by FMCS workstation in the Control Room
- 4k ITMX and FMX Optical Lever lasers were turned off by Richard
- Fred leads tour to EY and LVEA
- Paul works on H1 PSL electronics
- Dust alarms ring for CS Optics Labs, (Bake Oven and Optics Lab)

J. Kissel, R. Lane

After the recent upgrades to the test stand, we were doing some further 'checkout' testing of the test stand. We were driving small signals and observing for a reaction of the suspension in dataviewer. When we disabled the test signal we observed some noise in a couple of the stored frame builder channels (X1:SUS-BSFM-M1-TEST-L-OUT-DQ, X1:SUS-BSFM-M1-TEST-Y-OUT-DQ), that does not appear in the test points of the same channels. These particular channels receive no input from live sensors, so with out excitation, they should read identically zero. The noise is ridiculously small (~ 1e-21 cts / rtHz), and we only noticed it because dataviewer had auto-scaled it to *look* large. However, other channels appeared to not have this noise, and we just upgraded trying to get rid of other harmonics, so we bring it CDS's attention. 

Spectra show the noise is composed of ~89 Hz harmonics. Curiously, the 7th harmonic (712.125 -- exact frequency limited by the resolution of the quick spectra) appears the loudest at ~2e-19 cts. 

Attached are a amplitude spectra (pg 1) and time series of the noise (pg 2).

Summary of Rolf's visit 6/6 - 6/15

Installed five front end computers in the LVEA to operate H2 ITMY/FMY cartridge install. IOP, SEI and SUS models were developed and installed, DAQ was configured for this system. SUS model templates were created (both quad and triple), ITMY, ITMX, BS, FMX and FMY were built from these templates.

RCG modified for biquad IIR filter change. Changes were applied to RCG 2.1, 2.3 and trunk.

RMS filter part limits were increased.

Test model was developed for ISI BSC8 electronics checkout.

SEI and SUS medm screens are being built from template files using macro substitution. The MEDM sitemaps and overview screens are being developed to allow efficient access to medm screens.

IRIG-B timing system was installed in the LVEA, all H2 frontends have no timing errors. H2 projector was configured in the control room.

SUS QUAD test stand was upgraded to RCG 2.1.5 (all features except long chan names).

Before posting BSC-ISI testing results, here is a recap of the work done on the teststand these last few days:
-	The BIO switches have been introduced in the BSC-ISI model. Calibration and compensation filters for the BSC-ISI are located in the seismic SVN respectively at /BSC-ISI/Common/Calibration_Filters_BSC_ISI and /BSC-ISI/Common/Calibration_Filters_BSC_ISI. E1100524 will sum up the contents of these filters. In attachment (BIO_Switches_GS13), times series showing a gain change in a GS13 interface chassis using a BIO switch. 
-	We had wrong decimation filters. Seiteststand2 has been updated from RCG 2.1.2 to RCG 2.1.4 to solve this issue. The attached figures (Decimation_Filters_2_1_2.pdf - Decimation_Filters_2_1_2.pdf, Decimation_Filters_DQ.png) show Powerspectra of DAQ noise (of the L4C interface chassis) recorded on the frame builder at different sample rate (4K, 2K, 1K). In , we can see that:
o	At full rate (Decimation_Filters_2_1_2.pdf), the decimation filters used to downsampled from the IOP to Model had a corner frequency close to 1K. Since, the model is running at 4K, this corner frequency should be slightly below 2K. 
o	At 1K, 2K the decimation filters used to record on the DAQ have corner frequencies at respectively 360 and 720Hz. These filters are built to have a 60dB attenuation at the Nyquist frequency. 
-	Due to a recurrent transmission error showing up few hours after restarting the IOP, one ADC has been changed (ADC_1_Transmission_error.jpg)
-	Awgstream starts excitation with one second delay. The problem has not been fixed (It doesn’t prevent us to work). Since seismic mainly uses awgstream launched from Matlab, a 1 second correction is introduced in awgstream.m located at /ligo/apps/linux-x86_64/Awgstream/matlab. This Awgstream.m is not under version control.
-	Note that awgstream doesn’t return a warning when the excitation channel doesn’t exist
-	The data rate in defaults at the top of the file.ini file must be the native rate of the model even if no channel is recorded at that rate. Awgstream doesn’t properly if the "datarate" in the header of the .ini file is not the native rate

(Corey, Doug C., Eric, Jim, Ken, Mike V., Rich M., Vincent)

BSC#1

• Cables were dressed.
• Sensors were aligned
• Testing crew has taken over.

For all intents and purposes, Assembly work is complete on BSCISI#1 (There are just a few remaining items related to the Vertical GS-13's which need to get installed).

BSC#2

• Top-facing Optics Table Plate had helicoils and dowel pins installed on its underside
• Bottom-facing Optics Table was flipped.  (modified flipping harware was used, and THIS TIME, the plate hung close to level.

Subassemblies:

• Small Actuators:  COMPLETE
• Large Actuators:  COMPLETE
• Lockers (both sets):  COMPLETE

J. Batch, J. Kissel

In efforts to resolve the 16Hz harmonics (from here on "16HzH") seen intermittently on the X1 SUS Electronics Test Stand, we decided to upgrade the front end code generating software from RCG 2.0.1 to RCG 2.1.5, along with associated other GDS software. In short, the upgrade took only a few hours (if that), and appears to have succeeded, both in our standard "does it *really* work?" tests and in getting rid of the 16 HzH. However, we should keep an eye out for the 16HzH popping up in the future (i.e. when we get a full QUAD's sensors back up and running, as opposed to merely 6 OSEMs on a BSFM).

Among the other tests (described below), we performed the same test we performed this morning, using two models (QUAD and BSFM) to simultaneously readout the same ADC channels, measuring both test points and frame builder channels. Knowing that the problem had been seen on different channels at different times, I made sure to look at all six degrees of freedom (see pages 1 - 6). All six DOFs show no sign of the aggregeous 16HzH. Further, the test was performed after several restarts of the front end process (which had been known to cause the 16HzH to jump from channel to channel), and still showed now sign of 16HzH.

Excellent!

The QUAD and BSFM still need to be "prepared," in the the matrix values must be restored, and filter settings to be corrected from their initial start up state. This will be done first thing tomorrow morning.

Details
-------
[What was done for the upgrade (forgive my Jedi Level 5 understanding, Jim was blazing through this stuff like a BOSS)]
The upgrade from RCG 2.0.1 to RCG 2.1.5 includes several bug fixes (e.g. bus creator/selector problems), newly supported Simulink parts (e.g. RMS block), the ability to use long channel ~50 names in EPICs, and most notably it changes the extension for frame builder channels from having the extension "_DAQ" to "_DQ".

However, in order to be sure that EPICs could handle the extra long channel names, it required a recompilation of several other associated software such as mbuff, awgtpman, and daqd/nds and re-installing them the kernel, target/gds/bin/, and target/gds/, respectively. Also, the GDS software (dataviewer, dtt), agwstream, and EPICs themselves needed upgrading and recompilation. Finally, once the above associated software was upgraded, and the RCG "release" folder was linked to a checkout of the advLigoRTS-2.1.5/ tag, both the x1susquad and x1susbsfm models needed to be recompiled.

*phew!*

[Once the upgrades were finished]
We ran through a battery of tests (some that are now a standard part of the CDS upgrade checklist -- DCC number eminent, "GDS Test Plan"):
- Open Dataviewer, look at test point channels and frame builder channels, see if it works
- Open DTT, take a spectra of a few channels, both in real time, and in the past, just to see if you can
- Use awggui to inject a small sign wave, and look to see if you see the excitation in dataviewer
- use awgstream from a terminal to inject a small excitation, see if you see it in dataviewer
- Open Matlab, make sure all mDV software is in place (gps, get_data in particular)
- Use Matlab's get_data to retrieve some data from NDS / frame builder
- Use Matlab's awgstream wrapper to send in an excitation, see if you see it in dataviewer

The only file that needed to be changed (for each model) where the .ini files, which are responsible for letting the frame builder know what channels are to be stored. This was a simple fix -- just replace all instances of "_DAQ" with "_DQ", then run a "DAQ Reload" from the GDS_TP MEDM screen (the result of which should be that the top middle indicator light should go green, and read 0x0). The foton (chans/.txt file), and the test point manager file (.par file) did not need to be restored or changed.

GV8 soft-closed then opened.  GV14 cracked open to pump H2 in X1.  Vertex MTP valved-out briefly.

R. Lane, J. Kissel, M. Barton

In order to continue investigation on the  16Hz phenomena  in the X1 SUS Test Stand we made a comparison between the BSFM model and the QUAD model. Running both models simultaneously we took power spectra of several OSEMs using DTT to measure the same physical OSEMs four different ways (both BSFM/QUAD channels, both Test Points (OSEMINF_IN1) and Frame Builder (OSEMINF_IN1_DAQ) channels). These OSEMs are mounted on BSFM01, and readout by the electronics associated with bsctestand2. The electronics (cables, satellite amps, I/O chassis) are identical, however new OSEMs are in place (the QUAD OSEMs went with the QUAD).

As expected in the F1 and RT channels, all four measurements agree. However the QUAD SD Test Point Channel (X1:SUS-QUAD_R0_OSEMINF_SD_IN1) has a loud 16Hz harmonics.

Of interesting note, and confirming the intermittancy of the problem, while setting up the test, the 16Hz harmonics switched to the RT OSEM for one on/off iteration of the test (sadly we didn't capture this, you'll just have to believe us). This confirms the existence of some stochastic digital problem (in addition to the fact that there are brand new OSEMs being readout).

The source models for the front end code that we're running can be found here: 
~/sus/trunk/Common/FrontEnd/models/x1susbsfm.mdl (BSFM)
~/sus/trunk/Common/FrontEnd/models/x1susquad.mdl (QUAD)

The DTT template for the measurement can be found here:
~/sus/trunk/QUAD/X1/Common/dtt_templates/BSFM_QUAD_16Hz_channelcomparison_110615.xml

(Corey, Doug C., Eric, Jim, Ken, Mike V., Vincent)

Here is an update of work from the last few days.....

BSC#1

After floating both stages last week, work continues here to get the ISI ready for Vincent to test. 

• Clean cabling has been connected and run. 
• Holes were drilled into the Test Stand structure to mount (3) cable feed-thru interface boards. 
• Interface boards have been installed. 
• Vertical GS13's have had dowel pin holes on the base plate reamed out (these holes turned out to be too small for the Dowel Pins which are on the mid-plate of Stage2). 
• (3) Vertical GS13's were installed.

BSC#2

• Doug & Ken reamed out holes on the Stage-2 Top-Facing Optics Table (the machine shop forgot to mill these out for us!  We've had to do this for BSC#1 as well). 
• Small Actuators are practically complete (some of the mounting hardware still needs to be attached)
• Large Actuators are about 60% complete
• Lockers are being built.

Today we hope to get to a point where we can start assembling walls for Stage1 & Stage2 in parallel.

Matt, Rolf, Dave, Alex (remote)

We got the Biquad filter module working in the new CDS system and made a few simple tests.  For these test I created a few somewhat complex filters:

• Pass 1Hz - a resonant filter which passes 1Hz and the cuts off steeply
• Not 1Hz - a 1Hz notch filter with 120dB of attenuation, also has a pair nearly canceling poles and zeros at 10mHz
• HP 1k - a high-pass filter, flat above about 1kHz

The first test was to check the transfer function.  The biquad filter matched the the standard filter (direct form 2) with various combinations of the above filters.  No problems were observed.

The noise test was designed to match the test performed at the 40m lab in March 2008. With all of the above filters engaged, a 1 Hz sine wave with amplitude 1 was injected into the input of the biquad filter and a standard filter module. In the frequency region where the noise is amplified by the HP filter, the biquad filter produced a numerical noise floor 8 orders of magnitude lower than that of the standard filter. Furthermore, the harmonic distortion seen in the standard filter was absent in the biquad.