Displaying reports 67401-67420 of 83394.Go to page Start 3367 3368 3369 3370 3371 3372 3373 3374 3375 End
Reports until 11:41, Tuesday 03 February 2015
H1 IOO
daniel.sigg@LIGO.ORG - posted 11:41, Tuesday 03 February 2015 - last comment - 10:35, Thursday 05 February 2015(16437)
Power readbacks after EOM and at periscope

(Peter K, Richard M, , Filiberto C, Daniel S)

We noticed that the fast channels corresponding to H1:IMC-PWR_IN and H1:IMC-PWR_EOM were never hooked up. This required installing the PD interface box in the PSL enclosure, running the DAQ cable into the PSL and installing a tee in the photodetector readback. (These channels have previously been hooked up to the EtherCAT system, so they that they are available to the rotation stage.) The EOM channel is currently railed and needs an adjustment of the PD gain.

EPICS updates:

Comments related to this report
kiwamu.izumi@LIGO.ORG - 10:35, Thursday 05 February 2015 (16487)PSL

Another update:

I have put a filter in IMC-PWR_IN in order to calibrate the signal into watts. I used the slow readback (i.e. H1:PSL-PERISCOPE_A_DC_POWERMON) as a reference for the calibration such that IMC-PWR_IN matches to the slow one. So now the filter bank looks like this:

Images attached to this comment
H1 PSL (DetChar, PSL)
edmond.merilh@LIGO.ORG - posted 11:35, Tuesday 03 February 2015 - last comment - 10:34, Wednesday 04 February 2015(16436)
PSL Weekly Report
Images attached to this report
Comments related to this report
edmond.merilh@LIGO.ORG - 10:34, Wednesday 04 February 2015 (16462)

These trends were taken while there was someone in the enclosure. New ones will be taken on 02/04.

H1 SEI (DetChar)
krishna.venkateswara@LIGO.ORG - posted 11:34, Tuesday 03 February 2015 (16434)
BRS reasonably centered and working correctly

K. Venkateswara

In response to the problems reported in 16391, I centered the beam-balance in BRS within the nominal range of the angular readout. To do so, I physically moved a small mass on the balance using the bellows mounted on the front face of the vacuum can. After a few tries I was able to center it to within a ~1/3 of the full range. The balance was then damped to low amplitudes and I repositioned the damper.

BRS is now functioning correctly. The first attached plot shows the tilt-subtraction at work. The second shows the coherence between various sensors. The low coherence between the tilt-subtracted super-sensor and BRS RY shows the subtraction is working reasonably well.

Images attached to this report
H1 CDS
daniel.sigg@LIGO.ORG - posted 11:31, Tuesday 03 February 2015 (16435)
EX EtherCAT reboot

Had to boot EX which seems to be a biweekly occurrence. The problem aren't the PLCs or the hardware interface but the communications. The tcioc stops updating with a "No DS mailbox available" error message. This is always preceded by numerous "CAS: UDP  recv error". So far, the only way to fix it is to reboot. I did notice that h1ecatx1 runs the Windows firewall whereas the c1 and y1 run a commercial product.

H1 CDS
cyrus.reed@LIGO.ORG - posted 11:11, Tuesday 03 February 2015 (16432)
Framewriter/QFS Configuration Change [WP5035]
C. Reed, D. Moraru

In an effort to ameliorate the daqd crashes on framewriters 0 and 1, we have enabled jumbo frames on the private network links between the framewriters and the QFS gateways under WP 5035.  This was the last remaining major difference between our configuration and the LLO DAQ (that we know of).  If this doesn't help, we will need to keep looking for a cause for our framewriting woes.
H1 SUS
betsy.weaver@LIGO.ORG - posted 10:45, Tuesday 03 February 2015 (16430)
new ITM and ETM safe.snaps taken

Betsy, Travis

Because of new filters loaded by Rana last week, I wasn't sure there had been an update to the safe.snap file for the ITM and ETMs.  Since the IFO was down for Tuesday chaos, we therefore took new ones and committed them to svn.  While we were at it, we committed the safe.snaps for the 3 MC SUSes due to my addition of the SDF column to the files yesterday.

