Alexa Daniel Dan Evan Jeff Lisa Sheila (+ many others)

Like a coffee hipster who won't touch beans that haven't passed through a civet, the IFO now measures DARM_ERR with the light transmitted through the OMC.

After the BS WFS were commissioned earlier today, we had several steady locks with 2.8W input power in which we attempted the handoff to DC.  We measured the DARM loop gain and set the UGF to be at the maximum of the phase bubble to make the transition as stable as possible (30Hz, ~30deg margin).  We experimented with different DARM offsets and settled on 5e-5 counts; with a preliminary calibration of 3x10^-7 m/ct this corresponds to an offset of 15pm.  The carrier TEM00 mode was somewhat larger than expected (see the attached pdf, peak at ~43 volts), about 15mA in DCPD sum, almost as much as the 45MHz sidebands.  We used this DARM offset for the rest of the evening.

We measured the OMC-DCPD_SUM --> DARM_IN1 transfer function and adjusted the OMC-READOUT_SCALE factor and LSC-OMC_DC_OFFSET to enable the handoff from AS45_Q.  The values we used are an offset of -2.33e-05 counts and a gain of -2e-6, these values were tuned at the few percent level in subsequent locking attempts to match gains as well as possible.  (Note that the gain comes before the offset, which makes trimming a little more straightforward.)  After these were applied the OMC-to-DARM noise TF looked like Fig. 1.  At this point we attempted the handoff to DC.

This blew the lock.  We realized the OMC input to DARM was subject to the normalization factor of sqrt(NPTRX).  We implemented an awkward fix by holding the output of the TR_X and correcting for the power normalization in the OMC-->DARM input matrix element.  The correction factor is 6.25, this changed by ~1% from lock to lock.

After that, the handoff to low noise worked.  The OMC DCPDs currently have no whitening enabled because the ETMY violin modes (at 508.1 and 508.2 Hz) are rung up and even a single stage of whitening will saturate the ADC.  So, we are ADC noise limited above ~400Hz.  One of our next steps will have to be the commissioning of the violin mode damping.  The ETMY bounce mode is also rung up; so far this isn't a problem, and we are nervous about turning on the damping before we're ready to end the lock.  A spectrum of the DCPD noise is in Fig. 2.

J. Kissel, B. Abbott

Over the past few weeks, I've been building up understanding of the HEPI pump servo -- more than I ever wanted to know. 

The conclusions from all this?
(1) The EPICs calculation of the PID loop (documented loosely in the EPICs manual here)
     (a) uses backwards differentiation approximation and velocity formalism to compute the *change* in control output value, which it then adds it to the previous cycle's control output value -- which turns it back into a "position" algorithm -- i.e. one *doesn't* have to differentiate the pole and two zeros of the P, I and D. Other good references I found are here, here, and here.
     (b) expects the "I" and "D" terms in [cycles / min] or [mins / cycle], respectively, i.e. it depends on the sampling rate / clock cycle turn-around time of the PID calculation. If you want to do any sane prediction of the filter shape, you've got to convert these to [rad/s] or [s/rad], again respectively, by multiplying by 60/(2*pi*Ts) [(min/sec).(rad/cycle)] or (2*pi*Ts)/60[(cycle/rad).(sec/min)].
(2) The EPICs turn-around time, or clock cycle, for the discrete PID controller calculation is longer than the requested sampling frequency, which means the sampling rate is determined by the clock-cycle. Further, it's slower in the corner station than the end stations. We should lower the EPICs record's demand of the sampling frequency from 10 [Hz] to 1 [Hz] (and check again if the PID can turn around the calculation fast enough).
(3) The HEPI Pump servo contains a second-order, 16 [Hz], Sallen-Key, anti-aliasing filter before the input to the ADC on all pressure sensor channels (see D0901559, pg 2)
(3) We should lower the PID parameters such that the UGF of the loop is ~ 1 [mHz]. Why?
     (a) The pressure sensors were never meant to be used as AC sensors. LHO aLOG 16500 hints that they shouldn't be used in a loop above a few [mHz].
     (b) The ADC noise of the Athena II, PC 104 computer is an abysmal 1e-2 [V/rtHz]. As they are currently amplified, the pressure sensor's signal gets buried in this ADC noise by ~10 [mHz].
     (c) Adding an EPICs "smoothing" parameter (a.k.a. SMOO) to the EPICs version of the pressure sensor channels adds a single-pole low-pass filter into the control loop. If sufficiently low in frequency, it'll start to creep in on your already-small phase margin. We should use this with caution, or at least be cognizant of its impact.

