From Linda and Bram:

X,Y arms were stabilized using ALS and moved 5 nm from the resonance, PRMI was locked on sideband using REFL165 I&Q. POP angular servo was running; PRMI RIN was good (~2-3%)

During slow offset reduction I was sweeping MICH, PRCL and POP servos for instabilities due to possible optical gain variations, loops were fine.

I could reduce offset down to ~200 pm and then lost lock due to 60 Hz oscillations as shown on the attached plot "arm_offset"

Arms were stabilized with RMS comparable to the offset and power in arms was fluctuating from 3 to 45.

60 Hz line most probably comes from MICH. RMS is dominated by the power lines and is ~ 1 nm as seen on the plot "PRMI_CAL". I think this is too much but we need to do simulations.

Attached is matlab code that I used

 % IMC OL
G = zpk(-2*pi*8964, 2*pi*[-10; -10; -10; -1000; -274000], db2mag(242.5)) * ...
    tf([1 0.8*1.55e+05 3.1806e+10], 1);

% CARM PATH
CARM = G/(1+G);

% Common mode boosts
BOOST = zpk(-2*pi*4000, -2*pi*40, 1);
BOOST1 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST2 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST3 = zpk(-2*pi*4500, -2*pi*300, 1);

% Coupled cavity pole
CCPole = zpk([], -2*pi*100, 2*pi*100);

% Servo gain
Gain = db2mag(43);

% CARM OL with boosts
H = CARM * CCPole * BOOST * Gain;
H1 = H * BOOST1;
H2 = H1 * BOOST2;
H3 = H2 * BOOST3;

% Plot
% bode(H, H1, H2, H3, 2*pi*logspace(3, 5, 10000));
% bode(1/(1+H), 1/(1+H1), 1/(1+H2), 1/(1+H3), 2*pi*logspace(3, 5, 10000));

Last time we designed MCL loop with UGF ~ 30 Hz and I think, it was hard to lock the arm because of large frequency noise injected to IFO.

This time I made a low bandwidth MCL loop with UGF=8 Hz. MCL error RMS is suppressed by factor of 10 and arms lock fine.

Attached plots show MCL OL, MCL error suppression and frequency noise injection to arms.

It is interesting that spectrum of arms increases below 1 Hz meaning that IMC sensing noise dominates in this range.

I did not include the loop into the IMC autolocker. I think it is necessary to turn it on only during day time activity and when beatnote is moving too much during arm stabilization.

 These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?

We should be able to estimate the noise coming out of the MC using the single arm and then make a guess for the CM loop gain requirement. There's no reason to keep the old Boost shapes; those were used in the old MC configuration which had a RefCav. In addition to minimizing the EOM range, we should also minimize the AO signal as Koji has pointed out. In practice, I've seen that using ~300 Hz of offset makes no harm with 4 kHz MC pole.

I had a look on x,y arms stabilization using ALS. Input green beam was misaligned and I was loosing 00 every few minutes. I vent on the floor and realigned green beams.

YARM alignemt was smooth - transmission increased from 0.4 to 0.85 with PSL shutter off.

XARM was tough. Steering mirrors did not have any derivatives when transmission power was 0.5. I walked the beam with piezos but got only 0.55. It seems that the input beam is mismatched to the cavity. When the transmission was 1 last time? Does anyone have a model of the xend table to compute mode matching?

Input green alignent was improved and I could keep arms stabilized for periods of ~30min - 1 hour. Still not forever.

I noticed that ALS_XARM and ALS_YARM servos have limiters of 6000 and control signal had high frequency components that were not rolled off as shown on the plot "ETMY_DRIVE". I have added a low pass filter that reduced RMS by factor of 5 and took 7 degrees of phase at UGF=150 Hz. Now margin is 33 degrees.

