40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 158 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  9123   Wed Sep 11 23:34:37 2013 MasayukiSummaryGreen LockingALS locking in both arms

[manasa, masayuki]

We locked the XARM and YARM with using ALS control loop and we succeeded to lock stably both arms. The performance of the ALS was tested with a measurement of the calibrated error signal. (attachment 1)

- red and blue : the in-loop noise of ALS of each arm.

- green and purple:Stability of the beat-note frequency with the MC and the arm freely running.

Discussion

In the high frequency region, YARM has larger noise than XARM, and these noises were not there in previous measurements by Koji and Manasa (elog8865). You can see that in both of in-loop noise and free running noise. These noises may be caused by the Green PDH servo or hte phase tracker servo or any other electrical staff. We will start noise budget of these servo.

At higher frequency than UGF of ASL control loop, the loop does not suppress the noises at all, but the inloop and free running noise are not equivalent. I have no idea about that so far.

 

 

 

Attachment 1: noise.pdf
noise.pdf
  9122   Wed Sep 11 17:35:38 2013 JenneUpdateLSCALS requirement

I have done a quickie look at Optickle to see how the linewidth of an arm cavity changes versus the configuration. 

To do this, I make different configurations, and do a sweep of ETMX.  For each configuration, I find the max peak value, and then find the points that are at half that value.  The distance between them is the full width at half max.

I get:

FWHM_DRFPMI = 3.8750e-11  meters

FWHM_PRFPMI = 3.8000e-11  meters

FWHM_SRFPMI = 2.3200e-09  meters

FWHM_FPMI =   1.1900e-09  meters

So, for the ALS to hold within 1/10th of a linewidth for the full IFO configuration, we want the ALS noise to be on the order of 3 picometers RMS.  If I recall correctly, that's about an order of magnitude better than we currently have.

 

ArmLinewidthComparison.png

                 use LOG y-scale

EDIT 8 Nov 2013, JCD:  New log-y plot:

LinewidthComparison.png

  9121   Tue Sep 10 17:35:50 2013 Masayuki, ManasaUpdateLSCMICH calbration

Quote:

[Manasa, Masayuki]

We took a bunch of measurements. Transfer function and power spectrum using DTT. They will be used to obtain calibrated MICH in-loop and free-running noise. Detail Elog with plots will follow very soon.

 [Masayuki, Manasa]

Estimation of free-running MICH displacement noise:

