Something is wrong with the timing we're getting out of the symmetricom driver, associated with the new spectracom card.

controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 127$ lalapps_tconvert 
1149538884
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ cat /proc/gps 
704637380.00
controls@fb1:~/rtscore/tests/advLigoRTS-40m/src/drv/symmetricom 0$ 

The GPS time is way off, and it's counting up at something like 900 seconds/second.  Something is misconfigured, but I haven't figured out what yet.

The timing distribution module we're using is spitting out what appears to be an IRIG B122 signal (amplitude moduled 1 kHz carrier), which I think is what we expect.  This is being fed into the "AM IRIG input" connector on the card.

Not sure why the driver is spinning so fast, though, with the wrong baseline time.  Reboot of the machine didn't help.

2x500 ml bottles of spectroscopic grade isopropanol were delivered. I marked them with today's date and placed them in the solvent cabinet. In the process, my shoulder bumped the laser interlock switch by the door to the VEA in the drill press area, which turned the PSL NPRO off. I turned it back on just now. The other NPROs are not connected to the interlock and so were unaffected.

As I am sitting in the control room, the PRM suspension watchdog tripped again. This time, there is clearly no seismic activity. Yet, the BS suspension also shows a slight disturbance at the same time as the PRM. ITMY shows no perturbation though. My best hypothesis here is that the problem is electrical. In Attachment #1, you can see that all of the Sensors go to -6000 cts (whut?) for ~30 seconds. Zooming in to that segment in Attachment #2, it would appear that the light detected by the LED changed dramatically (went dark?) on all 5 coils. The 4 face coils have the same time constant but the side has a different one, but in any case, this level of light change in half a second is clearly not physical. Then the watchdog trips because this huge apparent motion elicits a kick from the damping loops.

The plots I attach are for the DQed sensor channels, so there is some digital filtering involved. But I confirmed that the signal doesn't go negative if I disable the input to the filter module. So it would seem that the voltage input to the ADC really chanegd polarity, seems unphysical. Could be Satellite Box or whitening electronics I suppose - I think we can exclude bad cabling, as that would just lead to the signals going to 0, whereas it would appear here that they did really change sign (confirmed by looking at the ULPDmon channel, which is digitized by Acromag, which reports -10 V at the time of glitch). But why should the BS care about the PRM electronics going wonky?

In addition to an exorcist, we need functioning electronics!

This optic has been hampering my locking attempts all evening. I switched the PRM and SRM satellite boxes, but then I remembered PRM has the Al foil "hats" to attenuate scattered light. of course the Al foil is conducting and can short the OSEM leads. I put some kapton pieces in between OSEM and foil to try and mitigate this issue but I suppose over time it could have slipped, and is making some intermittent contact, shorting PD anode and cathode (that would explain the PD reporting -10 V instead of some physical value).

If this is the problem we would need a vent to address it. In the daytime I'll measure L and R of the coils to see if the actuator imbalance I reported is also due to the same problem...

Steve had showed me some stock of long fibers a while back - they are from Oz Optics, and are 50m long, and are already spooled - so barring objections, we will try the MZ setup with the spooled fiber and see if there is any improvement in the fringing rate of the MZ. Then we can evaluate what additional stabilization of the fiber length is required. Anjali will upload a photo of the spooled fiber.

• Attchment #1,2,3 and 4 shows the results with frequency modulation of 32 Hz, 140 Hz , 300 Hz and without frequency modulation. I am trying to understand these results better.
• A lot of fringing is there even when no modulation is applied. We hope to improve this by spooling the fiber and then encasing it in a box. 
• As mentioned by Gautam, we have got a 50 m spooled fiber. Attachment #5 shows the photo of the same

Summary

The spot positions on the MC mirrors were measured with coil balance gains.
The estimated spot positions from the center of the MC1 and MC3 are as followings:

MC1H = +0.29 mm
MC1V = -0.43 mm
MC3H = +1.16 mm
MC3V = -0.68 mm

The cordinates are described in the figure

Method

As far as the cavity mirrors are aligned to the incident beam, spots on the MC1 and MC3 tell us the geometry of the incident beam.
Note that spot position on the MC2 is determined by the alignment of the MC1 and MC3, so it does not a big issue now.
The calibration between the coil balance and the spot position are described in the previous entry.

1. Lock the MC. Align it with MC2/MC3
2. Run A2L scripts. script/A2L/A2L_MC1 and so on.
   
   • The scripts run only on the solaris machines. They require "expect" in stalled some specific place which does not exist on the linux machines.
   • Excitation amplitude, excitation freq, readback channels were modified

Result

Beam powers
MC Trans: 0.18
MC Refl: 0.12-0.13

Alignment biases
MC1P 3.2531
MC1Y -1.0827
MC2P 3.4534
MC2Y -1.1747
MC3P -0.9054
MC3Y -3.1393