Then I excited ETMY longitudinally at 100 Hz and measured first and second harmonics of the YARM RIN. I got total DC offset of 0.3 nm. This means significant length coupling to RIN. First of all, "scan arm" script does not tune the offset very precise. I guess it looks at DC power, checks when cavity passes through symmetrical points of the resonance and takes the average. It is also useful to look at POX/POY and confirm that average is 0. Plot "ALS_RIN" shows comparison of YARM power fluctuations when it is locked using IR and stabilized using ALS. By manually correcting the offset I could reduce length coupling into RIN, coherence was ~0.1.

Cavity RMS motion also couples length to RIN. Plot "ALS_IR" shows YARM error signal. I also looked at POY signal (LSC-YARM_IN1) as an OOL sensor. At low frequencies POY sees only IMC length fluctuations converted to frequency. I have engaged MCL path and ALS error and LSC error signals overlaped. Cavity RMS motion is measured to be 200 pm.

Looks good.

Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.

We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL.

I have modified/compiled/installed/restarted c1scx and c1scy models to include arm transmission QPDs in angular controls.

For initial test I have wired normalized QPD pitch and yaw outputs to ASC input of ETMs. This was done to keep the signals inside the model.

QPD signals are summed with ASS dither lines and control. So do not forget to turn off QPD output before turning on dither alignment.

Medm screens were made and put to medm/c1sc{x,y}/master directory. Access from sitemap is QPDs -> ETM{ X,Y} QPD

 It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.

Frequency response of the servo is taken from the document D040180. I assumed coupled cavity pole to be ~100 Hz.

The only question is if our EOM has enough range. Boost 2 increases noise injection by 10 dB in the frequency range 20-50 kHz. Boost 3 has even higher factor.

 The temperature went down to room temp with temporary fan in the back. Voltage and current are stable.

Regardless, it will be replaced early next week.

rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.

I have calibrated ETMX and ETMY actuators and added a template armSpectra.xml into /users/Templates directory.

Template shows control and error signals of both arms. Procedure is standard: calibrate control to meters and match error based on UGF measurement. XARM UGF: 200 Hz, YARM UGF 210 Hz.

Noise level at high frequencies (>100 Hz) for YARM is 3*10^-15 and is factor of 3 better then for XARM. Servo gains are in the same ratio. I think there is less light on POX than on POY RF PD because I checked phase rotation and analog gain. I assume transimpedances are the same.

I'm not as good as a fit, but it seems that there is a loop delay of about 30 microseconds, looking at the high frequency phase. This might explain the limitation on the BW. Eric should be able to get the delay out of the fit with some care.

According to the measurement by Eric, the X-arm green PDH UGF is too low. We still have some room to increase the gain.

The out of loop stability of the ALS for each arm should be measured everyday.
Otherwise we can't tell whether the arm is prepared for advanced locking activities or not.

We expect to see the arm stablity of ~50pm_rms for the Y arm and ~150pm_rms for the X arm.

[Jenne, Den]

Tonight we worked on tweaking up the PRCL new ASC, and then PRMI+1 arm locking.  We were unable to get the Xarm to stay locked on a TEM00 mode for very long, and after an hour or two of using the PZTs to try to align the beam to the cavity, we gave up and just used Yarm green.

NB: We haven't done anything to MCL, although it is not in use.  Den is still going to get around to elogging what servo shaping he changed on that last night.

I wrote a script that will handle the transitions between the new PRCL ASC and the PRM oplev and local damping.  The script is accessible from the PRC ASC screen, and will detect when the PRMI is locked or not.  When it is locked, it will turn down the PRM oplev gains and turn on the ASC, and then it will turn off the local shadow sensor damping for PRM pitch and yaw.  When the PRMI unlocks, the script will turn off the ASC and restore oplev and local shadow sensor damping. 

We saw that the bounce mode of the PRM was getting rung up with our new ASC, so we included a band stop in the ASC, and also turned on the triggering for the PRCL LSC FM6, which has the resonant gain for the bounce mode (as well as roll, and the stack mode).  This made the PRMI spot very stable. 

