It looks like the injection actually does hit the 400 count limit (plot 1). It saturates right at the end when the injection chirps up to high frequency. There's some kind of ringing as well (plot 2). From the spectrogram (plot 3) and the zoom (plot 4) this looks like a feature at just above 300 Hz. I thought it might be a notch for the PCal line, but that's 331.9 Hz. So someone will have to check the inverse actuation filter and see what's happening at that frequency.

It's possible to see the overflow from the first injection in the ETMY L3 MASTER channel (plot 5). It happens at -131072 counts, and the injection is trying to push it past -200000. The blind injection caused an overflow as well, but since this channel is only recorded at 2048 Hz, it looks like it falls short of overflow (plot 6). There's a faster readback whose name escapes me at the moment.

Unless the blind injection is made a factor of about 10 smaller, or rolled off at high frequency, it will be trivial to detect it by looking at the drive to the ETM.

FYI, the injected waveform was fiducial waveform from ER7:

https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=16125

It's a 1.4-1.4 BNS at 45 Mpc, optimal orientation.

There are a couple of things to watch out for when performing CBC hardware injections, based on iLIGO experience:

• In iLIGO, the actuation function had a notch at the violin-mode frequencies. If you just invert A(f) without smoothing this out, the notch will get inverted and you'll give the the mirrors a hard kick as the inspiral sweeps through the notch frequency. (My guess is that Adam and Jeff have already dealt with this, though.)
•  If the end of the inspiral signal is not smoothly rolled off and the signal drops from some loudish amplitude to zero then you put a step function in. This caused the iLIGO test mass to swing at its pendulum frequency, putting a huge ringdown in the data (called the "whooper" in iLIGO). In iLIGO, the CBC group generated waveforms in counts, by applying 1/A(f) ourselves using the adiabatic inverse calibration, so we smoothed 1/A(f) ourselves before applying it. In aLIGO, 1/A(f) is: (i) more complicated, and (ii) applied in the front end by IIR filters. It is possible that the sharp turnoff of the CBC injection at the end is causing the filters that apply 1/A(f) to ring and that's what's giving us garbage at the end of the signal.

For the ER7 injection we used an SEOBNRv2 waveform that has a ringdown at the end, hoping that this turn off would not trigger an impulse. However, for BNS masses, the turn off and ringdown is pretty sharp. I've asked Chris check that there are no "whooper" effects with the SEOBNRv2 waveform, but we haven't had chance to do this yet. For a SpinTaylorT4 waveform (the other waveform CBC wants to inject), there will definitely be a step, so this needs to be checked and rolled off carefully.

One other comment on the test: what scaling in awgstream did you use? That waveform looks monstously loud (eyeball SNR > 20). That's much louder than would be useful for a blind injections, but good for helping us find whooper effects.

Duncan, the scale factor is 1.

Just for completeness, because I didn't see it posted, here's an Omega scan of the injections in h(t). The first is the non-blind injection, the second is the blind injection. I think the glitch ten seconds after the blind injection is unrelated. I thought it might be a filter turning off or being reset, but it's not on a GPS second (it's at 1124603210.28). It does cause an overflow of the ETMY ESD DAC.

I verified that the blind injection was correctly recorded in the raw frame file.

Evan deciphered the ODC screen that was apparently telling us that TCS was not observation ready.  We put a 0 in the   H1:ODC-MASTER_TCS_2_MASK, and this made the observation bit ready, so Ed has set the intent bit.  

I think this has uncovered a bug/issue:  There may be a problem with the connection between the TCS ODC and the ODC-MASTER models at LHO.  I'm debugging it now and will reply with what needs to be fixed.  

On a separate note:  I believe site leads (at least Fred) said that operators would be trained on how to read and use the ODC with the changes made in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20870 and Duncan M. and Stefan B. are the experts on site to teach people how to read this screen, but I'll walk through the way to read it for this example:

Evan correctly read off the bit that was preventing obs-ready from being green from the ODC MASTER overview screen.  To do this, you just trace across the row that you care about (OBS-READY) and find the red bit, then count across the top list of subsystems to find which subsystem that is coming from (I would appreciate it if anyone can show us how to turn those text boxes so we can align them with the columns better).  The next step would be to look down one step further by clicking on the TCS button to see that the 30th bit of the TCS ODC is the only bit that can affect the OBS-READY bit.  From the comment, this was done correctly as well, and you can read off the bitmask for the relevant row in the matrix on the right.   You can also see this by looking at the large black/green matrix to find the green bits that affect each row, which tell you which bits of the subsystem ODC are mapped to which row in ODC MASTER.  At this point, you will see that the whole TCS ODC at the top of that screen is red, however, which I believe is a bug somewhere in the FE code.  If it were behaving normally and you wanted to learn what the bits meant in the vector at the top:  The last step would be to click on the relevant subsystem from the ODC-SITE-OVERVIEW screen, and in this case you would learn that bit 30 is the Excitation bit, as expected.   

I have found the issue:  The h1odcmaster.mdl was locally edited and then committed to SVN on Aug. 18, as recorded in alog:  https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20622

This occured after we had circulated the new h1odcmaster.mdl that was used for alog: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20870.

Duncan M. is going to ensure that everything is up to date with the SVN, then re-implement the changes he made on Aug. 18 in a copy of h1odcmaster.mdl and then generate the ECR to fix the bug.

For the time being, I have set all the bitmasks of form H1:ODC-MASTER_TCS_XX_MASK to 0x0 so the bad connection cannot affect ODC-MASTER.

Ryan, this does not adequately explain the situation. Why does the bit mask in TCS affect READY? We were told that READY was just GRD-IFO_OK and NO EXC. How was it that TCS was somehow wired into that logic?

The SYS_DIAG node was removed this morning, so those channels will never exist.

There is now a DIAG_MAIN node, so new channels: H1:GRD-DIAG_MAIN...

Dave updated the guardian autoBurt files and I rescanned the channel list.

+ H1:GRD-DIAG_MAIN_LOGLEVEL
+ H1:GRD-DIAG_MAIN_MODE
+ H1:GRD-DIAG_MAIN_NOMINAL_S
+ H1:GRD-DIAG_MAIN_REQUEST
+ H1:GRD-DIAG_MAIN_REQUEST_S
+ H1:GRD-DIAG_MAIN_STATE_S
+ H1:GRD-DIAG_MAIN_STATUS
+ H1:GRD-DIAG_MAIN_TARGET_S
+ H1:GRD-SR3_CAGE_SERVO_LOGLEVEL
+ H1:GRD-SR3_CAGE_SERVO_MODE
+ H1:GRD-SR3_CAGE_SERVO_NOMINAL_S
+ H1:GRD-SR3_CAGE_SERVO_REQUEST
+ H1:GRD-SR3_CAGE_SERVO_REQUEST_S
+ H1:GRD-SR3_CAGE_SERVO_STATE_S
+ H1:GRD-SR3_CAGE_SERVO_STATUS
+ H1:GRD-SR3_CAGE_SERVO_TARGET_S
- H1:GRD-SYS_DIAG_LOGLEVEL
- H1:GRD-SYS_DIAG_MODE
- H1:GRD-SYS_DIAG_NOMINAL_S
- H1:GRD-SYS_DIAG_REQUEST
- H1:GRD-SYS_DIAG_REQUEST_S
- H1:GRD-SYS_DIAG_STATE_S
- H1:GRD-SYS_DIAG_STATUS
- H1:GRD-SYS_DIAG_TARGET_S
inserted 16 pv names
deleted 8 pv names

That almost always means there's a syntax error with the ISC_LOCK guardian node:

jameson.rollins@operator1:/opt/rtcds/userapps/release 130$ guardutil print ISC_LOCK
ifo: H1
name: ISC_LOCK
Traceback (most recent call last):
  File "/ligo/apps/linux-x86_64/guardian-1485/bin/guardutil", line 396, in <module>
    args.func(args)
  File "/ligo/apps/linux-x86_64/guardian-1485/bin/guardutil", line 34, in sprint
    cli.print_system(system)
  File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/cli.py", line 90, in print_system
    system.load()
  File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/system.py", line 403, in load
    module = self._load_module()
  File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/system.py", line 291, in _load_module
    self._module = self._import(self._modname)
  File "/ligo/apps/linux-x86_64/guardian-1485/lib/python2.7/site-packages/guardian/system.py", line 165, in _import
    module = _builtin__import__(name, globals, locals, fromlist, level)
  File "/opt/rtcds/userapps/release/isc/h1/guardian/ISC_LOCK.py", line 1339
    @nodes.checker().switch('SUS-PR2_M1_LOCK_P', 'INPUT', 'ON')
                    ^