-------------
Details.

I attach 5 plots per pump station:

Pg 1: On the EPICs turn around time defining the sampling rate
In my perusing of the EPICs manual, I found that the PID channel, e.g. H1:HPI-PUMP_EX_PID, has sub records, one of which is "DT," which one can query with a simple caget:
jeffrey.kissel@opsws8:/$ caget H1:HPI-PUMP_EX_PID.DT
H1:HPI-PUMP_EX_PID.DT          0.312006
This is "the time difference in seconds between processing steps." Consequently, I caget'd this sub record 5000 times. This turned out to be faster than the EPICs calc record would update the number by 3, so I took every third report. Then I histogrammed the results, to find that the clock cycle is 0.55 and 0.28 [sec] (!!) for the corner station and both end stations, respectively. The end stations show some clock jitter, but I took the mode of the 1667 points and used that as the clock cycle. This immediately informs us that the features seen in all ASDs that happen at 1.8 [Hz] and 3.5 [Hz] at the corner and end stations are just a function of the terribly slow sampling rate -- even slower than the EPICs 16 [Hz], and the request calc record rate of 10 [Hz].

Pg 2: On EPICs Implementation Discrete PID Control
It's too difficult in a simple text editor to really do the explanation any justice, but check out all of the references I show above, while you wait for coherent presentation version of this aLOG. One of the many reasons why my initial guess at what the servo was doing (in LHO aLOG 16447) was incorrect was because I wasn't accounting to the time delay of the discretization. As I found out later, it turned out that the discretization was much slower that was defined in the EPICs calc record.

Pg 3: Modifying the measured plant (see LHO aLOG 16601) with the anti-aliasing filter, and an EPICs smoothing filter 
On the SMOOOOOOO at EY
Hugh's initial instinct to combat the newly-noisy differential signal was to add some EPICs sub-record defined "smoothing factor" to the supply and return channels which form the differential pressure signal. Again, from the EPICs manual, 
"The converted data value is subjected to the following algorithm:
val = newvalue * (1 - smoo) + oldvalue * smoo
SMOO should be a value between 0 and 1, with 0 meaning no smoothing and one meaning ultimate smoothing (in fact the data will never change)."
*sigh* who writes these manuals? Thank god they wrote out the algorithm. This is just the discrete realization of a first order low-pass filter. The pole frequency of which is defined by
f_{pole} = 1/(2*pi*Ts) * ln(1 / (1 / alpha))

Hugh had entered in a SMOO of 0.75, which at a dismal sampling rate of Ts = 0.28 [sec], means the pole frequency is at 0.159 [Hz], which explains *some* of the excess gain peaking that we see at EY. 

Pg 4: Loop Design figures of merit given the now-(mostly)-understood plant and controller

Pg 5: Model of closed loop ASD noise
Clearly I'm still missing some phase loss term that increases the gain peaking, but at least I get the suppression correct. I could hunt around for several more days as to why this is, and find some other nasty EPICs trickery. But I'm not gunna.

Thomas, Elli

We are interested in developing a way to measure the beam location on a test mass using camera images of the test mass. This can potentially be used for interferometer alignment.

This method is based on the PCal beam localization procedure. (See T1500039 for more details on the procedure.)

We used the Pcal camera on the ETMX to take a picture during full IFO lock. One can clearly see the red beam scattering off the test mass. To locate the center of the beam we fit a 2D gaussian to the beam scatter pattern in the image.  

The PCal camera is at a 10deg angle to the optic face.  We fit an ellipse to the image of the optic edge to work out its exact  orientation with respect to the camera. The we use this fit to locate the center of the optic, and the location of the center of the IR beam.  

Tonight we measure the IR beam location at {X,Y]=[-4.6mm,-20mm] +/- 5mm offset from the center of the optic.  This is a tentative result, we will put further thought into whether our beam fitting procedure has any sneaky assumptions in it.  
We also could reduce the uncertainty in this result by tweaking camera settings in order to better fit the optic edge.  The illuminator in BSC9 is on (it has been on since 19 December), turning this off would also help our cause.

The attached plot shows the tidal feedback signals during the 3.1 hour lock with the common correction on. There was about 150µm of motion in the y arm and about 100µm in the x arm, while the IMC stayed within a 100 KHz of nominal with no visible drift. The L1 drives of of both ETMs stay within 2µm of zero.

