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).

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.

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:

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.

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.

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).

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.  

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:

• 33w - between M1 & M2 (just outside of the front end)
• 26w - reflected from PMC
• 27.2w - incident light on PMC
• 24.4w - downstream of the EOM (in the IO section of the PSL table)
• 24.9w - PMC transmitted

• 67.5mW – upstream of the FSS AOM
• 54.5 mW - Single pass power, upstream of M25 (81%)
• 36.3mW - Double pass power, upstream of FSS EOM (66%, 54%)
• 33.7mW – At top of periscope mirror, incident on RefCav

3) Measured voltage of RefCav REFL PD (H1:PSL-FSS_RFPD_DC_OUTPUT):

• 299mV – With FSS RefCav unlocked
• 165mW – With FSS RefCav locked
  • This is too high, giving a RefCav visibility of only 45%!

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.

• Vertical adjustment dropped RefCav to 83mV
• Horizontal adjustment dropped RefCav to 65mV

After adjustment (and locking of adjustment screws):

• RefCav REFL PD - 300mV (with FSS RefCav unlocked)
• RefCav REFL PD - 60mV (with FSS RefCav locked)
  • This gives a FSS RefCav visibility of 80%, which is better.  Per Rick S. this should closer to 98%, so some more work to do here, but is good enough for now and we were running out time in our maintenance window.
• RefCav TPD - 1.63V (H1:PSL-FSS_TPD_DC_OUTPUT)
• RefCav transmitted power - 19.1mW

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:

• UGF: 200kHz, phase margin 35 deg
  • According to Rick S. this should be closer to 600kHz, so we have some work to do here.
• At 500kHz: -6dB, phase margin 58 deg 

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.