Method 1. Assuming AS55_Q_err to be a linear sensor, as shown in (1) of figure below, free-running MICH noise (V_d) can be estimated by measuring V_err and the OLTF G. H can be estimated by using method explained in elog

 Method 2. Considering that the AS55_Q signal might be distorted or saturated, method 1 may not be precise. In method 2, we will use the ASDC as the sensor (S' in (3)) instead and lock MICH using ASDC in mid-fringe to calibrate the ITM actuators.

Figure:1

Schematic:

MICH_calib_loops.png

What we did:

1. Estimate H' from free-running ASDC signal (bright to dark fringe).
2. With MICH locked on ASDC, give an excitation signal to C1:LSC-SUS_XXXX_EXC (XXXX could be ITMX or ITMY) and measure R'. [(3) of schematic]
3. Measure OLTF of MICH locked on ASDC (hence estimate L). [(3) of schematic]
4. With MICH locked on AS55_Q, give an excitation signal to C1:LSC-SUS_XXXX_EXC (XXXX could be ITMX or ITMY) and measure R1. [(2) of the schematic] 

Results/Plots: 

Figure:2

OLTF of MICH locked on ASDC

 OLTF_MICHDC.png

 

Figure2:

Actuator excitation to MICH transfer function (MICH locked using ASDC) 

MICH_DC_resp.png

* y axis (no units)

Figure 3:
Actuator excitation to MICH transfer function (MICH locked using AS55Q)

MICH_RF_resp.png 

* y axis (no units)

Figure 4:
Free-running MICH noise

MICH_free_noise.png 

Discussion: 

1. By using the second sensor, we also eliminate the effect of the MICH servo loop locked on AS55_Q (Estimated V_d does not depend on G but only on G').

2. The free-running MICH noise is still suppressed at 1Hz. This should be coming from the effect of the UGF of the loop at ~10Hz and the vicinity to the pendulum frequency at 1Hz.

 

Edit/Masayuki// This noise curve is not collect, especially in low frequency region. We used the measured OLTF for compensating the free running noise, but that is not collect in low frequency region. So we should model the OLTF and fit that into the measured OLTF. We will fix this soon.

 

 

  9120   Tue Sep 10 15:43:01 2013 SteveUpdateVACTP3' dry pump is replaced

Quote:

 

 TP3 foreline's dry pump is getting noisier and noisier.  Turbo TP3 is pumping on the annulos. The foreline pressure is 7.2 mTorr and it is not degrading. It was swapped in March 5, 2013

The seal is very good, but the bearing is dying.

 

 

 

 The drypump is replaced at 95,781 hrs on TP3 controller time. The foreline pressure is 30 mTorr and dropping.

 It is 13 mTorr after 17 hours of pumping.

  9119   Tue Sep 10 09:18:22 2013 SteveUpdateVACdry pump is getting loud

 

 TP3 foreline's dry pump is getting noisier and noisier.  Turbo TP3 is pumping on the annulos. The foreline pressure is 7.2 mTorr and it is not degrading. It was swapped in March 5, 2013

The seal is very good, but the bearing is dying.

 

 

 

  9118   Mon Sep 9 20:46:28 2013 MasayukiUpdateLSCMICH calbration

[Manasa, Masayuki]

We took a bunch of measurements. Transfer function and power spectrum using DTT. They will be used to obtain calibrated MICH in-loop and free-running noise. Detail Elog with plots will follow very soon.

  9117   Mon Sep 9 15:33:06 2013 SteveUpdateVACvertex crane repair is scheduled

Quote:

 

 [Fred Goldbar, Mike Gerfen, Dennis Coyne and Steve]

We inspected the hinge, 1.25" cross pin and I-beams. It is hard to explain what is  causing the folding I-beam corner to jam against the main I-beam.

To limit the motion of the folding I-beam  cross pin bushing will be added. This will take a week to complete.

 

 

 

 

 

 KoneCrane contact John McDaniel (562) 903 - 1371,

Wednesday, September 18,  folding I-beam will be removed.  KoneCrane will start working at 7:30am and they should be out by 12:30pm

 Friday,  September 20, reinstalling machined hinge on the I-beam. Same timing schedule as Wednesday.

  9116   Fri Sep 6 23:01:08 2013 KojiUpdateLSCStable DRMI lock was recovered from the impact on the RF system modification

Summary

Stable DRMI lock was recovered. The AS110 phase was adjusted. PRCL and MICH were locked with REFL33I and REFL165Q.
Still SRCL is controlled with REFL55Q.


PRMI sensing matrix

Thursday night, Jenne and I found DRMI can not be locked at all. Also the PRMI lock with REFL55 showed change in the optical gain.

In order to investigate what is happening, the PRMI sensing matrix was measured and compared with the previous one taken in the night of 8/26.

SensMat_PRMI_1000cts_580Hz_2013-08-26_235635.pngVSSensMat_PRMI_1000cts_580Hz_2013-09-06_201137.png

It shows that some signals are unchanged, some are partial change, and some are completely different.
My intuition saids something is wierd with the sensing matrix measurement.
Right now I can't trust these plots.

- Jenne and I have adjusted REFL55 demod angle so that REFL55Q has no PRCL. And I have confirmed with DTT that this is still true.
  However, the radar chart shows that REFL55Q is almost correct phase for PRCL instead of MICH.

- REFL11 shows the same amplitude and angle as before. But POX11/POY11 shows different MICH angle.

- I have rotated REFL55 demod phase and remearsured the sensing matrix. Evrything else looked same but REFL55.
  Since REFL55I&Q were not used for the control for this measurement, what we expect is to see no change of the sensing matrix and
  only see the angle of "I"&"Q" rotates. But the result was different from the expectation.

DRMI locking

Since no real info was obtained from the sensing matrix, I had to make a fight without any weapon.
After sevral hours of work, stable DRMI lock was recovered.

Basically I gave larger gains to REFL55 signals: REFL55I for SRCL was 100 instead of 1, and REFL55Q for MICH was 2 instead of 0.1.
This was enough to get a second locking. Using this short sections, I have optimized the FM triggers and the gain boosts (i.e. FM1)
as well as the mirror alignment.

Then, PRM ASS was left running during the lock. This actually stabilized the lock a lot.
This made thee lock indefinite.

The demod phase of AS110I was adjusted so that AS110Q fluctuates around zero.
In this condition, the nominal AS110I was 7300 with the whitening gain of 30dB.

Note that the AS110I&Q were also measured with PRMI. With the same phase and gains, AS110I and Q were -35,  -170, respectively.
Do we expect to have this phase shift? If I believe these numbers, the aplitude of 110MHz at the optimal phase is 173,
The ratio of AS110 between DRMI and PRMI is 7300/173 = 42. This corresponds to the ratio of the 110MHz sideband power at the AS port.
According to the wiki, this ratio shoud be ~160.

AS110I was in fact glitchy as you can see in the StripTool chart. I wonder this signal is suitable for the normalization or not.


=== SENSING ===

REFL11 -67deg / whitening gain 0dB
REFL33 -20deg / whitening gain 30dB
REFL55 45deg / whitening gain 6dB
REFL165 96deg / whitening gain 45dB

POP110 69deg whitening on / 15dB
POP22 102.2deg whitening on / 21dB
AS110 145deg whitening off / 30dB (seems to be related to AS11 whitening setting)

=== INPUT MATRIX ===

REFL11I x -0.125 => PRCL (REFL33I x 2.5 was also OK)
REFL55I x 100 => SRCL
REFL55Q x 2 => MICH (REFL165Q x 0.1 was also OK)

=== NORMALIZATION / TRIGGER ===

No normalization

Trigger settings
MICH POP22I UP:50 DOWN:10
PRCL POP22I UP:50 DOWN:10
SRCL POP22I UP:50 DOWN:25

=== SERVO FILTERS ===

MICH x -0.8 FM4/5 ON, no limitter
FM Trigger: delay 2sec, FM1 (modified from 6dB to 20dB), FM2, FM3

PRCL x +0.035 FM4/5 ON, no limitter
FM Trigger: delay 0.5sec, FM2/3/6

SRCL x -0.1 FM4/5 ON, no limitter
FM Trigger: delay 5sec, FM1, FM2

=== OUTPUT FILTERS ===

MICH => PRM -0.267 / BS +0.5

PRCL => PRM +1.0

SRCL => SRM +1.0

=== VIOLIN FILTER TRIGGER ===

delay 1sec: FM1/FM2/FM3/FM6

=== ASC/ASS ===

PRM ASC UP:50 DOWN:25
PITCH&YAW: FM1/9 (ALWAYS ON) + FM2/3 (turned on by the up-script)

PRM ASS left turned on for slow tracking

Attachment 1: DRMI.png
DRMI.png
  9115   Fri Sep 6 09:27:10 2013 SteveUpdateVAC31 days after pumpdown

Quote:

 Valve configuration: Vacuum Normal

 

 

Attachment 1: day31vac.png
day31vac.png
  9114   Thu Sep 5 21:07:09 2013 JenneUpdateLSCStarted work on logic for triggering

I want something like an "AND" for the degree of freedom triggers.  Koji and I talked through an idea, and I have it running in the c1tst model, but the logic isn't working like I expect, so I need to look into it more before I can put it into the lsc model.

  9113   Thu Sep 5 15:18:41 2013 JenneUpdateLSCFree swinging DRMI power buildups

I have the DRMI free swinging right now, since it's not really locking.  Looking at these time series in the attached pdf, particularly around time=1.15, it would be super handy to trigger the SRCL degree of freedom on AS110 after the PRMI is triggered on POP22.

Attachment 1: DRMI_free_swing_power_buildups.pdf
DRMI_free_swing_power_buildups.pdf
  9112   Thu Sep 5 11:19:33 2013 JenneUpdateSUSPRM side

Quote:

I think the crane repair guy accidentally  stepped on the  BS support beam.

PRM side is not coming down.

 Seems fine now.

  9111   Thu Sep 5 10:47:58 2013 SteveUpdateVACvertex crane folding issue

 

 [Fred Goldbar, Mike Gerfen, Dennis Coyne and Steve]

We inspected the hinge, 1.25" cross pin and I-beams. It is hard to explain what is  causing the folding I-beam corner to jam against the main I-beam.

To limit the motion of the folding I-beam  cross pin bushing will be added. This will take a week to complete.

 

 

 

 

 

Attachment 1: 5mmLess.jpg
5mmLess.jpg
  9110   Thu Sep 5 10:28:17 2013 SteveUpdateSUSPRM side

I think the crane repair guy accidentally  stepped on the  BSC support beam.

PRM side is not coming down.

Attachment 1: craneguywashere.png
craneguywashere.png
  9109   Thu Sep 5 01:55:29 2013 JenneUpdateLSCLSC model upated to have AS110 channels, violin filter triggering

I have modified the c1lsc model so that I have access to the AS110 channels in the triggering and power normalization matrices. 

I also put in a few blocks so that we can have triggering on the violin notches that we moved to the LSC model a week or so ago. 

Here is my svn comment, so I don't have to retype things:

2 changes:  AS110 channels added, and Violin filter triggers added.

AS110:     We recently installed a    new demod board    and PD for an AS110 signal.  Since we will not    be using AS11 in the forseeable    future,    the AS110 demod    board outputs use the former AS11 channels.  I    have left the AS11 channels in the model so that we can easily    add them back if we want to, but they are grounded rather than    connected to the ADC.  I've added digital demodulation for AS110, power normalization,    and then added the I&Q signals to both the trigger matrix and the main    power normalization matrix.  NOTE that these slide the matrix columns around.    Since the AS110    is also    using the former AS11 whitening    channels, swapped those on the    BIO block also.

Violins:  Recently, Rana and I moved the SUS LSC violin    filters    from the individual suspension    models over to the LSC model.  Giving every optic every    optics' violin    notch helps eliminate bad cross-coupling between servo loops.  Here, I have enabled triggering    for these notches, so that the violin filters can come on after a cavity is locked.  Since the    filter banks SHOULD BE THE SAME    for all LSC_SUS banks,    the "mask" is common to    all optics.

I also edited several medm screens, to show the new changes:  the lsc overview screen has a button to the violin notch triggering screen, in addition to being able to get to the new screen from the regular triggering matrix screen.  I made the trigger and normalization matrix screens bigger, since there are now 2 new columns. 

I added AS110 to both the LSCoffsets script, and Masayuki's new, better, LSCoffsets2.py. 

I added new lines to the .req files for the ifo configure burt restores for the new matrix columns, and the violin triggering.

I restored, checked out, and saved the Xarm, Yarm, MICH, PRM_sb, and DRM configurations. 

 


I tried locking the DRMI, but haven't really been successful.  I'm not 100% sure how to do the phasing for AS110, so that could be a problem.  For POP, I can watch POPDC to see if something is a carrier or a sideband flash, but I don't have something quite as convenient at the AS port.  I have set the AS110 phase to 60 degrees for now, since during free swinging DRMI flashes, it looks like most of the buildup is in the I phase with 60 degrees.  Even with the same configurations as a week or so ago, I'm not getting much more than ~1 second locks.

I also tried locking the SRMI, but am not getting anything at all.  I think I need to go back to simulation-land to figure out what good signals might be.

 


Other thoughts:

Stefan modified the LSC filter module triggering blocks, so now we have a new epics variable, "_INVERT", which sends the trigger through a NOT or not.  I think that we want to keep this variable set to 0 to be the same as things were, but I do need to expose this new variable on the screens.

The trigger and normalization matrices pictured on the LSC overview screen need to be expanded by the 2 new columns.  The actual matrix screens are good, but I forgot to fix up the little Kissel buttons.

When I have a free swinging SRMI, MICH and SRCL should have the same sign for the gain, if I'm using AS55 I&Q for locking.

LLO is using REFL 9I for SRCL, and ASDC for MICH for the SRMI, but I don't have any REFL beam with a misaligned PRM, so I don't think I can copy what Den and Lisa did on Monday night.

I have figured out / rediscovered why the "sqrt" buttons on the power normalization screen aren't restored when you restart the LSC model - They are controlled by momentary epics records, which go to embedded c-code to do some toggling.  I don't know yet of a good way to save the configuration of these guys for burt restore-type restoration.  This will be a problem for anything that is using these toggle c-codes.

  9108   Thu Sep 5 00:40:33 2013 ranaUpdateSUSMC2 tickler turned OFF

 

 You're right - down turns it on. Still, the fact that the same tickle recently causes a problem and didn't make 20% power fluctuations until now tells me that its not that the tickle amplitude is too large. Whatever changed recently is the problem.

  9107   Wed Sep 4 22:14:35 2013 JenneUpdateSUSMC2 tickler turned OFF

Quote:

 

 Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.

The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.

 Isn't that backwards?  Shouldn't the tickler be enabled by the down script, and disabled by the up script?  Either way, the problem was that, after I acquired lock, the tickler was causing the transmitted power to fluctuate by ~20%, and often the MC would lose lock after a minute or so.  Also, the WFS definitely couldn't be enabled by hand. 

Anyhow, I'll try to keep in mind that this exists, so I'm not stymied by it again.

  9106   Wed Sep 4 21:44:54 2013 Not JenneUpdateElectronicsRF distribution box: Reinstalled

Temporary fix for the switch: give a bit of oil to the button

Permanent fix: buy better switches.

  9105   Wed Sep 4 20:47:15 2013 manasaUpdateLSCCalibrated in-loop MICH noise

To estimate in-loop MICH noise:

(a) Calibrate MICH_ERR:

1. Lock the arms for IR using POX11 and POY11.
2. Misalign the ETMs.
3. Obtain the average peak-to peak (bright to dark fringe) counts from the time series of AS55_Q_ERR. I measured this to be d = 6.358 counts.
4. This gives the calibration factor for AS55_Q_ERR [Calibration factor = 2*pi*d/1064/10^-9 = 3.7546x10^7 counts/m]

(b) In-loop MICH noise:

1. Lock MICH using AS55_Q.
2. Since LSC input matrix sets MICH_IN1 = 1* AS55_Q_ERR, the power spectrum measured using dtt and calibrated using the calibration factor from step 4 in (a) gives us the calibrated in-loop MICH noise.

The plot below shows the in-loop MICH noise and the dark noise (measured by closing the PSL shutter):

Compared with old measurements done by Keiko elog 6385 the noise levels are much better in the low frequency region below 100 Hz.
(No, no, no... this is not an apple-to-apple comparison: KA)

Attachment 1: MICH_noise.pdf
MICH_noise.pdf
  9104   Wed Sep 4 20:39:23 2013 ranaUpdateSUSMC2 tickler turned OFF

Quote:

 [Jenne, Manasa]

While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLERthat was left enabled. This was turned OFF and MC locked just fine after that.

 

EDIT JCD:  The Tickler should be disabled, if the autolocker is disabled.

 Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.

The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.

  9103   Wed Sep 4 17:22:09 2013 JenneUpdateLSCDemod phases for RFPDs

I checked the demod phases for AS55, POP110, and all the REFL PDs. 

AS55:  I locked MICH, and shook the ITMs (+1 for Y, -1 for X), and watched the AS55 I & Q spectra at 580Hz (notch in the servo was enabled).  I rotated the phase from -32.0 to +13.0 to get the signal entirely in the Q phase.

POP110:  I locked the PRMI (triggering on POP22), and maximized POP22.  I then rotated the phase of POP110 until the signal was maximally positive.  I forgot what the starting phase was, but it is now 84.  The POP11_I signal was entirely negative when I started, so the new phase is about 180 from the old phase.  I also checked by unlocking the cavity, and seeing that a large peak in POPDC corresponded to large negative dips in POP110_I and POP22_I.

REFL PDs:  I locked the PRMI, and shook the PRM (notches in the servos were enabled for both MICH and PRCL).  Maximized the peak in the I phase.  REFL11 was fine, REFL33 was fine.  REFL55 was changed from 120 to 45.  REFL165 was changed from 106 to 96.

I restored the SRM on the IFO_ALIGN screen, but the saved value was almost 2 full integers off in yaw from actual DRMI resonances.  It looks like it was saved when Rana and I were working late last week.  We must have accidentally saved it when it was misaligned, since hysteresis can't do that much.

I want to check the phases for POX and POY with arm locking, just in case.  Also need to set the AS110 phase (which is plugged into the AS11 channels - need to fix the channel names).

 

  9102   Wed Sep 4 16:08:22 2013 manasaUpdateSUSMC2 tickler turned OFF

 [Jenne, Manasa]

While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLERthat was left enabled. This was turned OFF and MC locked just fine after that.

 

EDIT JCD:  The Tickler should be disabled, if the autolocker is disabled.

  9101   Wed Sep 4 16:06:40 2013 JenneUpdateElectronicsRF distribution box: Reinstalled

I have reinstalled the RF distribution box, as well put in the AS110 demod board.  I plugged everything back in, and turned it all on.

The switch on the distribution box may be starting to fail.  When I was turning the box on, I could depress the button, and see the blue glow, but it wouldn't catch, so when I removed my finger, the glow went away.  I was afraid that I'd have to pull the box, but after a few more button toggles, I got it to stay on.  I'm leaving it for now, but we should remember that this may be a problem.

I will look at the phases of all the PDs, but none should need changing except POP 110.  Every other PD has the exact same cables as before.

  9100   Tue Sep 3 21:10:36 2013 JenneConfigurationElectronicsputting together a 110 MHz LSC demod board for AS

Quote:

 

 I should actually stick in the SXBP-100's, which will band pass from 87-117 MHz.

 I have removed the 135 MHz low pass from my new AS110 demod board, but these SXBPs have different feet than the SCLFs, so I want to confirm with Koji or someone that I can solder them in the same way, before I get carried away and destroy anything.  I should be able to finish this up tomorrow, plug in the demod board and the distribution box, and try out AS110 triggering, etc, tomorrow night.

  9099   Tue Sep 3 21:08:13 2013 JenneUpdateElectronicsRF distribution box: 110 MHz LO options

The RF distribution box is still on the bench, so again, don't be surprised that the MC doesn't lock.

I have completed my modifications as proposed in elog 9096, but I want to do a couple of quickie tests in the morning before I declare it ready for service.

  9098   Tue Sep 3 14:23:21 2013 SteveUpdatePEM earthquakes

 ~Vancuver, Canada earthquakes: magnitude 6,  5  and more shaking

 

Attachment 1: EQm6&5.png
EQm6&5.png
  9097   Tue Sep 3 10:54:33 2013 SteveHowToGeneralHow To Coil Cables

Quote:

 http://youtu.be/pEd7ru24Vx0

 B grade Nobel is awarded.

                                  If cables could dream?

This skill should be  mandatory for LIGOX graduates.

  9096   Mon Sep 2 18:06:21 2013 JenneUpdateElectronicsRF distribution box: 110 MHz LO options

After scrounging for parts, and opening up the box, I have modified my proposal to the following:

RF_distribution_box_proposed_modifications.pdf

Note that the freq multiplier is supposed to take, at maximum, 15 dBm.  The reason I put the 5 dB attenuator, then an amplifier, then another attenuator is that I don't know of / can't find easily a 10 dB amplifier with the usual case type on the MiniCircuits site.  (If anyone knows of one off the top of their head, that would be handy.  Then I'd remove the attenuator between the multiplier and the amplifier, and make the 10 dB attenuator a 5 dB.)

Anyhow, the ZFL-500HLN can only output 16 dBm of power, and I don't think I have space for another ZHL-2 (which can output up to 26 dBm) inside the box, so I put an attenuator before, as well as after, the amplifier. 

I think I have space inside the box for all the bits and pieces I'll need, although to do things correctly, I need to drill holes in the teflon mounting plate to mount the amplifier and splitter.

0902131751.jpg

I also think that I have space on the front panel to put another isolated SMA feedthrough.

0902131751a.jpg

I have, on my desk, all the parts (except for mounting screws, and cables between things) to make these modifications to the distribution box. 

  9095   Mon Sep 2 16:46:32 2013 JenneUpdateElectronicsRF distribution box is on the bench

I have pulled the RF distribution box out of the rack, so I can look at it, and modify it to have 2 110 MHz spigots. I'm going to make the mods as in elog 9072.

Before I pulled the distribution box, I turned off the RF Generation Box, so don't be surprised that the MC will not lock.  I have terminated the cables that bring the 11 and 55 MHz signals from the generation box to the distribution box, so if someone does turn on the generation box, there won't be bad reflections.

To get the box out, in addition to unplugging all of the cables that go to the distribution box, I had to disconnect 2 of the ADC ribbon cables from the top row of RFPD demod / whitening / ADC boards, since they were in the way.  Everything is labeled, so it should be easy to put back together.

Note to Future Jenne:  Past Jenne put the screws needed for those ADC cables and to hold the box in the rack, in the plastic box that is on the floor in front of the LSC rack. 

Also, I measured the 110 MHz port before I pulled the board, so I would know what my "before" looked like.  I was using the 300MHz 'scope's measurement functions, so these are in volts, not dBm.  Amplitude = 1.33V, RMS = 456 mV, freq = 109.4-111.9 MHz

  9094   Mon Sep 2 15:22:57 2013 JenneUpdatePSLPMC relocked

 The PMC was locked on an LG 10 mode (or something like it), for at least the last 8 hours.  I relocked it on the regular 00 mode, and it's fine now.  

Also, in CDS news, I did an mxstream restart (the RCG upgrade is supposed to make this not an issue anymore...), and did a "diag reset" afterwards, and all of the IPC errors except for one in the LSC model have gone away (OAF is still not running....on my to-do list, but not super high priority).

  9093   Mon Sep 2 03:51:14 2013 ranaHowToGeneralHow To Coil Cables

 http://youtu.be/pEd7ru24Vx0

  9092   Fri Aug 30 14:31:57 2013 SteveUpdateGeneralcleaning up

I cleaned up around MC2 and 1Y1 area this morning.

ETMY NPRO moved from the side to the center of the low shelf. Thorlab catalog " as spacer " removed after lunch.

The Lightwave Controller values: LT 40.4C,  LTEC +0.1V,  T 41.041C,  Pwr 239 mW,  Adj 0,  DC 1.82A,  DPM  0.0V,  Neon OFF,  Ldon OFF,  Display 5,  DT 21.0C,  Dtec +1.0V

 

Attachment 1: MC2areaCP.jpg
MC2areaCP.jpg
Attachment 2: 1Y1areaCleanedUp.jpg
1Y1areaCleanedUp.jpg
Attachment 3: ETMY_NPROmoved.jpg
ETMY_NPROmoved.jpg
  9091   Fri Aug 30 11:00:46 2013 ManasaUpdateGeneralSeries of earthquakes

There has been a series of earthquakes since the big 7.0 in Alaska this morning.

None of the watchdogs were tripped when I came in. But I could not retrieve any info about the suspensions from fast channels because c1sus was not talking to the fb and that required an mxstream restart to fix it.

MC is trying to lock itself, but the seismic doesn't seem to get quiet. So MC is not all that happy.

 Screenshot-Earthquakes_-_Mozilla_Firefox.png

SUSnSEIS.png

  9090   Fri Aug 30 08:08:29 2013 steveUpdatesafetyfire horns-flashers tested OK

 

 We had fire alarm tests  and evacuation drills at 1:30pm yesterday. All flashers and horns are functioning unbearably loud and bright including clean assembly room.

  9089   Fri Aug 30 01:01:28 2013 rana, nicSummaryComputer Scripts / ProgramsaLIGO Noise Budget code installed and running

Chris Wipf has been developing a new Noise Budget code that allows us to use our existing Simulink models to handle all of the noise transfer functions. This is mainly by being clever about avoiding the numerical pitfalls that we encounter when doing linearization of Simulink models (e.g. linmod or linmod2).

Screen_Shot_2013-08-30_at_1.00.02_AM.png

In this model, the optical plant is done with analytic TFs using the formulae from the Sigg Frequency Response doc. The big Orange block has just the DAC and some simple pendulum TFs. The upper section contains the simulated digital system: input matrix, digital filter TFs, and output matrix. The digital filters are just based on my memory of iLIGO. The CARM path is made to be fast to approximate the high gain of the Common Mode servo. Without this high gain the PRC optical plant is unstable due to the right half plane zeros. This simple model is used just so that we could see the NB work on a multi-loop system. For the next steps of getting it to work for the 40m, we will use the Optickle TFs instead of analytic functions and also load the digital filters directly from the FOTON files. For the LLO DRMI, we'll add some simplified version of the SUS Simulink models for triples and quads.

 

Yesterday, Nic and I took my old iLIGO IFOmodel.mdl Simulink model and added the new NB hooks that allowed us to use the new code. The screenshot below is from a run of this code:

1) Figure 1 shows the DARM Noise budget. So far we have included shot noise in DARM, CARM, MICH, & PRC. Radiation pressure noise on the ITMs and ETMs. Coating thermal noise on all mirrors.

2) Figure 2 shows the breakdown of how each of the shot noises at each port couple to the DARM readout. The RED trace is the AS port DC readout shot noise. The GREEN trace is the MICH shot noise feeding through the MICH loop and being mostly cancelled by the scalar MICHdamp feedforward path.

3) Figure 3 shows that we've set the coating thermal noise to be equal on all 4 TMs.

