The DARM open loop consistently show a decrepancy between our DARM model at a few percent level. Inspecting the past four measurements (Aug-26, Aug-28, Aug-29 and Sep-08), I found that all of them show the same behavior. Something is wrong.

I have two hypothesis in my mind:

1. The way we measure the open loop is bad. For example, the excitation is too high and some part of the interferometer is not linearly responding or something.
2. Something is wrong in our analysis code. For example, some mistakes or tyops somewhere.

In either way, the residual is smaller than what we are trying to achieve in terms of the calibration accuracy.  So we will go ahead and update the CAL CS calibration filters to the latest without correcting this "DARM open loop descrepancy".

Attached:

The 1st four pdfs are the sensing function or DARM response measured by Pcal Y from different days. As shown, the residula looks typicaly residual.

The 2nd four pdfs are DARM  open loop measurements. All of them shows similar behavior in the residuals

Some notes:

Additionally, I edited H1DARMOLGTFmodel_ER8.m so that it takes the mismatch in the whitening filters into account. This is something Darkhan tried but did not get a chance to complete (alog 21318). Now it is coded.

Betsy, Hugh

There are some channels which we have identified with SDF that change between lock stretches and should therefore be not monitored.  So far, Hugh and I have set the foolwing to not be monitored:

- SR3 CAGE SERVO OFFSET -SR3_M2_TEST_P_OFFSET)

- BSC ISI CPS SETPOINTS_NOW

- IMC PZT P/Y OFFSETS

- LSC PSL-POWER_SCALE_OFFSET

- ALS CAMERA SERVO SETTINGS (ALS_CAM)

- PSL-ISS_REFSIGNAL and PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA

We have not set the alignment sliders to be NOT MONitored so be prepared to set those tonight as needed:

ALL SUS OPTICALIGN P/Y OFFSETS

Again, if you run into problems with red alarms on any SDF screen that is blocking you from hitting the Intent bit, please 1) check with your commissioners to clear any temporary changes and then 2) set the outstanding channels to NOT MON and we will audit them tomorrow when we continue on this work.

ER8 Day 24. No restarts reported.

We are currently not locked while a few measurements are being run and while there is hammer drilling going on on the beam tube enclosures. The plan is to proceed back to locking in a few hours.

The 3 SSD drives that failed yesterday for the Raid on h1tw0 had been replaced. Jim will work on mount process for minute trend.

Sheila, Evan

Since we have recently gotten rid of the excess oscillator AM noise in DARM, we wanted to look at the residual of the DCPD sum and null. This test has been done at LLO several times (most recently here).

Unlike the previous look at this noise, we decided to follow the LLO technique and notch the DARM loop by 20 dB between 100 Hz and 700 Hz. In order to do this, we had to reduce the DARM ugf to 20 Hz or so. Unfortunately, this rang up the quad bounce modes. Rather than recommission the bounce mode damping, we just turned it off and collected the sum/null data in a few 20-minute intervals, and then applied damping inbetween using the usual DARM loop shape. In total we collected a little over an hour's worth of data, with the usual 20 mA of current on the sum. The attached plot shows the data processed into 1-second ASDs.