Coil balances
MC1H 1.02682
MC1V 0.959605
MC3H 0.936519
MC3V 1.10755

(subtract 1, then multiply 10.8mm => spot position.)

[Unni, Manasa, Jenne]

It turned out that the beam was a teeny bit high in the corner, so we touched PZT1 and PZT2 knobs to translate the beam down a bit.

Now the beam is centered on the BS (using the 45 degree non-iris target), centered on ETMY (using Steve's latest target, which worked perfectly), and then BS was aligned a tiny bit (really, it didn't need much) to get the beam centered on ETMX.

After dinner I'll align ITMX and ITMY such that their beams retroreflect and I get MICH fringes.  I'll also align SRM and PRM to retroreflect.  Check no clipping on AS path, get REFL path out, center IPPOS and IPANG, check POX, POY and POP.  Then, I think we might be almost done.

I want to measure the spot positions on the IMC mirrors. We know that they can't be too far off centerBasically I did the bare minimum to get these scripts in /opt/rtcds/caltech/c1/scripts/ASS/MC/ running on rossa (python3 mainly). I confirmed that I get some kind of spot measurement from this, but not sure of the data quality / calibration to convert the demodulated response into mm of decentering on the MC mirrors. Perhaps it's something the MC suspension team can look into - seems implausible to me that we are off by 5mm in PIT and YAW on MC2? The spot positions I get are (in mm from the center):

MC1 P          MC2P           MC3P           MC1Y          MC2Y           MC3Y

0.640515    -5.149050    0.476649    -0.279035    5.715120    -2.901459

A future iteration of the script should also truncate the number of significant figures per a reasonable statistical error estimation.

[kevin, gautam]

We have been working on double checking the noise budget calculations. We wanted to evaluate the amount of squeezing for a few different scenarios that vary in cost and time. Here are the findings:

All calculations done with

• 4.5kohm series resistance on ETMs, 15kohms on ITMs, 25kohm on slow path on all four TMs.
• Detuning of SRC = -0.01 deg.
• Homodyne angle = 89.5 deg.
• Homodyne QE = 0.9. 
• Arm losses is 20ppm RT.
• LO beam assumed to be extracted from PR2 transmission, and is ~20ppm of circulating power in PRC.

Scenarios:

1. Existing setup, new RC folding mirrors for PRG of ~45.
2. Existing setup, send Innolight (Edwin) for repair (= diode replacement?) and hope we get 1.7 W on back of PRM.
3. Repair Innolight, new PRM and SRM, former for higher PRG, latter for higher DARM pole.
4. Same as #3, but with 10 W input power on back of PRM (i.e. assuming we get a fiber amp).

Remarks:

• The errors on the small dB numbers is large - 1% change in model parameters (e.g. arm losses, PRG, coil driver noise etc) can mean no observable squeezing. 
• Actually, this entire discussion is moot unless we can get the RIN of the light incident on the PRM lower than the current level (estimated from MC2 transmission, filtered by CARM pole and ARM zero) by a factor of 60dB.
  • This is because even if we have 1mW contrast defect light leaking through the OMC, the beating of this field (in the amplitude quadrature) with the 20mW LO RIN (also almost entirely in the amplitude quad) yields significant noise contribution at 100 Hz (see Attachment #1).
  • Actually, we could have much more contrast defect leakage, as we have not accounted for asymmetries like arm loss imbalance.
  • So we need an ISS that has 60dB of gain at 100 Hz. 
  • The requirement on LO RIN is consistent with Eq 12 of this paper.
• There is probably room to optimize SRC detuning and homodyne angle for each of these scenarios - for now, we just took the optimized combo for scenario #1 for evaluating all four scenarios.
• OMC displacement noise seems to only be at the level of 1e-22 m/rtHz, assuming that the detuning for s-pol and p-pol is ~30 kHz if we were to lock at the middle of the two resonances
  • This assumes 0.02 deg difference in amplitude reflectivity b/w polarizations per optic, other parameters taken from aLIGO OMC design numbers.
  • We took OMC displacement noise from here.

Main unbudgeted noises:

• Scattered light.
• Angular control noise reinjection (not sure about the RP angular dynamics for the higher power yet).
• Shot noise due to vacuum leaking from sym port (= DC contrast defect), but we expect this to not be significant at the level of the other noises in Atm #1.
• Osc amp / phase.
• AUX DoF cross coupling into DARM readout.
• Laser frequency noise (although we should be immune to this because of our homodyne angle choice).

Threat matrix has been updated.

To be quantitative, since we are looking at smaller squeezing levels and considering the possibility of using 5 W input power, it is possible to see a small amount of squeezing below vacuum with no SRM.

Attachment 1 shows the amount of squeezing below vacuum obtainable as a function of homodyne angle with no SRM and 5 W incident on the back of PRM. The optimum homodyne angle at 210 Hz is 89.2 deg which gives -0.38 dBvac of squeezing. Figure 2 is the displacement noise at this optimal homodyne angle and attachment 3 is the same noise budget shown as the ratio of the various noise sources to the unsqueezed vacuum.

The other parameters used for these calculations are:

• 4.5 kΩ series resistance for the ETM coils; 15 kΩ for the ITM coils
• 100 ppm transmissivity on the folding mirrors giving a PRC gain of 40
• PD quantum efficiency of 0.88

So maybe it's worth considering going for less squeezing with no SRM if that makes it technically more feasible.

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.

VS

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

By including a differentiator from 10 Hz to 50 Hz, we increase the phase margin and the resulting

magnetic levitation system is stable even without the help of eddy-current damping.

The new block diagram for the system is the following:

Here the eddy-current damping component is removed and we add an additional differential

circuit with an operational amplifier OP27G.

In addition, we place the Hall sensor below the magnet to minimize the coupling between

the coil and the Hall sensor.

The resulting levitation system is shown by the figure below:

[Paco, Yehonathan, Yuta, Hiroki]  

Achieved stabler lock of sideband-resonant PRMI w/ 3f by tuning feedback damping

We worked on the PRMI and achieved the followings:

• Added an action button to lock sideband-resonant PRMI w/ REFL33 easily
• Tuned the gains for feedback damping to lower the coherences between ASDC and error signals for damping
• Achieved stable lock of sideband-resonant PRMI w/ REFL33
  • Lock stretch for ~7min. : 1375245020 - 1375245310

Details

Action button to lock sideband-resonant PRMI w/ 3f:
To switch the control loop between carrier-resonant PRMI w/ 1f and  sideband-resonant PRMI w/ 3f easily, we added an action button in the LSC window that activates the control loop for sideband-resonant PRMI w/ 3f.
The saved lock conditions are as follows (*whitening gain and demod. angle are not changed by the action button.):

• MICH:
  REFL33_Q (30 dB whitening gain, -19.275 deg demod angle), Power norm. = 0.002*POP110_I, C1:LSC-MICH_GAIN=-1.56, offset=0, boost= off, roll_off=off , Actuator = 0.5*BS-0.307*PRM
• PRCL:
  REFL33_I (30 dB whitening gain, -19.275 deg demod angle),Power norm. = 0.002*POP110_I, C1:LSC-PRCL_GAIN=0.036, offset=0, boost = on, Actuator = 1*PRM
• Trigger:
  POP110_I*1 ⇒ MICH_TRIG ⇒ Threshold upper:150, lower:100
  POP110_I*1 ⇒ PRCL_TRIG ⇒ Threshold upper:150, lower:100

The parameters above are saved in scripts/LSC/PRMIsb-REFL33.yml 

Tuning of feedback damping: 
We locked PRX and monitored the coherences between ASDC and error signals of feedback damping for BS, PR2, PR3, PRM and ITMX.
Then we changed the gains of OSEM loop and OPLEV loop so that the coherences would be small:

• PR3
  C1:SUS-PR3_SUSPIT_GAIN: 30 -> 5
  C1:SUS-PR3_SUSYAW_GAIN: 30 -> 5
• BS
  C1:SUS-BS_SUSPIT_GAIN: 7 -> 10
  C1:SUS-BS_OLPIT_GAIN: -0.1 -> -0.05
• PRM
  ​C1:SUS-PRM_OLPIT_GAIN: 9 -> 6

The resulting spectra and coherences are shown in Attachment 1.

Success in stable locking of sideband-resonant PRMI w/ 3f:
As a result of gain tuning above, we succeeded in locking sideband-resonant PRMI w/ 3f for ~7min.

• Lock stretch: 1375245020 - 1375245310

Some clarification is warranted regarding the different shapes of stacks. Corrections are appreciated:

1) The single-leg stack that I just completed should function as a working model for the IO, OO, and MC1/3. Rana commented, however, that the current dimensions are slightly off for MC1/3 (which makes sense since I could only find drawings for the IOC). If anyone knows the whereabouts of similar drawings for MC1/3, I'd much appreciate it.

2) A triple-leg stack can model the BS, ITMX, and ITMY chambers. I don't have exact dimensions for these, but I can make decent approximations from to-scale stack drawings. I'll probably work on a model for this style next, since at least I have some information regarding this version.

3) The MC2 chamber has its own stack model, about which I haven't found any drawings in the binders. I can't start on MC2C at all until I find such drawings.

[steve,gautam]

We tried to estimate what the load cell measurement should yield. Here is the weight breakdown (fudge factor for Al table is to try and account for tapped holes):

• Steve pointed out that there is some material removed from the stack legs for stability (hollows into which the viton springs fit). These countersinks have dimensions of diameter=2", height=1.75". So if we assume each leg has 10% less mass, the total weight becomes ~4600lbs.
• I think we will need to use one more load cell (i.e. total 4) for this measurement (we have more load cells, just need to setup one more controller).
• Steve is looking into acquiring some low profile jacks to deal with the fact that we only have limited travel range on the overall stack height because of the bellows.
• A useful document, from which we pulled some numbers (which also look reasonable using estimated dimensions and density calculations): P952005