4) Figure 78754 is a set of Bode plots of the open loop gains of the 4 LSC loops (inferred from the closed loop TF). Also plotted is the residual MICH2DARM TF (with the MICHdamp cancellation path ON).

5) Figure 9911123 are the step responses of the LSC loops: step inserted at the error point and response measured just after the excitation point.

The editor window on the left shows how simple the NB code is to use once the Simulink model has had all the hooks added to it.

Attachment 1: NBplots.png
NBplots.png
  9088   Thu Aug 29 17:25:50 2013 JamieUpdateSUSSUS medm screen upgrade

Rana asked me to look at the SUS MEDM screen upgrade situation, and provide an upgrade prescription.  Unfortunately there not really a simple prescription that can be used, since our configuration diverges quite a bit from what's at the sites.  But here's what I can say:

It looks like we already have the beginnings of an upgrade in place, so I say we just run with that.  The new screens are in:

/opt/rtcds/userapps/release/sus/c1/medm/new

The primary screen is:

/opt/rtcds/userapps/release/sus/c1/medm/new/OVERVIEW.adl

This seems to be a copy of the site ASC_TIPTILT screens.  (In fact I think I remember putting this here).  I went ahead and did some ground work to make it easier to get these new screens into place.

  • I cleaned up all the channel name prefixes so that at least the channel prefixes will resolve to our SUS channels.
  • I made a link from the sitemap with some of the correct macros to fill some things in appropriately: "IFO SUS/NEW ETMX"
  • I fixed the names to the sub-screens, so that it correctly opens the correct sub-screens (although the macros seem to not be passed correctly)