I have measured the violin mode using the most recent lock data (February 10th ~5pm). Due to the lack of precisions in the existing information and the mismatch in values I was not able to identify any of the peak except for the ITMX BR (Back Right) at 499.9 Hz. The violin mode found in the recent lock data are as follow:

499.9, 505.58, 505.71, 505.80, 505.85, 505.92, 506.92, 507.16, 507.20, 507.36, 508.01, 508.15, 508.20, 508.85 Hz 

The (fundamental harmonic) violin mode is expected to be somewhere between 500Hz and 520 Hz. Not every line is present - possibly due to high noise floor.

The violin mode has been previously identified as follow:

Positions of the wire:

BL = Back Left

BR = Back Right

FL = Front Left

FR = Front Right

Where's left and where's right you ask? I'm trying to find the answer myself!

I have started a SenseMon instance running on the dewhitened H1:OAF-CAL_DARM_DQ channel. The lock detection uses the guardian ISI lock channel as recommended by Jamie. I have set up a dmtviewer configuration to plot both the L1 and H1 ranges. The dmtviewer file is in 

   /opt/rtcds/userapps/release/isc/h1/scripts

and is called HL-Range.xml. I also added a script to set the DMTWEBSERVER environment variable so that it can find the web servers at both observatories. This is in the same directory and can be run from bash with 

   cd /opt/rtcds/userapps/release/isc/h1/scripts
  source dmtvsetup 

Then run dmtviewer with e.g.

  dmtviewer HL-Range.xml &

Note that this requires kerberos authentication so you must kinit and supply a key tab or username/password.

 

Lisa, Peter, Alexa, Evan

We have closed WFS loops to stabilize the angular motion of the BS during full lock.

We looked at ASA36Q and ASB36Q while giving small steps to the BS angle. We found that ASB36Q responds with the wrong sign (i.e., if the BS step gives an improvement to POPAIR18 and ASAIR90, the ASB36Q signals move away from zero), so we aren't using it. ASA36Q has the right response, so that's what we're using.

In the ASC-MICH filter banks, we are using FM1 (-20 dB), FM2+FM3 (1/f shape everywhere), and FM10 (inverse BS angular plant). The gains for both pitch and yaw are 0.3 ct/ct. The time constants of the loops are about 1 s.

On the BS suspension, we are feeding back only to M2. M1 is off. We are leaving the BS oplev damping on.

TCS slow channels

Alastair, Aidan, Dave. WP5043

The two laser setpoint channels which were temporarily added to script0's IOC last friday were removed and replaced by these plus more chanels in the h1tcscs front end model. The full list of new channels added to tcs/common/model/TCS_MASTER.mdl are

• H1:TCS-ITMX_CO2_LASERPOWER_SETPOINT
• H1:TCS-ITMX_CO2_LSRPWR_SETPOINT
• H1:TCS-ITMX_CO2_LASER_INTERLOCK
• H1:TCS-ITMX_CO2_CHILLER_TSTEP
• H1:TCS-ITMX_CO2_PZT_VOLTAGE_LCKPT
• H1:TCS-ITMY_CO2_LASERPOWER_SETPOINT
• H1:TCS-ITMY_CO2_LSRPWR_SETPOINT
• H1:TCS-ITMY_CO2_LASER_INTERLOCK
• H1:TCS-ITMY_CO2_CHILLER_TSTEP
• H1:TCS-ITMY_CO2_PZT_VOLTAGE_LCKPT

TCS_MASTER.mdl submitted to SVN r9793. This closes WP5043

PEM DAQ channels

Peter F, Robert S, Dave. WP5042

The PEM models h1pemcs, h1pemex, h1pemey, h1pemmx and h1pemmy were modified to conform with Peter and Roberts PEM data rates to frame document T1400768. There remains an inconsistency in the number of magnetometers and accelerometers, so this WP will remain open. Code was committed to SVN r9794

PCAL addition of working standard channel

Rick, Sudarshan, Dave. WP5045

An additional ADC channel was added to the PCAL model to read out the Working Standard signal. The model files pem/h1/models/h1pem[ex,ey] and cal/common/models/PCAL_MASTER.mdl were modifed. The new code went in at the same time as the above PEM restarts because CAL and PEM were merged. The PCAL_MASTER.mdl was committed to SVN r9763. This closes WP5045.

DMT Broadcaster and DAQ configuration

John Z, Dave

The following channels were added to H1BROADCAST.0.ini