We then moved on to green arm locking.  The Yarm is behaving perfectly nicely (as nice as it has been lately - it's alignment and mode matching could also use some work), but Xarm was giving us a bit of trouble.  As always (since the PZTs were installed?), the mode matching isn't excellent for the green to the arm, so it can be hard to catch a TEM00 mode.  Also, even if we did catch a good mode, it would often not stay locked for more than a few tens of seconds.  We tried several alignment tweakings, and several different end laser temperatures (within the confines of seeing the beatnote under 100MHz), and didn't have a lot of success.  It looks like Eric had the slow servo engaged for the Xend laser, so the temperature offset was something like +300,000, which seemed totally crazy.  I turned that off, and found the beatnote somewhere around output of -10,300.  So, I haven't gone to the end to look at the temperature, but it's going to be different than when Eric was taking measurements this afternoon.  It seems like the main problem with the Xarm is poor mode matching - the maximized input pointing for TEM00, when you unlock and relock the cavity, is just as likely to give you a TEM_9_0 mode, as TEM00.

So, we gave up on the Xarm for the evening, and tried PRMI+1arm, with the new PRCL ASC.  This was successful!   The Yarm beatnote was around laser slow servo output of +4450.  Beatnote at 46.0MHz, -26dBm.  We found the IR resonance, moved off, locked the PRMI, transitioned to the new ASC, and brought the Yarm back to IR resonance.  What we see is that the power fluctuations in the PRC are much smaller than they were back around Halloween (elog 9338), however the arm power fluctuations still seem very, very large.  This is certainly partly due to the fact that we haven't done a thorough Yarm alignment since before messing with the greens, so we will have drifted somewhat.  Also, the ALS beatnote sensor isn't perfect, so won't be perfect at holding us near resonance. 

Den is thinking about whether we can use the arm transmission QPD signals to feed back to the ETM ASC servos, to try to reduce the RIN in the arms.  I feel like we should also see if this amount of power fluctuation can be explained by our ALS noise, because maybe we'll be fine once we transition to IR and turn off the ALS system.   Attached is a plot showing that the arm's RIN is coherent with the spot motion seen by the transmission QPD, so we need to check the alignment of the cavity, as well as consider using the trans QPD in an ASC feedback loop.

Here is a plot of the PRC sideband power, as well as the Yarm transmission.  The GPS time for this plot is approximately 1070963372.

OK, the next question will be "why the loop bandwidth is so miserable?"
In other words, what is preventing us to have the bandwidth of 20~30kHz?
Your breaking down will give us the answer.

The ITM oplevs were pretty close to the edge of their ranges, and none of the oplevs have been centered in a while, so I centered ITMX, ITMY, BS, PRM after having done alignment (arms, then PRMI).

With the newly repaired PDH board, I spent some time with the x arm green PDH loop. I found it SO MUCH EASIER to measure the OLTF by injecting before the servo, instead of after it. (i.e. I added a swept sine from the SR785 to the mixer output (error signal) before the servo input). This is likely because the error signal is much flatter. I used a 10mV excitation across the whole frequency range (30-100kHz). 

Here's the OLTF. I'm working on fitting it and breaking it up into its constituent TFs, then making a rudimentary noise budget. 

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

In order to accomplish CARM control with the PSL laser frequency, we use two actuators.

One is the longitudinal direction of one of the MC mirrors. The londitudinal motion of the MC induces
the laser frequency control via the MC servo. As we move the mirror, the range is sort of big,
but the BW is limited by the mechanical response.

The other is the additive offset path. We inject a signal to the additional input port of the MC.
The MC servo supresses this injection by giving the same amount but oppsite sign offset to
the error signal (before the addtion of the inputs). The bandwidth of this AO path is limited
by the bandwidth of the MC servo. Basically the BW of the AO path is about 1/10 of that of the MC servo.

In order to confirm the capability of the AO path as a frequency actuator, 1) OLTF of the MC servo
2) TF of the AO input to the servo error was measured.

Attachment 1 shows the openloop TF of the MC servo. The UGF seems just little bit higher than
100kHz. The OLTF is empirically modelled by LISO as seen in the figure.

