Added a gain change for ASAIR_B_RF18, ASAIR_B_RF90, ASAIR_B_LF and  ASAIR_A_LF when the AS port beam diverted closes (it has 10% residual through beam).

            # Set the ASAIR PD gains for BDIV open
            ezca['LSC-ASAIR_B_RF18_I_GAIN'] = 18
            ezca['LSC-ASAIR_B_RF18_Q_GAIN'] = 18
            ezca['LSC-ASAIR_B_RF90_I_GAIN'] = 18
            ezca['LSC-ASAIR_B_RF90_Q_GAIN'] = 18
            ezca['LSC-ASAIR_A_LF_GAIN'] = 11
            ezca['LSC-ASAIR_B_LF_GAIN'] = 11


Curiously, the DC gains scale differently than the RF channels...

More Whitening Filter changes to reduce the pole frequency and thus high frequency distortion (LHO alog 20393).

CAL-CS_DARM_DELTAL_RESIDUAL:  zpk ([1 1],[500,500],1)

                  changed to zpk ([0.1 0.1],[100,100],1)

CAL-DARM_ERR zpk ([10 10],[100,1000],1)

                  changed to zpk ([1 1],[200,200],1)

CAL-DARM_CTRL : zpk ([5 5],[500,500],1)

                  changed to zpk ([1 1],[200,200],1)

Attached plot shows the signal with old filter and the new filter for comparison.

- Set the nominal ODC threshold values for all SUS, LSC, ASC, TCS and OMC during the morning lock.
- Updated SDF with those settings.
- Note that TCS got disconnected yesterday, so ODC_MASTER settings related to TCS are not SDF'ed yet.
- Updated all ODC screens to show all relevant bits.
- Added the intent bit button to the ODC master screen (it is also available on the Guardian screen).

With that almost all indicator are green in full lock. The exceptions are:
- ADC saturation:
  - Unfortunately many models have an ADC channel that by design saturates, i.e. the CDS bit delivered to ODC for those models is always lo.
  - On top of that some models (like e.g. ASC) report a saturation, even though n channel seems to be saturation. Dave Barker has noticed that before...