• [H1:GRD-ISC_LOCK_ERROR]
• [H1:GRD-ISC_LOCK_MODE]
• [H1:GRD-ISC_LOCK_OK]
• [H1:GRD-ISC_LOCK_STATE_N]
• [H1:OAF-CAL_DARM_DQ]

The ALS testpoint par file was added to the DAQ (was accidentally left out during the ISC split last week)

DAQ Restart

Jim B, Dave

To support all the above, the DAQ was restarted. Jim delayed the startup of h1fw1 and h11nds1 to reconfigure their NFS mounts to support minute trend offloading on h1fw1.

Cleanup

Dave

I pressed all the DIAG_RESET buttons to clear accumulated ADC,IPC,etc. errors.

The following models had modified filter file warnings, I did a full filter file load on them: h1susmc2, h1iscex, h1iscey.

h1susmc2 did not seem to actually have a modified file (filter_archive files were identical).

isc end stations were a residual of the ISC split last week, so of the filters left in the isc models no actual filter changes were applied.
 

== Daily Ops Summary ==

06:50 Jeff to LVEA/PSL
07:30 Karen to LVEA
08:00-10:00 Jeff runs a test on HEPI pump servo
08:02 Peter King to H2 enclosure
08:04 Rick worked on PSL. IMC state DOWN, input to frequency servo disabled
08:11 Corey to EX (30 mins)
08:16 Andreas and Aiden to TCS area around HAM4
08:30 Jamie runs Guardian upgrade testing on ITMX seismic system
      Fil and Richard to HAM4, 5 ISI and STS2
      NDS servo shutdown
09:00 Joathan and a visitor went to LVEA
08:45 Sudarshan and Thomas to End Y (PCal)     
09:00 Cyrus to LVEA
      Karen to Mid Y
09:17 Cyrus back
09:04 Corey back from EX -> heading to VLEA
09:06 Ali to EX, EY
09:24 Doug to LVEA H1 PSL Area
      Matt to H2 enclosure
09:26 Hugh to LVEA
09:40 Karen left Mid Y
      Jeff restarted pump servo (EX)
      Travis taking TFs (ETMX SUS)
9:50 Corey back
     Jonathan and the visitor back
     Jeff - HEPI Pump servo mag. sys. identificaion 
10:00 Jim restarting PEM model for Corner, Mid, and End stations
      Jim restarting TCS (Corner Station)
      Doug back from the LVEA
10:31 Aiden and Alestair to X manfold lab
10:46 Jeff done with pressure servo test
11:05 TJ and Mitch - forklift from mech. room to VRW
11:09 Travis done measuring TFs (ETMX)
11:15 Jeff brought down ETMX chamber
11:19 Jeff brought ETMX to safe
11:25 Thomas and Sudarshan back
11:09 Travis done measuring TFs
11:15 Jeff brought down ETMX Chamber
11:19 Brought ETMX Chamber to SAFE
11:25 Sudarshan and Thomas back 
11:30 Rick et al back, IMC locked
11:37 Jim restarted DAQ
12:58 Jim restarted OAF
15:52 Peter K. back

Happy Maintenance Day

Attached is spectra from WHAM6 looking at the GS-13 INF IN1s--before the digital filters.

The Red traces where taken at 1417utc (~6am local) with the FM4 & FM5 ON, my understanding and based on the plots here, this is analog low gain and whitening.

The Blue traces are from 1550utc with FM4 ON and FM5 OFF--analog low gain but not whitened.

Green traces are from 1650utc with both FM4 & 5 OFF--analog high gain and not whitened; The brown traces start at 1722utc with FM4 OFF and FM5 ON, that is, analog whitening and high gain.

Again, based on the plots, the switches appear to be doing what I thought and expect.

Do we have saturations when in whitened high gain?  No, based on the H1:FEC-51_ACCUM_OVERFLOW, no saturations accumulated during any of the measurements.

What about being ADC limited in low gain without whitening.  Included on the traces are the ADC noise from the svn.  It certainly looks like in low gain without analog whitening, we approach the ADC limit at 100Hz and very likely about a few 100Hz.

Conclusion--Leave FM5 ON all the time--we are not saturating in high gain and we are near the ADC noise in low gain without whitening...but wait:

But what about those ugly lumps between 200 and 400Hz?  They do not show up on the unwhitened hi gain signal but are evident on the other three configurations.  The ringing is exactly 1Hz and the beating is about 45Hz.  Maybe this suggests a problem with the whitening filter?  Maybe we should not whiten the signal when in high gain.

