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.

- Laser Safe today.
- RichardM, CyrusR and FilibertoC out to work by SUS stand by HAM12
- TerryS and crew mopping in the LVEA by BSC7 and BSC10
- MichaelR installing acoustic enclosures by H2 PSL, drilling into studs.
- RichardM works on TCSX access controls
- DaniA works on TCSY dark study
- Ski and Control Solutions technician out to MY to work on HVAC control system
- Paradise Water arrives in the morning
- Apollo crew working at EY
- DI water overflowed in LSB Fiber Lab at ~15:50. Clean-up is ongoing, LisaB supervising.
- Clean room craned to HAM12
- Sock placed on top of BSC7's dome
- GregM gave seminar on Fourier Transformations
- DaniA gave laser safety orientation to SURFs
- Particle counts high in OSB Bake Oven Lab (see Kyle's entry), HAM12 (mopping), H2 PSL (mopping).

Over the past several weeks I have been notified by Patrick and Jonathan of intermittent high particle counts being recorded in the bake oven room (room 169).  These high counts don't necessarily correspond to times when people are present in the room -> 

Initial investigation shows that the dedicated exhaust fan (added to exhaust any "smells" that could eminate from the hot ovens to the building exterior and which is separate from the HVAC) has 0.6" H2O accross its iris damper while nominal has traditionally been 0.5" H2O.  The variable speed adjust is set to minimum speed which is normal and should result in 0.5" H2O drop when all other air supplies/returns are nominal.  Ski confirms nothing has changed recently in the HVAC system supplying this and adjacent rooms. Also, the fume hood switch is in the on position as is nominal.  

I noticed that the ceiling tile located directly above the particle counter shows evidence of having been removed recently (caulking seam separated with visible gaps around tile periphery).  I will see to it that this tile gets caulked and attempt to verify the the fume hood fan is actually working.  Also, its time for a general clean-up in this room.

Opened Vertex to the YBM and X-end for a couple of hours for the squeezer folks.  Vertex and X-end pressures too high to leave opened to BT for any extended period.

Need to review user settings for Corner Station large ion pumps -> seems like maximum power setting is set too low and/or current limiting "I-protect" option not as expected.  

Apollo clening in new transmon lab at end Y
Cleaning at BSC7 in preparation for in chamber cleaning
Assembly of clean room for mechanical test stand
Drilling for floor bolts for squeezer table stand
Gate valves opened for locking H1 X arm
CDS work on electronics racks in LVEA for H2 ITM cartridge install
Cardboard recycling pickup

The dust monitor at location 4 was pulled outside of the clean room at ~22:00 UTC.

Summary of work performed 6-11th June. Rolf, Dave, Richard, Cyrus. Computing and Networking

We have installed five front end computers in the LVEA on the outside of the Y arm, next the the TCS systems. Four of these computers have IO Chassis attached and are

The fith machine is h2tcsl0 which is waiting on its Chassis.

All four machines are running IOP models and user models. All were built against RTS branch-2.3.

Networking was installed in the LVEA to support these systems. A Workstation was installed (on the CDS LAN) next to the racks. More workstations will be moved into the inside of the arm when needed.

Note:  The measured dewpoint of the blow down air, i.e. the air comming out of the +1 psig VE, was -6C while the air sourced from the purge air header measured the normal <-54C.  Prior to valving-in the pumps to a vented volume I typically close the vent valve to the VE and measure the air sourced from the purge air header then close-off the header air and open and measure the air blowing out of the slightly pressurized VE.  Normally the two measure the same as you would expect and are "off scale" dry.  In this case, the two were much different.  I repeated this measurement a few times and the values were exactly repeatable.  I conferred with John W. and decided to begin pumping the "wet" VE anyway.  

The ambient humidity is high today.  I intend to investigate with the people involved with today's unlocking if they had closed-off the purge air during the in-chamber activity for some reason or if they had blocked off 1/2 of the door opening as is the norm.  Not doing so would negate the effectiveness of the purge air's ability at keeping wet room air from mixing with the chamber interior air and might explain this observation. 

I opened GV7 too.  

The mid stations don't have their pressure gauges cabled and CDS indicated values are bogus.  Y-mid seems slow to change and is still indicating ~8 x 10-8 torr at the turbo inlet.