Attachment 2 shows the TF from the additive input (In2) to the error monitor (MC Servo module Q error mon).
The gain setting of the MC servo box was: In1 +18dB, In2 0dB. The measured TF has arbitorary gain 
due to the gain setting, the measuemrent data was multiplied by 4 to mach the DC value to the unity.
This is to compare the measurement with the prediction from the OLTF.

The AO path TF is expected to show the character of -G/(1+G) where G is the OLTF. In my case,
G = 0.75*OLTF showed the best maching. There might have been some misalignment of the MC
upon the AO path measurement as I found after the measurement.

From the plot , we can see that the response is flat up to 20kHz. Above that it rapidly raises.
This should be dealt with the CM servo filter as the bump may hit the unity gain. Since we have to use
strong roll off to avoid the bump, this will eat the phase margin at low frequency.

In the case that we don't like this bump:
This bump is caused by low phase mergin of the OLTF at 30~40kHz. If the total gain
is increased, the bump is reduced. Or, we can decrease the PZT loop gain in order to
reduce the dip at the crossover ferquency between the PZT and PC loops. In both cases,
the PC path suffers more actuation. We may need to think about the HV actuation option
for the PC (Apex PA85).

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

Jenne, Den

Today we worked on PRM angular servos and Y-arm ALS stabilization.

In the current PRMI angular control configuration two servos simultaneously drive PRM - oplev and POP ASC. We considered 2 ways to redesign this topology:

• once lock is acquired, turn on POP ASC servo that corrects oplev error signal
• turn off PRM oplev and turn on POP ASC  servo

The first option requires model rewiring so we started from the second one. We had to redesign POP ASC pitch and yaw servos for this because PRM TF has changed. Attached is servo OLTF.

This method worked out well and once PRMI is locked we turned off oplev servo with ramp of 0.5 sec and enable ASC POP servo with ramp of 1 sec.

Once PRMI was locked and ASC running we have turned off PRM angular local damping that presumably prevents us from bringing arms into resonance due to IR coupling to shadow sensors.

PRMI was stable using only ASC POP servo and we moved on to ALS. We found Y-arm beatnote and enabled control to ETMY.

Cavity was stabilized but not robust - we were loosing IR in a minute because green relocked to 01 mode with transmission equal to more than half of 00 mode. This is probably due to angle to length coupling of ETMY.

We were also loosing IMC during cavity stabilization. We made MCL servo and will tune it tomorrow looking at the arm spectrum as an OOL sensor.

What a such long pain we suffered.

After more than three years from Kiwamu's discovery, the PDH box 50kHz oscillation issue was finally solved.

This "weird peak at 50kHz" was caused by the oscillation of the voltage regulator (ON's MC7912).
As it imposed common noise almost everywhere, it screwed up transfer function measurements
like EricQ saw recently.

The negative voltage regulator (79XX) tends to get unstable than the positive counter parts (78XX).

The oscillation was removed by adding 22uF electrolytic capacitor between the output pin (pin3) and the ground pin (pin1) of MC7912.
This is indeed more than 20 times of the specification you can find in the data sheet.

I *finally* figured out how to bend Matlab to my will, and close a very simple oplev loop using LQR technology. 

This is super, super simple, but it's a step in the right direction.  There is no noise, just a simple pendulum with a resonant frequency of 0.75Hz, and a Q of 10.  The LQR tries to keep the position of the pendulum at a minimum, and does not care at all about the velocity.  You cannot (with Matlab's LQR, at least that I can find) make it care "0" about the control output, so it cares about the control output a factor of 1e-4 as much as the position.

Here are some plots:

The first plot has the open loop system (just the pendulum, no control at all), as well as the closed loop system (the pendulum under control).

Plot 2 is the open loop gain of the controller that the LQR designed.

Plots 3 and 4 are the step and impulse responses of the open loop (pendulum with no control), and closed loop (pendulum with feedback) systems.

