HWS code stopped during the weekend because the disk ran out of space. I deleted some of the old data and the scripts are running again. I'm working on a script that will delete old data automatically.
Status / Work Permit review
SEI - nothing to report. Tues plans to examine the IMTY coild driver
SUS - No report
CDS - (for Tues)ITMY SEI coil driver investigation/ITM cameras. May restart baffle PD boxes
PSL - ongoing chiller flow sensor errors causing laser trips.
VAC - BSC Ion pump repcaement scheduled for Tues
FAC - Divers on site to inspect fire water tank.
Software - revisions to be made to GDS programs. Additional framewriter to be added to collect data from concentrator.
A TV crew froim Hong Kong will be on site tomorrow
According to T1500556, current settings for test mass oplevs are:
| Whitening gain | Number of active whitening filters | oplev SUM counts | |
| ETMX | 18dB | 1 | 40500 |
| ETMY | 0dB | 2 | 28000 |
| ITMX | 0dB | 2 | 2400 |
| ITMY | 0dB | 0 | 5400 |
ITMY oplev PIT noise is close to the DAQ noise floor at about 3Hz, and the DAQ noise dominates the RMS down to 0.7Hz or so. ITMX is OK for RMS due to double 1:10 whitening, but not much better at 3Hz. Not good for oplev damping.
Also it seems totally fine to use two stages of whitening filters for ETMX.
We can set things up like this (changes in bold font):
| Whitening gain | Number of active whitening filters | 4000*10^(24/20)oplev SUM counts | |
| ETMX | 18dB | 2 | 40500 |
| ETMY | 0dB | 2 | 28000 |
| ITMX | 21dB | 2 | 27000 |
| ITMY | 15dB | 2 | 30000 |
The filter gains for the high power oscillator monitoring diodes were switched back from 1 to their old values that were recorded under 20599 Jason/Peter
The IOC for h1cam18 was not running properly, an old image was being displayed and centroid values were frozen. Tried restarting the IOC, it didn't clear the problem. Tried rebooting h1digivideo1, it came back OK, but the IOC for h1cam18 wouldn't run. Tried deleting all of camera 18's log files and restarting, still wouldn't run. Logged on to network switch to power cycle the h1cam18, then restarted the IOC and it appears to be behaving OK now.
Multiple LASER trips are evident in the trends. Also, apparently, H1:PSL-OSC_DB3_CUR is reporting 100A. This is inconsistent and virtually impossible. Something wrong with the channel. FRS# 5955 filed.
Came in to find that the laser had tripped. Error messages were as before. Found that although I could
reset the laser I could not turn it on without rebooting the Beckhoff computer. All the TwinCAT channels
were live and so on. When the command was issued to turn on the pump diodes, the pump diode current(s)
did not increase.
The crystal chiller displays "Error Flow - sensor 1", as before, even though the laser is up and
running.
One other observation is that the mouse on the Beckhoff computer appears to be dead. Whilst its LED
is on, moving the mouse does not move the cursor. Not sure that the two problems are related but it
certainly doesn't help.
I have been taking spectra from the SR785 (WP6005) whenever I get a chance over the last week to see if there is any evidence of three mode interactions in the 60kHz to 70kHz region that we will not be sensitive to with the aliased OMC DCPD HF channels that we normally analyze.
There is a consistent peak at 62935Hz, this peak is present with no optical power in the arm cavities.
There are several other more transient peaks, one of the times several had large amplitudes is shown in the first figure.
The largest peak is at 63776Hz The maximum amplitude seen was 5E-6 This is about the same as the 18040Hz mode when it is 2 orders of magnitude above thermal noise and 2 orders of magnitude under unlocking the cavity.
The second largest is at 70160Hz and the third largest at 62336.
There is no evidence of peaks in DARM at this time at the expected aliased frequencies 1760Hz, 3200Hz or 4624Hz and the peaks that appear in the HF channels that do not appear in the normal DCPD channels do not coincide in frequency, see the second image.
We disconnected this SR785 around 11am local time today. This closed work permit #6005.
J. Kissel, T. Hardwick We've taken the liberty of rifling through Carl's home directory in hopes to find the raw data from this entry to re-plot for clarity. We found it! The newly attached plot now highlights the PI modes that Carl mentions in his aLOG, and also shows the anticipated ADC noise. Thus, any modes below 6.3e-6 [V/rtHz] should not be resolved by the ADC, and therefore will show up aliased into digitized signals in the detection band. Terra notes that the mode Carl mentions at 70160 Hz is the largest of several peaks at 69.84, 69.95, and 70.03 kHz (not highlighted), which is likely a mode cluster. Other details: The raw data lives here (determined by Terra knowing that Carl keep his GPIB data in his home folder, then lining up the data on the figure with the filename): /ligo/home/carl.blair/gpib/netgpibdata/dataSPSR785_24-07-2016_212424.txt This data (as described in the referenced work permit 6005), is the raw analog output of the TMSY's red QPD's whitening chassis. This data also happens to cover the frequency region surrounding the 65536 [Hz] native sampling frequency of the General Standards ADC, and the corresponding notch in all Anit-Aliasing (AA) chassis. One can see, delightfully, that there is very little noise or lines in this frequency band on this channel that might also otherwise be aliased down to low frequency. We should perform a similar spectral analysis of the OMC DCPD whitening chassis output voltage to check if their AA chassis is also sufficiently notched so as to not contribute noise in to the DARM sensitivity.
[Matt, Carl]
The phase lock loop is now installed as an optional tool in the PI armory. I have used the settings and method Matt demonstrated to me on the test stand to lock onto OMC PI signals in the last 50W lock. I tried locking onto QPD signals but was unable to at quiescent amplitudes. The phase locked loop in the locked state is shown in the first image. It is tracking a 15521Hz ITMX mode (sorry for the poor labeling in the figure, there's still a few bugs in medm screens).
The settings used were:
Filter I - 100Hz LP Gain 1
Filter Q - 100Hz LP Gain 1
Freq Filter 1 - gain 1
Freq Filter 2 – gain 0.02, 20mHz integrator + low pass see below
FC Count - 10mHz low pass (this was not low enough as the frequency estimate was still fluctuating by 20Hz
Ampl Filt er - 1Hz low pass gain 1
Lock Filter - 1Hz low pass gain 1
Lock was acquired by setting a set frequency close to the mode frequency observed in a spectrum of the OMC HF channels. The loop was engaged with a 100Hz low-pass in Freq Filter 2 then put in a narrow band mode by engaging a 1Hz low-pass in Freq Filter 2, the loop lost lock when I tried to further reduce its bandwidth by either reducing the gain of decreasing the frequency of the low-pass. The figure is in the high bandwidth mode. The PLL and iwave can be accessed from the mode block for any mode and a matrix is used to select a control signal, see the second image.
I think the best way to transition from PLL "aquisition mode" (high-gain and wide-band) is:
This should keep the output of FF2 (which contains an integrator) fairly constant, and thus keep the PLL locked during the transition.
Well, step 1 was supposed to read:
start with gain of 1 in FREQ_FILT1 and FREQ_FILT2 (FF1 and FF2), no filtering in FF1, and Int20mHz + LP10 in FF2
We had a lockloss at 50W due to what looked like the ISS 3rd loop, so I re-measured with higher recycling gain. It seems that when we recover recycling gain by moving the PRM, we get some loop interactions that reduce the gain of the 3rd loop right where we need it. So far, just increasing the gain of the loop has been enough to keep things under control.
Attached is a set of measurements of the 3rd loop, with the state of the IFO noted in the magnitude legend on the upper left. "g" refers to the gain H1:PSL-ISS_TR_GAIN.
Once, while the 3rd loop gain was -1.5, it started to oscillate. I put the gain to -2, then down to -1. I think it liked -1 better at that time, and that's how I left it for the rest of that lock, but -2 could also have been okay perhaps. I'm not totally sure. Perhaps we need to give this thing a UGF servo?
Will make log entry when leaving. Also, BSC8 annulus ion pump railed again, same as back in May. See also, https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=27325 and https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=27385 Will likely replace pump during Tuesday Maintenance period
Started pumps in room 169 @ 1615 hrs. local -> will be running until further notice 1700 hrs. local -> Leaving site now
[Jenne, Carl, Terra]
To facilitate the damping of the 18kHz ETMX mode, we are currently locked at 50W using ETMY so that ETMX can be swapped to its low noise driver. SRM dither loop is open.
To do this, it's okay to (once IncreasePower is finished) go to Manual mode and select LowNoise_ESD_ETMY. Last week we lost lock trying to do this because this state also (used to) switch the L2 coil drivers to their low noise state, which we aren't ready for. So, the noise is acceptable for the lownoise ESDs, but not the low noise L2 drivers. On the to-do list is to decide where in the sequence to put the L2 switching.
PI and other work is ongoing.
For the L2 coil drivers, if I understand correctly you are set up to transition to the lowest noise (and lowest range) state, state 3. As an alternative you might transition to state 1, where the ACQ mode is switched OFF, but the low-pass remains OFF. I believe the low-pass is a 1 Hz pole, 10 Hz zero, so this would afford more range above 10 Hz than state 3, and still puts the L2 noise low enough that it's not a significant limit, at least for our O2 goal. See Chris W's entry 28264.
Ah, yes. I think you had mentioned this, but I forgot. I'll give that a try.
Kiwamu, Carl, Terra
18041 Hz (ETMY) successfully damped through several locks. 15542 Hz (ETMX) unstable after about 1 hour at 50 W but we cannot damp without going to LOWNOISE_ESD_ETMY.
We had a few ~1 hour locks at 50 W today, with a bit of time at 60 W.
18041: damped first with +30 phase, +30K gain but rang up in the second lock despite. Changing to zero phase damped it in the second lock and prevented any ring up during the third lock.
15542: rings up almost immediately at 60 W. Rings up after an hourish at 50 W. This mode belongs to ETMX but we've been sitting at INCREASE_POWER during locks so we cannot use the LNLV ETMX driver to damp.
Because ETMX PI couldn't be damped, I tested my ITM DARM charge measurement script, which broke lock. I know the cause and will be able to fix it for another attempt tomorrow.
The SUS_PI guardian is running again. It had got stuck with spm differences after the model restarts.
During these lock stretches settings for damping several modes were found and put in the gaurdian.
15522Hz ITMX (mode2) was ringing up at the end of the last lock aand was damped with gain -300 and phase -60 deg.
15541Hz ETMY (mode25) was stable but the driven up to find a damping gain 1000 and phase +60deg and the
18041Hz ETMY phase has been adjusted to 0 deg (gain stays 1000)
This is a quick note on the SRM dither loop.
The SRM dither loop does not seem to give us the optimum SRC alignment when the PSL power is above 50 W in this evening. I don't remember seeing this problem two days ago (28577). Today at one point, we had a lockloss at 50 W when slowly introducing an offset in the PRM pointing from 0 to 0.5 QPD count over 5 min. During this engagement process, AS90 kept decreasing while the carrier recycling gain kept increasing. In the next lock stretch, we opened up the SRM dither loop and started manually aligning SRM. At the optiumum point where the signal recycling gain (i.e., AS90 / POP90) was maximized, the dither-based error signals had a non-negligible offset in both pitch and yaw (on the order of 0.005 at the input of the control filters for both).
