I'm trying to get some intuition how digital noise due to quantization shows up in iir filters. I decided to do tests in C using Python to calculate psd and visualize. I've implemented Direct Form 1, 2, "Biquad" and "Low Noise" forms of realization of second-order iir filter from Matt's presentation. There is a typo in the "Low Noise Form" scheme - a₁ and a₂ gains should be switched. Other then that schemes correctly implement 2 order iir. 

The input signal to each filter was a sine wave plus white noise with small amplitude x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ),  g << 1, f=1kHz. Sampling frequency was 16384 Hz. All 4 forms implemented 2 order low-pass butterworth filter with cut-off frequency 0.2 Hz

For g=1e-2 all implementations work fine. For g=1e-8 when quantization noise increases, all implementations give a lot of noise at low frequencies. I did not notice any significant difference between any of these implementations. I'll try to do more tests to figure out any difference in noise between the forms.

Quantization noise depends on the architecture of the processor, compiler and what not. But I do not think this can give a huge difference in results. We need to understand carefully digital noise during PSD estimation and all operations done at Matlab or Python.

controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ ls
C1IOO_LKIN_OUT_MTRX.adl   C1IOO_MC_ASS_LOCKIN5.adl     C1IOO_WFS1_I.adl             C1IOO_WFS_LKIN.adl
C1IOO_LOCKMC.adl          C1IOO_MC_ASS_LOCKIN6.adl     C1IOO_WFS1_Q.adl             C1IOO_WFS_MASTER.adl
C1IOO_LOCKMC_BAK.adl      C1IOO_MC_ASS_PIT_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl      C1IOO_WFS_MASTER.adl~
C1IOO_MC_ALIGN.adl        C1IOO_MC_ASS_YAW_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl.old  C1IOO_WFS_MASTER_BAK.adl
C1IOO_MC_ALIGN.adl~       C1IOO_MC_LOCKINS.adl         C1IOO_WFS2_I.adl             C1IOO_WFS_OUTMATRIX.adl
C1IOO_MC_ALIGN_BAK.adl    C1IOO_MC_SERVO.adl           C1IOO_WFS2_Q.adl             C1IOO_WFS_QPD.adl
C1IOO_MC_ASS.adl          C1IOO_MC_TRANS_QPD.adl       C1IOO_WFS2_SETTINGS.adl      C1IOO_WFS_QPD.adl.old
C1IOO_MC_ASS_LOCKIN1.adl  C1IOO_Mech_Shutters.adl      C1IOO_WFS2_SETTINGS.adl.old  fmX
C1IOO_MC_ASS_LOCKIN2.adl  C1IOO_MODECLEANER.adl        C1IOO_WFS_HEADS.adl          junk
C1IOO_MC_ASS_LOCKIN3.adl  C1IOO_QPDS.adl               C1IOO_WFS_HEADS.adl.old      master
C1IOO_MC_ASS_LOCKIN4.adl  C1IOO_QPDS_BAK.adl           C1IOO_WFS_INMATRIX.adl       svn-commit.tmp~
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 0$ helppp
helppp: command not found
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 127$ help me
bash: help: no help topics match `me'.  Try `help help' or `man -k me' or `info me'.

Instrument rack power supplies checked and labeled at present loads.

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

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

All rack power supplies labeled if their load changed.

[Tega, Jamie]

Here is a proposal for what we would like to do in terms of reshuffling a few rack-mounted equipments for the CDS upgrade. 

• Frequency Distribution Amp - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Then disconnect power and signal cables one at a time to enable optimum rerouting for strain relief and declutter.  

• GPS Receiver Tempus LX - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Then disconnect power and signal cables one at a time to enable optimum rerouting for strain relief and declutter.

• PEM & ADC Adapter - Move the unit from 1X7 to 1X6 without disconnecting the attached cables. Disconnect the single signal cable from the rear of the ADC adapter to allow for optimum rerouting for strain relief.

• Martian Network Switch - Make a note of all connections, disconnect them, move the switch to 1X7 and reconnect ethernet cables. 

• MARTIAN NETWORK SWITCH CONNECTIONS
  #	LABEL	#	LABEL
  1	Tempus LX (yellow,unlabeled)	13	FB1
  2	1Y6 HUB	14	FB
  3	C0DCU1	15	NODUS
  4	C1PEM1	16
  5	RFM-BYPASS	17	CHIARA
  6	MEGATRON/PROCYON	18
  7	MEGATRON	19	CISC/C1SOSVME
  8	BR40M	20	C1TESTSTAND [blue/unlabelled]
  9	C1DSCL1EPICS0	21	JetStar [blue/unlabelled]
  10	OP340M	22	C1SUS [purple]
  11	C1DCUEPICS	23	unknown [88/purple/goes to top-back rail]
  12	C1ASS	24	unknown [stonewall/yellow/goes to top-front rail]

   

I believe all of this can be done in one go followed by CDS validation. Please comment so we can improve the plan. Should we move FB1 to 1X7 and remove old FB & JetStor during this work?

Attachment 1: Reshuffling proposal

Attachment 2: Front of 1X7 Rack

Attachment 3: Rear of 1X7 Rack

Attachment 4: Front of 1X6 Rack

Attachment 5: Rear of 1X6 Rack

Attachment 6: Martian switch connections

@tega This looks great, thank you for putting this together.  The rack drawing in particular is great.  Two notes:

1. In "1X6 - proposed" I would move the "PEM AA + ADC Adapter" down lower in the rack, maybe where "Old FB + JetStor" are, after removing those units since they're no longer needed.  That would keep all the timing stuff together at the top without any other random stuff in between them.  If we can't yet remove Old FB and the JetStor then I would move the VME GPS/Timing chassis up a couple units to make room for the PEM module between the VME chassis and FB1.
2. We'll eventually want to move FB1 and Megatron into 1X7, since it seems like there will be room there.  That will put all the computers into one rack, which will be very nice.  FB1 should also be on the KVM switch as well.

I think most of this work can be done with very little downtime.

I took the pictures of all racks of electronics yesterday, and then uploaded these pictures on the wiki.

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

You can see them by clicking "pictures" in the wiki page.

The south arm labels were changed from y to x to reflect reality.

So racks, manual disconnects and breakers now have their actual name. The east arm will be changed over tomorrow.

Please remove incorrect labels if you see any !

I can not find 1X4 breaker so it will be  traced.

The crontab for op340m which runs various IFO maintenance activities has been set to the wrong path for the watchdog rampdown script since the CDS changeover.

This is a dangerous situation. With the watchdog thresholds set as high as 1000, the magnets can be broken if the new CDS has some mental problems. This kind of thing happened before at LHO (which is why Stan invented the watchdogs). Please try to make sure that the watchdog thresholds are not set that way - its our only defense against bad CDS.

I've now corrected the crontab. The watchdog thresholds are being stepped down every 30 minutes as before.

However, out test points are gone again, so who knows how things are behaving.

I found some DQ channels (e.g. SENSOE_UL and etc.) for C1SUS haven't been activated, so I ran activateDQ.py.

Then I restarted daqd on fb as usual. So far the DQ channels look working fine.

Rana, Jan, Jenne

We noticed that the Ranger data was all bogus at low frequencies. So we checked it and found that the proper procedure had not been used when changing it from horizontal to vertical last week. So the huddle test data from the weekend is not valid for the ranger; we will have to repeat it sometime.

So we used the manual, and extended the hanger rod on top of the Ranger to free the mass. It now has good response and coherence with the Guralps down to 0.1 Hz. See attached plot soon.

Last jump at rack Y2.

1. The vertical axis should start from zero. The horizontal axis should be extended so that it includes the waist. See Zach's plot http://nodus.ligo.caltech.edu:8080/40m/2818

2. Even if you are measuring only the linear region, you can guess w0 and z0, in principle. w0 is determined by the divergence angle (pi w0/lambda) and z0 is determined by the linear profile and w0. Indeed your data have some fluctuation from the linear line. That could cause the fitting prescision to be worse.

3. Probably the biggest reason of the bad fitting would be that you are fitting with three parameters (w0, z0, zR) instead of two (w0, z0). Use the relation ship zR= pi w0^2/lambda.

I tried Koji's suggestions for improving the fit to the vertical beam profile; however, I could not improve the uncertainties in the fit parameters.

I started retaking the data today with the same laser settings used last time and noticed that the photodiode was saturating. We were using an ND 4.0 neutral density filter on the photodiode. Koji and I noticed that the coating on the filter was reduced in the center and added an additional ND 0.6 filter to the photodiode. This seemed to fix the photodiode saturation.

I think that the photodiode was also saturating to a lesser extent when I took the last set of data. I will take another vertical beam profile tomorrow.

[Edit by KA: Metallic coating started being evaporated and the ND filters reduced their attenuation. We decided to use absorptive one as the first incident filter, and put a thinner one behind. This looked fine.]

Give me the plot of the fit, otherwise I am not convinced.

I thought that the micrometer I was using to move the razor through the laser beam was metric; however, it is actually english.

After discovering this mistake, I converted my previous measurements to centimeters and fit the data to

w = sqrt(w0^2+lambda^2*(z-z0)^2/(pi*w0)^2) with the following results:

reduced chi squared = 14.94

z0 = (-4.2 ± 1.9) cm

w0 = (0.013 ± 0.001) cm

I used the Mathematica CurveFit package that we use in Ph6/7 to make the fits for the beam profile data. I wrote two functions that use CurveFit shown in the attachment to make the fits to the error function and square root.

I asked CDS mattermost for help. Chris (Wipf) checked it and reported it is working fine as usual (without fixing anything).

I've reverted the copied C1MCS.txt back in the chans dir (/opt/rtcds/caltech/c1/chans). The filter coefficients were loaded from the GDS screen. The filters were properly updated.

Here is the info from Chris:

Some transient NFS problem, maybe?

One possible clue is that the filter file that the FE actually loads is not chans/<model>.txt,
but chans/tmp/<model>.txt. Before loading, the filter file is copied into the tmp directory,
and a diff of the two files is written to chans/tmp/<model>.diff.
This diff file should normally be an empty file, indicating that the two files match.
But it was not empty at first, so there must have been some issue with the previous load.
After I reloaded, the diff then became empty.

I noticed the same issue today with C1RMS.txt, when trying to update the coil actuation gains for SRM. The filter changes were saved to chans/C1RMS.txt, so next I checked chans/tmp/. There is no chans/tmp/C1RMS.txt, or chans/tmp/C1RMS.diff. The updated filters do not load.

Update from Chris:

C1RMS.txt is a remnant from some model that doesn't exist anymore. It can be removed.

I went ahead and deleted chans/C1RMS.txt and chans/tmp/C1RMS.txt.

I have clarified my elog from last night to indicate that the sensing matrix in the "33MHz cancellation" configuration was measured with the PRMI held on REFL55 I&Q.

Also, I just re-read my control room notes from yesterday, and I typed the wrong demod phases into the table last night.  The elog has been edited.  Most significantly, the REFL33 demod phase did not change by 70 degrees.  It did change by 10 degrees, but that is likely from the fact that it was formerly tuned for PRCL in PRFPMI, and last night I tuned it for PRCL in PRMI-only.

The command to get the data from spectrum analyzer right now

From command line, put ./netgpibdata -i 192.168.113.108 -d AG4395A -a 17 -f meas01

(EDIT JCD:  You must first be in the correct folder:  /opt/rtcds/caltech/c1/scripts/general/netgpibdata/)

(EDIT JCD again: "meas01" in the command line instruction will be the name of the filename.  Also, the output file meas01.dat has a comment in the first line that must be deleted before you can plot the data.  This sucks, and we should write a script to strip that line, then make nice plots.)

Please take notice that although IP address of AG4395A is same as written in the help of netgpibdata, the GPIB address is not same. It's 17.

How to use  'scope from control room.

Open the browser. Put the IP adress of 'scope (192.168.113.25) into adrress bar of the browser. If it's on the network, below screen will open.

You can control 'scope, get the data, and so on from control room.

Please take notice that Google Chrome cannot connect the 'scope. So you have to use the Firefox or other browser.

Guralp readout box received +13.7 /0/ -15V instead +15V because of the broken fuse. Power provided by the source is normal.

Edit by Den: I've found a similar fuse on one of the tables and borrowed it. Guralp is not working again.

 I've meant Guralp is NOW working again 

[Valera / Kiwamu]

 We are able to lock each arm smoothly.  It is ready for the Schnupp asymmetry measurement.

( to be done )

 - Manual D-phase adjustment of the AS55 channel.

 - A script to adjust the D-phase.

 - Trigger logic for the boost filters.

 - Modification of some old alignment scripts to adopt them to the new LSC channels

I have slightly shifted the MC beam pointing to relax the PZT1 PITCH. As a result the TRY value went to 0.97 in a first lock trial.

However another issue arose:

   The polarity for controlling the PZT1 PITCH seems to have flipped for some reason.

Since it is still sort of controllable, I am leaving it as it is.

If I remember correctly, sliding the PZT1 pitch value to the positive side brought the beam spot upward in the AS CCD. But now it moves in the opposite way.

Also the ASS feedback looks tending to push the PZT1 pitch to the wrong direction.

I am not 100 % sure if the polarity really flipped, but this is my current conclusion.

(MC pointing)

1. Locked the Y arm and aligned ITMY and ETMY with the ASS servos such that the beam spot on each test mass is well centered on the test mass.
   • With this process the eigen axis of the Y arm cavity is well prepared.
2. Checked the beam positions of the prompt reflection light and cavity leakage field in the AS CCD.
   • It looked the incident beam needed to go upward in the CCD view.
3. Offloaded the MC WFS feedback values to the MC suspension DC biases in a manual way.
4. Disabled the MC WFS servos. The MC transmitted light didn't become worse, which means the suspensions were well aligned to the input beam
5. Changed the DC bias in the MC2 PITCH, to bring the beam spot upward. I changed the DC bias by ~ 0.1 or in the EPICS counts.
6. Aligned the zig-zag steering mirrors on the PSL table to match the incident beam to the new MC eigen beam axis.
   • The transmitted DC light and reflected DC values went back to 27000 counts and 0.58 counts respectively without the WFS servos.
7. Re-engaged the WFS servos.

Since we are going to lock the MC today, I aligned it back to the default place.

I was looking into plotting temperature sensor data trend and why we currently do not have frame data written to file (on /frames) since Friday, and noticed that the FE models were not running. So I spoke to Anchal about it and he mentioned that we are currently unable to ssh into the FE machines, therefore we have been unable to start the models. I recalled the last time we enountered this problem Koji resolved it on Chiara, so I search the elog for Koji's fix and found it here, https://nodus.ligo.caltech.edu:8081/40m/16310. I followed the procedure and restarted c1sus and c1lsc machine and we are now able to ssh into these machines. Also restarted the remaining FE machines and confirm that can ssh into them. Then to start models, I ssh into each FE machine (c1lsc, c1sus, c1ioo, c1iscex, c1iscey, c1sus2) and ran the command

rtcds start --all

to start all models on the FE machine. This procedure worked for all the FE machines but failed for c1lsc. For some reason after starting the first the IOP model - c1x04, c1lsc and c1ass, the ssh connection to the machine drops. When we try to ssh into c1lsc after this event, we get the following error :  "ssh: connect to host c1lsc port 22: No route to host".  I reset the c1lsc machine and deecided to to start the IOP model for now. I'll wait for Anchal or Paco to resolve this issue.

[Anchal, Tega]

I informed Anchal of the problem and ask if he could take a look. It turn out 9 FE models across 3 FE machines (c1lsc, c1sus, c1ioo) have a certain interdependece that requires careful consideration when starting the FE model. In a nutshell, we need to first start the IOP models in all three FE machines before we start the other models in these machines. So we turned off all the models and shutdown the FE machines mainly bcos of a daq issue, since the DC (data concentrator) indicator was not initialised. Anchal looked around in fb1 to figure out why this was happening and eventually discovered that it was the same as the ms_stream issue encountered earlier in fb1 clone (https://nodus.ligo.caltech.edu:8081/40m/16372). So we restarted fb1 to see if things clear up given that chiara dhcp sever is now working fine. Upon restart of fb1, we use the info in a previous elog that shows if the DAQ network is working or not, r.e. we ran the command

 The output shows that MX device was not initialiesd during the reboot as can also be seen below.

NOTE: We commented out the line

Restart=always

in the file "/etc/systemd/system/daqd_dc.service" in order to see the error, BUT MUST UNDO THIS AFTER THE PROBLEM IS FIXED!

Koji and kiwamu

The existing optics on the ETMX/ETMY end table were rearranged in this morning.

The main things we have done are -

1. relocation of the optical levers for ETMs ( as mentioned in koji's entry )

This relocation can make a space so that we can setup the green locking stuffs.

The optical path of the green locking is planed to start from the right top corner on the table, therefore we had to relocate the oplevs toward the center of the table.

2. relocation of the lens just before the tube

Because we are going to shoot the green beam into the arm cavity, we don't want to have any undesired lenses before the cavity.

For this reason we changed the position of the lens, it was standing just in front of the tube, now it's standing on the left side of the big mirror standing center top.

Since we did not find a significant change in its the spot size of the transmitted light, we did not change the position of all the TRANS_MON_PDs and its mirrors. And they are now well aligned.

Attachment1: ETMX end table

Attachment2: ETMY end table

After I did a fine alignment of the X green beam path on the PSL table, the X arm beat-note was also obtained.

Here is a picture of the latest setup. The blue lines represent S-polarizing green beams.

During I was working on the PSL table HEPA was at 80 %, and after the work I brought it to 20 %.

There was an equipment malfunction in one of Pasadena's substation that caused the outage. After about an 8 second delay, back up circuits restored power. This affected about 1/2 of the campus.

Mike 

-----Original Message-----
From: Steve Vass [mailto:steve@ligo.caltech.edu] 
Sent: Tuesday, October 07, 2014 2:18 PM
To: Anchondo, Michael
Subject: 5s

Hi Mike,

Can you tell me about yesterday's power outage?

Thanks, Steve

We're exploring some effects which may give some funny macroscopic detuning and cause a near phase degeneracy in the REFL RF signals (see radar plot from Jenne below).

1) Alignment: we centered the oplevs to reduce fluctuations and then tweaked the BS and PRM alignment to build up the power. No significant change in the RF phases of the DOFs.

2) Measuring RAM: we set the dark offsets (by hand since the Masayuki script doesn't really work well anymore) to with 1 counts. We then locked the MC, misaligned the ITMs, and looked at the REFLOUT16 channels using the following command line:

z avg 12 C1:LSC-REFL11_I_OUT16 C1:LSC-REFL11_Q_OUT16 C1:LSC-REFL33_I_OUT16 C1:LSC-REFL33_Q_OUT16 C1:LSC-REFL55_I_OUT16 C1:LSC-REFL55_Q_OUT16 C1:LSC-REFL165_I_OUT16 C1:LSC-REFL165_Q_OUT16

C1:LSC-REFL11_I_OUT16     -12.04
C1:LSC-REFL11_Q_OUT16     -14.34
C1:LSC-REFL33_I_OUT16       0.43
C1:LSC-REFL33_Q_OUT16      -0.28
C1:LSC-REFL55_I_OUT16       2.84
C1:LSC-REFL55_Q_OUT16       5.64
C1:LSC-REFL165_I_OUT16      4.40
C1:LSC-REFL165_Q_OUT16      0.10

So these offsets are small in counts. In meters this corresponds to....less than 3 pm for any of the I signals.

Refl11I = 2.06e-12 meters

Refl11Q = 2.94e-10 meters

Refl33I = 5.28e-13 meters

Refl33Q = 1.07e-11 meters

Refl55I = 2.71e-12 meters

Refl55Q = 3.55e-11 meters

Refl165I = 3.07e-13 meters

Refl165Q = 8.63e-14 meters

3) Next we want to put large offsets into the error points of the loops

4) Change modulation depth

5) Check IMC length (todo for Q/Manasa for Tuesday - Wednesday)

I found that all the front end machine showed the red light indicators of DAQ on the XXX_GDS_TP.adl screens.

Also I could not get any data from both test points and DAQ channels.

First I tried fixing by telneting and rebooting fb, but it didn't help.

So I rebooted all the front end machines, and then everything became fine.

For some reason the c1ioo machine suddenly died just 30 miteus before.

It died after we added a DAQ channel for c1gcv and rebooted the frame builder.

It didn't respond to a ping command. Therefore I rebooted the machine by clicking the physical reset button.

Now it seems fine.

Baja 4.9 m earth quake tripped suspentions, except ETMX Sus damping recovered. MC is locking.
 

All suspensions were tripped. Damping were restored. No obvious sign of damage. BS OSEM-UR may be sticking ?

1. Control room is at +66 F. Brrrr.
2. Alignment of input beam into the IMC was wacky; locked on HOM.
3. Re-aligned beam into the PMC first.
4. Restarted mxstream for c1sus.
5. Power cycled Martian router; all laptops were lost. Now better.
6. Aligned launch beam from PSL to get onto the MCWFS better, MC is locking OK now. Moved MC SUS a little to get back to OSEM values from 6 days ago.
7. Fixed LOCK_MC screen quad displays to be cooler.
8. changed many of the ezcawrite calls in the mcup / mcdown to be 'caput -l' for more robustness. Still need ezcawrite for the binbary calls.
9.  I didn't touch the mirrors on the MC REFL path, so we can still use that as a reference once the temperature returns to normal; the PSL room temp is down to 20C from 22 C a couple days ago.
10. TRX values coming in to the LSC were frozen and the TRY_OUT16 was going to huge values even though camera flashes were reasonable. Tried restarting c1lsc model. No luck.
11. Also tried shutdown -r now on c1lsc. No luck. Probably needs a RFM boot.
12. Increased the FSS SLOW servo threshold to 9999 counts to avoid it running on some misaligned TEM01 mode locks. Increased the PID's I gain from 0.05 to 0.356 by tuning on some step responses as usual.
13. By midnight the control room temperature is back around 71 F.

* EQ Southeast of LA around 45 minutes ago. Callum and I felt it.

* Koji and I came in to recover. MC suspensions had been mis-aligned. ETMs both tripped their watchdogs.

* As before, the ETMX was stuck in its cage and the UR & LR OSEMs were reading zero V.

* We moved the MC sus back to their OSEM values from 2 hours ago. Koji aligned everything else by just using his chee.

* To shake the ETMX loose, I tried a different tactic than the "Great Balls of Fire". I started giving it 20k steps through the ASCYAW filterbank (with ramping OFF). I used the green light in the X arm video to look at the swinging. Using this as a readback I pumped the OFFSET button on ASCYAW to resonantly swing up the yaw motion. I had to turn the watchdog thresh up to 2000 temporarily. After a couple minutes the ETMX was free.

* We then used the bias sliders to steer it back onto the OL center (which Q nicely lined up for us recently) and then X arm locked in green right away.

Fri Mar 28 22:38:04 2014:  We've just ridden through the 5th aftershock. None of the aftershocks have tripped the watchdogs  but they break the IMC lock.

Local earthquake activity is up. Our suspensions are holding well.    ETMX and ETMY sus damping restored.

Recovery from the power shutdown

 - Turned on the raid disk of linux1.

 - Woke linux1 up. No fsck this time.

 - Woke up all the lab machines.

 - Turned on all the electronics racks' AC powers

 - Woke up fb and then front end machine (the raid for fb had been already up as I turned on the AC powers)

 - Turned on all the electronics racks' DC powers (Sorensens, Kepcos, and etc.)

 - Turned on the Marcnois which is driving the RF generation box.

 - Woke up all the lasers (PSL and End lasers)

 - Some burtrestoring (c1ioo, c1sus, c1susaux, c1msc, c1psl, c1iool0, c1auxey, c1auxex, c1oaf, c1pem)

 - Ran autolockMC scripts on op340m => After relocking of PMC a lock of MC was acquired immediately.

 - Turned on the PZT HV drivers.

Some issues

 - One of the Sorensens in 1X8 rack is showing the current limit sign. This is exactly the same situation as we saw before (#5592).

       Currently it's off. It needs an investigation to find who is drawing such a large amount of current.

 - C1SCX is not properly running. Rebooting the machine didn't help. This needs to be fixed.

       The symptom is : (1) all the values are frozen in the screens. (2) the c1scx status screens shows NO SYNC sign. (3) however the timing board looks blinking happily.

 - One of the VME rack on 1X3 is not showing the +/-15V green LED lights.

   This is the one on very upper side of the rack, which contains the old c1lsc machine and c1iscaux2. If we are still using c1iscaux2, it needs to be fixed.

 restarted Apache on Nodus for the SVN as per wiki instructions

 __Epics_Channel_Name______   __OLD_____    ___New___
 C1:SUS-MC1_PIT_COMM          4.490900        3.246900 
 C1:SUS-MC1_YAW_COMM          0.105500	      -0.912500
 C1:SUS-MC2_PIT_COMM          3.809700	      3.658600 
 C1:SUS-MC2_YAW_COMM          -1.837100	      -1.217100
 C1:SUS-MC3_PIT_COMM          -0.614200	      -0.812200
 C1:SUS-MC3_YAW_COMM          -3.696800	      -3.303800

We aligned accurately 00 green in yarm, changed voltage on PZT2 to see red flashing at TRY at the normalized level 0.2-0.3. The plan was to lock yarm using POY11 and green from other side, maximize red TRY by adjusting PZT2. But POY11 does not go out of the vacuum, so we adjusted TRY by flashing. 2 DOFs of PZT2 is not enough to match 4 DOFs of red beam so we adjusted both PZT2 and cavity mirrors. TRY flashing is 0.5-0.6 and green is still locking to 00 though its transmission is not maximized. We'll fix it later by adjusting input green beam.

Next we wanted to get red beam on TRX PD. Beam steering was done by BS only. We misaligned BS in pitch and excited BS angle motion by 1000 counts. We could see red beam moving on the wall of ETMX chamber. We moved it to ETMX mirror frame, estimated position of the mirror center and moved BS to this position. The beam should be approximately in the middle. For now we can not see red beam on the camera at ETMX table, more work is needed.

 It does but slighty low and does not get on mirrors. We need to change optic mounts to adjust the height. Red is flashing in yarm at 00 and 10 modes. TRY is ~0.4-0.5.

I've adjusted BS angle, camera and TRX PD at ETMX table so I can see red flashing at 03 mode while green is locked to 00 and its transmission is maximized. I thought that by adjusting BS angle, I will be able to align red to 00 not disturbing green, but this was not the case. Maximum TRX I could get was 0.1. I've adjusted POX to get into PD and I can see PDH signal though I can't lock as cavity is still misaligned for red.

You have constraints for the IR beams (i.e. one PZT and one BS for 8 dofs), so now you need to align the arms for the input IR beams.
The PZT and BS should be aligned so that you have the beam spots as center as possible with the above restrictions.

Then realign end greens for the given arm alignment. You can replace the mounts if necessary to align the end green.
Even if you lose the coarse alignment of the green, realignment is not difficult as you know now

We aligned and locked x and y arms.

MCL loop makes arms lock unstable, adds a lot of noise at frequencies 60-100 Hz. We'll fix it.

At some point we were not able to lock because of ADC overflows of PO signals. They happened if whitening filters were enabled. So we reduced the gain of POX whitening filters down to 36 dB and POY - to 39 dB. Now cavities can be locked with whitening filters.

Also we changed the pedestal of the lens in the beam path to the POX because the beam was too high.

Also ordered 1 ea.

Blue 20mW

Green 10mW

IR 780nm 3mW

HeNe 1103P 2mW Recertified

(Koji, Suresh, Yuta)

Summary:
  We need MC to be locked and aligned well to align other in-vac optics.
  By using a new python script A2L.py(see elog #3863), we are measuring A2L coupling and centering the beam.
  Tonight's goal was to reduce common mode displacement of the beam through MC1 to MC3, and we succeeded.

Strategy of beam centering:
  We first ignore the beam position at MC2 and focus on MC1,MC3. If MC1,MC3 alignments are given, MC2 alignment is determined.

  For MC1 and MC3, we first reduce the common mode displacement using the last steering mirror at PSL table.
  The last steering mirror makes translation of the incident beam because it is far (~m) from the MC.
  So,
    1. Rotate the steering mirror nob a little
    2. Lock MC so that MC beam axis will be the same as the incident beam axis
    3. A2L measurement
    4. To 1-3 over until the beam crosses MC1 center to MC3 center axis
        The amount of vertical/horizontal displacements of the beam spot at MC1 and MC3 should be the same.
        From our convention, for vertical, MC1 and MC3 should have opposite sign. For horizontal, same sign. (see picture below)

Result:

 
  From the A2L measurement, now the beam spot is lower right at MC1 and upper right at MC3.
 

  The directions of the beam spot motion agree with the steering mirror tilts.
  Also, the amount of the motion seems reasonable.
    1 tooth rotation of the steering mirror nob makes ~1e-3 inch push which equals to ~0.5mrad rotation.
    The steering mirror to MC is like ~2m and 0.5mrad mirror tilt makes ~2mm displacement at the MC optics.
    2mm displacement is ~15% at the mirror (see Koji's elog #2863;note that coil-coil distance is 1/sqrt(2) of the mirror diameter).
    The measured vertical spot motion is ~15%/1tooth. Horizontal is sqrt(2) times bigger because of the angle of the MC1, MC3 and they are about that much, too.

Plan:
 - Use IM1 to make beam tilt and finally center the beam
 - Improve the script so that it features weighting in fitting
 - Write a script that balances actuation efficiency of the 4 coils.
     We are currently assuming that 4 coils are well balanced.
     In order to do the balancing, we need to balance OSEMs too.

The last entry I found relating to ref cavity was 2011 Aug 19