Attached stdout of command line.

Neat! looks good.

Hi Chris,
It looks like there is a 1s offset between the times you report and the rough coalescence time of the signal. Do you know if it is exactly 1s difference?

Yes, as John said, all of the end times of the waveforms are just about 1 second later that what's in the original post.

I ran a version my simple bandpass-filtered overlay script for these waveforms.  Filtering both the model (strain waveform injected into the system) and the data from 70-260 Hz, it overlays them, and also does a crude (non-optimal) matched filter to estimate the relative amplitude and time offset.  The four plots attached are for the four injected signals; note that the first one was injected with a scale factor of 0.5 and is not "reconstructed" by my code very accurately.  The others actually look rather good, with reasonably consistent amplitudes and time delays.  Note that the sign of the signal came out correctly!

I ran the daily BBH search with the injected template on the last two injections (1127075235 and 1127075742).

For 1127075235; the recovered end time was 1127075235.986, the SNR was 20.42, the chi-squared was 29.17, and the newSNR was 19.19.
For 1127075242; the recovered end time was 1127075242.986, the SNR was 20.04, the chi-squared was 35.07, and the newSNR was 19.19.

KW sees all the injections with the +1 sec delay, some of them in multiple frequency bands.
From 
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074624-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127074752-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075200-64.trg
  /gds-h1/dmt/triggers/H-KW_RHOFT/H-KW_RHOFT-11270/H-KW_RHOFT-1127075712-64.trg

    tcent         fcent significance channel
1127074640.979948   146    26.34      H1_GDS-CALIB_STRAIN_32_2048
1127074774.015977   119    41.17      H1_GDS-CALIB_STRAIN_8_128
1127074773.978134   165   104.42      H1_GDS-CALIB_STRAIN_32_2048
1127075235.980545   199   136.82      H1_GDS-CALIB_STRAIN_32_2048
1127075743.018279   102    74.87      H1_GDS-CALIB_STRAIN_8_128
1127075742.982020   162   113.65      H1_GDS-CALIB_STRAIN_32_2048

Omicron also sees them with the same delay
From :
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074621-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127074771-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075221-30.xml
  /home/reed.essick/Omicron/test/triggers/H-11270/H1:GDS-CALIB_STRAIN/H1-GDS_CALIB_STRAIN_Omicron-1127075731-30.xml

    peak time          fcent      snr
1127074640.977539062  88.77163  6.3716
1127074773.983397960 648.78342 11.41002  <- surprisingly high fcent, could be due to clustering
1127075235.981445074 181.39816 13.09279
1127075742.983397960 181.39816 12.39437

LIB single-IFO jobs also found all the events. Post-proc pages can be found here:

 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074640.98-0/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127074773.98-1/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075235.98-2/H1L1/H1/posplots.html
 https://ldas-jobs.ligo.caltech.edu/~reed.essick/O1/2015_09_23-HWINJ/1127075742.98-3/H1L1/H1/posplots.html

all runs appear to have reasonable posteriors.

Here is how Omicron detects these injections:

https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074641/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127074774/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075236/
https://ldas-jobs.ligo-wa.caltech.edu/~frobinet/scans/hd/1127075743/

Here are the parameters measured by Omicron (loudest tile):
1127074640: t=1127074640.981, f=119.9 Hz, SNR=6.7
1127074773: t=1127074773.981, f=135.3 Hz, SNR=11.8
1127075235: t=1127075235.981, f=114.9 Hz, SNR=12.8
1127075742: t=1127075742.981, f=135.3 Hz, SNR=12.4

The BayesWave single IFO (glitch only) analysis recovers these injections with the following SNRs:
4640: 8.65535
4773: 19.2185
5253: 20.5258
5742: 20.1666
The results are posted here:
https://ldas-jobs.ligo.caltech.edu/~meg.millhouse/O1/CBC_hwinj/

General Question:  Does this knock us out of Observation Mode?  Could I have reset this this morning?

IFO was in Commissioniing.

No, the DIAG_MAIN guardian node is NOT under the OBSERVATION READY check.  It can be changed/reset/etc. without affecting OBSERVATION MODE.

I think Cheryl was talking about the diag reset button on the GDS overview screen for the front end, not the DIAG_MAIN guardian.

Intent mode was turned off before tests.

Noticed there is a RED Timing error for H1SUSETMX.  Would like to hit Diag_Reset to see if this clears this error, but I'm not sure if this knocks us out of Observation Mode.  Will hold off.

I brought up this question on my last shift and I believe the answer was that it's inconsequential to reset this bit while Observing except that subsequential errors may be happening during the period that it's RED and we won't know about them/be able to see them in the trend. I took a trend last week at the beginning of one of my shifts and found this error had only happened ~ 1/week. So as far as I can tell you, it's ok to reset this error,  but it would be nice to get this blessing from the CDS crew. 

