J. Kissel Attached is a screenshot of the values installed on Sunday will be lost because of SDF precision issues.
Both HPCL-2231 optoisolators were replaced. After re-inserting the servo card, I checked that the laser was on and that the NPRO noise eater was still happy. The laser MEDM screen indicated both. When I pulled up the ISS screen the power on the photodiodes was zero. I checked the PMC screen and it indicated that there was no laser power incident on the PMC. A closer look at the laser screen indicated that the low power shutter in the laser had closed. Resetting the external shutter request from the laser MEDM screen restored the light. After locking the ISS servo, everything seems okay as far as the laser goes.
Board affected is S/N S1107804.
J. Kissel, B. Weaver, C. Vorvick - ISC_LOCK guardian to DOWN, set in PAUSED - IMC_LOCK set to OFFLINE - ALIGN_IFO set to PAUSED - SEI_ETMY to OFFLINE and SUS_ETMX to SAFE for prepping SUS EX reversion to slow front end computer. -Cleared ETMX SDF warnings about new violin mode damping configuration, initialized new RMSLP and L3_CAL_LINE channels and set to monitored - Accepted ETMY BIAS sign flip and corresponding DRIVEALIGN gain sign flip. - Accepted ALS Y PZT2 YAW MISALIGN BIAS to be 11200 (from 11500) - Reverted SUS BS LOCK L OFFSET (and TRAMP) to 0 and 10 (respectively) from 10000 and 30 (respectively). - Accepted SUS ITMY violin mode damping settings, and that the output is OFF for ITMY OLDAMP P. - Accepted SUS ITMX optical lever Y damping GAIN to be 0.0 (from -111). NOTE: ITM Optical Lever P Damping is totally inconsistent. We've found that ITMX P is ON (gain and output switch) yet ITMY Y is on OFF (gain -300 output is OFF). We tested TJ's modifcations to the SUS guardian by exercising the SAFE state, which turns OFF the outputs. By design, the outputs should be turned back ON in the DAMPED state. Will speak with TJ.
While looking at a few big glitches, I noticed that many have a curious post-glitch feature around 300Hz. The post-glitch ring seems to match the periscope frequencies we usually see noise at... could this be a hint as to the source of some of our glitches? Maybe this was fixed last night, maybe not.
Looking at all the glitches previously indentified, it runs out that only 17 out of 151 show an excitation of the periscope peaks, as found by Matt. Here are the times:
1117617558.82
1117690781.51
1117713007.28
1117754567.25
1117873501.47
1117888336.85
1118320556.34
1118336224.73
1121762741.96
1121942076.77
1121966658.37
1121986392.35
1121991554.23
1122466633.18
1122474562.14
1122479776.82
1122484101.65
Alignment and locking issues aloged earlier.
IFO did make it to low noise about 6 hours ago.
Relocking about 45 minutes had trouble with Guardian that we hadn't had any issues with all night - not sure why. At JeffK's suggestions I commented out the offending section of code. Code is attached as a screenshot.
IFO handed off to Mantenance activities.
----------Maintanance Activities ------
7:00 - Richard and Ken, roof
7:37 - Bubba and Chris, LVEA fan maintenance
7:41 - PeterK, ISS
7:42 - Richard and Ken, Electronic's Room
7:59 - Richard/Ken DONE
7:59 - PeterK Done
Cheryl, Evan
The 0.43 Hz pitch instability strikes again. I had to turn up the dHard pitch gain from 10 to 20 in order to prevent a runaway. Back into the guardian it goes!
It takes tens of minutes to ring up, and even after tweaking loops, it never exactly rings down (the fuzz in the attached striptool is almost all from this 0.43 Hz feature).
Attached are error and control signals for the arm pitch loops at several different powers: 10.4 W (blue), 15.2 W (yellow), and 19.8 W (green).
Is it strong enough to show up in the suspension OSEMS?
Are the OPLEVs still on? They suppress the ASC gain below 1Hz, and might be the cause of instability.
A trend of the oplev PIT loop buttons over the last 12 hours show the:
ITMY OL damping OFF
ITMX OL damping ON
SR3 OL damping ON
PR3 OL damping OFF
ETMX OL damping OFF
ETMY OL damping OFF
All above YAW loops OFF.
BS OL PIT and YAW damping ON.
THe sttached screenshot is from the few minutes before Evan turned up the DHARD PIT gain last night. You can see that there is an oscillation in the Y arm only, and it seems to be soft. The same oscillation shows up in MICH but it is much smaller.
As Betsy pointed out, ITMX oplev damping was on last night, while ITMY oplev damping was on. Both ITM oplev loops are currently turned on in the INCREASE power state of the ISC_LOCK gaurdian, which still seems to be necessary for stability. Based on OLG measurements of DHARD, the Oplevs should not impact the stability of DHARD. However, we haven't been able to get good measurements of CHARD since rephasing the REFL WFS and hopefully getting a reasonable amount of gain from these loops. (just because of other activities).
Hopefully we can spend some time on CHARD today, which may shed light on why we need the ITM oplevs and hopefully reduce the large optical gain fluctuations we have.
This is a report by Jenne.
[Sheila, Jenne, Cheryl, Evan]
We have (finally) recovered from the input pointing adventures of the day.
In the end, I think all we did was some hand alignment to get the ASC error signals small-ish, so that the loops could take over without pulling down the power buildups. We are now able to go all the way through the guardian states automatically.
This is the first low-noise lock since the EOM driver was replaced earlier today with the new box that can suppress amplitude noise of the sideband (20392). From Lisa's log post (20131), we see that a useful comparison is the OMC DCPD Null stream with the Sum. In the plot below, the dotted line references are from August 1st, when we still had the old 45 MHz driver. The solid lines are from tonight. The null stream is the same then and now, (as it should be), but the sum has come down significantly. This means that our OMC DCPD is now closer to the shot noise limit, since we have better suppressed this RFAM noise.
[Edit: It's true that the coherent excess in the DCPD sum has been decreased, but there is still a broadband excess everywhere from 400 Hz to 7 kHz, and we still see broadband coherence between DCPDs A and B with AS C. See second attachment (the IOP channel is AS C segment 1). Might be worthwhile to try varying the modulation index. —Evan]
LVEA: Laser Hazard IFO: Unlocked Observation Bit: Commissioning All Times in UTC 23:00 Take over from Jim W. 23:40 Sheila & Jenne – Going to IOT2L table to look for beam 23:55 Sheila & Jenne – Back in LVEA at IOT2L 00:45 Daniel & Sheila – Going into PSL enclosure to check PZTs 01:00 Daniel & Sheila – Out of PSL enclosure 01:10 Adjust ISS diffracted power to 8% 02:37 Evan & Daniel – Going into the LVEA to work on EOM drivers 03:00 Commissioners working on reestablishing lock
Initial alignment was redone following today's PSL work.
Attached is the whiteboard list of tomorrow's scheduled tuesday maintenance activites.
We'll start with some hardware related work, and follow up with an ASC model restart. As usual, please let us know when you are coming and going to VEAs, whether for listed work or not, so we can ensure efficiency of everyone's work.
1st wave tasks:
Fix 1st loop ISS servo card
Install PI AA chassis (Ex, EY)
Install TCSx viewport temp sensor
Finish SEI "safe" .snaps
Stagger start in 1st wave task:
Pcal work at Ey
Sweep VEAs for test equipment that needs to come home
PEM injection setup
2nd wave tasks:
ASC model restart
REVERT EX FE computer to original machine
DAQ Restart
Kiwamu recently found, while trying to to use suspension model to calibrate Pcal, that the use of IIR filter in the front-end results in distortion of the filter response from its actual intended response. (G1501013).
We decided to check all the whitening filters that are use in CAL-CS model to confirm (check) if we see similar effect. The following filters were analyzed:
CAL-DARM_CTRL_WHITEN
CAL-DARM_ERR_WHITEN
CAL-CS_DARM_DEALTAL_CTRL_SUM(L1/L2/L3/M0)
CAL-CS_DARM_RESIDUAL_WHITEN
CAL-CS_DARM_DELTAL_EXTERNAL_WHITEN
The frequency response of these filters deviate from the model by about 2.5% at its max in amplitude and about 8 degrees in phase (at around 5 KHz). Some filters are severe than the other but they produce this effect nonetheless.
I varied a pair of pole frequencies, keeping two zeros at 1 Hz, to see what the effect looks like. From the last plot, we can see that the distortion is more severe if the pole frequencies are higher.
(Evan, Kiwamu. Daniel)
We installed the 45.5MHz EOM driver in the PSL room. It is located below the PSL table and replaces the RF amplifier at the same location. The drive power has been adjusted to be the same as before at 23.2dBm. This is now controlled remotly through medm.
Calibration:
The RF phase shift was compensated by cable length to within 1°.
The RF phase has a slightl dependence on the RF level. At 45.5MHz with 23dBm output level the phase advance of the entire chassis is 121°. The relative phase shift at 17dBm is +4.8° (advance), +8° at 13dBm, and 12.8° at 5dBm—or –0.8°/dBm.
The attached plot shows the RF AM RIN in dBc/Hz for both the in-loop and out-of-loop sensor (double-sided). At 100Hz with 23dBm output we are achieving-170dBc/Hz.
We kept track of the RF phase shift by keeping the interferometer in a freeswinging Michelson configuration while watching the time series of AS45I and AS45Q. Before the swap, we had arctan[Q/I] = arctan[42.0(3)/10.3(3)] = 76.2(4)°. After the swap, we found that the signals had shifted by +144°. [Note that just watching the freeswinging I and Q time series only determines the phase shift modulo 180°. We locked the Michelson and found that instead of the expected dark fringe lock, we got a bright fringe lock—indicating that the phase shift must lie somewhere between +90° and +270°.]
Then we experimented with adding extra cable length between the 45 MHz distribution spigot and the EOM driver. In the end Kiwamu and Daniel made a 150 cm LMR 195 cable, which brought the phase of AS45 back to arctan[41.8(6)/10.1(4)] = 76.4(6)°.
I assume the following SDF setting changes are related to this work, so I have accepted them into the LSC safe.snap for future restores.
JeffreyK, Darkhan
Overview
We found that some of the calculations in the recently implemented CAL_CS front-end model (see LHO alog #20360) do not produce expected results. We found this problem in the division block that takes input of significantly smaller number for denominator vs. number in the nominator.
Since this calculation is done on quantities that should change only as a result of manual input we've decided to calculate these quantities in Matlab and then export final results to EPICS. Tomorrow we will add these EPICS inputs into CAL_CS front-end model.
Details
In this section we show how this bug was identified.
Following EPICS input channels exist in the CAL_CS front-end model: REF_A_TST_REAL and REF_A_TST_IMAG. They form a complex quantity Atst = Re{ Atst } + i * Im{ Atst } = REF_A_TST_REAL + i * REF_A_TST_IMAG.
We wanted to calculate Re{ -1/Atst } and Im{ -1/Atst } as
| Atst |2 = Re{ Atst }2 + Im{ Atst }2
Re{ -1/Atst } = - Re{ Atst } / | Atst |2
Im{ -1/Atst } = Im{ Atst } / | Atst |2
When we provided both inputs (real and imaginary) with quantities their values, the quantity | Atst |2 came out to be about right, but the final values Re{ -1/Atst } and Im{ -1/Atst } were off by several orders of magnitude.
The finals values should have been
Re{ -1/Atst } = 1.39199e+16
Re{ -1/Atst } = -1.14388e+16
We don't know for sure, but it might be possible to avoid this bug by trying rearrange signals in simulink design (e.g. replace division by multiplication by inverse of the quantity or maybe some other way).
For this case we decided to calculate these final quantities in Matlab and into EPICS only final results.
Looks to me that the FE prevents divide-by-zero errors by limiting the denominator to 1E-20.