The conclusion from the plots (if this were an interesting system) is that it doesn't take much to damp an ideal pendulum.  The real conclusion here is that I think I now know how to use the Matlab LQR function, and can make a loop with some noise now.

Yesterday evening I inspected at IMC servo as a preparation of the CM servo recommissioning.

More details to come.

 New razor beam dump installed to trap reflected beam of the input vacuum window.

Aluminum shield replaced by razor beam dump.

In order to unify the theme for MEDM screens, I'll have to make many combinations of rectangles, polygons, and invisible related-screen buttons.
Everytime I change the size of the block, I have to modify the size of this combination. It is impossile for me.

So, I made a script to replace a certain type of rectangles with a combination of the objects with the same (or related) size.

The script is here (so far)

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

So far, there is only "TYPE1" for the predefinition. It actually takes another argument to specify the
path of the related screen to open when the block is clicked. The path should be filled in "Channel B"
slot of the original rectangle. (See Attachment 1)

The "TYPE1" style has the function calls as indicated below. place_rect is to place a rectangle object. You can
specify the filling method and color. place_rel_disp is to place an invisible button with the link to the specified
path by strOpt. place_polygon places a polygon. The cordinate array for the polygon is described with
the relative positions from the specified position.

        place_rect(rect_x-4,         rect_y-4,        rect_w+7, rect_h+7, "outline",  0) # outline white box
        place_rel_disp(rect_x, rect_y, rect_w, rect_h, strOpt, 0, 14)                    # invisible button
        place_rect(rect_x,           rect_y,          rect_w,   rect_h,   "fill",     3) # main gray box
        place_rect(rect_x+3,         rect_y,          rect_w-6, 3,        "fill",     0) # top white rim
        place_rect(rect_x,           rect_y,          3,        rect_h-3, "fill",     0) # left white rim
        place_rect(rect_x+rect_w-3 , rect_y,          3,        rect_h,   "fill",    10) # right gray rim
        place_rect(rect_x,           rect_y+rect_h-3, rect_w-3, 3,        "fill",    10) # bottom gray rim
        place_polygon(rect_x+rect_w-3,rect_y,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # top-right white triangle
        place_polygon(rect_x,rect_y+rect_h-3,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # bottom-left white triangle


I worked on the CDS related stuffs for LSC yesterday and today.

1. Slow machines:

I checked the database files for c1iscaux and c1iscaux2 (slow machines). They are mainly
used for the control of LSC whitening filters. The channel names were totally random as we
reconfigured the RF PDs while the channel names had been unchanged.

- Now the database was modified so that the PD name and the channels are related.
- saverestore.req and autoBurt.req were also changed accordingly.

- PD interface channels are completely random. Don't use them.
- I found the whitening of DCPDs are not effective.

- We need to clean up /cvs/cds/caltech/target directory. The autoBurt requests in the old targets
are making unnecessary burt files.

2. LSC screens

- The channel names on the LSC OVERVIEW screen was modified. (Attachment 1)
- A new LSC Whitening screen was made. (Attachment 2)

3. LSC screen generator

To touch the main LSC screen is very tough. The screen was split in to several sub screens
and combined with a command.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/generateLSCscreen.py

This command combines the multiple adl files into a single file with x&y offsets.
This way, you can work with the each section of the screen.
Also, moving the blocks are just easy.

4. LSC Code Bug?

During the screen making, I found that a couple of the whitening switches are not
working properly. e.g. When AS165 (either I or Q) FM1 is activated throught the whitening trigger,
the MSB bit (bit15) of the binary I/O (C1:LSC-BIO_0_0) does not .

SImilarly ASDC FM1 does not toggle bit15 of C1:LSC-BIO_0_1.

The other channels seems OK.

At first, I thought this is a bug of "Bit2Word" block. But an individual test of the block showed that
the block is not guilty. So why is only Bit15 malfunctioning???

 IOO pointing monitoring qpds received razor beam dumps on their refs.

The Pos QPD was rotated and recentered.

The Ang QPD was left untouched.

TREND plot of 23 days is attached.

Yesterday, made a slew of measurements on the X-arm when locked on green. By tweaking the temperature loop offset and the green input PZT pointing, I was able to get the transmitted green to around 1.0. The PDH board gain was set to 4.0. I had trouble making swept sine measurements of the OLTF; changing the excitation amplitude for different frequency ranges would result in discontinuities in the measured TF, and there was only a pretty narrow band around the UGF that seemed to have reasonable coherence.

So, I used the SR785 as a broadband noise generator and measured the TF via dividing the spectra in regions of coherence. Specifically, I used the "pink noise" option of the SR785. I also used a SR560 as a low pass to get enough noise injected into the lower frequency range to be coherent, while not injecting so much into the higher frequencies that the mode hopped while measuring. 

The servo board TF was easily fitted to a 4th order zpk model via VFIT, but I'm having trouble fitting the OLTF. (There is a feature in the servo TF that I didn't fit. This is a feature that Zach saw [ELOG 9537], and attributed to op amp instability) Plots follow. Also, while these need to be calibrated to show the real noise spectrum of the cavity motion, I'm attaching the voltage noise spectra of the error and control signals as a check that electronics/PD noise isn't dominating either signal. 

 The PRM sensors are no longer effected by IR. What changed? The MC still does.

 Koji cleaned up very nicely.

 Yes.  I think that's a good idea, since we're not using them at this time, and we want c1mcs to behave.  Maybe make an elog note of which version is the first without them, so that we can conveniently find the model(s) in the svn?

 PRM-BS & Faraday video ccd  cameras  covered as shown. These thin wall metalized ducts are perfect for blocking light in both direction.

They are very light and give you easy access to adjustment.

 My job right now is to characterize the green PDH loops on each arm. Today, Jenne took me around and pointed at the optics and electronics involved. She then showed me how to lock the green beams to the arms (i.e. opening the shutters until you hit a TM00 shape on the transmitted beam camera). Before lunch, the y arm was easiest to lock, and the transmitted power registered at around 0.75. 

After lunch, I took a laptop and SR785 down to the y end station. I unhooked the PDH electronics and took a TF of the servo (without its boost engaged, which is how it is currently running) and noise spectrum with the servo input terminated.

I then set up things a la ELOG 8817 to try and measure the OLTF. However, at this point, getting the beam to lock on a TM00 (or something that looked like it) was kind of tough. Also, the transmitted power was quite a bit less than earlier (~0.35ish), and some higher order modes were higher than that (~0.5). Then, when I would turn on the SR785 excitation, lock would be lost shortly into the measurement, and the data that was collected looked like nonsense. Later, Koji noted that intermittent model timeouts were moving the suspensions, thus breaking the lock. 

We then tried to lock the x arm green, to little success. Koji came to the conclusion that the green input pointing was not very good, as the TM00 would flash much less brightly than some of the much higher order modes. 

Tomorrow, I will measure the x arm OLTF, as it doesn't face the same timeout issue that is affecting the y arm.

c1scy had frequent time-over. This caused the glitches of the OSEM damping servos.

Today Eric Q was annoyed by the glitches while he worked on the green PDH inspection at the Y-end.

In order to mitigate this issue, low priority RFM channels are moved from c1scy to c1tst.
The moved channels (see Attachment 1) are supposed to be less susceptible to the additional delay.

This modification required the following models to be modified, recompiled, reinstalled, and restarted
in the listed order: c1als, c1sus, c1rfn, c1tst, c1scy

Now the models are are running. CDS status is all green.
The time consumption of c1scy is now ~30us (porevious ~60us) (see Attachment 2)

I am looking at the cavity lock of TEM00 and I have witnessed no glitch any more.
In fact, the OSEM signals have no glitch. (see Attachment 3)

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

Last week, Koji cleaned up the LSC model to make it much more readable, while he was working on piping the ALS signals to the LSC model.  However, somehow the DAQ Channels block got deleted before the model was committed to the svn.  Since there were 2 months between svn checkins for c1lsc.mdl, it's possible that someone had the model open just to look at, and the block got deleted, and that's the version that Koji started with. 

Anyhow, thankfully we have the svn, so Koji and I found that the DAQ Channels block was (as expected) in the previously checked-in version of the LSC model.  I put a copy of the old model onto my desktop, opened it up, copied the DAQ Channels block, and then pasted it into the new cleaned-up version of the model.  (Jamie - is there a way to conveniently download a previous version through the web interface?)

I have checked it in, compiled and restarted the lsc model.  The _DQ channels are back now.

2 weeks ago I took some data, and remembered today at the 40m meeting that I hadn't posted it.  Bad grad student.

All I'm trying to show here is that we see flashes in the arms that are larger than the ~50 units that we see saturate the Thorlabs transmission PDs. For arm power values below ~50, the QPD sum and Thorlabs PDs give approximately the same values.  So, 1 unit on the Thorlabs PDs is equivalent to 1 unit on the QPD sum, and 50 units on the Thorlabs diode is equivalent to 50 units on the QPD sum.

The situation was arms held on resonance with ALS, and the PRMI was flashing.

Arm powers of ~140 imply a power recycling gain of ~7.

 When I came in this morning, in addition to the fb being unhappy [elog 9436] (which Koji later fixed [elog 9437] ), c1auxex was down / not talking to the world nicely. 

I tried telnet-ing, but was rejected, so EricQ and I went down to the Xend and pushed the reset button on the computer.  The computer came back up just fine, and I did a burt restore to 03:07 on Nov 30th.

Now FB is fixed: daqd and nds are running

When I rebooted FB, I noticed that any of the nfs file systems were not mounted.
I started tracking down the issues from here.

I googled the common issues of the nfs mounting during the boot sequence.
- It is good to give "_netdev" option to fstab to mount the system after the network connection is established.

- "auto" option specifies that the file system is mounted when mount -a is run

Resulting /etc/fstab is this:

But this didn't help mounting the nfs file systems at boot yet. I dug into google again and found a command "/sbin/rc-update".
"/sbin/rc-update show" shows what services are activated at boot. It did not include "nfsmount". So the following command
was executed

> sudo /sbin/rc-update add nfsmount boot

> /sbin/rc-update show

After rebooting, I confirmed that the nfs file systems are correctly mounted
and daqd and nds are automatically started.

This means that FB had never been configured to run correctly at boot. Shame on you!

It seems that the front fan unit was running at the full speed. The fan itself seems still OK.

I talked with Jamie and make a power cycling (i.e. shutdown gracefully, unplug the power supply cables (x4), plug them in again, and pushed the power button)

The warning signal went off and the fan is quiet. FOR NOW.

Now, daqd and ndsd is down.

FB cannot mount /opt/rtcds and /cvs/cds during its boot.

After mounting these manually, I tried to run /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab
but they don't keep running.

I'll be back to this issue tomorrow with Jamie's help.

 I was trying to repeat  elog 9007  I did only get to line 2 of the Solution by Koji when Ottavia shut down, where I was working. This was all what I did.

Steve was trying to do something to it this morning, but I'm not exactly clear on what it was.  Maybe that helped?  Steve, can you tell us what you were trying to do this morning?

I just got over here from Downs, where I managed to convince Todd to let me borrow one of their three remaining timing slave boards for c1iscex.  I walked down to the X end to replace the board only to discover that the link light on the existing timing board was back!  c1iscex was not responding, so I hard rebooted the machine, and everything came up rosy (all green!):

To repeat, I DID NOTHING.  The thing was working when I got here.  I have no idea when it came back, or how, but it's at least working for the moment.  I re-enabled the watchdog for ETMX SUS and it's now damped normally.

I'm going to hold on to the timing card for a couple of days, in case the failure comes back, but we'll need to return it to Downs soon, and probably think about getting some spare backups from Columbia.

Rack 1x6 is very noisy.

 SunFire X4600 computer: FB (directly below Megatron) has it's yellow warning light on. It must be loosing one of it's  fan bearings.

Jetstore's error message: IDE channel #2 reading error

 I felt in my bones that the MC was in trouble so I came by and noticed that it hadn't locked for a couple hours. The FSS SLOW was at -1.6V, but putting it back to zero didn't fix things. I adjusted the FSS error point offset to +1 and that took the FSS_FAST off of the +10 V rail. Relocked and seems OK.

We need to plan to make the M Evans mod to the FSS box to make the PC drive less angry.

Last 40 days of MC Alignment trends  show that the recent MC WFS tuning / offseting worked out OK. MC REFL seems low and flat.

The Phase tracker outputs (= ALS X/Y error signals) are now conveyed to the LSC model.

Their entry points at the LSC model are C1:LSC-ALSX_IN1 and C1:LSC-ALSY_IN1.
They are connected to the signal matrix (28th and 29th signals) via signal conditioning filters (C1:LSC-ALSX and C1:LSC-ALSY).

The main LSC screen has not been updated. The conventional ALS servos are still remains as they were.

This renovation required the recompilation of c1als, c1rfm, and c1lsc. Two PCIe-RFM bridge paths were added resulting in
increase of the c1rfm timing budget from 38 to 44.

[Jenne, Koji]

I was trying to lock the Yarm, and saw that I was not getting signals to go between the LSC and SCY models.  I had digital zeros for TRY, and when I overrode the trigger and tried to force signal to ETMY, I had digital zeros at the SUS-ETMY_LSC input. The corresponding filter bank in the rfm model was receiving signals, so the Dolphin connection between LSC and SUS was okay, it was just the RFM connection going to the end station that wasn't succeeding. 

Koji restarted the c1scy model, and then went inside the IFO room, and found that the SUS IO chassis power was off.  We must have accidentally turned it off while we were in there earlier.  Koji turned on the power, and also restarted the rfm model, and we now have real signals going back and forth. 

Yarm is locked, ASS worked nicely, etc, etc, so things seem normal again (with the Yarm....ETMX stuff is still out of order).

 [Koji, Jenne]

The new fiber arrived today, and we tried it out.  No luck.  We think it is the timing card, so we'll need to get one, since we can't find a spare.

Order of operations:

* Lay new fiber on floor, plugged it in at both ends, saw no fiber link lights.

* From control room, killed all models running on c1iscex, shutdown computer.  Still no link lights.

* Power cycled computer and IO chassis.

* Tried plugging new fiber into different port on Master Timing Sequencer, with other end still plugged in to c1iscex.  Still no link lights.

* Looked around with flashlight at Xend IO chassis.  The board that the fiber is connected to does not have a power light, although the board next to it has 2.  We compared with the SUS IO chassis, and the board there with the fiber has one power light, plus the fiber link lights, as well as 2 on the board next to the fiber.  So, perhaps there's a problem with power distribution on the timing board at the Xend? 

* Unplugged and replugged the power connector to the timing board, inside the IO chassis, board next to the fiber's board got lights back, but the fiber's board did not.  However, power must be going through the board with the fiber attached, to the next board, so there's power at least on some part of the timing board, just not the whole thing.

From this, we conclude that the blue fiber that was in place is probably fine (or is not found guilty), and that we need a replacement timing board.  Koji didn't find one in the "CDS stuff" boxes underneath the Jenne Laser, and I feel like I recall Jamie saying that we would have to get a spare from somewhere else.  We rolled up the new spare fiber, and put it in the box with other "CDS Stuff" under the Jenne Laser table.

 Steve and Koji looked around, and called around, and there seem to be no spare fibers that are long enough to reach the end, so Steve has ordered

"Tripp Lite N520-30M 100' Multimode Duplex 50/125 Fiber Optic Patch Cable LC/LC"

 and it should be here tomorrow.