- DAC saturation: TCS currently reports a DAC saturation - not sure why.
- LSC and ASC report a incorrect parity bit (that's an ODC internal issue)

To show the calibration group how to analyze duotone, I looked at the IOP channel for the duotone input of the first LSC ADC card (the same card that is used for OMC DCPD).

Nothing is automated yet (that's for Sudarshan), I just used dtt to access 64kHz IOP channel, took 2 sec of time series, exported it to text, and used matlab to analyze.

According to my script the delay is 7.3us (i.e. the duotone second boundary is 7.3us behind the digital world second boundary).

The medm screen for each IOP has a simpler duotone timing monitor and it is reporting 5us delay instead of 7 (see attached). I don't know where that descrepancy comes from. I know that the number the medm screen is reporting comes from a simple zero-crossing calculation at around the second boundary, but even when you look at the zero-crossing, it looks more like 7us than 5 (second attachment).

Tomorrow we'll do the loopback duotone test for pcal and ETM SUS.

Evan Stefan Daniel

The second EOM driver was installed in the CER using the 9MHz control and readback channels. The first attached plot shows the DAQ readback signals. Both drivers show the similar noise levels for the in-loop and out-of-loop sensors. They are also coherent with each other as well as ASC-AS_C! The in-loop noise is clearly below which would indicate that the signal is suppressed to the sensor noise. The measured out-of-loop noise level is also a factor of 4 higher than the setup in the shop.

The second plot shows the same traces but this time the ifr is feeding the EOM driver in the CER. As expected its out-of-loop noise level is now consistent with measurements in the shop and no longer coherent with the unit in the PSL.

We were starting to suspect that we are looking at down-converted out-of-band noise...

Although the error reporting is not detailed enough yet on the production server to provide the channel name and value that caused an error upon attempting to insert it into the MySQL database, it is on the test system. The following channels and values caused errors on the test system:

Jul 11 16:59:40 H1:OMC-READOUT_ERR_GAIN: -nan
Aug  4 07:54:43 H1:SYS-MOTION_C_PICO_F_MOTOR_1_NAME: 'xF3x01'
Aug  8 12:25:47 H1:OMC-READOUT_ERR_GAIN: -nan

LVEA: Laser Hazard
IFO: Locked
Observation Bit: Undisturbed    

All Times in UTC (PT)

15:00 (08:00) Take over from Ed
15:00 (08:00) IFO locked at NOMINAL_LOW_NOISE, 68Mpc
15:38 (08:38) Switch to commissioning/calibration mode for commissioners
16:15 (09:15) Alarm on Instrument air MR-PT199 – Left message for Kyle & spoke to Bubba
16:25 (09:25) Bubba – Check into alarm with PT0199
16:30 (09:30) Lockloss – Due to commissioning – Put IOF in DOWN per commissioner request
17:19 (10:19) Kyle – Going to X2-8 near End-X for vacuum work
17:59 (10:59) Filiberto – Going to Mid-Y to get parts for PEM work
18:00 (11:00) IFO locked at NOMINAL_LOW_NOISE, 65Mpc
18:17 (11:17) Filiberto – Back from Mid-Y
19:26 (12:26) Fire Protection Specialist – On site working on alarm system in VPW
19:32 (12:32) Filiberto – Going into CER looking for tools
19:38 (12:38) Kyle – Leaving X2-8 going to Y2-8 on the Y-Arm
21:44 (14:44) Lockloss – Commissioners looking into cause
22:10 (15:10) IFO Locked at NOMINAL_LOW_NOISE, 65Mps 
22:19 (15:19) Lockloss – Calibration activities
22:32 (15:32) Lockloss – Possibly due to Earthquake

 
Shift Summary & Observations:

   Took over from Ed at 15:00 (08:00). IFO locked with good range. LLO down. 
   Commissioners have started working on calibration.
   IFO was stable during the day. After first lock loss the IFO relocked at NOMINAL_LOW_NOISE in 34 minutes. 
   21:56 (14:56) 5.2 Mag EQ at N. Mid-Atlantic Ridge R-Wave arrival ~22:28 (15:28)  

We are testing out a DMT to EPICS bridge that is able to translate DMT data to EPICS data real time.

The channel names are subject to change (comments should be directed to Dave Barker, not the alog).  Currently they are not being recorded in the frames.  There should be a discussion regarding whether or not it is a good idea to put another copy of the range in the frame with a different name and a slight time offset due to being captured from EPICS.

Current channels:

• H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC
  • This is the inspiral range as displayed in the DMT viewer in the LHO control room.
• H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC_GPS
  • The GPS time associated with the data in the range channel.

Please remember that the range is a really a minute trend, and that it is visible at some point within a minute of it being generated, see the _GPS channel for the time it refers to.

There are a few other approaches we can take to getting DMT data into the control room faster than the frames appear, so if this does not work out there are some other avenues open to exploration.

Keita updated the ASC model to come inline with LLO channels they are using.  The OM3_PIT1 & YAW1 FM channels changed to just OM3_PIT & YAW.

These changes caused the SDF overview to go yellow for ASC as there were now channels not found and channels not initialized.

Removed these lines from the safe.snap to clear the channels not found:

+H1:ASC-OM3_PIT_GAIN 1 0.000000000000000e+00 1
+H1:ASC-OM3_PIT_LIMIT 1 0.000000000000000e+00 1
+H1:ASC-OM3_PIT_OFFSET 1 0.000000000000000e+00 1
+H1:ASC-OM3_PIT_SW1S 1 0.000000000000000e+00 1
+H1:ASC-OM3_PIT_SW2S 1 5.120000000000000e+02 1
+H1:ASC-OM3_PIT_TRAMP 1 0.000000000000000e+00 1
+H1:ASC-OM3_YAW_GAIN 1 0.000000000000000e+00 1
+H1:ASC-OM3_YAW_LIMIT 1 0.000000000000000e+00 1
+H1:ASC-OM3_YAW_OFFSET 1 0.000000000000000e+00 1
+H1:ASC-OM3_YAW_SW1S 1 0.000000000000000e+00 1
+H1:ASC-OM3_YAW_SW2S 1 5.120000000000000e+02 1
+H1:ASC-OM3_YAW_TRAMP 1 0.000000000000000e+00 1
 

The new channels are not used at LHO but the path came up with the gain of 1 and the IN and OUT of the FMs engaged.  There is no medm for these FMs so I set the gains and filters to 0 and OFF with CAPUT and EZCASWITCH.  Will this be an ODC issue?

See the attachment for the list of new channels and their current values.  Snap committed.

ECR 1500312, WP 5455

A new frame writer, h1fw2, has been added to the DAQ system for H1.  It is currently writing science and commissioning frames to it's local file system to allow comparison with existing frame writers.  

This frame writer is an Ubuntu 12.04 based system, with a daqd compiled from advLigoRTS/trunk rev 4057. The computer is a new dual 10 core CPU computer with 132G of RAM.  The ultimate goal is to see if this configuration can be used to replace the existing frame writers.

At this point, h1fw2 should have no impact on the DAQ system unless there is an effect on the data concentrator (h1dc0). We don't anticipate any effect, this configuration has been running at Livingston for at least a week.

After some email communication with Keith Thorne and Elli, I've added limits at 32,500 to the channels L1:TCS-ITMX_CO2_CHILLER_OUT_GAIN_OUT and its y-arm sibling.  This has also been done at LLO.

These channels have a static output on them, and are used to set the chiller temperature for the TCS CO2 lasers.  The value is not changed, and will not be at all affected by the limit being put in place. 

[Sheila, Dan, Evan, Jenne, others]

All afternoon (basically, since we started relocking after maintenence day) we have seen a 1 Hz comb (offset by 0.5 Hz) in the DARM spectrum, as well as in many, many other places.  This seems like the same thing as the final bullet point that was reported in aLog 20790 a few days ago, but with much taller peaks.

Much of the day was spent looking into this, by several people.  The lines are very clear in all of the length error signals, as well as the ASC error signals. 

One thing that we tried, just to exonerate it, was swap the PRC length actuation from the PRM to PR2, and then turn off the PRM M3 coil driver.  As expected, PR2 affects the cavity length twice as much as the PRM, so we needed a gain of 0.5 in the M3 LOCK filter bank for PR2, rather than the 1 that PRM has.  We were able to turn off the PRM M3 coil driver, but saw no change in the length signals' spectra.  We put the actuation back on PRM, but when we tried to turn off the PR2 coil driver, PR2 tripped and we lost lock.  So, the new PRM coil driver is certainly not to blame for this new noise.  (PR2 was untripped, and its coil driver turned back on)  Also, we haven't seen the glitches due to the old PRM coil driver at all today, so hopefully they're gone for good, and not just hidden.

At Richard's suggestion, we tried restarting the models that were restarted earlier today in case it is some kind of synchronization problem.  We restarted h1prm, h1pr2, h1lsc, h1asc.  This didn't change anything - the lines are still there loud and clear after relocking. 

The 1 Hz comb is still present, and we are running low on ideas for what it could be, and what to do about it.  DetChar friends, and anyone with ideas, please let us know if you have a suggestion of where to look.

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

I don't know if this has the same cause as the 1Hz comb, but there are also some unusually large lines at ~838 Hz and ~855 Hz.  These lines are a few Hz wide, and are coherent with magnetometer signals.  But, the magnetometers have seen these lines at the same (or larger) amplitude, in the past, without seeing the lines in DARM.  Why would the coupling from magnetic fields have changed so drastically??

Patrick, Sheila, Jenne, Eric

For the first part of the test, we injected our fiducial CBC waveform (same one used in ER7) and tried raising the LIMIT value on the hardware injection block in order to address saturation problems observed in ER7. During ER7, the LIMIT was 200. We raised it to 400. The first injection did not go through:

1124601535 1 1.000000 cbctest_1117582888_		intent bit off, injection canceled

Patrick, Sheila, and Jenne tried to turn on the intent bit, but there was some sort of problem, which will be alog'ged separately. As a temporary work-around, we turned off the tinj intent-bit check and injected again:

1124602724 1 1.000000 cbctest_1117582888_		successful

Patrick determined that the injection produced a maximum |amplitude| of 15 counts coming out of the injection block, which seemed to indicate that the original LIMIT value of 200 was sufficient. However, an alarm went off to indicate that there was saturation at ETMY. Thus, the saturation problem cannot be solved by tinkering with the INJ block in MEDM. Rather, the problem is occurring downstream on the ETM actuators. We request that Jeff K, Adam M, et al. look into options for avoiding saturation at the ETMs.

Next we tried a blind injection using the new blind injection code. The blind injection code does not log injections in EPICS so they are not automatically picked up in the segment database.

1124603111 1 1.000000 cbctest_1117582888_		successful

The blind injection was clearly visible. The ETM saturation warning went off again. The injection was logged correctly in the blind injection blindinj_H1.log:

current time = 1124603049...
Attempting: awgstream H1:CAL-INJ_BLIND_EXC 16384 /ligo/home/eric.thrane/O1/Hardw
areInjection/Details/Inspiral/H1/cbctest_1117582888_H1.out 1 1124603111
Injection successful.

All of these injections were carried out with scale factor = 1; (that's the 1.000000). The injection file, described in a comment below, is a 1.4 on 1.4 BNS, optimal orientation, at D=45 Mpc. It is the same waveform used in previous ER tests.

Since LLO had been down in this afternoon, I took this oportunity to renew the dtt templates that are for measuring the transfer function of each stage of ETMY. I tuned the envelop parameters while the interferometer was locked at 23 W in the NOMINAL_LOW_NOISE state. The attached are the resultant templates. The frequency range is newly adjusted to [10 200] Hz with 21 frequency data points as planned. Each one takes several minutes to complete the measurement. According to the results I got, we can get a quite good coherence for all the relevant stages (i.e. L1, L2 and L3 stages) at all the frequency points with a coherence of more than 0.99. On the other hand, the template for measuring the DARM closed loop in this particular frequency band may need a bit more tuning because the coherence was not as great as the ones for the ETMY transfer functions.