[SV,KA,RXA,GV]

The stack weight measurement is going on at EX. ETMX watchdog is shutdown. Area is off limits over the weekend until the test is finished.

Not related to this work, but the dog clamps used on the EX table have to be re-positioned such that the clamping force is better distributed. The 2" beam splitter mount used to pick off a portion of the EX NPRO beam to the fiber has to be rotated. Also, there was a M6.9 EQ in Hawaii while we were doing this work it seems..

[steve,koji,gautam]

Since we think we already know the stack mass to ~25% (i.e. 5000 +/- 1000 lbs), we decided to restore the ETMX stack. Procedure followed was:

• Take photos of all dial indicators and spirit level. We were at ~-22 mils on all 3 indicators, with 0 being the level before we touched the stack two Fridays ago, i.e. May4.
• Raised all four jacks installed underneat blue crossbeams in 5mil increments until we were at +25mils on all of them. At this point, there was negligible load on the load cells on top of the STACIS legs, and we could easily slide the load cells out.
• Rotated all jack screws clockwise (i.e. moving jack screws downwards) by 270 degrees. The southeast jackscrew was rotated by an additional 360 degrees. This was to undo all the jack-screw raising we did on Friday, May 4.
• Re-installed jacks which were present originally on the STACIS legs, taking care to center the jack as best as we could by eye on the STACIS leg, per Dennis Coyne's suggestion not to impose shear strain on STACIS legs. There were supposedly never carrying any load, and are according to Steve, are there more for safety purposes.
• Lowered all four jacks in 5 mil steps until dial indicators read ~0. The Northwest jack resting on the STACIS leg was somehow ~0.5cm (!!) below the blue crossbeam even though the corresponding dial gauge read 0, so we raised the jack until it was barely grazing the bottom of the blue crossbeam (confirmed by looking at the point where the dial indicator started going up again). Not sure why this should have been, best hypothesis we have is that someone (one of us) changed the level of this jack while it was removed from the setup.
• Checked that jack screws could not be turned by hand. At this point, all the load has to be resting on the jack screws, as the jacks we had installed to raise the blue crossbeams could be slid out from underneath the blue beams and hence were carrying no load.
• Took photographs of all dial indicators, spirit level. We were satisfied that we had recovered the "nominal" stack alignment as best as we could judge with the available indicators.
• ETMX Oplev spot had returned to the PD. ETMX watchdog was re-engaged, optic was re-aligned using SLOW bias sliders to center Oplev spot.
• EX NPRO was turned back on, and the green beam was readily locked to a cavity TEM00 mode .

I will upload the photos to the PICASA page and post the link here later.

The final set-up of stack measurment with 3 load cells and 4 leveling wedge mounts as Atm 1

Sensor voltages BEFORE and AFTER this attempt.

 I'll be gone to Hanford site next week and come back to Caltech on 24th's week.

I setup a standalone RT system at the desk around circuit stock in the 40m.

Please leave this setup until I come back. I'll keep working when I come back.

I had 8 standoffs made at the Caltech chemistry machine shop to be used as spacers for the side magnets on the 3" Ring assembly. This is to create enough clearance between the magnet and the cap screws directly above on the wire clamp.

These are 0.075" diameter by .10" length. Putting them through clean and bake now.

Tried locking the arms

• Ran IFO > Configure > ! (YARM) > Restore YARM. Nothing happened.
• Trying to align through tip-tilt:
  • Previous values: TT1: PIT: -1.7845, YAW: -0.2775; TT2: PIT: -1.3376, YAW: -0.0436
  • Couldn't get flashing of light in the arms at all.
  • Restored values to previous values.
• Noticed that ITMY OPLEV YAWW Error has gone very high overnight while other oplevs remained the same.
• Trying to change the C1:SUS-ITMY_YAW_OFFSET to bring this oplev yaw error back to near zero.
• Changed C1:SUS-ITMY_YAW_OFFSET from -34 to 50. OPLEV_YEROR reduced to around -23 from -70.
• Same thing with BS PIT. OPLEV_PERROR is highlighted in red at -52.
• Changing C1:SUS-BS_PIT_OFFSET from 55 to 30. This brought OPLEV_PERROR to -15 from -52.
• Trying to align PRM by changing C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET.
• Inital values: C1:SUS-PRM_PIT_OFFSET: -20 , C1:SUS-PRM_YAW_OFFSET: 39.

Did the WFS step response test on IMC in between while waiting for help. See 16094.

Back to trying arm locking

• Tried IFO > Configure > ! (XARM) > Restore YARM. Nothing happened.
• Tried IFO > Configure > ! (YARM) > Restore YARM. Nothing happened again.
• Tried Movie Capture of AS screen from VIDEO > Movie Capture > AS. But the script failed due to module not present error.

