These are trends from the past 10 days
Dan, Evan
We measured the dark noise of the OMC DCPDs with the IMC unlocked and MC2 misaligned. (We also trimmed the dark offsets.)
The attached xml file & plot has measurements of OMC-DCPD_{A,B}_IN1 and _OUT with zero, one, and two stages of analog whitening enabled (and the corresponding digitial dewhite filters). The y-axis units are in cts/rt[Hz] for the IN1 channels, mA/rt[Hz] for the OUT channels.
With zero whitening (the case for the locks last night), the ADC noise is about 7x10^-3 cts/rt[Hz] at IN1. Last night our noise was about 10x larger than this (see upper left plot here).
Some notes about the conversion of the DCPD signals from counts to milliamps in the DCPD filter banks:
In the noise budget, we have
These agree with each other.
In response to yesterday's locking activity (alog 16628), I newly added the DARM->M0 damping path in the QUAD suspension models under WP 5047. This allows us for damping the bounce mode through the M0 stage using DARM signals as was done in LLO (LLO alog 16686).
(h1susi(e)tmex(y) models are modified)
Right now the modifications are completely local in the sense that I did not change the common QUAD master block but the local front end models, namely h1susetmx, h1susetmy, h1susitmx and h1susitmy. In these front end models, I disabled the link of the QUAD master block in the top layer so that they are now detached from the common QUAD master. I then added the DARM damping filters by coping the filters from Livingston's. I copied them from l1susetmx.mdl. Note that the latest-latest l1 quad suspensions are capable of routing the WFSs signals in addition to the DARM damping, but we don't have this at the moment.
I checked in all the four quad models into svn.
(some screens)
I then updated the medm screen, common/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl (see the attached) which is a variant of what LLO currently has. I have not checked this screen into svn. Jeff will take care of it. Also I added a new screen, SUS_CUST_QUAD_M0_DAMP.adl which displays the filters. This is a duplication of what LLO locally has. Neither of the sites checked this screen in yet.
EY bounce filters are copied from LLO.
The attached PDFs show the resistance measurements for all RHs and the relative resistance vs time for the RHs as 1W is applied to each segment. All segments are operating within nominal parameters.
The resistances for the segments are:
Segment | Resistance (Ohms) |
ITMX UPPER | 44.0 |
ITMX LOWER | 42.4 |
ITMY UPPER | 40.7 |
ITMY LOWER | 42.5 |
ETMX UPPER | 41.9 |
ETMX LOWER | 41.0 |
ETMY UPPER | 42.2 |
ETMY LOWER | 43.6 |
Just for reference, here is the transient thermal lens in ITMX, as measured by the HWS, from this morning's 2W RH test (~1800s of applied power).
A follow-up. The data from the RTD temperature sensors for each RH is plotted in the attaced PDF.
The ETMY and ITMX RH RTDs are non-responsive.
J. Kissel, I've updated the /opt/rtcds/userapps/release/sus/common/medm/ directory to receive a few overview screen and BIO screen updates that Stuart and Joe have made, see BSFM LHO aLOG 16368 QUAD LHO aLOG 16760 jeffrey.kissel@opsws3:/opt/rtcds/userapps/release/sus/common/medm$ svn up Restored 'SUS_DRIFT_MON_SMALL.adl' U bsfm/SUS_CUST_BSFM_BIO.adl U bsfm/SUS_CUST_BSFM_OVERVIEW.adl U quad/SUS_CUST_QUAD_BIO.adl Updated to revision 9804.
Turned off earlier to allow Thomas and Elli to enter end X.
BCS9 illumintator turned off at 11:30 PT.
Due to some extenuating circumstances, Travis, Richard, and I moved the remaining hardware out of the 2 large 16' assembly cleanrooms in the west bay of the LVEA and turned them off. There is still a small cleanroom on against the West wall of the LVEA which we will turn off in a few weeks when we are finally finished kitting 3IFO hardware.
Note, we also turned the dust monitor off that was in the room since it started alarming when we turned the rooms off (was after 10am so were rushed to finish up and vacate). Of course, we should turn the monitor back on and reset the alarm thresholds...
12 hour OpLev trends starting 5:51:04 UTC. No obvious issues.
All scans look normal except the frequency scan (dbb_frq-001.pdf); scan shows some interesting features between 1 and ~20 Hz. As of our PSL maintenance yesterday we know there are some issues with the FSS system (see alog). We will continue to investigate this as time, and commissioning, allows.
Just getting ranges correct and consistent for display of reds & greens. All pressure lights are now Green and OK. The SERVO database is set up so restart does not affect the HEPI platforms too much. I of course would not do this if anyone was running any tests. The times are: EY 1603, EX 1619, CS 1638utc. Attached is 40 minutes of second trends with these times annotated. The corner station pressure glitch was non existent, the ends had glitches of a few PSI.
When I look at the HEPI L4Cs during this pressure glitch, it looks like it is absorbed into the normal background glitching. See the latter two attachments.
The database still has the old PID parameters. We will update these once we finish the plant analysis. Anyway, we have been running different parmeters for the LVEA Pumps and I forgot to change these (with the medm) when I restarted it. I've just now corrected this--again this should only make things better (reduce sensor noise coupling) and the transition should have been transparent.
SEI: nothing to report SUS: nothing to report Aidan and Alastair: Ready to put TCS 3IFO parts in LVEA CDS: PEM work, cabling microphones, H2 room work Facilities: beam tube cleaning Safety meeting at 3:00 in LSB
Sheila, Dan, Daniel, Evan Jeff, Lisa, Alexa
Starting at 08:43:06 UTC Feb 11, 2015 we had a DC lock for ~1:54min. We lost lock again because of the 9 Hz bounce mode in ETMY. We had tried damping with the L2 stage, which helped a bit but still ultimately caused the lock loss. Tomorrow we should try damping with M0, as done at LLO (LLO#16686).
Sheila has pointed out that we might as well notch out the bounce mode resonances in the DHARD WFS loops. So now there is a 9.8 Hz stopband filter installed in FM9 of DHARD_P and (in an abundance of caution) in DHARD_Y.
Nice going with all the long lock segments. Once something is working you learn a great deal quickly.
Some important times from the lock:
Lock sequence started at ~8:17 UTC when arms locked on green
Handoff to POPAIR at 8:27 UTC (this is the last step in the ISC Guardian before the handoff to DC readout - see LSC matrix element 3_10 in the attached plot)
DARM offset applied and OMC locked at 8:40
DARM handoff to DC readout at 8:44
Lock lost at 10:36 UTC
We have seen in our two DC readout locks tonight what looks like it could be a fringe wrapping shelf in DARM.
We transitioned to DC readout at 8:43:06 UTC Feb 11 and it is still locked. If anyone could make a spectrogram of LSC-DARM_ERR durring this time, that would be interesting. We made an attempt to do this using ldvweb, but didn't suceed yet.
I've attached 4 spectrograms of DARM_IN1_DQ: 1. 20 minutes elapsed 2. 20 minutes elapsed normalized (divided by median ASD) 3. 1 hour elapsed 4. 1 hour elapsed normalized I'd be happy to make a few more if ldvw is still being problematic for you.
The summary pages are automatically generating calibrated spectra/spectrograms of the CARM and DARM error signals whenever the ISC_LOCK guardian is 'OK'.
J. Kissel, B. Abbott Over the past few weeks, I've been building up understanding of the HEPI pump servo -- more than I ever wanted to know. The conclusions from all this? (1) The EPICs calculation of the PID loop (documented loosely in the EPICs manual here) (a) uses backwards differentiation approximation and velocity formalism to compute the *change* in control output value, which it then adds it to the previous cycle's control output value -- which turns it back into a "position" algorithm -- i.e. one *doesn't* have to differentiate the pole and two zeros of the P, I and D. Other good references I found are here, here, and here. (b) expects the "I" and "D" terms in [cycles / min] or [mins / cycle], respectively, i.e. it depends on the sampling rate / clock cycle turn-around time of the PID calculation. If you want to do any sane prediction of the filter shape, you've got to convert these to [rad/s] or [s/rad], again respectively, by multiplying by 60/(2*pi*Ts) [(min/sec).(rad/cycle)] or (2*pi*Ts)/60[(cycle/rad).(sec/min)]. (2) The EPICs turn-around time, or clock cycle, for the discrete PID controller calculation is longer than the requested sampling frequency, which means the sampling rate is determined by the clock-cycle. Further, it's slower in the corner station than the end stations. We should lower the EPICs record's demand of the sampling frequency from 10 [Hz] to 1 [Hz] (and check again if the PID can turn around the calculation fast enough). (3) The HEPI Pump servo contains a second-order, 16 [Hz], Sallen-Key, anti-aliasing filter before the input to the ADC on all pressure sensor channels (see D0901559, pg 2) (3) We should lower the PID parameters such that the UGF of the loop is ~ 1 [mHz]. Why? (a) The pressure sensors were never meant to be used as AC sensors. LHO aLOG 16500 hints that they shouldn't be used in a loop above a few [mHz]. (b) The ADC noise of the Athena II, PC 104 computer is an abysmal 1e-2 [V/rtHz]. As they are currently amplified, the pressure sensor's signal gets buried in this ADC noise by ~10 [mHz]. (c) Adding an EPICs "smoothing" parameter (a.k.a. SMOO) to the EPICs version of the pressure sensor channels adds a single-pole low-pass filter into the control loop. If sufficiently low in frequency, it'll start to creep in on your already-small phase margin. We should use this with caution, or at least be cognizant of its impact. ------------- Details. I attach 5 plots per pump station: Pg 1: On the EPICs turn around time defining the sampling rate In my perusing of the EPICs manual, I found that the PID channel, e.g. H1:HPI-PUMP_EX_PID, has sub records, one of which is "DT," which one can query with a simple caget: jeffrey.kissel@opsws8:/$ caget H1:HPI-PUMP_EX_PID.DT H1:HPI-PUMP_EX_PID.DT 0.312006 This is "the time difference in seconds between processing steps." Consequently, I caget'd this sub record 5000 times. This turned out to be faster than the EPICs calc record would update the number by 3, so I took every third report. Then I histogrammed the results, to find that the clock cycle is 0.55 and 0.28 [sec] (!!) for the corner station and both end stations, respectively. The end stations show some clock jitter, but I took the mode of the 1667 points and used that as the clock cycle. This immediately informs us that the features seen in all ASDs that happen at 1.8 [Hz] and 3.5 [Hz] at the corner and end stations are just a function of the terribly slow sampling rate -- even slower than the EPICs 16 [Hz], and the request calc record rate of 10 [Hz]. Pg 2: On EPICs Implementation Discrete PID Control It's too difficult in a simple text editor to really do the explanation any justice, but check out all of the references I show above, while you wait for coherent presentation version of this aLOG. One of the many reasons why my initial guess at what the servo was doing (in LHO aLOG 16447) was incorrect was because I wasn't accounting to the time delay of the discretization. As I found out later, it turned out that the discretization was much slower that was defined in the EPICs calc record. Pg 3: Modifying the measured plant (see LHO aLOG 16601) with the anti-aliasing filter, and an EPICs smoothing filter On the SMOOOOOOO at EY Hugh's initial instinct to combat the newly-noisy differential signal was to add some EPICs sub-record defined "smoothing factor" to the supply and return channels which form the differential pressure signal. Again, from the EPICs manual, "The converted data value is subjected to the following algorithm: val = newvalue * (1 - smoo) + oldvalue * smoo SMOO should be a value between 0 and 1, with 0 meaning no smoothing and one meaning ultimate smoothing (in fact the data will never change)." *sigh* who writes these manuals? Thank god they wrote out the algorithm. This is just the discrete realization of a first order low-pass filter. The pole frequency of which is defined by f_{pole} = 1/(2*pi*Ts) * ln(1 / (1 / alpha)) Hugh had entered in a SMOO of 0.75, which at a dismal sampling rate of Ts = 0.28 [sec], means the pole frequency is at 0.159 [Hz], which explains *some* of the excess gain peaking that we see at EY. Pg 4: Loop Design figures of merit given the now-(mostly)-understood plant and controller Pg 5: Model of closed loop ASD noise Clearly I'm still missing some phase loss term that increases the gain peaking, but at least I get the suppression correct. I could hunt around for several more days as to why this is, and find some other nasty EPICs trickery. But I'm not gunna.
Rick S., Jason O., Matt H., Ed M., and Jeff B.
Went into the PSL today and performed a few maintenance tasks (work permit #5039).
1) Measured PSL power at several points in the beam path:
3) Measured voltage of RefCav REFL PD (H1:PSL-FSS_RFPD_DC_OUTPUT):
Once again the RefCav Trans PD (TPD) has begun to drift down. Was set to ~1.6V on 1/5/2015 (see alog 15871) and today is reading ~0.9V. Therefore we adjusted the RefCav alignment by adjusting the vertical and horizontal of the top periscope mirror. Measured voltages at the RefCav REFL PD.
After adjustment (and locking of adjustment screws):
Will keep an eye on this as the RefCav transmitted power seems to drift down suddenly. We’re not sure what’s causing this apparent alignment drift. All the measured powers leading up to the RefCav were close to those measured during the 1/5/2015 adjustment, but the RefCav TPD was still reading ~44% less.
4) We also measured the UGF of the FSS:
5) For Daniel, we adjusted power at IO PD (IO-AB-PD3-DC) to 3.3V by turning up the PD gain by 3 clicks and adding a ND filter to the PD (see Daniel's earlier alog).
6) We are now storing the 2 3IFO PMCs in the NW corner of the PSL LAE on a cart, with their lids off.
Now that have a measured power budget here at LHO for some areas of the PSL table (note for completeness that the power readings at LHO were done using 250W water cooled meter and at LLO using 50W air cooled meter) we can compare the losses through the system to (and after) the PMC.
Position | LHO | LLO |
---|---|---|
(1) Out of MOPA (35W laser) | 33W | 34.25W (alog 16569) |
(2) After faraday in HPO | N/A | 31.44W (alog 16569) |
Delta (1) - (2) | N/A | 2.81W |
(3) At HPO window with corona aperture out | N/A | 29.1W (alog 16569) |
Delta (1) - (3) | N/A | 5.15W |
(4) In front of PMC (ISS off) | 27.2W | 28.75W (alog 16569) |
Delta (1) - (4) | 5.8W | 5.5W |
(5) Power Trans (power out of PMC) | 24.9 W (ISS off) | 26.9 W (from todays monitor screen (ISS looks to be on)) |
Throughput ((5)/(4)) | 91.5% | ~93.5% (probably slightly better if ISS was off as (5) would be slightly higher) |
Visibility | 93% (alog 16576) | |
Delta (1) - (5) | 8.1W | 7.35W |
(6) After EOM (ISS off) | 24.4W | 25.7W (alog 16576) |
So basically the performance of the two laser systems are similar. LLO has slightly less loss from the output of the MOPA to the input of the PMC (5.5W loss at LLO compared to 5.8W at LHO). Also LLO has slighlty less loss of power once comes out of the PMC as well (LLO ~7.35W dropped from output of MOPA to output of PMC, compared to 8.1W at LHO). But all in all the two systems in terms of loss through the PSL components is very similar
Here is a 60 day trend of the FSS RefCav transmission (H1:PSL-FSS_TPD_DC_OUT_DQ) showing the two drops in PD voltage we've seen in the last couple months. The first occurred around 12/25/2014 and was adjusted on 1/5/2015. The latest drop happened around the middle of last week and we adjusted it yesterday.