kyle.ryan@LIGO.ORG - posted 16:11, Tuesday 02 February 2016 (25321)
Manually over-filled CP3
~1535 1555 hrs. local -> To and from Y-mid Next over-fill to be Thursday, Feb. 4th before 4:00 pm
~1535 1555 hrs. local -> To and from Y-mid Next over-fill to be Thursday, Feb. 4th before 4:00 pm
The articulating boom lift, (10,000 lbs.) is blocking the walk way at the corner near HAM 3 & 4. You could climb over the tire, however, the preferred route would be around HAM 1.
DaveB rebooted the ASC model for me earlier today. I have confirmed that all of the signals go through the matrices as I expect.
I have also copied antiwhitening filters into the individual segment filter banks of the new AS 90 WFS, and loaded the whole ASC Foton file
Tomorrow morning, Elli, Cao and I will go with Rich and Fil to measure the relative phase between the I and Q channels of each segment. After that, we should be ready to start using the new AS 90 channels (setting the analog gain and whitening, digital demod phasing, etc.).
WP #5710
I have added two functions in the PSL ISS front end model. Both are related to the second loop and not to the first loop. The model has been compiled, installed and restarted. The changes I made are:
I have not yet tested these functions. Since the changes are additive to the existing model, one can still use the guardian to engage the second loop.
The attached is a half-baked and inaccurate medm which shows the new functions. Even though it is inaccurate, it is conceptually good enough to show what I implemented.
The trigger logic is shown in the right hand side of the screen. It watches the amount of the signal (i.e. SECONDLOOP_SIGNAL) which would go to the inner loop and triggers the second loop when it meets the trigger setting.
The software AC coupling function is show in the left of the screen. When one wants to keep using the manual silder to adjust the offset, one can fill the first row of the matrix which plugs the slider value to the offset point. When one wants a slow servo as the guardian has been doing, one can plug three different error signals and correct the offset point depending on the engagement steps.
Currently, Masayuki is editing the screen.
I finally managed to get the HWS TECs working on the superluminescent diodes. The problem was that the trimpots on the LDTC0520 drivers were not set correctly. Per page 11 of the manual, for a SLED with a thermistor and a TEC, we use trimpot LIM_A to set the cooling current limit and LIM_B to set the heating current limit.
The actual temperature on the SLED now goes to the set point temperature.
The temperature and humidity data for the long term storage Dry Boxes, and Desiccant cabinet. No apparent problems or issues noted with these storage boxes.
For a while I've been trying out sensor correction from the St1 T240s to the St2 CPS's, in X&Y. I thought this was working at ETMY, but not at ETMX, on closer inspection this seems to be not true. Looking into the model with Dave and JimB, we found that the wrong signals are being sent to the X and Z CPS, but Y is okay. It turns out the X CPS is getting the RZ T240, Y is receiving the Y T240, and Z is getting the X T240. Attached image shows the problem area, circled in red. The T240 signals in the T240 bus to St2 are inverted, the bus is labeled X, Y and Z, but if you follow the wires from the T240 cart matrix they go to RZ, Y, X, as I noted. Even worse, the X CPS is receiving not only the T240 RZ, it's receiving the T240 signal before we subtract the Z drive coupling. No wonder X didn't work.
I'm going to file a work permit, fix the bug and let the rest of the SEI group discuss when LLO should get the fix.
Svn up'd LHO's common guardian masterswitch and watchdog folders:
hugh.radkins@opsws1:masterswitch 0$ svn up
U states.py
Updated to revision 12509.
hugh.radkins@opsws1:masterswitch 127$ pwd
/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/masterswitch
hugh.radkins@opsws1:masterswitch 0$
hugh.radkins@opsws1:masterswitch 0$ cd ../watchdog/
hugh.radkins@opsws1:watchdog 0$ svn st
hugh.radkins@opsws1:watchdog 0$ svn up
U states.py
Updated to revision 12509.
I restarted HAM6 and tested by disabling an output leg. The trip appeared to execute the functions as expected-I did not notice any problem. Restarted HAM5 and tested, it too turned off the FF and reduced the GS13 gains as expected, no problem noticed. Restarted HAM4 but did not test (by tripping the platform.)
Restarted HAM3 after enabling the GS13 Switching feature as I wanted to test the problem of the guardian being unable to turn the GS13 gain up without tripping the platform. This is where I noticed the problem.
When guardian turned up the GS13 gain, the HAM3 tripped and it successfully turned off the FF and lowered the GS13 gains but it left the DAMPing loops engaged. I thought the restart of the guardian may have been responsible for this behaviour. I cleared the trip but did not turn off the DAMPing path first. The ISI did not trip until the GS13s were again toggled to high gain but this time, the DAMPing path was turned off as I would expect. Okay, maybe first time around problem. Cleared the trip and again the platform tripped when the GS13 gain changed and again the DAMPing path was left on. I repeatd and again the DAMPing path was left on. I disabled the GS13 Gain Switching feature and we made it to isolated and I set the GS13 gains to high with the Command Script.
I've repeated the test on HAM5 and there too, DAMPing path remained on.
Meanwhile ITMX tripped due to LVEA activity, DAMPing path not turned off and this guardian has not been restarted with the new update. Repeated this on ITMY and it too left the DAMPing path enabled. Okay, it looks like this DAMPing problem is not related to the current code upgrade.
I will continue to restart the guardian with this current upgrade though as the turning off of the GS13s when tripped is a good thing and generally, the platform can deal with untripping the watchdog with stuff coming out of the DAMPing path, as long as the GS13 are in low gain. And since HAM2 & 3 can't handle guardian gain switching, they must have the gains toggled manually.
I've restarted all the LHO ISI Guardians. Tested the function/features and problems and they are all present on ITMX ISI too.
I modified watchdog/states.py to accomodate for this additional request to the T150549 update. The update was comited to the SVN:
The LVEA has transitioned to laser safe. A reminder that no work involving opening a table enclosure door may occur.
I again looked at the cross-correlation of POP and POPAIR 45Q during full lock, in order to find out what the vertex LSC noise looks like below the shot noise level.
This time, I added a bandstop filter to PRCL, MICH, and SRCL that gives ≥40 dB attenuation between 82 and 101 Hz. This ensures that shot noise is not impressed on the vertex dofs in this band, so that we can get a true estimate of the freerunning displacement/sensing noises.
The result of 1 hour of cross-correlation is attached. In the case of POP 9I (used for PRCL) and POP 45I (used for SRCL), there is significant coherence between the two PDs. For 9I this is not so surprising, since the same (unknown) structure can be seen in both spectra. For 45I, a similar irregular structure is seen in both PDs. The coherence in the notched portion is 0.01.
For POP 45Q (used for the Michelson), the coherence seems remarkably free of the irregular structures seen in 9I and 45I. The notched portion appears to be at the noise floor of the correlation measurement, with a coherence <0.001. The coherence of 0.01 around 130 Hz probably comes from noise being injected into the Michelson loop.
The uncontrolled quadrature (9Q) shows some evidence of irregular structure, despite the fact that POP 9 and POPAIR 9 were both phased to mimize the apperance of PRCL in Q.
Time is from 2016-02-01 04:18:00 to 05:18:00 Z.
Title: 2/1 Eve Shift 22:00-6:00 UTC (14:00-22:00 PST). All times in UTC.
State of H1: Lock acquisition. Lost lock in the last 15 minutes of my shift.
Shift Summary: Several locklosses at various stages and from various causes (commissioning activities notwithstanding). Locked at NLN for ~2 hours, but in Commissioning mode, while Jenne and Evan do their thing.
Incoming operator: None
Activity log:
22:44 TCS crew to CO2Y table
23:11 Joe D back from beam tube sealing
23:26 reset H1SUSETMY tim error
0:21 TCS crew done
I pushed the numbers from Gabriele's Saturday alog (25265) through the beam position calculating / calibrating script, and see that the ETMY pitch spot was moved by 2.4mm.
| Old position [mm] | New position [mm] | Delta [mm] | |
| ITMX | -4.5 | -4.5 | 0 |
| ITMY | -0.3 | -0.8 | 0.5 |
| ETMX | -1.8 | -1.6 | 0.3 |
| ETMY | 2.0 | 4.4 | 2.4 |
I'm not sure why this happened. I need to think some more on this.
The HWS SLED temperature (H1:TCS-ITMX_HWS_SLEDTEMPERATUREMON) has never read back correctly. I tracked down the problem to a missing wire in a 15-pin cable.
Lo and behold, the thermistor was correctly wired to the SLED driver chassis and now reads back a sensible temperature. What's more, turning on the SLED with 100mA going through it shows a 2.5C increase in temperature - as expected.
However ... I could now finally check if the SLED temperature changed as I changed the setpoint temperature to drive the TEC on-board in the diode package.
Changing the setpoint temperature had no response on the actual temperature.
I want to get this fixed as it will increase the lifetime and output power of the diodes.
(All of this was repeated for SLED 2).
[Alastair, Aidan]
The Y-arm CO2 laser, which has not been getting injected to the CP, has now had its beam block removed so that we can perform the alignment proceedure. The AOM drive from the DAC has a very low frequency pole that would stop us from injecting a large enough signal to do the alignment this way, so we have directly bypassed the module that has this filter.
Instead we put an oscillator directly on top of the enclosure set to 23.8Hz, 0.1V pk-pk, 0.1V offset. This oscillator is running on AC power and has quite a noisy fan. The oscillator is being fed through to the table and directly connected to the AOM driver, bypassing the DAC and all other electronics.
The laser has its rotation stage set to output the minimum power we could achieve (11mW) so this signal shouldn't be visible in the interferometer at the moment. If it is critical to stop it doing this then the laser can be turned off from MEDM, however I would request that if at all possible we leave the laser running because I am still working on the long-term stability of the locking loops.
Attached are spectra comparing the SUS ETM L3 LV ESD channels from lock segments before (Jan 24, 2016 03:35:00 UTC) and after (Feb 1, 2016 01:50:00 UTC) the ESD Driver update last Tuesday alog 25175 (and the subsequent ESD fixes on Wed 25204). Before the install, the channels looked like ADC noise, while they look live now. The ETMx plot is included, but of course the ETMx ESD is not ON during either lock stretch, so all the plot really says is that something happened to the channels. Whether or not the ETMy channels look like they actually should, according to various ECRs, is to be determined.
Keita helped me make more useful plots to evalute the new LV chassis mods. See attached.
The alog that motivated all of these is alog 22199.
In Betsy's new plots, reference traces are with the old hardware, current traces are new, both in full low noise lock. In summary, this is good.
The spectrum/coherence plot shows that the new whitening is useful, the monitor is actually monitoring what we send rather than just ADC noise. (It used to be totally useless for f>7Hz or so as you can see from the reference coherence.) You can also see that there's a small coherence dip at around 30Hz, and there are deeper dip at around various band stop filters, but otherwise it's actually very good now.
In the second plot, you see Y channel spectrum together with X. Since we don't send anything to X during low noise lock, X is just the sensing noise. When you compare the signal (red) and the sensing noise (light green), we can see that the signal is larger than the noise across the entire frequency range except the stopbands.
At around 30Hz (where we saw a tiny coherence dip in the first plot) the noise is only a factor of 3 or 4 below the signal. We expect the higher frequency drive above f=100Hz to drop as we increase the power, so the signal/noise ratio there might drop in the future. There's still a large headroom before we rail the ADC (RMS is 600 counts), so if necessary I'm sure we can make some improvement, but this is already very good for now.
The only thing is, what's these lines even when we don't send anything (X)?
It seems as if 57Hz and harmonics, whatever they are, in the non-driven channel are at least as large as in the driven channel.
57Hz was the HWS at the end stations.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=25383
Feb. 1 2016 18:31 UTC Stopped Conlog on conlog-test-master. Had been started 19:42 UTC Jan 27 2016 (alog 25201). Shutdown conlog-test-master to install Spectracom card.
Feb. 2 2016 02:36 UTC Connected conlog-test-master back to the same 97,469 process variables as h1conlog1-master.
We have had multiple locklosses today from the beamsplitter coil driver switching.
This is puzzling, since this step was largely unproblematic during the run.
Opened FRS ticket 4325. Unfortunately for the this study, the only BS's coil driver monitor channels stored are noise and voltmons, both of which are upstream of the output impedance network (so they don't measure the current effect of switching the "acquire" network off as is done here) *and* they're only stored at 1024 at the fastest. I recommend we start by either (a) installing an analog voltage breakout pick-off in-line with the M2 BOSEM chain down-stream of the coil driver to identify the amplitude of glitching which takes out the IFO's lock, and address from there, or (b) Changing the h1susauxb123 front-end model to store the driver's FAST I MON at 16 [kHz]. (These can go in the commissioning frames, and also the noise and voltmon can be removed.)
Starting to look at this but have a question before I start. Why is the Ramp on UL 0sec and the other filter 10 Sec.
Richard refers to the ramp time in COILOUTF bank; however the ramping between coils is performed by the new Ramp Matrix part not this bank. It's likely that this COILOUTF bank ramp times were "set" some long time ago (clearly more than 300 days ago!) and because it's not used for any ramping of control signals, it has merely remained untouched.
This problem has gotten worse and better in the past without any known cause, for example durring ER7 it was particularly bad.