PMC got unlocked

• Infront of me, PMC got unlocked. I did not go to PMC locking the screen at all since morning.
• I opened the C1PSL_PMC screen. The PSL Autolocker blinker is not blinking but the switch is set to Enable. 
• I do not see any automatic effort happening for regaining lock at PMC.
• I'll try it manually. I was able to get the PMC locked again. C1:PSL-PMC_PMCTRANSPD is showing 0.761 V and C1:PSL-PMC_RFPDDC is showing 0.053 V.
• Now IMC auto locker seems to be trying to get the lock acquired.
• It acquired a lock a few times but struggled to keep it on. I reduced C1:IOO-WFS_GAIN to 0 and then the lock could stay on. Seemed like the accumulated offsets were not good.
• So I cleared the history on WFS1, TRANS and WFS2 filter banks and then ramped the WFS overall gain (C1:IOO-WFS_GAIN) back to 1 and now IMC seems to stay locked in a stable configuration.
• However, I still don't know what caused the PMC to get unlocked in the first place. Did my repeated arm locking attempts did something to the main laser frequency?

Back to trying arm locking

• Tried IFO > Configure > ! (YARM) > Restore YARM again. Nothing happened again.

t Both arms were locked simply by using IFO > Configure > ! (YARM) > Restore YARM. I had to use ASS to improve the TRX/TRY to ~0.95.

I measured C1:LSC-XARM_IN1_DQ and C1:LSC-YARM_IN1_DQ while injecting band limited noise in C1:IOO-WFS1_PIT_EXC using uniform noise with amplitude 1000 along with filter defined by string: cheby1("BandPass",4,1,80,100). I calibrated the control arms signals by 2.44 nm/cts calibration factor directly picked up from 13984.

For the duration of this test, all LIMIT switches in the WFS loops were switched OFF.

I do not see any affect on the arm control signal power spectrums with or without the noise injection. Attachement 1 shows the PSD along with PSD of the injection site IN2 signal. I must be doing something wrong, so would like feedback before I go further.

This is the actuator calibration. For the error point calibration, you have to look at the filter in the calibration model. I think it's something like 8e-13m/ct for POX and similar for POY.

Joe and I started working on the new LSC FE control today. We made a diagram of the system in Simulink, but were unable to compile it.

Joe checked out the latest CDS software out of their new SVN and put it somewhere (perhaps his home directory).

We then copied the directory with the .mdl files and the CDS parts library into our real Simulink Model Directory:

/cvs/cds/caltech/cds/advLigo/src/epics/simLink

Use this and not someplace in Alex or Rob's home directory !

Joe will put in more details on Monday once he figures out how to build the new stuff. Basically, we decided not to support multiple versions of the CDS real time code here. We'll just stay synced to the latest stable ~versions.

I exported the current version of the LSC FE into our public_html/FE/ area on nodus where we will put all of the self-documenting FE diagrams:

https://nodus.ligo.caltech.edu:30889/FE/lsc_slwebview_files/index.html

To make a web setup like this, you just use the "Export to Web" feature from the top-level Simulink diagram (e.g. lsc.mdl). Choose the following options:

Note: in order to get the web page to work, I had to change the apache httpd.conf file to allow AddType file overriding. Here's the term cap of the diff:

nodus:etc>diff httpd.conf httpd.conf~
155c155
< ServerAdmin jenne@caltech.edu
---
> ServerAdmin aso@caltech.edu
225d224
<     AllowOverride FileInfo

LSC Plant Model. That is all.

Once you made a CDS model, please update the following wiki page. This will eventually help you.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/Existing_RCG_DCUID_and_gds_ids

The SVN checkout was done on megatron.  It is located under /home/controls/cds/advLigoRTS

So, to compile (or at least try to) you need to copy the .mdl file from /cvs/cds/caltech/cds/advLigo/src/epics/simLink to /home/controls/cds/advLigoRTS/src/epics/simLink on megatron, then run make SYS in the advLigoRTS directory on megatron.

The old checkout from CVS exists on megatron under /home/controls/cds/advLigo.

I tried many times this evening to engage the AO path, with limited success.

Q's new scripts worked really well, and so I have some transfer functions!  To take these measurements, in ...../scripts/general/netgpib, I am running ./TFSR785 TFSR785_CARMloop_May2014.yml, where the file name is the name of my parameter file.  The data, and the saved pdfs, are in /users/jenne/PRFPMI/CARM_loop_measurements/2014May14/ .  For these measurements, the SR785 is hooked up to the "A" set of excitation and test points on the CM board.

All of these traces were taken while the IFO was PRFPMI, with PRCL and MICH on REFL33, DARM on ALS diff, and CARM on InvSqrtTrans.  carm_cm_up.sh is up to date, through the echo "REFL_I should now be zero" (~line 111 in the script).  All you need to do is set the beatnotes, and then run the script.  Follow instructions in the prompt (such as "press enter to confirm PRMI is locked"). 