At this point someone needs to just go through and fix all the channel names to match ours, and tweak the screen to our needs (there's no side OSEM, for instance).  The subscreens need to be cleaned up as well.

sed replace string

If there is a specific string you want to replace every instance of in the screen, you can do that easily from the command line like this:

sed -i 's/OLD/NEW/g'  

This will replace every instance of the string OLD with the string new in the file path/to/file.  Be careful: this will replace EVERY instance of OLD.  If OLD matches things you don't want, they will be replaced as well.

This construction is actually "regular expressions", so if you want to get fancy you can match against more complicated strings.  But just be careful.

If you leave out the "-i" the string-replaced text will go to stdout, instead of being replaced in the file "in place", so you can check it first.

query replace in emacs

If you want more fine-grained control of text replace, so that you can see what's being replaced, try using "query-replace" in emacs:

M-x query-replace

You can then type in the original string, followed by the replacement string.  When it starts to run it will highlight the string that will be replaced.  Hit "space" to accept or "n" to skip and go to the next.

 

 

  9087   Wed Aug 28 23:09:55 2013 jamieConfigurationCDScode to generate host IPC graph
Attachment 1: hosts.png
hosts.png
Attachment 2: 40m-ipcs-graph.py
#!/usr/bin/env python

# ipc connections: (from, to, number)
ipcs = [
    ('c1scx', 'c1lsc', 1),
    ('c1scy', 'c1lsc', 1),
    ('c1oaf', 'c1lsc', 8),

    ('c1scx', 'c1ass', 1),
    ('c1scy', 'c1ass', 1),
... 96 more lines ...
  9086   Wed Aug 28 19:47:28 2013 jamieConfigurationCDSfront end IPC configuration

Quote:

It's hard to believe that c1lsc -> c1sus only has 4 channels. We actuate ITMX/Y/BS/PRM/SRM for the length control.
In addition to these, we control the angles of ITMX/Y/BS/PRM (and SRM in future) via c1ass model on c1lsc.
So there should be at least 12 connections (and more as I ignored MCL).

Koji was correct that I missed some connections from c1lsc to c1sus.  I corrected the graph in the original post.

Also, I should have noted, that that graph doesn't actually include everything that we now have.  I left out all the simplant stuff, which adds extra connections between c1lsc and c1sus, mostly because the sus simplant is being run on c1lsc only because there was no space on c1sus.  That should be corrected, either by moving c1rfm to c1lsc, or by adding a new core to c1sus.

I also spoke to Rolf today and about the possibility of getting a OneStop fiber and dolphin card for c1ioo.  The dolphin card and cable we should be able to order no problem.  As for the OneStop, we might have to borrow a new fiber-supporting card from India, then send our current card to OneStop for fiber-supporting modifications.  It sounds kind of tricky.  I'll post more as I figure things out.

Rolf also said that in newer versions of the RCG, the RFM direct memory access (DMA) has improved in performance considerably, which reduces considerably the model run-time delay involved in using the RFM.  In other words, the long awaited RCG upgrade might alleviate some of our IPC woes.

We need to upgrade the RCG to the latest release (2.7)

  9085   Wed Aug 28 15:41:42 2013 SteveUpdateVACRGA scan at day 23

 Valve configuration: Vacuum Normal

pd76-m-d23

 

Attachment 1: pd75md23.png
pd75md23.png
  9084   Wed Aug 28 11:23:41 2013 SteveUpdateVACcrane repair sheduled

Quote:

 1, Vacuum envelope grounds must be connected all times!  After door removal reconnect both cables immediately.

 2, The crane folding had a new issue of getting cut as picture shows.

 3, Too much oplev light is scattered. This picture was taken just before we put on the heavy door.

 4, We were unprepared to hold the smaller side chamber door 29" od of the IOC

 5, Silicon bronze 1/2-13 nuts for chamber doors will be replaced. They are not smooth turning.

 

 Fred Goldbar of KoneCranes will come 7:30am Wednesday, September 4 to look at this issue.

It is changed to Thursday morning.

  9083   Wed Aug 28 11:15:02 2013 SteveUpdateGreen LockingXend green layout corrections

Quote:

Quote:

 Shutter moved, no more clipping.

Pick-off mirror 2" replaced by 1" one. Laseroptik HR 532nm, incident angle 30-45 degrees, AR 532 nm

Green REFL PD moved to 4" close to pick-off mirror. Pd being close to pick-off does not separate multiple reflections on it. I'll replace Laseroptic mirror with Al one. It is not easy to find.

 Hole cut into side wall for doubler oven cable to exit.

 

 

 Beam trap for Pd refl is in place. Cabeling is ti·died up.

 Laseroptic 1" mirror is replaced by Al 1" mirror. Problem remains the same. This diffraction patter has to be coming from the Faraday.

  Atm1, good separation when Pd is far 

  Atm2, bad separation when Pd is close 

 The extra high post 3.375"  for PZT is ready. We also have 2 more 2" green Laseroptik mirrors. I'm ready to swap them in.

The  75 mm  focal length  lens  was placed in front of the green REFL PD yesterday.

  9082   Wed Aug 28 07:33:51 2013 manasaUpdateLSCMICH locking

I wanted to measure the OLTF of MICH.

What I did:
1. Ran LSC offsets script to zero all the offsets.

2. Restored the IFO configure settings for locking Michelson (locked on AS55Q).

3. MICH wouldn't lock on these settings.

4. The MICH servo was hitting its limits (10000 counts). I checked the filter module. After a little bit of looking into things, I disabled FM3 (0,0:5,5), FM4 (1:10) and FM7 (1:5). FM3 and FM7 were filter modules that were switched ON at the trigger. I set these to manual. Enabling any of the filters (FM3, FM4, FM7) caused MICH to lose lock.

5. MICH gain was changed from -20 to -30. MICH locked with ASDC suppressed to 0.01 counts. I looked at the power spectrum of C1:LSC-MICH_OUT on dtt. //edit: Manasa// The plot (uncalibrated) now shows MICH_OUT power spectrum with MICH PSL shutter closed, free-running MICH and loop-enabled MICH.

6. I then wanted to measure the OLTF of MICH using dtt. A channels were set to C1:LSC-MICH_IN1/C1:LSC-MICH_IN2 and excitation given through C1:LSC-MICH_EXC. But I have not been able to get any good coherence for the measurement as yet.

Attachment 1: MICH.pdf
MICH.pdf
  9081   Wed Aug 28 06:26:28 2013 manasaUpdateComputer Scripts / ProgramsASS req and snap files edited

[From yesterday] ASS for X arm was behaving slightly funny over the last couple of days. ASS could not correct the BS misalignment. Jenne pointed out that the LSC output matrix on the ASS medm screen set itself to zeroes whenever we ran the ASS_dither_ON script. I checked the burt request file: ASS_DITHER_ON.req  in /opt/rtcds/caltech/c1/scripts/ASS and found that the LSC output matrix channels were not added to it. I added these channels for both the X and Y arm. Following this, I also edited the corresponding snap file as well. This should now set the LSC matrix to the right values everytime we run the script.

  9080   Wed Aug 28 06:17:15 2013 manasaUpdateComputer Scripts / Programsalias for MATLAB2010

Although Matlab 2013 has not been causing any visible trouble so far, it takes a while to startup.

I have added alias 'ml10' to bash to start Matlab 2010 from the terminal for convenience.

  9079   Wed Aug 28 05:21:58 2013 manasaUpdateCDSCDS svn commits not happening

I am responsible for missed svn commits with als and asx. I have committed them.

But I have not modified anything with ioo in the last few weeks.

 

  9078   Wed Aug 28 03:28:00 2013 JenneUpdateLSCPlaying with DRMI, some ASS automation prep

[Rana, Jenne]

We did lots of poking around with the DRMI tonight.  I should elog more in the morning, but the most important points are:

Locking settings same as elog 9068, except PRCL gain changed to 0.035, and the FMs that are triggered.  PRCL tonight had FM2,3,6 triggered.  MICH had FM1,2,3,7 triggered.  SRCL had FM1,2 triggered.  Engaging the MICH boosts helped make things more quiet, so that some of the SRC boosts could be enabled.  Still not as good of lock stretches as Koji got last Friday (elog 9060). 

REFL55 and REFL11 were still saturating (only during acquisition), after the optical path changes I did last week (elog 9043).  We reduced the REFL55 whitening slider from 15 dB to 6 dB (but forgot to compensate with digital gain), to keep the counts (as seen on DTT time series, binning off) to less than ~20,000 counts.  REFL11 is still saturating, and we're not sure why, since it's slider gain is 0 dB.  To be investigated.

I was prepping the ASS to be more conveniently put into a wrapper script, which could be called from the IFO Configure screen.  This involved adding PRCL to the burt .req and .snap files, as well as modifying the scripts a little bit to include PRCL as an option.  I ended up changing the script names from DITHER_Arm_ON.py and DITHER_Arm_OFF.py to DITHER_ASS_ON.py adn DITHER_ASS_OFF.py, since they are no longer restricted to being arms-only.  You must still provide an argument to the script, to tell it which degree of freedom you want to activate.  I also changed the save offsets scripts.  The way they were, the X and Y arms just had separate hard-coded scripts, with no convenient way to incorporate PRCL.  I merged them (including PRCL) into WRITE_ASS_OFFSETS.py, which you must now provide the DoF as an argument.  I tested these new scripts on all 3 of the DoFs, and made changes to the ASS screen, so it now calls only the new scripts.  It should now be easy to incorporate future ASS modifications.

Rana was in the middle of modifying the ASS model to include SRCL, and we also need to include MICH.  The ASS model is not compile-ready, so don't compile it!!  If you need to compile the ASS, please save what's there as a different name, and do an "svn up" to get the latest working version.


We suspected that there might be angular drive issues with the SRM (it was wiggling a lot). We checked the damping via step responses - all Qs were less than 10. Then we found that the INPUT button on the SRM PIT OL was OFF (why ???). After turning this back on it behaved better. We measured the loop shape and found that the UGF was 7 Hz; good. Need to work on some loop shaping for this guy. Its just 1/f out to 300 Hz right now. UGF should be made a little lower so that we can stably turn on the Bounce/Roll notches and a ~50 Hz low pass filter.

Most importantly, the F2A filters need to be measured and implemented. They are a few years old.

  9077   Wed Aug 28 00:41:23 2013 JenneUpdateCDSCDS svn commits not happening

svn status update. asx, als and ioo were found not committed. Not sure about who modified ioo last after Jenne.

//edit Manasa - edited the/ elog instead of replying //

  9076   Tue Aug 27 20:43:34 2013 KojiConfigurationCDSfront end IPC configuration

The reason we had the PCIe/RFM system was to test this mixed configuration in prior to the actual implementation at the sites.
Has this configuration been intesively tested at the site with practical configuration?

Quote:

Attached is a graph of my rough accounting of the intended direct IPC connections between the front ends. 

It's hard to believe that c1lsc -> c1sus only has 4 channels. We actuate ITMX/Y/BS/PRM/SRM for the length control.
In addition to these, we control the angles of ITMX/Y/BS/PRM (and SRM in future) via c1ass model on c1lsc.
So there should be at least 12 connections (and more as I ignored MCL).

I personally prefers to give the PCIe card to c1ioo and move the RFM card to c1lsc.
But in either cases, we want to quantitatively compare what the current configuration is (not omitting the bridging by c1rfm),
and what the future configuration will be including the addtional channels we want add in close future,

because RFM connections are really costly and moving the RFM card to c1lsc may newly cause the timeout of c1lsc
just instead of c1sus.

  9075   Tue Aug 27 19:50:06 2013 JamieConfigurationComputer Scripts / Programscdsutils checked out into /opt/rtcds

I have checked out the new cdsutils repository at:

/opt/rtcds/cdsutils/release

This is a new repository that is intended to hold all of our python libraries and command-line utilities for interacting with the IFO, things like:

  • get/write values EPICS channels
  • interact with filter module switches
  • average a test point for some amount of time
  • etc.

Basically everything that used to be ez* or tds*.

There's not much in there at the moment, but hopefully it will start to get filled in soon.

WARNING:

This code in here will be used by the sites to interact with the real aLIGO IFOs.  Please be careful as you develop things in here, and o so conscientiously.  If you do bad things here and it messes things up at the sites people will be angry.  Particularly me, since I have to support everything in here for Guardian use.

Usage

<cdsutils>/lib/cdsutils is the primary python library.  For each function you want to add, put it in a new file named after the function.  So for instance function "foo" should be in a file called <cdsutils>/lib/cdsutils/foo.py.

There is a command line utility at <cdsutils>/bin/cdsutils.  It will automatically find anything you add to the library and expose it as a sub command (e.g. "cdsutils foo")

We'll try to put together a wiki page describing development and usage of this soon.

  9074   Tue Aug 27 19:34:36 2013 JamieConfigurationCDSfront end IPC configuration

So the IPC situation on the front end network is not so great right now.  For various no-longer-valid reasons, c1lsc had no RFM card, all the IPC connections were routed through the c1rfm model on c1sus, and routed to c1lsc via dolphin PCIe as needed.  As things grew, c1rfm became overloaded.  Koji tried to fix the situation by breaking things out of c1rfm to make direct connections where we could.  This cleared up c1rfm a bit, but not c1mcs is overloading.

Reminder: PCIe (dolphin) is faster and higher bandwidth than RFM.  The more things we can put on PCIe the better.

Attached is a graph of my rough accounting of the intended direct IPC connections between the front ends.  By "intended direct" I mean what should be direct connections if we had all the appropriate hardware.  Right now the actual connection graph is more convoluted than this since things are passing through c1rfm.  I note this graph was NOT particularly easy to make, which is very unfortunate.  I had to manually look through every model and determine the ultimate source of every incoming IPC.  Kind of a pain in the butt.  It would be nice if there was a simple way to represent this.

Here are some various solutions to the problem as I see it:

a) put c1lsc on the RFM network

This would allow c1lsc to talk to c1ioo, c1iscex, and c1iscey without having to go through c1sus, thereby eliminating c1rfm altogether.  I'm not sure why we didn't just do this originally.

Requires:

  • One RFM card for c1lsc

b) put c1ioo on the PCIe network (and move c1sus's RFM card to c1lsc)

This is probably the most robust solution.

b1) There are roughly 8 IPCs going from c1ioo to c1sus, and 4 going the other way, and 3 IPCs from c1ioo to c1lsc.  If we put c1ioo on PCIe all of these now RFM connections would become direct PCIe connections, which would be a big win.