I added a zoom in of the high frequency beat  stuff.

From JeffK's 16425, while I'm a bit confused as to Jeff's language I think i understand:

These two states are compensated for digitally in FMs 4 and 5 of the GS13INF banks, by the difference between the two states (the overall gain of 2 is folded into the calibration filter). FM4 is the switchable gain compensation, FM5 is the switchable compensating de-whitening filter. The front-end code for the HAMs and BSCs is set up that these digital banks control the analog switching. 
- When FM4 is ON, the gain switch is HI (or a binary output of 1), so the analog gain is 2, and FM4 compensates the gain of 10 difference. 
- When FM4 is OFF, the gain switch is LO (or a binary output of 0), so the analog gain is 20.
- When FM5 is ON, the analog whitening is LO (or a binary output of 0), so there is no whitening, and FM5 compensates the z:p = 50:10 difference. 
- When FM5 is OFF, the analog whitening is HI (or a binary output of 1), so the whitening is engaged.

and I think the FM5 states are backwards as to the above verbeage.  The digital DWH filter certainly looks like a De-Whitening and the above traces bare out the FM5 enables the analog whitening.

dtt template is in /ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/HAM6/HAM6_GS13_GAIN_DWH.xml

J. Kissel

I've performed the same step response system identification (SysID) for the two end station HPI pump systems, as I'd done for the corner station HPI pump system (see LHO aLOG 16447), now that both ends are using the differential, supply - return, pressure signal that close to the chamber (EY switched in Nov 2014 LHO aLOG 14888; EX switched this morning LHO aLOG 16595).

Results: The low frequency response is well-characterized by
EX: a single pole at 12 +/- 1 [mHz] and a DC gain of 0.163 [PSI/ct]
EY: a single pole at 17 +/- 1 [mHz] and a DC gain of 0.141 [PSI/ct]
and for quick reference,
L0: a single pole at 24 +/- 1 [mHz] and a DC gain of 0.0546 [PSI/ct]
I quote an uncertainty on the pole frequency because the fitting method -- matching the step response against data by-eye -- is crude (though sufficiently accurate for my needs). I don't quote an error bar on the DC gain because the fitting method for that is quantitatively robust and the uncertainty is negligible.

The three attachments are the raw data and fitting for EX and EY, and a plot showing the (low) frequency response of all three models together.

I'll speak more on this in a later entry and/or DCC document, but note that this estimation of the plant via step response does *NOT* measure several other parameters that determine the high-frequency (above ~1 [Hz]) response that I've discovered to be relevant to the PID loop design  (in particular, the phase), including
- The second-order, 16 [Hz], Sallen-Key, anti-aliasing filter before the input to the ADC on all pressure sensor channels (see D0901559, pg 2)
- The [clock cycle / sampling rate] time delay
- Any epics smoothing parameters that have been installed on any pressure sensor channels
Including all of these features, I think I'm finally able to predict what we see in the closed-loop amplitude spectral densities (see, e.g. 16474, or 16426). Stay tuned.

Log files of the excitation, including GPS times of step impulses:
/ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/
2015-02-10_HPIPumpServo_EX_OpenLoopSteps.txt
2015-02-10_HPIPumpServo_EY_OpenLoopSteps_SMOO_ON.txt

Scripts to load and process the data (needs on-site nds access, but could be modified to gather data remotely):
/ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/
H1HPI_PumpServo_EX_StepResponse_20150210.m
H1HPI_PumpServo_EY_StepResponse_20150210.m

Rick S., Jason O., Matt H., Ed M., and Jeff B.

Went into the PSL today and performed a few maintenance tasks (work permit #5039).

1) Measured PSL power at several points in the beam path:

• 33w - between M1 & M2 (just outside of the front end)
• 26w - reflected from PMC
• 27.2w - incident light on PMC
• 24.4w - downstream of the EOM (in the IO section of the PSL table)
• 24.9w - PMC transmitted

• 67.5mW – upstream of the FSS AOM
• 54.5 mW - Single pass power, upstream of M25 (81%)
• 36.3mW - Double pass power, upstream of FSS EOM (66%, 54%)
• 33.7mW – At top of periscope mirror, incident on RefCav

3) Measured voltage of RefCav REFL PD (H1:PSL-FSS_RFPD_DC_OUTPUT):

• 299mV – With FSS RefCav unlocked
• 165mW – With FSS RefCav locked
  • This is too high, giving a RefCav visibility of only 45%!