Here are my notes for the various times:

23:01:44 - MC IN2 = 0dB, CARM gain = 5.0

23:13:45 - MC IN2 = 10dB, CARM gain = 5

23:26:10 - MC IN2 = 6dB, CARM gain = 10 (after Q suggested increasing overall gain, rather than just AO path)

00:13:07 - MC IN2 = 6dB?, CARM = 6ish?  don't remember exactly.

00:45:00ish, Realigned IFO using IR with arms.

01:03:17 - MC In2 = 0dB, CARM gain = 5

01:07:42 - MC IN2 = 8dB, CARM gain = 6.295  (AO went up to 6dB, then +1dB steps to both simultaneously using  ezcastep C1:LSC-CARM_GAIN 1dB C1:IOO-MC_AO_GAIN 1)

01:08:57 - MC IN2 = 10dB, CARM gain = 7.92447

01:10:08 - MC IN2 = 12dB, CARM gain = 9.97631

lockloss when trying to add 1 more dB to both.

01:41:36 - MC IN2 = 12dB, CARM gain = 9.97

lockloss when just MC IN2 up by 1dB, left CARM gain alone.

Other notes:

The 60Hz noise in TRY is back.  Since I thought I remembered someone suggesting that it was leakage light from the exit sign, Koji went in and wrapped the end table in foil, however the lines are still present.

 In addition to a transparent legend, we need the corresponding CM crossover measurements from DTT to compare with the Q-Mist-Loop model results. The xover tells us when the AO gain is high enough so that they can be ramped up together.

Also, I wonder how much power fluctuation we get from the large ALS DIFF noise and if that demands we get the TR signals normalized by POPDC.

[Steve, Koji, Gautam]

We started pumping down at ~12:15PM.

Vent finalization ~ YEND

• The table leveling was way off. This was adjusted by the balancing weight. (Attachment 1~3)
• The alignment of ETMY was not too much off. Just aligned it with the oplev spot on MEDM and this already made the green flashing.
• The Green TEM00 was maximized with ITMY and ETMY. This made the PSL IR flashing.
• The heater wires were checked. I found that one of the heater wires was touching the optical table via the cable shield. This is because the upper pins were shifted to the left side (Attachment 4&5). The pins were shifted and now all 4 cables are isolated form the table. I also checked the mutual resistance between the 4 terminals. They were measured to be isolated except two pairs that showed 4.4 Ohms and 4.0 Ohms (Attachment 6)
• The tools were removed from the chamber. The Y arm was still flashing.
• We closed the ETMY door.

Vent finalization ~ Vertex

• Found the ITMX stuck. Gautam came in and showed us his black magic to release the optic...
• This allowed us to align X arm. The green flash was found and the TEM00 flash was seen. This allowed us to see the PSL IR flash at the X end.

• PRM Refl was aligned. SRM was aligned with the oplev.
• The beam on the AS port was checked. The AS beam came out from the window.
• Closed the OMC chamber.

Pumping

• Started pumping with RP1 and RP3. (~12:15PM)

Steve and Koji

WE started to build 5 TTs. 4 of them are used in the recycling cavities. One is the spare.

We built the structure and are building the cantilever springs.

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.

I'm working on the PSL table to set up the PLL setup for the AbsL experiment.

I've been trying to start recovering IFO functionality, but quickly hit a frustrating roadblock. 

Upon opening the PSL shutter, and deactivating the MC mirror watchdogs, I saw the MC reflected beam moving way more than normal. 

A series of investigations revealed no signals coming out of c1sus's DAC.  

The IOP (c1x02) shows two of its DAC-related statewords (DAC and DK) in a fault mode, which means (quoting T1100625):

"As of RCG V2.7, if an error is detected in oneor more DAC modules, the IOP will continue to run but only write zero values to the DAC modules as a protective measure. This can only be cleared by restarting the IOP and all applications running on the affected computer."

The offending card may be DAC1, which has its fourth bit red even with only the IOP running, which corresponds to a "FIFO error". /proc/c1x02/status states, in part:

DAC #0 16-bit fifo_status=2 (OK)
DAC #1 16-bit fifo_status=3 (empty)
DAC #2 16-bit fifo_status=2 (OK)

Squishing cables and restarting the frontend have not helped anything. 

c1lsc, c1isce[x/y] are not suffering from this problem, and appear to be happily using their DACs. c1ioo does not use any DAC channels. 

As a further headache, any time I restart any of the models on the c1sus frontend, the BURT restore is totally bunk. Moreover, using burtgooey to restore a good snapshot to the c1sus model triggers a timing overflow and model crash, maybe not so surprising since the model seems to be averaging ~56usec or so. 

