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 (?).
As far as the overflows are concerned, A1 and A2 overflow in OMC is OK as the only channels in A1 and A2 used by OMC are the ones used for acquisition/transition.
If you look at H1OMC_GDS_TP screen, there are four potential source of overflow, A0, A1, A2 and D0 representing ADC card 0, 1, 2, and DAC card 0. In the attached, you can see that ADC2 is overflowing.
If you press "A2" button, you'll see that the channel overflowing is C_DIFF_PLL_CTRL_INMON (second attachment), and that this channel is the only one in ADC2 that is used by the OMC frontend.
This channel is only used before RF lock and always rails after full lock. It's safe to ignore this in observation mode as the channel is not used in full lock.
Likewise, if A1 overflows in observation mode, that's fine as the channels in ADC1 used by OMC (ASAIR_A_RF45_I and Q) are only used before DC lock.
If A0 or D0 was constantly overflowing, that would have been a concern.
To follow up, here's Kiwamu's email regarding the outstanding OMC filter file that was modified last night causing additional confusion and his clearing of it this morning:
"I loaded the coefficients. The CFC bit is now back to green.
$ diff filter_archive/h1omc/H1OMC_1125809279.txt H1OMC.txt
173a174,175
> # DESIGN LSC_OMC_DC 3 zpk([1],[2.5],1,"n")gain(0.4)
> # DESIGN LSC_OMC_DC 4 zpk([2.5],[5],1,"n")gain(0.5)
180a183,184
> LSC_OMC_DC 3 12 1 49152 0 1:2.5:ac 0.9997125807026548 -0.9990417213032660 0.0000000000000000 -0.9996165783185160 0.0000000000000000
> LSC_OMC_DC 4 12 1 49152 0 2.5:5:ac 0.9995213195808776 -0.9980843600250285 0.0000000000000000 -0.9990417213032660 0.0000000000000000
kiwamu"
Upon some closer inspection, I'm not totally convinced that the lockloss at 10:30:46 UTC was due to the earthquake.
Attached is a plot for a single seismometer (located at End-X), but all 5 STS-2s that are mounted on the floor look the same. The top row is x-axis data, the middle row is y-axis and the bottom row is z. The columns from left to right are in increasing order of BLRMS bands. The lockloss is at about 0 seconds (actually -0.9ish), and the plots are 10 minutes of data, centered around the lockloss. We don't see the earthquake until about 150 seconds after the lockloss. This is consistent with the anticipated P-phase arrival time from Terramon - 10:33:12 UTC, but much earlier than the S-phase time (10:38:25 UTC) or the R-phase time (10:43:56 UTC).
I don't know yet what did cause the lockloss, but I don't think it was the Alaskan earthquake.