Once again the RefCav Trans PD (TPD) has begun to drift down.  Was set to ~1.6V on 1/5/2015 (see alog 15871) and today is reading ~0.9V.  Therefore we adjusted the RefCav alignment by adjusting the vertical and horizontal of the top periscope mirror.  Measured voltages at the RefCav REFL PD.

• Vertical adjustment dropped RefCav to 83mV
• Horizontal adjustment dropped RefCav to 65mV

After adjustment (and locking of adjustment screws):

• RefCav REFL PD - 300mV (with FSS RefCav unlocked)
• RefCav REFL PD - 60mV (with FSS RefCav locked)
  • This gives a FSS RefCav visibility of 80%, which is better.  Per Rick S. this should closer to 98%, so some more work to do here, but is good enough for now and we were running out time in our maintenance window.
• RefCav TPD - 1.63V (H1:PSL-FSS_TPD_DC_OUTPUT)
• RefCav transmitted power - 19.1mW

Will keep an eye on this as the RefCav transmitted power seems to drift down suddenly.  We’re not sure what’s causing this apparent alignment drift.  All the measured powers leading up to the RefCav were close to those measured during the 1/5/2015 adjustment, but the RefCav TPD was still reading ~44% less.

4) We also measured the UGF of the FSS:

• UGF: 200kHz, phase margin 35 deg
  • According to Rick S. this should be closer to 600kHz, so we have some work to do here.
• At 500kHz: -6dB, phase margin 58 deg 

5) For Daniel, we adjusted power at IO PD (IO-AB-PD3-DC) to 3.3V by turning up the PD gain by 3 clicks and adding a ND filter to the PD (see Daniel's earlier alog).

6) We are now storing the 2 3IFO PMCs in the NW corner of the PSL LAE on a cart, with their lids off.

Summary:

Looking at ITMx HWS data from full interferometer locks on 7 Feb and 9 Feb, here are some estimates of ITMx coating absorption:   500(150) parts per billion measured on Feb 7,  9 Feb: 430(130) ppb measured on Feb 9.  For reference, Livingston measured 140-200 ppb coating absorption on the ITMs, see log 14634.

Method:

-HWS measures spherical power.  The raw data was multiplied but a factor of 0.00326 in dataviewer to account for magnification of the image, which gives Spherical power in diopters.   The change in the spherical power before and after the interferometer drops lock was ~5*1(0.02) microdiopters both days.  The measurements were averaged over a few minutes.

-The shperical power is related to absorbed power by 1.06(0.3) mW/microdiopter (log 14634) which means ~5mW power was absorbed.

-On 7 Feb 10.4 kW was in the x-arm, on 9 Feb 11.5 kW was on x-arm (calculated as per alog 16579).  I've assumed 10% uncertainty on this power, but perhapse that is too small.

[absorption in ppb]=[absorbed power]/[locked arm power] *1e9

Datasets and code are saved in /ligo/home/eleanor.king/HWSreadouts.

Jeff restarted ETMX SUS, but this didn't solve the decimation problem reported in alog 16511.

All models on h1oaf0 stopped running just before 1:00 PM PST with ADC timeout errors.  Had to kill the user models and restart the IOP model to recover timing, then the user models were restarted.

The first attachment is a time series of the HAM6 Watchdog, the Fastshutter State, and a GS-13 trace on HAM6.  The switch to low Gain is clear on this last trace.  This is a 5 day trend and the ~20 minutes needed to get the below .005Hz BW data is comfortably unmolested by the ISI or the fastshutter--the start times of the Spectra calculations begin at the vertical black lines.  As for ISI trips and shutter fires--there were none.

The High Gain Spectra period begins at 0800utc on 29 Jan, the Low Gain Spectra begins at 0800utc 1 Feb.

The second attached graph has Horizontal GS13s on HAM6 in High and Low Gain on the upper plot.  The Verticals are in the lower plot. High Gain Spectra is Dashed, Low Gain traces are Solid.  Also shown is our ADC noise in counts.

One caveat is that the ground motion is different at the two times.  The third attachment shows the Cartesian DOFs for the HAM6 GS-13s in the upper two plots and the ground noise in the bottom plot.  We've had a ground motion decrease in the microseism frequencies and below during the low gain period.  You can see the Low Gain Spectra are at the ADC level below 50mHz.  And the 10x signal reduction expected is more like 5x below these frequencies.  If this conclusion passes mustard, we'll have to revisit the GS13 triggering delays/levels.

DTT template is /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/HAM6_GS13_GainNoiseTest.xml