We need to update the indicators on the CDS_FE_STATUS screen to expose the new indicators, so that we have better visibility for these issues.

I'm not sure why this DAC is failing. It may indicate an actual problem with the DAC itself.

This is related to changes to how the front ends load their safe.snaps. I think they're now explictly expecting the file:

targtet/<model>/<model>epics/burt/safe.snap

I'll come over this afternoon and we can get acquainted with the new SDF system that now handles management of the safe.snap files.

Jamie showed me how to use the SDF system. We created new safe.snap files for all of the running models based on the autoburts from the morning of July 1st, before the upgrade began, and then pruned them of invalid channels. 

Now all of the models start up without having to race for the BURT button. 

We saw that c1sus was timing out all over the place once the filter settings had been restored. I was thinking I would move one of the vertex optics into c1mcs, but instead I found it easier to remove the global damping parts. Now the c1sus model runs at ~50usec.

The c1sus frontend's DAC is still nonfunctional. Jamie is seeking advice. 

Will advise when I'm finished, will be by 1 pm for ALS work to begin.

Testing is finished.

[Koji, Jc]

Koji and I began starting that Vacuum system up.

1. Reverse order step 2 of shutting down electronics. Anthing after, turn on manually.
2. If C1vac does not come back, then restart by holding the reset button.
3. Open VA6
4. Open VASE, VASV,VABSSCI, VABS, VABSSCO, VAEV, and VAEE
5. Open V7
6. Check P3 and P2, if they are at high pressure, approx. 1 Torr range, then you must use the roughing pumps.
7. Connect Rotary pump tube. (Manually)
8. Turn on AUX Pump
9. Manually open TP2 and TP3 valves.
10. Turn on TP2 and TP3, when the pumps finish startup, turn off Standby to bring to nominal speed.
11. Turn on RP1 and RP3
12. Open V6
13. Once P3 reaches <<1 Torr, close V6 to isolate the Roughing pumps.
14. When TP2 and TP3 are at nominal speed, open V5 and V4.
15. Now TP1 is well backed, turn on TP1.
16. When TP1 is at nominal speed, Open V1.

- Once the FRG gauge readings are back (see next elog by Tega), I could open V1 to pump down the main vacuum manifold.
- TP2/TP3 were brought back to stand-by mode (slower spinning)
- V7 was closed to separate the annuli side and TP1

During the vacuum recovery, I saw TPs were automatically turned on as soon as the backing pumps were engaged. I could not figure out what caused this automation.

Also, I saw some gate valve states changed while I was not touching them. e.g. V7 was close / VM3 was open / etc
I really had no idea what/who was handling these.

As of ~18:00 local, the main volume pressure is ~2e-5 torr and ready to open the PSL shutter.

[Paco, Yehonathan, JC]

We began starting up all the electronics this morning beginning in the Y-end. After following the steps on the Complete_Power_Shutdown_Procedures on the 40m wiki, we only came across 2 issues.

1. The Green beam at the Y-End : Turn on the controller and the indicator light began flashing. After waiting until the blinking light becomes constant, turn on the beam. 
2. C1lsc "could not find operating system"-unable to SSH from Rossa : We found an Elog of how to restart Chiara and this worked. We proceeded by adding this to the procedures of startup.

I've added states to the summary pages to only show data for times at which one certain channel is above a specified threshold. So far, I've incorporated states for the IOO tab to show when the mode cleaner is locked.

You can see these changes implemented in the IOO tab of my personal summary pages for June 30: https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/ioo/.

I've written a description of how to add states to summary pages here: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp#How_to_Define_and_Implement_States.

The attached table shows the amplitude of the green beat note when the end laser was in various states. We can increase the beat note amplitude dramatically by switching to a different states.

State 1
C1:GCX-GRN_REFL_DC:             638 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    950 avg counts (zero = -794 counts)
amplitude of beat note:            -23dBm (after PD + amps) (f ~ 30 MHz)?
C1:GCX-SLOW_SERVO2_OUT:            318 counts

State 2
C1:GCX-GRN_REFL_DC:             180 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    1270 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked)    1700 avg counts (zero = -794 counts)
amplitude of beat note:            -7dBm (after PD + amps) f = 60MHz
amplitude of beat note:            0dBm (after PD + amps) f = 30MHz
C1:GCX-SLOW_SERVO2_OUT:            290 counts

State 3
C1:GCX-GRN_REFL_DC:             220 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    1120 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked)    1520 avg counts (zero = -794 counts)
amplitude of beat note:            0dBm (after PD + amps) f = 15MHz
C1:GCX-SLOW_SERVO2_OUT:            305 counts

PSL temp = ??
C1:PSL-FSS_SLOWM = -3.524
 

