chandra.romel@LIGO.ORG - posted 07:36, Monday 04 April 2016 (26413)
turned on Kobelco in prep for HAM6 vent
...at 7:20 am local time. Pressure reads 1.2 psig.
...at 7:20 am local time. Pressure reads 1.2 psig.
If you'd like to move the table, you need to do the following:
PT243 - 1.17 x 10-9 torr PT244 - 1.57 x 10-9 torr PT210 - 1.57 x 10-9 torr I know, I know :)
I did some follow-up tests today to understand the behavior of the DARM cavity pole. I put an offset in some ASC error points to see how they affect the DARM cavity pole without changing the CO2 settings.
I conlude that the SRC1 ASC loop is nominally locked on a non-optimal point (when PSL is 2 W) and it can easily and drastically changes the cavity pole. The highest cavity pole I could get today was 362 +/- a few Hz by manually optimizing the SRC alignment.
[The tests]
This time I did not change the TCS CO2 settings at all. In order to make a fair comparison against the past TCS measurements (26264, 26245), I let the PSL stay at 2 W. The interferometer was fully locked with the DC readout, and the ASC loops were all engaged. The TCS settings are as follows, TCSX = 350 mW, TCSY = 100 mW. I put an offset in the error point of each of some ASC loops at a time. I did so for SRC1, SRC2, CSOFT, DSOFT and PRC1. Additionally, I have moved around IM3 and SR3 which were not under control of ASC. All the tests are for the PIT degrees of freedom and I did not do for the YAWs. During the tests, I had an excitation line on the ETMX suspension at 331.9 Hz with a notch in the DARM loop in order to monitor the cavity pole. Before any of the tests, the DARM cavity pole was confirmed to be at 338 Hz by running a Pcal swept sine measurement.
The results are summarized below:
The QPD loops -- namely CSOFT, DSOFT, PRC1 and SRC2 loops -- showed almost no impact on the cavity pole. The SOFTs and PRC1 tended to quickly degrade the power recycling gain rather than the cavity pole. I then further investigated SRC1 as written below.
[Optimizing SRC alignment]
I then focused on SRC1 which controlled SRM using AS36. I switched off the SRC1 servo and started manually aligning it in order to maximize the cavity pole. By touching PIT and YAW by roughly 10 urads for both, I was able to reach a cavity pole of 362 Hz. As I aligned it by hand, I saw POP90 decreasing and POP18 increasing as expected -- these indicate a better alignment of SRC. However, strangely AS90 dropped a little bit by a few %. I don't know why. At the same time, I saw the fluctuation of POP90 became smaller on the StrioTool in the middle screen on control room's wall.
In order to double check the measured cavity pole from the excitation line, I ran another Pcal swept sine measurement. I confirmed that the DARM cavity pole was indeed at 362 Hz. The attached is the measured DARM sensing function with the loop suppression taken out. The unit of the magnitude is in [cnts @ DARM IN1 / meters]. I used liso to fit the measurement as usual using a weighted least square method.
By the way, in order to keep the cavity pole at its highest during the swept sine measurements, I servoed SRM to the manually adjusted operating point by running a hacky dither loop using awg, lockin demodulators and ezcaservos. I have used POP90 as a sensor signal for them. The two loops seemingly had ugf of about 0.1 Hz according to 1/e settling time. A screenshot of the dither loop setting is attached.
Probably interestinmg to take a look at ASC_ASA/B_36/90/DC, and see, if there is a better combintion available.
It occurs to me that we might try putting some offsets into the centering loops for the SRC WFS. Can we find a pointing location where the AS36 signals give us an optimal alignment for the SRC?
On a somewhat parallel thought, Evan and I wonder if we could set offsets in the SRC1 loops after choosing an alignment based on some dither lines? Maybe we don't want always-on dither lines, but we could use them to help us figure out what our optimal alignment is.
Here are some more data.
In this plot, full lock was achieved at some point between 0 and 500 sec. A small change in the SRM alignment offsets are due to the DRMI guardian completing the ASC offload to the top mass before decreasing the CARM offset. The measurement of the cavity pole and optical gain is valid only after 500 sec or so.
As I mentioned in the last ISC call, the cavity pole frequency and optical gain are anti-correlated -- one goes up and the other goes down.
The below shows a summary of my manual SRM alignment.
| Before | After | Difference (after - before) | |
| SRM PIT | -727 urad | -737 urad | -10 urad |
| SRM YAW | 908 urad | 901 urad | -7 urad |
As I wrote in the original entry, I steered SRM PIT and YAW by -10 and -7 urad respectively.
Also I attach a screen shot of trends showing the 2f RF signals during the same period.
As the cavity pole increases the POP90 consistently decreases. This is what we expected because SRC sucks more light into it. POP18 also increased at the beginning which is good. However it decreased slightly after I aligned SRM yaw for some reason. The most outrageous one is AS90. As the cavity pole increased, the AS90 kept decreasing. I have no idea why.
Conclusion (again): it is the SRC alignment that changes the cavity pole.
[SRM and SR2 alignments]
I completely forgot about the SRC2 loop which controls the pointing of the output beam on to ASC_AS_C. This loop was active during my measurement silently correcting SR2 and SRM as I manually moved SRM. So I checked the witness sensors to see how much they actually moved instead of looking at my adjustment of the SRM alignment.
As you can see, SRM actually moved to the opposite direction in its angles due to the SRC2 loop counteracting on my adjustment. In total they have moved by the amounts listed in the table below.
| before | after | difference (after-before) | |
| SRM pit | -105 urad | -95 urad | 10 urad |
| SRM yaw | 873 urad | 876 urad | 3 urad |
| SR2 pit | 2603 urad | 2600 urad | -3 urad |
| SR2 yaw | 790 urad | 791 urad | 1 urad |
[A finesse simulation also suggests that the cavity pole is a strong function of SRs' alignment]
With the above misalignment values in hand, I then ran a finesse simulation to see if I can reproduce a similar result. Indeed, I could change the cavity pole from an optimum of 366 Hz to 344 Hz in the simulation (while my measurement was from 360-ish Hz to 345-ish Hz). The attached is a simulated DARM response with and without these misalignment.
Because I was too lazy to fit out the effect of the time delay and next FSR peak, I simply searched for a frequency point where the phase rotates by 45 deg as a cavity pole frequency. This probably makes the absolute calibration of the cavity pole somewhat inaccurate, but the difference between the two cavity pole frequencies should be moreorless accurate.
Also I attach the finesse code in pdf format.
Addendum:
In the finesse simulation, the DARM response showed some difference at low frequencies between the two results. So I re-ran the same code and extended the frequency range to 0.1 Hz. It is seemingly due to a radiation pressure effect. I don't have a good explanation why it changed by SRs' alignment.
[Evan, Jenne, JimW]
We turned the ITM pitch oplev damping back on, set some QPD offsets for POP and transmons, and were able to go to 20W without trouble. We have finally made it to nominal low noise for the first time in weeks! Hooray! Sadly, a 2.84Hz oscillation killed us after about 10 seconds. Work continues, but I was excited enough to write an alog.
We lost lock several times very suddenly within 20 minutes of powering up. Also, POP90 seemed to be escaping upward. Looking at the 36 MHz wavefront sensors, one can see several quadratures of AS A are escaping. (AS A has not been used in any alignment loops for the past six weeks or so). In particular, AS A 36Q seems to correspond to the motion of SRM yaw as seen by its OSEM (see attachment).
We switched control of the SRM yaw loop from AS B 36I to AS A 36Q immediately after powering up to 20 W. This stops POP90 from escaping and seems to hold SRM yaw in place. So far we have been at >20 W for more than 90 minutes. The new setting (−0.5 ct/ct for AS A 36Q to SRC1 yaw) is not in the guardian.
Overall, the carrier power in the PRC seems less stable than before. It seems to have ~0.2 Hz fluctuations that sometimes approach 5% RIN, and correspond to fluctuations in cHard pitch, PRM pitch, and beamsplitter pitch. This frequency seems too low to correspond to an optomechanical resonance, so we suspect some alignment control problem. We tried turning down the PRM pitch loop gain by a factor of 2, but this didn't seem to change anything.
As Sheila anticipated, angular noise in DARM is quite bad right now. Some of it can probably be improved with a careful A2L retuning. The rest may require loop reshaping.
We also chose new QPD offsets for the soft loops and the PRM loops, in order to maximize recycling gain at 2 W.
1555 -1635 hrs. local -> To and from Y-mid Recent conditions -> 60F - 75F days, Dewar ~40% full vapor pressure 14 psi, LLCV 18% open [Executed nominal procedure as was practiced for 48 hour over-fill intervals] LN2 at exhaust after 32 min 30 seconds with LLCV bypass 1/2 turn open and exhaust check valve bypass open Next scheduled over-fill to be Monday, April 4th before 4pm local. NOTE: Need to revisit agreement between Dewar's local mechanical level gauge and value indicated by CDS. Also, recommend adopting new default for LLCV bypass X turns open for new 72 hour over-fill interval (something more open than previous default of 1/2 turn open).
After seeing that it took 30 minutes to get liquid out and given the warm weather I called the control room and had Jim raise the liquid level control valve to 20% from the existing 18%. The next web snapshot showed that the exhaust pressure had risen to 1 psi (from .7).
We're looking at replacing the HWS code which is compiled in MATLAB (and quite incompatible with newer versions on Ubuntu) with a more streamlined, Python-based version. The test bed for this is H1HWSEY.
So far, we have tested the following:
serial_cmd and succesfully connect to the internal menu system of the cameratake commandNeed to install EPICS/ PYEPICS ancd CDS tools.
State of H1: unlocked for 3.5 hours due to an earthquake
Activities since mid-day update:
Currently Activity: Jenne is looking at the alignment
See the attached for an incorrect syntax and the correct way to direct the front end to save the channels in the Science Frames.
The asterisk placed after the desired science frame rate makes the rate interpreted incorrectly. Since it did not know what to do with 1024*, it was storing the channel in the commissioning frames at 4096 and not at all in the science frames. The asterisk on the channel name is the correct way to go. The directions are all there, I just failed to look closely. I should have learned the necessity of doing so after all these years.
The modification was to a library part so the edits at least were not extensive. The change is committed:
hugh.radkins@opsws1:models 0$ svn commit -m "Corrected syntax error in frame storage"
Sending models/ISI_to_SUS_library.mdl
Transmitting file data .
Committed revision 13015.
hugh.radkins@opsws1:models 0$ pwd
/opt/rtcds/userapps/release/isi/common/models
After Jeff and Hugh made their fixes to all the ISI models and restarted them, I did a DAQ restart.
The restart was normal except that h1fw1 did not come back. It had tried to restart its daqd process, and then kernel panic'ed similar to Wednesday evening's crash (VFS count 0). I reset the machine by pressing the front panel RESET button, it all came back normally after that.
We had two more kernel panics after this restart. The sequence is: daqd process dies, monit starts new daqd, process gets as far as opening its log file, kernal panic from put_cred_rcu function.
After second panic, I performed a full power down of h1fw1 and h1ldasgw1. Recovery sequence: power up h1ldasgw1 wait for boot, then manually mount /cds-h1-frames and export as NFS. Then power up h1fw1.
Remember that since the h1susex and h1susey computers were upgraded to faster models (but still running the 2.6 kernel and 2.9.6 RCG), the sus model timing error rate was reduced but no zero'ed.
I have trended 30 days of FEC-88 (SUS ETMX) and FEC-98 (SUS ETMY) STATE_WORD starting 31 days ago, to determine the rate or TIM (second bit) and ADC (third bit) errors.
h1susetmx had 36 TIM errors and 1 ADC error. 37 errors in 30 days = average of 1 error per 20 hours.
h1susetmy had 125 TIM errors and 1 ADC error. 126 errors in 30 days = average of 1 error per 5.8 hours.
The process to gather the data is to use the command line nds1 client to give the MAX channel minute trend. A python script then masks out the upper bits from the STATE_WORD, so the overflows and CFC bits are discarded.
[Keita, Jenne]
We have recorded the label of each cable connected to ISCT6. Anyone may feel free to disconnect all of the cables at any time on Monday morning, to facilitate the moving of the table.
Attached is the set of cable labels, and where they are.
The HAM ISI model updates Tuesday, alog 26321, allow the suspension motion calculation to be done by the ISI. The filters and matrices to convert from ISI GS13 cartesian basis to the optic euler basis are now filled.
The BSC ISIs were updated for this earlier in the month. Alogs: original model updates-25913, ISI vs SUS calibration filter- 25993, mods for multi sus plarforms- 26117, library part cleanup/corrections- 26128, BSC filters & matrices populated- 26132, svn commits- 26143.
DetChar can now start pointing to these ISI computations. Look at channels: H1:ISI-{isi platform}_SUSPOINT_{suspension}_EUL_{euler dof}MON.
euler dof is L, T, V, R, P, orY
isi platform is HAM2, 3,..6, ETMY, ETMX,..,BS
suspensions available are ETMY, TMSY, ETMX, TMSX, ITMY, ITMX, BS, MC1, MC2, MC3, PRM, PR2, PR3, IM1, IM2, IM3, IM4, SRM, SR2, SR3, OMC. Of course you have to get the suspension on the correct isi platform.
Attached is a snapshot of the medms: the GS13 filter bank and available suspension calcs are accessed from the ISI Chamber overview; the transformation matrices are accessed from the calc screen.
SDF files, safe and OBSERVE, have been updated and committed to the svn:
hugh.radkins@opsws1:burtfiles 0$ svn commit -m "updated snaps for the SUSPOINT motion calculations"
Sending burtfiles/h1isiham2_OBSERVE.snap
Sending burtfiles/h1isiham2_safe.snap
Sending burtfiles/h1isiham3_OBSERVE.snap
Sending burtfiles/h1isiham3_safe.snap
Sending burtfiles/h1isiham4_OBSERVE.snap
Sending burtfiles/h1isiham4_safe.snap
Sending burtfiles/h1isiham5_OBSERVE.snap
Sending burtfiles/h1isiham5_safe.snap
Sending burtfiles/h1isiham6_OBSERVE.snap
Sending burtfiles/h1isiham6_safe.snap
Transmitting file data ..........
Committed revision 13006.
hugh.radkins@opsws1:burtfiles 0$ pwd
/opt/rtcds/userapps/release/isi/h1/burtfiles
Above I noted the ISI channels at which DetChar should look but I listed the epics channel:
DetChar can now start pointing to these ISI computations. Look at channels: H1:ISI-{isi platform}_SUSPOINT_{suspension}_EUL_{euler dof}MON.
Of course, the channels of interest would be the DAQ channels, e.g. H1:ISI-ETMY_SUSPOINT_TMSY_EUL_L stored at 1024; these are also going into the Science Frames. Welllll, not just yet.
Woops, I made a syntax error on my frame collection designation--see new alog.
These are now being captured correctly in the Science Frames--see 26400.
We've had much more success tonight with the non-broken Xarm Trans QPD. We once again re-centered the spots on the ETMs, although they didn't need much moving. We are able to sit at 10W and 12W just fine now. Now, we're running into regular ol' loop oscillations, so we've been measuring loops at different powers, and trying to re-tune them.
CHARD Y seemed the most egregious, so we created a new control and boost filter combo, which live in FMs 4 and 5. Unfortunately, these filters are totally unuseable at 2W, although they improve our stability at 10W, so right now the guardian still only engages the old loop shape filters. We'll have to re-think the 2W filter situation to make sure we can transition between these filters. Right now, we were by-hand turning off the CHARDY loop, changing the filters, then re-engaging the loop. Attached is an open loop gain for the new loop.
PRC2 pitch we've decided is kind of okay if we use a factor of 2 less gain.
Now, we're seeing oscillations that also show up in AS 90, so we suspect either the MICH or SRC angular loops. Unfortunately, there's something going on with NDS/the lockloss plotter/something, such that I can't get data from the last ~5 locklosses. The ones before that, I can still get and plot, but it can't find data for the last several even if it's been an hour since that lockloss.
So, next up: Measure the MICH and SRC loops at 10W to see if they're close to unstable. Measure again at 15W, and then think about going from there.
I feel I should know this already, but what is known about the QPD failure (circumstance at failure, failure mode, etc.)
It's not totally clear to me yet what the exact problem was. R.McCarthy is looking into why (apparently) putting the PI chassis spoiled the signal. Removing the new PI chassis seems to have fixed our problems. See alog 26328 and comments for symptoms and Rich's comment.
The PI AA was off and its OpAmp inputs were probably 'shorted' to ground due to the input protection diodes.
I am designing the input circuitry for the ITM PI Driver using the same input chip as that used on the ETM PI AA, so I will hedge our bets by including some input protection circuitry (current limit and clamp) to avoid this if that turns out to be the case.
In the lab, Fil reproduced the situation at EX by connecting a function generator to a coil driver test box (D1000931) and only used the single to differential converter of the board inside (D1000879) to drive the input of unpowered PI bandpass, and daisy chained to powered AA board.
Things looked OK until the PI input reached about +-1V differential (that's +-500mV positive and -+500mV negative), anything larger than that and the voltage started to be pulled down. Looked like a diode and a small resistor in series to me. As soon as the PI bandpass was powered on, everything got back to normal.
Daniel is correct. The chips used on the input to the PI filters have internal input protection diodes that will (up to the limit of their current handling capacity, which is not much over 10mA or so) clamp the voltage from the QPD amplifier to something around a volt. This is not a problem if the PI BPF is powered, which is the normal state of the system. This event prompted a redesign of the differential input to the ITM ESD Driver to avoid this in the future. Another case of incremental learning.
Darkhan, Kiwamu,
We found that the optical follower servo (aka OFS) for the Pcal Y had stopped running. Pressing around some buttons on the medm screen, we could not make it back up running. We are suspecting some kind of hardware issue at the moment. According to trend data, it seems that it stopped running at around 18:30 UTC on Mar 18th for some reason. We will take a look at the hardware in the next Tuesday during the maintenance period.
J. Kissel, E. Hall, [R. Savage via remote communication at LLO] This was re-discovered again tonight. Opened FRS ticket #5241 so we don't forget. Email sent to E. Goetz and T. Sadecki suggesting they address on Monday 4/4. Further information from our re-discovery: Looks like Kiwamu had left the calibration line amplitude in a low / off state. We restored the line amplitudes to nominal, and it caused excess noise in the DARM spectrum (lots of lines, a little bit of elevated noise floor). We don't see any sine-wave-like excitation in the OFS, TX, or RX PDs with a single calibration line on at reasonable amplitude (which is contradictory to elevated noise in DARM). Rick suggests: - Check the AOM. - Check the shutter. - Check that the laser hasn't tripped.
All done, ISCT6 was moved to the side of HAM5, JeffB is covering the duct opening on ISCT6. (JeffB, Richard, Kyle, Keita)