H1 CDS
james.batch@LIGO.ORG - posted 08:20, Tuesday 03 February 2015 (16427)
Updated Dataviewer for Ubuntu Workstations
WP #5031

Dataviewer has been updated to version 2.9.1.1 for Ubuntu workstations in the control room.  This is to fix bugzilla 786, allowing dataviewer to display raw data of multiple signals in a single plot in playback mode.
H1 ISC
sheila.dwyer@LIGO.ORG - posted 01:17, Tuesday 03 February 2015 - last comment - 11:04, Tuesday 03 February 2015(16424)
today's locking progress
Alexa, Evan, Sheila, Kiwamu, Elli, Daniel
 
Today we made several small improvements

We then made several attempts to transition off of TR_CARM.  As on friday, we are able to get to low CARM offsets, and sit there stably, but haven't been able to turn off TR_CARM yet.  We found that we could sit at about 5 pm (TR CARM = -39) stably with just TR_CARM on. 

Transition attempts:

At -36 in TR_CARM, engage analog REFLAIR 9 with 40 dB total gain on summing junction and CM board. 

At -36. engage REFLAIR9 with and offset of -1.8, tried turning off FM 9 (the complex pole compensation) in TR_CARM.  Lost lock at 7:23:45

We've had trouble engaging the DHARD WFS with the opposite sign at the small CARM offsets tonight, which on Friday seemed like it was key to being stable at low offsets.  

Comments related to this report
alexan.staley@LIGO.ORG - 11:04, Tuesday 03 February 2015 (16431)

At one point we also tried transitioning at a farther offset. If I remember correcly, the CARM offset was about -25. This also failed.

H1 SEI (DetChar)
jeffrey.kissel@LIGO.ORG - posted 22:02, Monday 02 February 2015 - last comment - 09:38, Tuesday 03 February 2015(16426)
HEPI Pump Servo Sensor Readout Appears to be Drowning in ADC Noise
J. Kissel, H. Radkins,