The dc current of the sum was 20.0 mA, meaning we expect a shot noise of 8.00×10−8 mA/Hz^1/2. On the other hand, the ratio of sum/shot and null/shot (attached) indicates that we might be too low by a few percent. It's a bit complicated, since it relies on a combination of the frontend calibration (Koji's preamp and whitening compensation filters) and a post facto calibration (Kiwamu's combination of the IOP inversion, the supernyquist preamp poles, the AA response, and the mystery 10.7 kHz pole).

New ion pump OK

As a periodic evaluation of condition, we'll be trending the Pump Station Pressures to watch for changes in the Pump Performance.

The attached plots show the pressure trends from the pump stations at the three buildings for the past 30 days.

There are no obvious steps indicating a pump stating cavitation--I don't really expect this out of the blue.  But if the system is taken down (Pump spun down) for any reason and then brought up, that is when cavitation has occurred and the pump pressures change.  This will be obvious for the corner station as the other pumps will compensate for the cavitating pump.  Hmmm, if this happens at an end station though...I expect the VFD output will have to increase to make up for this if if can.  I've only seen this at the corner so...   Anyway, I include the VFD output for the ends to look for this.

Observations:

Corner Station:  Bizarrely, the first pressure out of the Pumps all show almost perfectly flat tends--look at the scales; I can't explain this.  All the other pressures show a somewhat regular glitch up; this may be dailyish but seem a bit irregular.

EndY: Nothing new here.  Pressure and VFD output steady.  The long documented daily and weekly glitches still present and the daily temperature swings evident on the VOUT.

EndX: Same story except there is no regular glitches and the building must insulate things from the temperature fluctuation as there is no daily signal in the VOUT.

LLO still down, and Kyle needs to unplug the aux cart down at EX.

While LLO is down, the cleaning crew needs to use the roll up door and head into the garb room breifly. Should be right back in as soon as they're done.

After the earth settled back down, I had no trouble relocking the IFO.  The OMC issue persists but our range has been stable.  I also had to clear SDF again after relocking, but I imagine this will be resolved when the transition to the Observe.snap state is completed.

12:49 locked in Observing Mode.

8:08 locked Low Noise

8:36 set to Observing after clearing a bunch of SDF diffs (Betsy had told me to set them to Not Monitored since they are still in the process of creating the observe.snap). Sheila helped clear some that couldn't be Not Monitored due to the 'too many decimal places' issue.

9:30 I noticed that the OMC had a red CFC block on the CDS overview.  The overflow was incrementing rapidly.  I tried to reset it anyways, but to no avail.  I then tried calling several people, none answered.  Finally I called Corey to let him know about the situation.  Eventually, I got a couple of calls back suggesting that I let it ride since we were already in Observing.  Looking at a few trends, I saw that this began during the locking sequence.  Perhaps the CDS overview had a red block in it, but I failed to notice (at least it didn't prevent me from going to Observing). 

10:30 lockloss due to 5.9 EQ in Alaska.

During the ~2.5 hours lock stretch, our range has been steadily trending downward, perhaps related to the OMC issue (?).

One possible cause of the DAC overflows we've been seeing (the ETMY saturation warnings) is something at high frequency using up the range of the drive. We only record the last output to the ESD DAC at 2048 Hz, so we don't see anything happening above a kHz. It's possible some high frequency line or feature bumps up against 2^17 counts and that makes the DAC overflow, which then causes a much larger glitch - once there's an overflow the whole thing will go crazy.

To try to investigate this, the simplest thing to do is to record a channel like SUS-ETMY_L3_MASTER_OUT_LL_DQ at the highest rate possible, or something equivalent that monitors the actual signal sent to the ESD DAC. Once an ETMY overflow happens, save the data for several seconds around the time somewhere that people offsite can access it, preferably in a common format like ASCII or frames. Some time without an overflow would be good for comparison. Then we can see if there's something using up the drive range, or if it's just something sudden from somewhere else in the DARM loop. A few instances of overflows would be nice.

If this is not possible, there's another tack we can take but it's more involved, so I'd prefer this.

Dan, Daniel, Evan

Summary

The addition of a 9.1 MHz bandpass on the OCXO output has removed the broadband excess noise between DCPD sum and null. The dashed lines in the figure show the sum and the null as they were three days ago (2015-08-31 7:00:00 Z), while the solid lines show the sum and the null after the filter was inserted.

Details and review

Since at least June (probably longer), we've had a broadband excess noise between the sum and null DCPD streams. Stefan et al. identified this as 45.5 MHz oscillator noise a few weeks ago (20182).

In parallel, we switched the 9 MHz generation from an IFR to the OCXO (19648), and we installed Daniel's RFAM driver / active suppression circuit (20392), but the excess noise remained (20403). For a while we suspected that this was 45.5 MHz phase noise (and hence not supressed by the RFAM stabilization), but the shape and magnitude of the oscillator phase noise coupling (20783) were not enough to explain the observed noise in the DCPDs, under the assumption that the OCXO phase noise is flat at high frequencies (20582). For that matter, the shape and magnitude of the oscillator amplitude noise coupling were also not enough to explain the observed noise in the DCPDs, assuming a linear coupling from the RFAM (as sensed by the EOM driver's OOL detector) (20559).

Daniel et al. looked at the 45.5 MHz spectrum directly out of the harmonic generator in CER, and found that most of the noise is actually offset from the 45.5 MHz carrier by 1 MHz or so (20930), which is above the bandwidth of the RFAM suppression circuit. This suggested that the noise we were seeing in the DCPDs could be downconvered from several megahertz into the audio band.

Yesterday there was a flurry of work by Keita, Fil, Rich, et al. to find the source of this excess noise on the 45.5 MHz (21094 et seq.). Eventually we found circumstantial evidence that this excess noise was caused by baseband noise out of the 9.1 MHz OCXO.

Tonight we installed a 9.1 MHz bandpass filter on the OCXO output. This has removed the huge 1 MHz sidebands on the 45.5 MHz signal, and it also seems to have greatly lowered the coherence between DCPD A and DCPD B above a few hundred hertz.

Loose ends

The chain from OCXO to filter to distribution amplifier currently involves some BNC, since we could not find the right combination of threaded connectors to connect the filter to the amplifier. This should be rectified.

Also, it appears that our sum is lower than our null in a few places (400 Hz in particular), which deserves some investigation.