SyntaxError: invalid syntax
jameson.rollins@operator1:/opt/rtcds/userapps/release 1$ 

The frequency response of OMC DCPDs (A and B) are checked using ASC-AS_C as a intensity noise monitor in the single bounce configuration. Even though the response of ASC-AS_C is not well known, the result shows an almost flat response as expected with a deviation of 6% at most which is encouraging.

In order to improve the accuracy of the measurement, we should prepare a well-calibrated photo detector, probably placed at ISCT6, and make the same comparison measurement with the OMC DCPDs.

Method:

The interferomter was in a single-bounce configuration where the beam bounces off of ITMX and goes to the AS port without any recycling. Also ETMs are misaligned as well in order to avoid flash from the arm cavities. The PSL power was intentionally set to the maximum in order to get the maximum signal to noise ratio everywhere. The OMC is locked to the carrier 00 mode with a OMC-LSC_GAIN of 20. I forgot the UGF of the OMC length loop, but it was on the order of 100 Hz, I believe. The OMC alignment was done by the QPD loops with a overall gain of 0.1. For some reason, I needed to engage DC centering loops for the AS WFS A and B, otherwise it would saturate the OMC suspension. The photo current on each OMC DCPD was about 17 mA, which is a bit too high compared with the nominal full lock photo current of 10 mA.

I injected swept sine signal to the ISS inner loop from 7 kHz to 10 Hz. Then I measured a relative response between ASC-AS_C segment 3 and two OMC DCPDs. One trick in doing this is that I had to use an IOP signal to measure the response of ASC-AS_C because the ASC front end runs at only 2 kHz. Also, since I used the IOP signal, I was not able to grab summed QPD signals, and that's why I ended up with one of the QPD segments. Segment 3 happened to receive the highest power and therefore I chose this for the final analysis.

The dtt file and its ascii formated data are checked into the SVN at

/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-24_omc_dcpd_and_asc_pd.xml

/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-24_asc_to_omc_dcpds_tfs.txt

/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-24_asc_to_omc_dcpds_coh.txt

Also the analysis code can be found in SVN at

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/analyze_asc_to_omc_dcpds.m

Results:

The result is shown in the attached pdf. It is relative gain (or transfer function) between OMC DCPDs and ASC-AS_C. The red dots are for DCPD A and blue for DCPD B. The following frequency responses are taken into account:

• OMC DCPD pre-amp high freq poles (13.7 kHz and 17.8 kHz) (alog 18008) 
• OMC DCPD pre-amp audio freq zpk (alog 17647) which are compensated in the OMC front end model.
• IOP down sampling filter (64 kHz -> 16 kHz)

Note that since AS_C is acquired at 64 kHz without any downsampling, I did not apply any digital low pass for it. Aside from these known parameters, I had to make some assumptions as follows.

• Analog antialiasing filters are the same between all the PDs and therefore they cancel when taking a ratio of any two PDs.
• ASC-AS_C has a built in whitening with zpk([0.39], [39.8; 79.6e3] ) according to D1001974.
• The response of ASC-AS_C is flat in frequency.

Obviously, the key points to success this method is to reduce the number of the assumptions, but this time I simply attempted with ASC-AS_C, which I had to make multiple assumptions, to get some idea of how the measurement would go.

As shown in the upper panel, the absolute magnitude is almost flat with a trend in which the DCPD response higher at high frequencies. The error bars are placed by using the usual coherence technique (see alog 10506). The low frequency part below 20 Hz is clearly limited by low coherence, but it seems to consistently show lower response at low frequencies. If we take a peak to peak of the variation, it is going to be roughly 1.04 / 0.94 ~ 10 %. Looking at the phase, shown in the lower panel, the phase seems to diverge as it goes to high frequencies such as AS_C response. I don't think it can be explained by mismatch in the analog anti-aliasing filters because they are usually well matched. At this point, we can not really say if the high frequency deviation is from the real DCPD response of some artifact from unidentified uncompensated AS_C response.