At this point only the end station front ends would be on RFM, and most of the connections to those come from c1lsc, so it would make sense to give c1lsc the RFM card, thereby eliminating a lot of stuff from c1rfm.

Requires:

  • dolphin card for c1ioo (do the old sun machines support these?  if they don't we could swap the old sun machine with a new spare aLIGO-approved supermicro machines, which we have spares of)
  • dolphin fibre to go to dolphin switch in 1X3 rack

b2) OR, we could move c1ioo to 1X4 with c1lsc and c1sus, and get a OneStop fibre cable to connect to its IO chassis.  We would still need a dolphin card, but we could use coper instead of fibre.  This is my preferred solution, since it moves c1ioo out of 1X1, where it's really in the way and making a lot of noise.  It would also be easier to manage all the machines if they're together in one rack.

Requires:

  • dolphin card for c1ioo
  • dolphin coper cable for c1ioo
  • OneStop fibre for c1ioo

c) put another cpu in c1sus

c1sus is (I believe) able to support another 6-core cpu.  If we added more cores to c1sus, we could break up c1rfm into c1rfm0, c1rfm1, etc.  This is a less elegant solution imho, but it would probably do the job.

Requires:

  • one new CPU for c1sus
Attachment 1: hosts.png
hosts.png
ELOG V3.1.3-