In further pursuit of HEPI Pump Servo Noise -- found to be coherent with the IFO at low-frequencies (see G1500099, and LHO aLOGs 16386, 16342, and 16239) -- Hugh and I briefly terminated the pressure sensor inputs to the HEPI pump servo (see times in LHO aLOG 16419), in attempt to measure the ADC noise of the PC/104, Athena II, 16-bit ADC (see Diamond System's product website for data sheet and user manual). 

Sadly, there appears to be no difference between the channels when the sensors are plugged in and when the sensors are terminated.

What's confusing about this, is that we know the pressure preamp (D1101839, which adds a gain of 151 [V_diff/V_diff] to each supply and return sensor) and the input instrumentation amplifier inside the servo (pg 2 of D0901559, adding a gain of 2 [V_se / V_diff] for a total of 300 [V_se / V_diff]) are functional and calibrated correctly in the EPICs database. If that weren't true, the DC signal on each sensor's EPICs readback would not match the dial gauges on the system.

Further, as mentioned on pg 13 of G1500099, if the pressure sensor's calibration is 0.3 [mV/PSI] (0 to 100 [mV] over a 0 to 300 [PSI] range), typical supply pressure is 70-80 [PSI], then the pre-amplified, instrumentation-amplified, supply pressure signal reaching the Pump Servo ADC should be roughly 6.3-7.2 [V] single-ended, using plenty of the range of the 0-10 [V] ADC range. On the other hand, the return pressure, typically ~5 [PSI], would arrive at the ADC as only 0.45 [V]. Small, but still well above the 10 / 2^16 = 1.5e-4 [V/ct] resolution.

So, the DC signals add up and agree with dial gauges, the signals should fit well within the ADC's range well above it's bit resolution, and responds appropriately to little steps in the control pressure. So why don't we get a change in ASD between terminated and connected?

We'll continue to investigate tomorrow morning. 

I attach three things:
(1) 2015-02-02_H1HPI_PumpServo_ADCNoiseCharacterization.pdf 
The pudding. Amplitude spectral densities of the Supply Pressure (H1:HPI-PUMP_L0_BSC2SUP_PRESS), Return Pressure (H1:HPI-PUMP_L0_BSC2RET_PRESS), and the calculated Differential Pressure (H1:HPI-PUMP_L0_DIFF_PRESSURE) for three different times. RED is with the pump servo closed (the current, nominal running state), BLUE is the with the pump servo open, but the sensors still connected, and MAGENTA is with the pump servo open and the sensor inputs terminated. As you can see -- no change between BLUE and MAGENTA.

(2) 2015-02-02_HPI_PumpServo_Pics_A.pdf 
A collection of pictures of the HEPI Pump system, as built at LHO.

(3) 2015-02-02_HPI_PumpServo_Pics_B.pdf 
More pictures of the HEPI Pump system, including pictures of the terminating plug used and how / where it was connected (starting on pg 9).

Following the pin out shown in D0901559, where (on pg 1, upper left corner) connectors J1A and J1B are shown to bring in the field Supply and Return pressure signals, I crafted two, dummy, DB9, pressure sensor terminators by connecting the + and - legs (pins 4 and 6) of the differential input with a 100 [ohm] resistive load. All other pins (i.e. the +10 [V] supply voltage to the pressure sensor, and the +/- 15 [V] supply voltage to the pressure sensor preamp) were left open. Again, see pgs 9 and 10 of 2015-02-02_HPI_PumpServo_Pics_B.pdf.
Non-image files attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 09:38, Tuesday 03 February 2015 (16429)
I have entered integration issue 1004 for this
https://services.ligo-wa.caltech.edu/integrationissues/show_bug.cgi?id=1004
H1 ISC (PSL)
daniel.hoak@LIGO.ORG - posted 19:11, Monday 02 February 2015 - last comment - 09:21, Tuesday 03 February 2015(16420)
Intensity noise at OMC, wth ISS 2nd loop on/off

On Saturday we closed the ISS second loop and dither-locked the OMC, with a single bounce from ITMX.  In this state we were able to measure the RIN at the OMC DCPDs with the 2nd loop open and closed.

With the ISS second loop closed, the relative intensity noise at the OMC DCPDs at 100Hz is about 5x10^-8 / rt[Hz].  Above 100Hz, the OMC DCPD RIN is limited by intensity noise; below 100Hz the noise is from something else.  See the first plot.  The OMC DCPD sum was ~14mA at the time of the measurement, and the shot noise RIN should be 5x10^-9/rt[Hz], well below the measured noise floor.

Compared to Gabriele's measurement from November, the noise with the ISS 2nd loop open is ~10x worse, compare the second plot, upper right, to his third plot, lower right & left.  Is the excess noise due to jitter into the IMC?  We did not take the time to fiddle with the IMC WFS offsets.  Gabriele measured 10^-8 RIN/rt[Hz] at 100Hz with the 2nd loop closed, but we measure 3x10^-8 /rt[Hz], so above 100Hz we may be limited by the gain of the ISS 2nd loop.  If this is the case, then improving the RIN out of the IMC could reduce the intensity noise at the AS port.

In the second plot, we compare some signals with the ISS loops open and closed.  The second loop suppresses the noise at the OMC DCPDs by about a factor of 100 (lower right plot).  Note that in the lower left plot, of the RIN observed by the IM4 trans PD, the ISS first loop only improves the noise at high frequency.

There is a peak in the intensity noise at 700Hz that is not suppressed by the second loop.  This also seems to be ~10x worse than what Gabriele measured in November.  It's not clear where the peak is coming from, it's seen by the IMC WFS (see third plot), but not by any PEM or IMC length channels that I can find.  This peak is broad enough that it may cause trouble with the OMC ASC dither lines.  (L1's dither frequencies are around 550-650Hz.)

Images attached to this report
Comments related to this report
gabriele.vajente@LIGO.ORG - 09:21, Tuesday 03 February 2015 (16428)

You can easily get a factor ~10 more noise in transmission of the IMC, if the alignment is not good, see for example log 14301. This is beam jitter converted by the IMC into intensity noise. 

H1 ISC (ISC, SUS)
daniel.hoak@LIGO.ORG - posted 17:48, Monday 02 February 2015 (16422)
HAM6 beam alignment: AS WFS diagonalized, OMC REFL path aligned, OMC ASC decoupled from WFS centering

Elli, Dan

On Saturday we made some changes to the DC centering loops in HAM6, for the AS WFS and the OMC.

==== AS WFS loops diagonalized ====

We started by measuring and inverting the sensing matrix for the AS WFS.  The new control matrix has been loaded into the ASC output matrix.  The old control scheme was AS-WFS-A --> DC3 --> OM2, AS-WFS-B --> DC4 --> OM1, all with matrix elements of unity.  The new output matrix elements are:

DC3 DC4 Pitch
-29 -419 OM1
410 109 OM2
     
    Yaw
-59 -423 OM1
-558 -111 OM2

To compensate for the new matrix elements we changed the gains on the DC3 and DC4 loops to be 0.03.  Based on the plot of the noise suppression it looks like this corresponds to a UGF of ~1-2Hz, but we need to measure the loop shapes during a break in the lock commissioning.

 

==== Alignment of OMC REFL path ====

With the fast shutter installed we felt confident to realign the beam going to the OMC REFL QPDs.  Previously this path had been roughly aligned, but we hadn't worked out the assignment of the in-vac picomotors and centered the beam on both OMCR QPDs.  The picomotors are on mirrors M9 and M10, see the diagram in D1000342-v14.  Both picomotors are upstream of the OMCR QPD sled.

We centered the beam on OMCR_A and moved each picomotor until OMCR_A_SUM dropped to 50% of the peak value.  Pico #6 moved half the distance of Pico #5, so we inferred that Pico #5 is driving M10 in the diagram, and Pico#6 is driving M9.  So, the HAM6 picomotor assignment is:

 

HAM6 Pico driver box channel Mirror as labeled in D1000342-v14
1 M101 - AS WFS A
2 M102 AS WFS B
3 M7 - ASC-AS_C
4 Not connected
5 M10 - use to center OMCR B
6 M9 - use to center OMCR A
7 Not connected
8 Not connected

After centering the beam on the OMCR QPDs we checked ISCT6 to make sure the OMCR beam was still coming out.  We found it was still well-aligned on the table (centered in periscope mirrors and lenses).

 

==== OMC SUS -> OMC {POS,ANG}  transfer function and OMC alignment topology ====

To decouple the OMC alignment from the AS WFS centering, we wanted to use the OMC SUS as an actuator.  (Following L1, we had added this functionality to the OMC and OMCS models in December.)  The trick is to make the OMCS look like a simple pendulum so that the OMC ASC loops can drive OM3 (a tip-tilt) and the OMCS at the same time.

We measured the OMCS --> OMC QPD transfer function with white noise, in the style of the SUS group.  The result, for pitch, is the first plot attached.  Then, we constructed some filters to remove the peaky features in the TF and make it look more like a damped tip-tilt.  The poles and zeros were loaded into the OMCS ASC filter banks, along with a 30Hz cheby low pass.  The result is a somewhat bumpy 1/f^2 transfer function above a ~1.7Hz feature that looks like a low-Q resonance; see the before/after comparison in the second plot.  The TF is a little more gnarly that we would like, I think we will make some tweaks after measuring the shape of the full OMC alignment loops.

With the new filters for OMCS ASC pitch and yaw we were able to measure an {OM3, OMCS} --> OMC QPD sensing matrix, invert, and closed the OMC alignment loops.  A screenshot of the output matrix is attached.  Because of the short lever arm from OM3 to the OMC QPDs the control matrix is not very diagonal, this could be a problem.  The loops were stable (at least, on a Saturday evening), and we could close the AS WFS DC centering and the OMC alignment loops independently.  We found that if we set the gain of the OMC alignment loops too high we would saturate the OMC suspension drive.  This could also be a problem for this alignment topology (along with cross-coupling between the OMCS degrees of freedom), depending on how much gain we want with the dither loops.  We need to measure the OLTFs, trend the control signals during weekday seismic noise, etc. before we can be confident that this distribution of the control is robust.

The fourth plot compares the beam jitter on AS WFS A and OMC QPDA, with the loops open and closed.  The noise befow 1Hz is suppressed by a factor of ~several.  The loops add some noise around 3Hz.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 17:40, Monday 02 February 2015 (16423)
End station ISC front end models ready for tomorrow's change

Daniel, Jim, Dave:

WP5034. We have changed the PEM, CAL and ISC models for EX and EY and created the new ALS model. For this week's test, CAL will be integrated into PEM and the ISC model split into two (ISC and ALS). The IOP and ODC models will remain unchanged. 

We have compiled the models h1iscex, h1alsex, h1pemex, h1iscey, h1alsey, h1pemey against a modified H1.ipc file. We have not performed "make install" and have reverted back to the running H1.ipc overnight.

H1 General
travis.sadecki@LIGO.ORG - posted 16:00, Monday 02 February 2015 (16417)
Morning meeting notes and OPS shift summary

Morning meeting:

SEI running TFs as target of opportunity for feedforward on all ISIs

Krishna will be here this week for BRS work at EX

HEPI pumpstation work

TJ working on RM and OM SUS Guardians

Jamie will be here this week working on Guardian

Matt Heintze will be here this week for 3IFO work

Beamtube cleaning ongoing

Bubba working on 3IFO purge plumbing in LVEA

 

OPS Shift Summary:

6:30 Cris and Karen to LVEA

8:19 Karen to EY, Cris to EX

8:23 Ken working on air handlers at EX and EY

8:50 Corey to squeezer bay

8:51 Ken to EY

8:51 Bubba to LVEA H2 input area

9:05 Corey done

9:19 Jodi to mid stations

9:23 Karen done

9:33 JeffK, Krishna, and Hugh to HEPI pumpstation

9:40 Jodi back

10:06 JeffK, Krishna, and Hugh done

12:00 Ken to EX HVAC work

13:48 Ken done at EX

13:54 Fil to MY for parts hunt

14:24 Fil done
 

I locked both arms with green this morning, and attempted to lock DRMI, but was foiled due to sneaky filter settings and constantly changing methodology (unable to follow OPS instructions due to changes by commissioners).

H1 SEI (DetChar)
jeffrey.kissel@LIGO.ORG - posted 15:53, Monday 02 February 2015 - last comment - 17:22, Monday 02 February 2015(16419)
Field HPI Pump Servo Sensor Inputs Terminated
J. Kissel, H. Radkins

Hugh and I continue to investigate the corner station HEPI pump servo noise at its source. As such, we've switched the servo OFF and terminated the two pressure sensors used for the loop error point (read in as H1:HPI-PUMP_L0_BSC2SUP_PRESS, and H1:HPI-PUMP_L0_BSC2RET_PRESS) with 100 [ohms] at 3:45 pm (23:45 UTC). The hope is to quantify the servo's ADC noise floor. We intend to leave it in this configuration for an hour or so before restoring it. Meanwhile, Hugh continues to manually maintain the pump pressure (though very little has been required but for a few 1 [ct] tweaks).
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:22, Monday 02 February 2015 (16421)DetChar
Pressure sensors have been reconnected at 2015-02-02 5:01pm PST (2015-02-03 01:01 UTC), and pump servo turned back ON at 5:20pm PST (01:20 UTC).
H1 SEI
hugh.radkins@LIGO.ORG - posted 14:45, Monday 02 February 2015 - last comment - 15:57, Wednesday 11 February 2015(16416)
WHAM6 ISI GS-13s are in Low Gain so as to not trip when the AS port Shutter fires. Are we ADC noise limited? It appears we are.

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

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 20:18, Monday 02 February 2015 (16425)
J. Kissel, H. Radkins

Which GS13 gain/whitening configurations are the "right" gain configurations? 
How many times have we asked this? 
Hugh is trying to settle this once-and-for-all with quantifiable results like the above entry, but I relay the history and current problems with the GS13 gain / whitening switching below.

The GS13 Interface Board (D1002706), used for both HAM and BSC ISI GS13s (in D1000067 and D1002432, respectively), has two *independent* switches: one for an analog whitening filter (switching between a flat gain of 1, or a zero:pole filter of 10:50 [Hz] -- a gain of 1 at low-frequency, 5 at high frequency), and one for analog gain (switching between a flat gain of). Thus, there are four possible gain/whitening states for this interface board. See attached visual aide.

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.

A long time ago, Brian had performed a design study (see G1000412) that had suggested (on pg 24-25) that
"Low Gain Mode [is] good enough to get close to requirements at all [frequencies] above 300 [mHz], tilt[-horizontal] coupling [from vertical GS13 noise turning into RX & RY, which causes X & Y].
[In] High Gain Mode, ADC noise is at least 2x below the sensor noise at all frequencies."
where he defines 
"Low-gain is DC gain of 2, with a zero at 10 [Hz], pole at 50 [Hz]"
and
"High-gain is fixed gain of 12 (input stage of 6)."
Clearly the later statement is now out-of-date with respected to the current revision of D1002706, but the intention is clear -- 
HI Gain = analog gain ON, analog whitening OFF (FM4 OFF, FM5 ON)
LO Gain = analog gain OFF, analog whitening ON (FM4 ON, FM5 OFF)
Indeed -- that a "Gain of 10" and "No Whitening" is the "nominal" configuration is now written directly surrounding the circuit in the schematic D1002706.
Why? Because 
- having *no* whitening or additional gain (i.e. FM4 and FM5 ON, or an overall interface response of a flat gain of 2), you'll likely be buried in the ADC noise floor at all relevant frequencies, and
- having *both* whitening and additional gain (i.e. FM4 and FM5 OFF, or an overall interface response of low-frequency gain of 20 and high-frequency response of 100, with a z:p pair at 10:50 [Hz]) will likely saturate the ADC.

Further, this was solidified in a SEI team summit at the March 2011 meeting, notes were taken (see T1200373) that say the following:
"
FM4 - Switchable Readout Gain:
	- Gain of 10 (7) [113] (cancels fixed gain in FM1)
	- FM4 is ON when analog gain is OFF
	- FM4 is ON in "low gain" mode (analog x10 gain is OFF)
	- FM4 is hooked to analog gain via BIO, such that when FM4 is turned OFF, the analog gain is turned ON
	- Choose for analog switch to happen at zero crossing (a bit you can flag in the foton .txt file)
FM5 - Switchable Whitening (for GS13s only):
	- Filter matches analog whitening (cancels fixed dewhitening in FM1)
	- FM5 is ON when analog whitening is OFF
	- FM5 is OFF in "low gain" mode (analog whitening is ON)
	- FM5 is hooked to analog whitening via BIO, such that when FM5 is turned ON, the analog whitening is turned OFF
	- Choose for analog switch to happen at zero crossing (a bit you can flag in the foton .txt file)
"

Seems clear, right? Great. 

Here's the problem:

(1) The front end does not restrict the user from the ADC-noise-swamped state, lets call it "ultra-lo gain mode," of FM4 and FM5 ON (additional analog gain and whitening OFF) or the ADC saturating state, let's call is "ultra-high gain mode," of FM4 and FM5 ON (additional gain and whitening ON).

(2) The python command script used to switch between the modes is 
${userapps}/isi/common/scripts/sensor_hilo
and IT ONLY SWITCHES FM4. This (and the name "hi gain" and "low gain") has confused users who only use this command script into thinking that the difference between the two relevant states is *only* the x10 gain and FM4. 

This had resulted in chaos and confusion during LHO's period of revolving commissioners, and ingrained a long-standing, almost superstitious, confusion about what "low gain" and "high gain" states mean.

Thankfully, I think after 15 discussions on SEI calls, 20 individual-to-individual email chains, and some LLO spy sessions via remote log-in over the past few years, Jim and Hugh have settled on what Brian thought was right answer for GS13s back in 2010:
- All* HAMs are in high-gain mode (with FM4 OFF and FM5 ON, i.e. additional analog gain of 10 and no whitening.)
- All* BSCs are in high-gain mode ("")
Why do I have asterisks next to ALL in both cases that continue to add to the confusion? 
Because of blasts from lock-acquisition / lock-loss.

From experience with DRMI lock-acquisition, LLO has found that ISI BS ST2 GS13s saturate regularly if in (nominal, not ultra) hi-gain mode. If the GS13s are in the (nominal, not ultra) low gain configuration, they don't saturate. As such, for the ISI BS only, we use the nominal lo-gain mode.

For experience with the Fast Shutter closing and opening on HAM6, LLO has found that the ISI HAM6 GS13s saturate regularly even in the nominal lo-gain mode. Thus, we've changed the configuration of the HAM6 ISI to the ultra-low gain mode (FM4 and FM5 ON, no additional analog gain or whitening).

So here's my suggestions: 
- we rewrite the python script sensor_hilo to be a FOUR state system instead of a TWO state system, and make sure that FM5 gets toggled as well as FM4. 
- we use either GUARDIAN or the new SDF system to keep track of these FMs. If the chamber needs to switch gains after lock acquisition or lock loss, it should be controlled by guardian.
- we continue to measure the performance of all platforms to find out where we're ADC noise limited in all possible states of the GS13 interface. 
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 17:36, Tuesday 10 February 2015 (16612)
"Trust, but verify." Always!

Hugh has caught an error in the above description of the GS13 interface's state machine which didn't obey reality. Thankfully, he was able to confirm this with real data from HAM6 -- see LHO aLOG 16606. I've added the following [clarification of / correction to] the above to Hugh's entry, and I repeat it here for completeness:

- 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 HI (or a binary output of 1), so the analog whitening is engaged, and FM5 compensates the analog whitening of z:p = 10:50 [Hz] with a de-whitening z:p = 50:10 [Hz] filter. 
- When FM5 is OFF, the analog whitening is LO (or a binary output of 0), so the analog whitening is is OFF, and no FM5 means no compensation.
jeffrey.kissel@LIGO.ORG - 15:57, Wednesday 11 February 2015 (16663)
Here's a corrected drawing to indicate the state of the FMs in each HI and LO states.
Non-image files attached to this comment
H1 SEI
jeffrey.kissel@LIGO.ORG - posted 14:55, Tuesday 20 January 2015 - last comment - 11:21, Tuesday 03 February 2015(16164)
Reboot of SEI HAM23 Computer Does Not Clear 0.6 [Hz] Feature from HAM3
J. Kissel, J. Warner, D. Barker, E. Merilh, TJ Shaffer

The one final quiver in our arrow against the sharp HAM3 0.6 [Hz] resonant feature was a computer (as suggested e.g. here), so we did so this morning. Sadly, it did not cure the problem. For now, we continue on, running in the configuration defined by Seb last week, see LHO aLOG 16100, in which the RY blend filters at a higher blend configuration, which is the only thing we can find that seems to help (see LHO aLOG 16001). This has now officially become a low-priority until it begins to quantifiably impact IFO performance.

A Recap of all of the things we've tried that DIDN'T make the feature go away:
- Restarting the front-end process LHO aLOG 15759

- Full power-down of Front-end and I/O Chassis (This aLOG)

- Coil Driver Swap LHO aLOG 16071, LHO aLOG 16061, LHO aLOG 15981

- Changing Suspension Damping LHO aLOG 16013, LHO aLOG 16001

- Changing Isolation Loops LHO aLOG 16001

- Location of Sensor Correction; ISI vs HPI LHO aLOG 15941. LHO aLOG 15933

- Changing from STS2 B to A; In analog LHO aLOG 15811, In digital LHO aLOG 15927, LHO aLOG 15894

- Checking between ADC and sensor correction bank LHO aLOG 15783

- Turning OFF CPS satellite amplifiers, checking jumper settings (oscillators, jumpers, etc.) LHO aLOG 15751

- Adding a large mechanical offset to relieve supposed mechanical rubbing LHO aLOG 15751

- Waiting LHO aLOG 15565
Non-image files attached to this report
Comments related to this report
brian.lantz@LIGO.ORG - 11:21, Tuesday 03 February 2015 (16433)
I have entered an integration issue for this at
https://services.ligo-wa.caltech.edu/integrationissues/show_bug.cgi?id=1005
Displaying reports 67401-67420 of 83394.Go to page Start 3367 3368 3369 3370 3371 3372 3373 3374 3375 End