There is an effort to switch to an all-digital system for the GigE camera feeds similar to the one running at LLO, which uses Joe Betzwieser's custom SnapPy package to interface with the cameras in Python and aggregate their feeds into a fancy GUI. Joe's code is a SWIG-wrapping of the commercial camera-driver API, Pylon, from Basler. The wrapping allows the low-level camera driver methods to be called from within Python, and their feeds are forwarded to a gstreamer stream also initiated from within Python. The problem is that his wrapping (and the underlying Pylon software itself) is only runnable on an older version of Ubuntu. Efforts to run his software on newer distributions at the 40m have failed.

I'm working on a fix to essentially rewrite his high-level SnapPy code (generators of GUIs, etc.) to use the newest version of Pylon (pylon5) to interface at a low level with the cameras. I discovered that since the last attempt to digitize the camera system, Basler has released their own official version of a Python wrapping for Pylon on github (PyPylon).

Progress so far:

• I've installed from source the newest version of Pylon, pylon5.0.12 on the SL7 machine (rossa). I chose that machine because LIGO is migrating to Scientific Linux, but I think this will also work for any distribution.
• I've installed from source the the newest, official Python wrapping of the Basler Pylon software, pypylon.
• I've tested the pypylon package and confirmed it can run our cameras.

The next and final step is to modify Joe's SnapPy package to import pypylon instead of his custom wrapping of an older version of the camera software, and update all of the Pylon calls to use the new methods. I'll hopefully get back to this early next week.

[Jenne, TaraV]

We had a look this morning at the status of the seismometer array, so that we can get it all put together. While we were looking at the Guralp at the Yend, we noticed that it was pointing the wrong way.  The North-South nubbins were pointed East-West, so X and Y coming out of the seismometer were backward.

To fix the Yend's Guralp, we powered off the Guralp readout box, rotated the seismometer, re-leveled it, and then turned the power back on.  Now X from the seismometer lines up with the X data channel, and similarly for Y.

The Yend Guralp has all of the cabling needed, and is installed on the granite slab.  This seismometer doesn't need any more work for now.  When we get around to it, we'll need to do some kind of thermal insulation, but other than that, it's good to go.

The Xend will also have a Guralp (Zach still has it in the Gyro lab for now).  We have the long cable that should go from the readout box to the slab that we'll need to put into the cable tray.  The short cable from the slab's plate to the seismometer is already in place.  For this seismometer, we should just need to plop the instrument in place and lay the cable in the overhead cable trays.  We should also remove the now obsolete STS-2 cable while we're doing that.  So, the Xend seismometer station doesn't need too much work.

The corner station will need more work.  Zach made for us the long cable, although he still has it in the Gyro lab, so when we get the seismometer and cable back, we'll need to lay that cable in the overhead trays.  The short cable from the slab's plate to the seismometer does not exist yet.  We want to make sure that we can feed the finished cable and connector through the hole in the slab, and then we'll solder it up out here on the EE bench.  I think this is how Den was doing things.  If not, we'll have to do the soldering in-situ, which we don't want.  So, for the corner station, we need to make the short cable, lay the long cable, get the T-240 back from Zach and put it on the slab, re-install the readout box that Zach has, etc, etc.  We should also make sure that the spaghetti pot fits on the slab, underneath the piece of metal that's sticking out over the slab.  We think that it's the same amount of clearance that the Yend pot has, so it should be okay, but we'll check.  The O-ring seems to be sitting on the MC2 chamber, so we should remember that. 

Neither the Xend nor the corner station had the yellow dog clamps, so we'll have to figure out where Den / Steve have hidden them. 

 EDIT:  We have checked, and the Guralp connector, which is larger than the Trillium connector, fits through the hole in the slab (with some disassembly), so we can solder together the short cable out here on the EE bench, and install it separately.  Eeeeexxxxxcelllent.

A few machines have still not been changed over, including a few laptops, mafalda, ottavia, and c0rga.

All the front ends have been changed over.

fb40m died during a reboot and was replaced with a spare Sun blade 1000 that Larry had.  We had to swap in our old hard drive and memory.

All the front ends, belladonna, aldabella, and the control room machines have been switched over. Nodus was changed over after we realized we hosed the elog and svn by switching linux1's IP.

At this point, 90% of the machines seem to be working, although c0daqawg seems to be having some issues with its startup.cmd code.

After Joe left:

1. Turned on op440m and returned him his keyboard and mouse.
2. Damped MC2.
3. Opened PSL shutter - locked PMC, FSS,
4. Started StripTool displays on op540m.
5. op340m doesn't respond to ping from anyone.
6. started FSS  SLOW and RCPID scripts on op540 - need to kill and restart on op430m.
7. ASS wouldn't come up - it doesn't know who linux1 is.
8. MC autolocker wouldn't run on op540m because of a perl module issue, started it on op440m - it needs to be killed and restarted on op430m.
9. probably mafalda, linux2, and op430m need some attention - they are all in the same rack.

As of 7:18 PM, the MC is locked and the PSL seems normal + all suspensions are damped and the ELOG is back up as well as the SVN.