This is actually FM2.

I was texting with Mike to see if taking H1 out of Observation Mode (when L1 is down) for this test was OK by him, and he concurred.  This work is referenced by Work Permit #5505.  In the work permit, I see a time of 9/21-25 for Period of Activity.  So Operators can allow this activity during this time since Mike has signed off on the work permit.  (perhaps in the future, we can reference the work permit in alog entries so Operators will know this is an acceptable activity.)

I'm not totally sure about when to make the decision to preemptively turn ON this filter if we get a warning of an impending EQ.  It's not totally clear to know which types of EQ will knock us out and which won't.  I guess I can look to see if (1) Terramon gives us a RED warning, and also (2) watch 0.03-0.1um/s seismic signal for an order of magnitude increase.  Perhaps in that case I could then end Observation Mode and turn ON the filter and stay out of Observation Mode until L1 comes back.  (sorry, just trying to come up with a plan of attack in case L1 drops out)

As it stands, L1 has been locked for 10hrs, so we'll keep an eye on them.  I asked William to contact me if they drop out (but I'll also watch the FOM & GWI.stat.

I believe that by switching this, while in 'Undisturbed', it will show as an SDF diff thereby automatically taking us to 'Commissioning' mode until the diff is accepted, the ODC Intent ready bit is Green(again) and we can once again click the intent bit to 'Undisturbed'. I asked this at the JRPC meeting yesterday.

Apologies for the wrong FM number, and in the future I'll try to rememver to put the WP number in the alog.   Operators can probably stop toggling this filter for now.  We will put this on the list of minor changes that we will make on maintence day, so that next tuesday it can be added to the guardian and the observe.snap, along with some HSTS bounce and roll notches. 

There was apparently some confusion about pausing mechanisms; see alog 21822.  If the scheme referred to there is restored, the PAUSE and ENABLE features will be fully under the control of the operators.  Independently, injections will automatically be paused by the action of the GRB alert code setting the CAL-INJ_EXTTRIG_ALERT_TIME channel.  I have emailed Duncan to try to sort this out.

Last night there were two GRB alerts that paused the injections, and they DID NOT enable Tinj. The Tinj Control went back to Disabled as we had it set to previously. This is good and works as outlined in the HWInjBookkeeping wiki (Thank you Peter Shawhan!). This was my main worry and seems that has already taken care of. It is a bit misleading when the Tinj control goes from Disabled --> Paused and begins to count up to the "Pause Until" time, but after trending the channels it shows that will not enable the Tinj after the times meet.

Appears to be a standard NDS2 burp:

2015-09-21T22:57:59.11305   File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/worker.py", line 459, in run
2015-09-21T22:57:59.11306     retval = statefunc()
2015-09-21T22:57:59.11306   File "/opt/rtcds/userapps/release/sys/common/guardian/SYS_DIAG.py", line 178, in run
2015-09-21T22:57:59.11307     return SYSDIAG.run_all()
2015-09-21T22:57:59.11307   File "/opt/rtcds/userapps/release/sys/common/guardian/SYS_DIAG.py", line 151, in run_all
2015-09-21T22:57:59.11308     ret &= self.run(name)
2015-09-21T22:57:59.11308   File "/opt/rtcds/userapps/release/sys/common/guardian/SYS_DIAG.py", line 136, in run
2015-09-21T22:57:59.11310     for msg in self[name](**kwargs):
2015-09-21T22:57:59.11311   File "/opt/rtcds/userapps/release/sys/h1/guardian/DIAG_MAIN.py", line 66, in PSL_ISS
2015-09-21T22:57:59.11311     diff_pwr = avg(-10, 'PSL-ISS_DIFFRACTION_AVG')
2015-09-21T22:57:59.11312   File "/ligo/apps/linux-x86_64/cdsutils-497/lib/python2.7/site-packages/cdsutils/avg.py", line 67, in avg
2015-09-21T22:57:59.11312     for buf in conn.iterate(*args):
2015-09-21T22:57:59.11313 RuntimeError: Requested data were not found.

Reloaded.

Having the guardian go into error because of an NDS2 hiccough is kind of irritating.

Based on this StackExchange answer, I added the following handler function to the DIAG MAIN guardian:

def try_avg(*args):
    while True:
        try:
            q = avg(*args)
        except RuntimeError:
            log('Encountered runtime error while trying to average {}'.format(args[1]))
            continue
        break
    return q

where avg is the cdsutils.avg function.

This is now used for the ISS diffraction and the ESD railing diag tests. If we like it, we should consider propagating it to the rest of the guardian.

This is a fine hack solution for this one case, but please don't propogate this around to all guardian NDS calls.  Let me come up with a way to better handle it within the guardian infrastructure, so we don't end up with a lot of cruft in the guardian user code.