40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 333 of 339 Not logged in
ID Date Author Type Category Subject
14254   Mon Oct 15 10:32:13 2018 yukiUpdateComputer Scripts / Programsloss measurements

I used these values for measuring armloss:

• Transmissivitity of ITM = 1.384e-2 * (1 +/- 1e-2)
• Transmissivitity of ETM = 13.7e-6 * (1 +/- 5e-2)
• Mode-Matching efficiency of XARM = 0.912 * (1 +/- 2e-2)
• Mode-Matching efficiency of YARM = 0.867 * (1 +/- 2e-2)
• modulation depth m1 (11MHz) = 0.179 * (1 +/- 2e-2)
• modulation depth m2 = 0.226 * (1 +/- 2e-2),

then the uncertainties reported by the individual measurements are on the order of 6 ppm (~6.2 for the XARM, ~6.3 for the YARM). This accounts for fluctuations of the data read from the scope and uncertainties in mode-matching and modulation depths in the EOM. I made histograms for the 20 datapoints taken for each arm: the standard deviation of the spread is over 6ppm. We end up with something like:

XARM: 123 +/- 50 ppm
YARM: 152+/- 50 ppm

This result has about 40% of uncertaintities in XARM and 33% in YARM (so big... ).

In the previous measurement, the fluctuation of each power was 0.1% and the fluctuation of P(Locked)/P(misaligned) was also 0.1%. Then the uncertainty was small. On the other hand in my measurement, the fluctuation of power is about 2% and the fluctuation of P(Locked)/P(misaligned) is 2%. That's why the uncertainty became big.

We want to measure tiny value of loss (~100ppm). So the fluctuation of P(Locked)/P(misaligned) must be smaller than 1.6%.

(Edit on 10/23)
I think the error is dominated by systematic error in scope. The data of beam power had only 3 degits. If P(Locked) and P(misaligned) have 2% error, then
$\frac{P_L}{P_M}\frac{1}{1+T_{\mathrm{ITM}}} = 0.99(3)$.
You have to check the configuration of scope.

Attachment 1: XARM_20181015_1500.pdf
Attachment 2: YARM_20181015_1500.pdf
14255   Mon Oct 15 12:52:54 2018 yukiUpdateComputer Scripts / Programsadditional comments
 Quote: but there's one weirdness: It get's the channel offset wrong. However this doesn't matter in our measurement because we're subtracting the dark level, which sees the same (wrong) offset.

When you do this measurement with oscilloscope, take care two things:

1. set y-range of scope as to every signal fits in display: otherwise the data sent from scope would be saturated.
2. set y-position of scope to the center and don't change it; otherwise some offset would be on the data.
14257   Mon Oct 15 20:11:56 2018 yukiConfigurationASCY end table upgrade plan

Final Procedure Report for Green Locking in YARM:

Purpose

The current setup of AUX Y-arm Green locking has to be improved because:

• current efficiency of mode matching is about 50%
• current setup doesn't separate the degrees of freedom of TEM01 with PZT mirrors (the difference of gouy phase between PZT mirrors should be around 90 deg)
• we want to remotely control PZT mirrors for alignment

What to do

• Design the new setup and order optices needed (finished!)
- As the new setup I designed, adding a new lens and slightly changing the position of optics are only needed. The new lens was arrived here.
• Check electronics (PZT, PZT driver, high voltage, cable, anti-imaging board) (finished!)

- All electronics were made sure performing well.
- The left thing to do is making a cable. (Today's tasks)
• Calibrate PZT mirror [mrad/V] (finished!)

- The result was posted here --> elog:40m/14224.
• Measure the status value of the current setup (power of transmitted light ...etc) (finished!)
• Install them in the Y-end table and align the beam (Almost finished!) (GTRY signal is 0.3 which means Mode-Matching efficiency is about 30%. It should be improved.)
• Measure the status value of the new setup (finished!)
• Prepare the code of making alignment automaticaly
• see sitemap.adl>ASC>c1asy. I prepared medm. If you move PZT SLIDERS then you can see the green beam also moves.
• Preparing filters is needed. You can copy them from C1ASX.
• Note that now you cannot use C1ASX servo because filters are not applied.
14258   Tue Oct 16 00:44:29 2018 yukiUpdateComputer Scripts / Programsloss measurements

The scripts for measuring armloss are in the directory "/opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_scope".

• armloss_derefl_asdcpd_scope.py: gets data and makes ascii file.
• armloss_AS_calc.py: calculates armloss from selected a set of files.
• armloss_calc_histogram.py: calculates armloss from selected files and makes histogram.
14260   Wed Oct 17 20:46:24 2018 yukiConfigurationASCY end table upgrade plan

To do for Green Locking in YARM:

The auto-alignment servo should be completed. This servo requires many parameters to be optimized: demodulation frequency, demodulation phase, servo gain (for each M1/2 PIT/YAW), and matrix elements which can remove PIT-YAW coupling.

14280   Wed Nov 7 05:16:16 2018 yukiUpdateComputer Scripts / Programsarm loss measuremenents

Please check your data file and compare with those Johannes made last year. I think the power in your data file may have only three-disits and flactuate about 2%, which brings huge error. (see elog: 40m/14254)

 Quote: On running the script again, I'm getting negative values for the loss.
3622   Wed Sep 29 16:56:36 2010 yutaUpdateVAC2 doors opened

(Steve, Koji, Joe, Kiwamu, Yuta)

Background:
The vent was started on Monday, and finished on Tuesday.
We were to open the doors on Tuesday, but we couldn't because the vertex crane got out of order.
Now the crane was fixed, and so we opened the doors today.

What we did:

We opened the north side of the BS chamber and the west side of the ITMX chamber.
Now, the light doors are put instead.

3623   Wed Sep 29 18:28:32 2010 yutaUpdateComputersaldabella connects to the wireless network

Background:
We need laptops that connect to the wireless network to use them in the lab.

aldabella:
Dell Inspiron E1505 laptop
Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01) (PCIID: 14e4:4311 (rev 01))

What I did:
1. I followed this method(Japanese!): http://www.linuxmania.jp/wireless_lan.html
Except I installed ndiswrapper-1.56 and cabextracted sp32156.exe.
Also, I didn't run
# ndiswrapper -m

2. Then I did step #6 in here: http://nodus.ligo.caltech.edu:8080/40m/1275
Note that the hardware is eth1 instead of wlan0.

3. Added the following line to /etc/rc.d/rc.local to make ndiswrapper load on every boot:
 /sbin/modprobe ndiswrapper

Result:
aldabella now connects to the wireless martian network on every boot!!

Note:
Somehow, the method that uses Broadcom official driver doesn't work.
It returns the following error when activating eth1:   Error for wireless request "Set Encode" (8B2A) :     SET failed on device eth1 ; Invalid argument.   Error for wireless request "Set Encode" (8B2A) :     SET failed on device eth1; Invalid argument.

3627   Thu Sep 30 14:09:33 2010 yutaUpdateComputersmariabella connects to the wireless network

Background:
We need laptops that connect to the wireless network to use them in the lab.

mariabella:
Dell Inspiron 1210 laptop
Broadcom Corporation BCM4312 802.11b/g (rev 01) (PCIID: 14e4:4315 (rev 01))

What I did:
1. I followed the same steps I did for aldabella: http://nodus.ligo.caltech.edu:8080/40m/3623
Except I unzipped R151517-pruned.zip.

2. Note that the PCIID is important for driver selection. Not the model No.
To check whether your driver selection is correct, run:
# ndiswrapper -l
after installing the driver.
If the driver selection is wrong, it will return only:
bcmwl5 : driver installed
If correct, it will return:
bcmwl5 : driver installed          device (14E4:4315) present (alternate driver: hoge)
This page has some information for the driver selection:

Result:
aldabella now connects to the wireless martian network.

Note:

Broadcom official driver didn't work for mariabella, too.

3630   Thu Sep 30 18:51:50 2010 yutaUpdateComputerssetting up aldabella and mariabella

(Kiwamu, Yuta)

Background:
We wanted to make aldabella and mariabella know how to work.

What we did:

1. Added 2 lines to /etc/rc.local
 /sbin/modprobe ndiswrapper  sleep 10  mount linux1:/home/cds/ /cvs/cds

2. Edited ~/.cshrc
 source /cvs/cds/caltech/cshrc.40m

Result:
Working environment is set to aldabella and mariabella. They have their access to the main system, linux1, now.

Note:
fstab doesn't work for aldabella and mariabella because the mount should be done after ndiswrapper loads.

3645   Mon Oct 4 19:48:00 2010 yutaUpdateVACseveral mirrors installed to ITMX/BS chamber

(Koji, Kiwamu, Yuta)

Lots of progress for the optics placement in the vacuum chamber.
We are ready to go to the next step: open the access connector between IMC and OMC.

### Background:

The actual work in the vacuum chamber started.
The first goal of the vent is to get the green beam coming out from the chambers to the PSL table.

### What we did:

1. Inspection of the tip-tilt suspension

The alignments of the TTs were inspected. We had five TTs having been sitting on the table in Bob's clean room.
Prior to their installation we checked the alignments of those because they sometimes showed large hysteresis mainly in the pitch directions.

If a TT has the hysteresis, the pitch position doesn't come back to the previous position. This may cause an issue of the interferometer operation.

- SN001, SN003, SN005 looked well aligned and show no hysteresis.

- The alignment of SN002 was not so good (theta ~ 0.004 rad ) compared to those three, but no hysteresis, we think this guy is still acceptable for the installation.

- SN004 had an apparent hysteresis. This guy doesn't come back to the previous place, being applied a touch. We have to fix this at some point.

2. Work in the ITMX chamber

Now all of the optic in this chamber was installed in the approximate place.

- Installed POX/POP steering mirrors.

- TT(SN003) was placed.

- The two steering optics for ITMX OPLEV were placed at the designed positions.

3. Work in the BS chamber

Installed 2 TTs to the BS chamber.
- SR3: TT(SN001)
- PR3: TT(SN005)

After the alignment of the green steering mirrors, we confirmed
the green beam is successfully hitting the west wall of the OMC chamber.

Those TTs are approximately aligned using the weakly reflected green beams.

### Next work:

- Open the access connector

- Place another periscope and two steering mirrors for green

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

Attachment 1: P1060901.JPG
Attachment 2: P1060904.JPG
3656   Tue Oct 5 21:22:46 2010 yutaUpdateVACgreen beam reached PSL table

YES ! We got the green light coming out from the OMC chamber to the PSL table !

(Koji, Kiwamu, Yuta)

Background

As a result of the work in the chambers, the green beam reached the OMC chamber yesterday.
Today's mission was to let the green beam coming out from the chambers to the PSL table.

What we did:
1. Installed the last three steering mirrors.
The mirrors were 532 HR mirror with AR and 1deg wedge (CVI Y2-LW-1-2050-UV-45-P/AR).
Two of them are placed to the MC chamber. Another one was to the OMC chamber

During putting the mirrors to the MC chamber, we found that a cable tower was sitting on a position exactly where we wanted to put one of the mirrors.

So we moved the tower to the very south west corner.

2. Installed a periscope to the MC chamber

The function of this periscope is to lower the beam height of the green light which is risen up by another periscope in the BS chamber.

We aligned it to the green beam, so that the beam hits the center of the mirrors on the periscope.

3. Aligned the optics

We aligned the green mirrors so that we can let the green beam go out from the chamber.

Actually the inside of the OMC chamber didn't look like the same as that of our optical layout.

For example there is unknown base plate, which apparently disturbs the location of our last steering mirror.

Therefore we had to change the designed position of the steering mirror.

Now the mirror is sitting near the designed position (~ 1/2 inch off), but it's fine because it doesn't clip any 1064 beam.

Result:

The green beam is now hitting the north wall of the PSL table.

Notes:

The green beam looks having some fringes, it may be caused by a multiple reflection from a TT when the green beam goes through it. We are going to check it.

Next work:

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

3667   Thu Oct 7 14:39:50 2010 yutaUpdatePSLmeasured PMC's laser power-output relation

(Rana, Yuta)

Motivation:

We wanted to see thermal effects on the PMC.

What I did yesterday:
Changed the current of the NPRO from 2A to 0.8A and measured the power of the reflected/transmitted light from the PMC when locked.
I also measured the power of the reflected light when PMC is not locked (It supposed to be proportional to the output power of the laser).

Result:
Attached. Hmmmm......
At several points of the laser current, I could'nt lock the PMC very well. The power of the reflected/transmitted light depend on the offset voltage of the PZT.
When the laser power was weak(~<0.9A), the power of reflected/transmitted light changed periodically(~ several minutes).

Attachment 1: PMCreflect.png
3672   Thu Oct 7 16:34:06 2010 yutaUpdatePSLmeasured PMC's laser power-output relation

Result2:
Attached is the visibility vs incident power(assuming output of the PD is proportional to the input laser power).
Ideally, the graph should be flat. (In another words, attached graph in the elog #3667 shoud be linear.)
But the visibility reduces with higher laser power in this graph. This is maybe because of the thermal effect. I'm thinking about how to confirm this.

Quote:

It was a bit difficult to comprehend the result.
Is it good? or bad? Have you seen the thermal effect? or not?

- Put linear lines to show the visibility of the cavity.

- Calibrate the incident power and make another plot to show the visibility (%) vs the incident power (W).

 Quote: (Rana, Yuta) Motivation:  We wanted to see thermal effects on the PMC. What I did yesterday:  Changed the current of the NPRO from 2A to 0.8A and measured the power of the reflected/transmitted light from the PMC when locked.  I also measured the power of the reflected light when PMC is not locked (It supposed to be proportional to the output power of the laser). Result:  Attached. Hmmmm......  At several points of the laser current, I could'nt lock the PMC very well. The power of the reflected/transmitted light depend on the offset voltage of the PZT.  When the laser power was weak(~<0.9A), the power of reflected/transmitted light changed periodically(~ several minutes).

Attachment 1: PMCvis.png
3674   Thu Oct 7 17:53:07 2010 yutaUpdateComputersFarfalla with Firefox, fixed

(Kiwamu, Yuta)

Symptom:
Farfalla(Acer Aspire one KAV60 netbook) couldn't run Firefox and returned the following error:
Error: platform version '1.9.2.8' is not compatible with
minVersion >= 1.9.2.9
maxVersion <= 1.9.2.9

What we did:
1. Added the following line to ~/.cshrc.
alias firefox "/usr/lib/firefox-3.6/firefox"
2. Made a cool launcher for firefox.

Result:
Farfalla can fly into the web with Firefox now.

Notes:

Even if it was then before, bash could run firefox. tsch couldn't.
The command firefox was /cvs/cds/caltech/apps/linux/bin/firefox for tsch, because of the source /cvs/cds/caltech/cshrc.40m.
I did this to zita which had the same symptom, too.

Next work:

Farfalla wakes up on the wrong side of the bed. This has to be fixed.

3675   Thu Oct 7 23:24:44 2010 yutaUpdateCDSchecking MC1 suspension damping

Background:
The new CDS is currently being set up.
We want to see if the damping servo of the suspensions are working correctly.
But before that, we have to see if the sensors and the coils are working correctly.
Among the 8 optics, MCs take top priority because of the green beam. for the alignment of the in-vac optics.

What I did:
By seeing the 5 sensor outputs (C1:SUS-MC1_XXSEN_IN1, XX=UL,UR,LR,LL,SD) with the Data Viewer, I checked if all the coils are kicking in the supposed direction and all the sensors are sensing that kick correctly.

All the matrices elements were set to the ideal values(-1 or 0 or 1) this time.

Result:
They were perfect.
1. POSITION seemed to be POSITION
When the offset(C1:SUS-MC1_SUSPOS_OFFSET) was added, all the sensor output moved to the same direction.
2. PITCH seemed to be PITCH
When the offset(C1:SUS-MC1_PIT_COMM) was changed, UL&UR and LL&LR went to the different direction.
3. YAW seemed to be YAW
When the offset(C1:SUS-MC1_YAW_COMM) was changed, UL&LL and UR&LR went to the different direction.
4. SIDE seemed to be SIDE
When the offset(C1:SUS-MC1_SDSEN_OFFSET) was added, DC level of the SD sensor output changed.

Notes:

c1mcs crashed many times during the investigation, and I had to kill and restart it again and again.
It seemed to be easily crashed when filters are on, and so I couldn't check whether the damping servo is working correctly or not today.

Next work:

- fix c1mcs (and maybe others)
- check the damping servo by comparing the displacements of each 4 degrees of freedom when servo in off and on.

3689   Mon Oct 11 16:09:10 2010 yutaSummarySUScurrent OSEM outputs

Background:
The output range of the OSEM is 0-2V.
So, the OSEM output should fluctuate around 1V.
If not, we have to modify the position of it.

What I did:
Measured current outputs of the 5 OSEMs for each 8 suspensions by reading sensor outputs(C1:SUS-XXX_YYPDMON) on medm screens.

Result:

 BS ITMX ITMY PRM SRM MC1 MC2 MC3 UL 1.20 0.62 1.69 1.18 1.74 1.25 0.88 1.07 UR 1.21 0.54 1.50 0.99 1.77 1.64 1.46 0.31 LR 1.39 0.62 0.05 0.64 2.06 1.40 0.31 0.19 LL 1.19 0.88 0.01 0.64 1.64 1.00 0.05 1.03 SD 1.19 0.99 0.97 0.79 1.75 0.71 0.77 0.93

White: OK (0.8~1.2)
Yellow: needs to be fixed
Red: BAD. definitely need fix

3690   Mon Oct 11 17:31:44 2010 yutaUpdateCDSActivation of DAQ channels for 8 optics

(Joe, Yuta)

Background:
We need DAQ channels activated to measure Q-values of the ringdowns for each DOF, each optics with the Dataviewer.

What we did:
1. Activated the following DAQ using daqconfig (in /cvs/cds/rtcds/caltech/c1/scripts).
C1:SUS-XX_AASEN_IN1
C1:SUS-XX_SUSBBB_IN1
C1:RMS-YYY_AASEN_IN1
C1:RMS-YYY_SUSBBB_IN1
C1:MCS-ZZZ_AASEN_IN1
C1:MCS-ZZZ_SUSBBB_IN1
(XX=BS,ITMX,ITMY  YYY=PRM,SRM  ZZZ=MC1,MC2,MC3  AA=UL,UR,LR,LL,SD  BBB=POS,PIT,YAW)

2. Set datarate to 2048 for each DAQ.

3. Restarted fb(frame builder).

Result:
We succeeded in making DAQ channels appear in the Dataviewer signal list, but we can't start the measurement because c1mcs is still flaky.

Note:
We found that c1mcs crashes everytime when turning off all the damping servo (using "Damp" buttons on the medm screen).
It doesn't crash when all the filters are off.

3692   Mon Oct 11 22:04:28 2010 yutaUpdateCDSdamping for MCs are basically working

Background:
Even if we can't use the Dataviewer to get the time series of each 4 DOF displacements, we can still use StripTool to monitor the ringdowns and see if the damping servo is working.

What I did:
1. Excited vibration by kicking the mirror randomly (by putting some offsets randomly and turing the filters on and off randomly).

2. Turned all the servo off by clicking "ShutDown" button.

3. Turned all the servo on by clicking "Normal" button.

3. Monitored each 4 DOF displacements with StripTool and see if there are any considerably low-Q ringdown after turning on the servo.
The values I monitored are as follows;
C1:SUS_MCX_SUSPOS_INMON
C1:SUS_MCX_SUSPIT_INMON
C1:SUS_MCX_SUSYAW_INMON
C1:SUS_MCX_SDSEN_INMON  (X=1,2,3)

All the settings I used for this observation are automatically saved here;
/cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/11/21:07/c1mcs.epics

Result:
Attached is the screenshots of StripTool Graph window for each 3 MCs.
As you can see, the dampings for each DOF, each MCs are basically working.

Note:
Do NOT turn off all the damping servo by clicking "Damp" buttons or setting the SUSXXX_GAIN to 0. It crashes c1mcs.

Next work:
- check and relate the signal sign with the actual moving direction of the optics
- fix data aquisition system
- measure Q-values when the servo is on and off using DAQ and Dataviewer

Attachment 1: SUS-MC1.png
Attachment 2: SUS-MC2.png
Attachment 3: SUS-MC3.png
3697   Tue Oct 12 15:51:18 2010 yutaBureaucracySAFETYthe 40m squad received safety training from Peter

Yuta, Joonho, and Suresh received the Basic Laser Safety Training from Peter King today.

Now, we got homework.

3699   Tue Oct 12 17:42:57 2010 yutaUpdateSUSvery first measurement of Q-values for MC1

Background:
Data aquisition system is fixed, and now we can use the Dataviewer to measure Q-values of the ringdowns for each DOF, each optics.
First of all, I measured MC1 suspention damping servo for a test.

What I did:
1. Used DAQ channels activated in this entry(#3690) to see and compare the ringdowns when the damping servo is on and off with the Dataviewer.

2. Plotted the data and fitted the ringdown using this formula;
p[0]*exp(-p[1]*t)*sin(p[2]*t+p[3])+p[4]
I used python's scipy.optimize.leastsq for the fitting.

3. Calculated the resonant frequency f0 and Q-value using following formulas;
f0=2*pi*sqrt(p[1]**2+p[2]**2)
Q=f0/(2*pi)/(2*p[1])

4. For plotting, I subtracted the offset(=p[4]).

All parameters I used for this measurement are automatically saved here;
/cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/12/13:07/c1mcs.epics
(-1,0,1 for all matrix elements, GAIN=3,3,3,150 for POS,PIT,YAW,SIDE)

Result:
Attached is the plot of each 4 DOF ringdown when servo is off and on.
"servo off" means off for that DOF. Servo for the other 3 DOFs are on.

As you can see clearly, the damping servo is working.

The resonant frequencies and Q-values calculated from the fitting are as follows;

 servo off servo on f0 (Hz) Q f0 (Hz) Q POS 0.97 large 0.97 16 PIT 0.71 96 0.73 6.9 YAW 0.80 100 0.82 8.9 SIDE 0.99 large 0.99 27

Resonant frequencies and Q-values have about 1% and 10% error respectively.
I estimated it from my 2-time measurement of the POS ringdown.

Next work:
- Find and modify some scripts to optimize the matrix elements
- Calibrate the displacement
- Do the same thing for other optics

Attachment 1: MC1ringdown.png
3700   Tue Oct 12 22:06:08 2010 yutaUpdateComputerscelan-installed CentOS 5.5 on mafalda

I clean-installed CentOS 5.5(32bit) on mafalda.
No firewalls, no SELinix.

3705   Wed Oct 13 11:09:28 2010 yutaUpdateComputersclean-installed CentOS 5.5 on mafalda

Dear mafalda,

Sorry for leaving you alone.
We put ethernet cable in you. You can talk to everyone now!
We created a user "controls" correctly. (UID: 1001)
We mounted linux1:/home/cds/ to your directory /cvs/cds.

Truly yours,
Joseph Betzwieser
Yuta Michimura

Quote:

 Quote: I clean-installed CentOS 5.5(32bit) on mafalda. No firewalls, no SELinix.

Yuta has removed my ethernet connection. Help me!!!

rossa:mDV>ping mafalda
PING mafalda.martian (192.168.113.23) 56(84) bytes of data.
From rossa.martian (192.168.113.215) icmp_seq=2 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=3 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=4 Destination Host Unreachable

--- mafalda.martian ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3999ms
, pipe 3

3708   Wed Oct 13 18:01:43 2010 yutaHowToCDSeditting all the similar medm screens

(Joe, Yuta)

Say, you want to edit all the similar medm screens named C1SUS_NAME_XXX.adl.

1. Go to /opt/rtcds/caltech/c1/medm/master and edit C1SUS_DEFAULTNAME_XXX.adl as you like.

2. Run generate_master_screens.py.

That's it!!

3710   Thu Oct 14 00:04:46 2010 yutaUpdateSUSQ-value adjustment for MC dampings

Background:
We need MC to be locked soon, so MC suspensions should be damped well(Q~5).

What I did:
1. Set the correct filters and turn all the damping servo on.

2. Kick the optics by adding some offset into the control loop.

3. Measure the Q-value of the ringdown with my eye.

4. If Q-value seems to be around 5, go to step #5. If not, change the filter gain and go to step #2.

5. Done! Do step #1-4 for all MCs.

All parameters I used for the servo are automatically saved here;
/cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/13/20:07/c1mcs.epics

Result:
Q-values of the damping servo for all MCs are set to around 5.
Attached is the ringdown of MC2 for example.
As you can see, my eye was very rough......

Next work:
- Make a script that does steps #2-5 automatically.
I need pyNDS module installed to get data using Python.
I already wrote the rest of the script.
We'll have Leo help us install pyNDS tomorrow.

Attachment 1: MC2ringdown.png
3713   Thu Oct 14 01:09:17 2010 yutaUpdateIOOtried to lock MC but failed

(Rana, Koji, Kiwamu, Suresh, Yuta)

We attempted to lock the MC and finally got flashes of the MC, but no luck.

Tomorrow we are going to check every components one by one to make sure if everything is okay or not.

Background:
MC suspensions are well damped now.
We need MC locked for the alignment of the in-vac optics.

Issues:

These are the issues which we are going to fix.
1. DC alignment of the MC2 suspension doesn't seem to be working correctly. (see here)

We should check the satellite box and the cable connection.

The coils look like woking fine because we can kick MC2 by using each of the coils.

2. Incomplete modematching.

The spot size of the reflected light from MC1 looked like bigger.

3. beam axis of the injection light to MC1

3717   Thu Oct 14 12:53:29 2010 yutaUpdatePSLmesured PMC's visibility vs power relation

Background:
I measured the PMC's visibility vs incident power relation last week to see the thermal effect, but I didn't calibrated the laser power(see elog #3672).
So, I calibrated it on Oct 12.

Setup:

Attachment #1
The laser grade window PW-1025-UV-1064-45P had power reflectivity of about 0.5% in this setup.

What I did:
1. Calibrated the laser power(Attachment #2).
To measure the laser power, I put the Ophir power meter at just in front of "PMC REFL PD".

2. For the calculation of the visibility K, I used the following formula;
K= [1-(R1-R0)/(R2-R0)]*100
where R0, R1 and R2 are the PD outputs in voltage when laser is off, PMC locked and not locked respectively.

3. Plotted the visibility vs the incident power(Attachment #3).

Result:
Attachment #2
From the linear fit by least squares, the calibration turned out to be 1.12±0.07 mV/uW. The error of this value is calculated from assuming PD output error~1mV and laser power error~3uW for all measured value.
The largest error was from the position and the angle of the power meter probe.

Attachment #3
I used the same data I took last week(see elog #3672), but better plot.
I put the error bars for just several points. When the laser power is weak, the errors are large because of the cancellation error. When the laser power is high, the errors are estimated to be so small that you can't see it in the plot(~1%).
At the several points, I couldn't lock the PMC well and  the power of the reflected light depended on the offset voltage of the PZT.
The horizontal axis has about 6% error because of the calibration error.

Note:
Now the condition is a bit different from this measurement(NPRO temperature changed, optics moved slightly), so the visibility may be changed.

Attachment 1: PMCsetup.png
Attachment 2: PDcalib.png
Attachment 3: PMCreflect2.png
3722   Thu Oct 14 20:31:15 2010 yutaUpdateComputerspyNDS installation

EDIT by kiwamu Dec.7th ;

The Pynds package has been moved to the appropriate place:

/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages

Background:
We need the python module pyNDS to get the data directly from the server using python.
Leo helped us install pyNDS today.

Installation:
1. Get pyNDS source tarball from here.

2. All you need is Boost.Python and nds2-client. See README in the pynds-0.3 directory.

3. I installed pyNDS to /cvs/cds/caltech/users/yuta/pynds

4. You have to set environment variable to import the module. For example, run;
setenv PYTHONPATH /users/yuta/pynds/lib64/python2.4/site-packages:${PYTHONPATH} Notes: RPM will be available soon from Leo. 3723 Thu Oct 14 20:49:50 2010 yutaUpdateComputersautomated Q-value adjuster Background: Now we can use pyNDS(see elog #3722), so I wrote a python script that adjusts Q-value automatically. What I did: 1. Wrote a python script. /cvs/cds/caltech/users/yuta/scripts/QAdjuster.py 2. Ran this script for every DOF, every MC suspension. Result: Following lines and attached are example output when I ran QAdjuster.py for MC3 POS. Currently, C1:SUS-MC3_SUSPOS_GAIN is 5 Connecting.... authenticate failed: Unspecified error Connecting.... done Current GPS time is 971149410 I kicked C1:SUS-MC3_SUSPOS_OFFSET Waiting for the ringdown...... 0\ Current GPS time is 971149431 omega_0= 6.326764, Q= 11.254252, A= -53.491850, delta= 5.007821, ofset= 4349.808434 Q-value was 11.3 Set C1:SUS-MC3_SUSPOS_GAIN = 10.2311380794 Current Q-values automatically set are as follows.  MC1 MC2 MC3 POS 4.9 4.8 5.9 PIT 6.8 5.5 4.5 YAW 6.4 5.6 5.3 SIDE 5.8 5.2 5.0 Next work: - Modify the script so that it adjusts all the channels automatically. Now, it is one by one, trial by trial. - Modify the script so that it automatically turns the offset switch on. Now, it must be turned on beforehand. - Write a how-to Attachment 1: MC3_SUSPOS.png 3742 Tue Oct 19 21:10:27 2010 yutaUpdateCDSbad filter coefficients for every suspensions! (Koji, Yuta) Summary: The damping servos of the MC suspensions has not been working since yesterday. They had worked on Friday. We found that some of the filter coefficients somehow changed from the correct value during dealing with the sampling frequency shift (from 2048Hz to 16384Hz). (see elog #3659) What we did: We thought that the problem occurred from the CDS update on Monday. So, we restored them using svn. 1. Went to /opt/rtcds/caltech/c1/core/advLigoRTS and ran svn update using the revision number 2125. svn update -r 2125 2. Rebuilt all the front ends. ssh -X c1sus cd /opt/rtcds/caltech/c1/core/advLigoRTS make clean-SYSNAME make SYSNAME make install-SYSNAME  (where SYSNAME=c1x02,c1sus,c1mcs,c1rms) 3. Restarted the front end models. ssh -X c1sus cd /opt/rtcds/caltech/c1/scripts sudo startc1SYS (where SYS=sus,mcs,rms) 4. Restarted mx_streams. sudo /etc/restart_streams See this wiki page for the restart procedures. At this point we judged that the realtime system and "dataviewer" worked fine (by poking some suspensions / by measuring PSDs/TFs of the signals). However, just restoring the RT system didn't fix the damping servos. After that, we measured the transfer functions of the servo filters using DTT(diaggui on rosalba). 5. The filter at MC1_SUSPOS, "3:0.0" should have a cut-off frequency at 3Hz, but it was around 0.3Hz. 6. We used foton in order to look at the filter bank files (in /cvs/cds/rtcds/caltech/c1/chans). Then we found that the filter design was somehow changed to zpk([0],[0.375],2.66666,"n") instead of the correct one zpk([0],[3],0.333333,"n") Why the filter designs changed?: We suspect that the filter designs were changed because of the replacement of sampling frequency in filter bank files(see elog #3659). We only replaced the lines like # SAMPLING SUS_MC3_SUSPOS 2048 to # SAMPLING SUS_MC3_SUSPOS 16384 and didn't changed the coefficients. This may caused a problem when opening the files with foton, and foton changed 3Hz to 0.375Hz (2048/16384) and other coefficients. Note: The damping servo for SIDE has been working for every MCs. POS, PIT, YAW are the ones not working. Next work: - Fix filters for every suspensions. There are backup files in /cvs/cds/rtcds/caltech/c1/chans/filter_archive directory, so this should help. But I don't think just fixing filters would fix the damping servo because the filter design of MC suspensions were changed this morning and the damping had worked until Friday. 3744 Wed Oct 20 01:22:18 2010 yutaUpdateCDSfixed filters for MCs, but no damping (Rana, Yuta) Summary: The damping servo for MCs has not been working since Monday. We already found that some filter coefficients were wrong.(see elog #3742) So, we fixed it (just for MCs now). But still doesn't work. What we did: Fixed the filters for MC suspensions; 1. In /cvs/cds/rtcds/caltech/c1/chans/ directory, we replaced C1MCS.txt with ./filter_archive/c1mcs/C1MCS_101019_101927.txt. This is the archive of the filter bank for MC suspensions, when filter designs were correct(when we hadn't opened it with foton yet). 2. Deleted all the filter coefficients. By using emacs magical C-<space> C-x r k. 3. Loaded with foton to get correct coefficients. 4. Reloaded coefficients for C1MCS. We now have the correct filters, but the damping still doesn't work. 5. To confirm that the filters are now correct and the model is working correctly, we measured the transfer function between ULSEN input and ULCOIL output and compared with the calculated TF from the filter bank file (Attachment #1) . 6. To calculate the designed function, we used the following matlab scripts; /cvs/cds/caltech/users/rana/mat/utilities/FotonFilter.m # takes the foton file and returns the TF /cvs/cds/caltech/users/rana/mat/utilities/readFilterFile.m # reads the foton file /cvs/cds/caltech/users/yuta/scripts/sentocoil.m # calculates the total TF from SEN to COIL Result: As you can see from the attachment, filters seem fine now. (The red line is the measured and the blue line is the calculated function in the plot) But the damping (for POS, PIT, YAW) still doesn't work. Why???? Next work: - see if coils are pushing correctly - push cable connectors further! - check input and output filters (whitening, dewhitening) - when fixed, use my fully updated QAdjuster.py for adjusting Q for multiple channels automatically!! Attachment 1: Screenshot.png 3748 Wed Oct 20 21:43:25 2010 yutaUpdateCDSchecking whitening filters for MCs and messed up (Joe, Yuta) Background: We found that the damping servo for MC suspensions somehow worked when we turned off the 13Hz Chebyshev filters. But that does not meet our satisfaction, so we started checking every components. First of all is the whitening filters. If we turn on a digital whitening filter(WF), corresponding analog WF should turn off, and vice versa. Reference: See DCC #D000210 for the analog circuit of WF. WF has 3Hz zero, 30Hz pole, 100Hz pole. MAX333A bypasses analog WF when supplied +15V(HIGH). What we did: 1. Compared the transfer function between MC2_SUSPOS_EXC and MC2_ULSEN_IN1 when digital WF on and off. When digital is on/off, analog should be off/on, so there should be difference but couldn't see. 2. We went through the simulink model and found 2 mistakes in the logic. One is the conflict with other optics. Even if we turn on/off digital WF of MC2, it didn't switched analog WF of MC2. Two is the additional bit invert (but it turned out to be our misunderstanding). 3. We (thought we) fixed it, rebuild it, and measured the TF again.(Attachment #1) [Attached #1] The red/blue line is when digital WF is on/off. Blue should be bigger(+10dB @ 10Hz according to (analog) WTF) than red, but it was the opposite. 4. To confirm that they are doing the opposite, I checked MAX333A input(pin#1,10,11,20) in "SUS PD Whitening Board" at 1X5-1-8B (which is for MC3) and found that switching is opposite. When I turned off/on the digital WF, MAX333A input was +15V/0V. It should be 0V/+15V. 5. Also, I found that LLSEN digital WF switch switches LRSEN analog WF and vice versa. [Attached #2] Transfer functions between MC2_SUSPOS_EXC and MC2_LRSEN_IN1 with; Red: LR digital off, LL digital on Blue: LR digital off, LL digital off Green: LR digital on, LL digital off As you can see, LL switch is the one which switches LR analog WF now. Conclusion: Currently, digital WF on/off corresponds to analog WF on/off. Also, LL/LR digital WF switch is LR/LL analog WF switch now. Next work: - fix the simulink models (or wiring) - check dewhitening filters Schematic: - whitening MC1 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3) MC2 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3) MC3 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3) D000210 has switches for bypassing analog WT(3,100:3). HIGH to bypass. - dewhitening (-) ... -> SOS Dewhitening Board(D000316) -> MC1,3 UL/UR/LR/LL coils (-) ... -> SOS Dewhitening Board(D000316) -> MC1,2,3 SIDE coils (SimDW)(InvDW) ... -> LSC Anti-imaging Board(D000186) -> Universal Dewhitening Board(D000183) -> MC2 UL/UR/LR/LL coils D000316 has switches for bypassing 28Hz elliptic LPF. HIGH to bypass. D000186 is 7570Hz elliptic LPFs. D000183 has switches for bypassing dewhitening filter. HIGH to bypass. See this wiki page for more comprehensive setup. Attachment 1: MC2ULSEN.png Attachment 2: MC2LRSEN.png 3757 Thu Oct 21 21:35:16 2010 yutaUpdateCDSfixed whitening filter switches (Joe, Yuta) Summary: We found some mistakes in whitening filter switches yesterday(see elog #3748). One was the mis-connection between LL/LR and the second was the bit invert. So, we fixed it and checked that they are now switching correct by probing MAX333A. Why we made mistake: 1. LL/LR mis-connection Simply, Simulink model was wrong. It occurred because UL/UR/LR/LL order is currently arbitrary and confusing. For now, we just swap the connection(Attached #1). In the future, we should fix all orders corresponding to the actual wiring order(UL > LL > UR > LR). 2. Bit invert It occurred from counter-intuitive output of Contec 32 BO(See Attachment #2(taken from this wiki page)). If "1," current goes from A to B, so MAX333A input will be 0V, which means analog WF is on. If "0," no current, so MAX333A input will be +15V, which means analog WF is off(bypassed). Next work: - There are no digital WF in SDSEN inputs. So, we have to put them. - Dewhitening filters are totally messed up now. Switches are wrong, some optics have digital DW but some doesn't, some have 28Hz elliptic LPF....... We have to grand unify them. Attachment 1: LLLR.png Attachment 2: Contec23BO.png 3758 Fri Oct 22 00:59:01 2010 yutaUpdateCDSnew MEDM screens, new filter banks(whitening and dewhitening related) (Joe, Yuta) Summary: No more discrimination for SIDE! We had all SIDE filters in SDSEN, so we splitted into SDSEN, SUSSIDE, and SDCOIL just like other DOFs. (Not SIDECOIL. SDCOIL from now on!) Also, there was a confusion in output filters, so we fixed the filter bank(dewhitening and 28HzELP). More than that, I found that "13HzCheby" in SUSPOS, SUSPIT, SUSYAW was actually doing ~1.6Hz Chebyshev, so I fixed it. (No wonder we had no damping when turing "13HzCheby" on!) Our new MEDM screen is Attachment #1. Input filter design: Every optics, every OSEM has same analog whitening filter. So;  digital analog 30,100:3 30,100:3 ON OFF OFF ON Output filter design: For every SIDE coils and MC1, MC3 coils, they have analog 28Hz elliptic LPFs. So;  digital analog 28HzELP 28HzELP ON OFF OFF ON For MC2(and other main optics) UL/UR/LR/LL coils, they have analog dewhitening filters. So;  digital analog InvDW SimDW DW ON ON OFF ON OFF ON InvDW and SimDW were in FM10 and FM9, but I swapped them to make it more consistent. Now, FM10 switches analog/digital output filiters for every optics. Let's put 28HzELP in FM9 so that FM9 switches analog/digital for every optics.  Quote: Schematic: - whitening MC1 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3) MC2 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3) MC3 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3) D000210 has switches for bypassing analog WT(3,100:3). HIGH to bypass. - dewhitening (-) ... -> SOS Dewhitening Board(D000316) -> MC1,3 UL/UR/LR/LL coils (-) ... -> SOS Dewhitening Board(D000316) -> MC1,2,3 SIDE coils (SimDW)(InvDW) ... -> LSC Anti-imaging Board(D000186) -> Universal Dewhitening Board(D000183) -> MC2 UL/UR/LR/LL coils D000316 has switches for bypassing 28Hz elliptic LPF. HIGH to bypass. D000186 is 7570Hz elliptic LPFs. D000183 has switches for bypassing dewhitening filter. HIGH to bypass. See this wiki page for more comprehensive setup. Next work: - Fix Simulink connection and logic so that analog/digital switching go correctly. - Check if the switching are correct for all channels by measuring transfer functions. - Currently, we are focusing on MCs, but we have to do the same fixing for other optics, too. - More than setting the right filter TF, there are switching settings like Zero History, Ramp, Zero Crossing...... We should investigate that. - Actually, TF of analog DW in D000183 doesn't look like the same with digital SimDW. Why?? Attachment 1: HappySideMEDM.png 3765 Fri Oct 22 19:53:27 2010 yutaSummaryCDSconversion failure in digital filters (Rana, Joe, Yuta) We now understand that we never succeeded in converting old fiter files to new filter files. For example, we just changed the sampling rate with coefficients remained and foton confused, or we forgot to rename some of the module names(ULSEN -> SUS_MC1_ULSEN) ...... This is why we sometimes damped and sometimes didn't, depending on filter switches. New filter files has been always wrong. So, we started to convert them again. We have to figure out how to convert the files that Foton accepts correctly. 3767 Fri Oct 22 23:29:48 2010 yutaUpdateCDSfixed output filter switching (Joe, Yuta) Summary: This evening, we fixed output filter analog/digital switchings in Simulink logic, but they didn't actually switched filters. That was because what we thought BO0 was BO2 and BO2 was BO0. We re-wired, re-labeled the cables. We checked it by using a LED(see "test configuration" in this wiki page). Also, we checked the Simulink connection by probing MAX333A in SOS Dewhitening Board located at 1X4-8-11B, which switches SIDE coils for all optics. Next work: - Currently, FM10 in UL/UR/LR/LL/SDCOIL filters switch analog/digital, but let's make FM9 do the switching.(See schematic in elog #3758) - Check all the logic by measuring transfer functions(maybe single frequency measurement is enough. we can use tdsdmd etc to automate). 3769 Sat Oct 23 03:36:05 2010 yutaUpdateCDSfixed filters for C1SUS, C1RMS, C1MCS (Joe, Yuta) Summary: This Monday, MC suspension damping got something wrong. We started to check filters and found that digital filters were wrong because of mis-conversion from old filter files to new files. We converted the file again, and with mutual understanding between Foton and us, we finally got correct filters(I hope!). What we did: 1. Merged filter files in old /cvs/cds/caltech/chans/ directory into C1SUS.txt(BS,ITMX,ITMY), C1RMS.txt(PRM,SRM), C1MCS.txt(MC123). 2. Rebuilt the RT models in order to get a correct filter file header(they have list of filter modules). 3. Concatenate the header with filter design part which we got from step1. 4. Replaced 'N 2048' with 'N 16384' It replaces sampling rate of "XXSEN"s. Basically, step1-4 was the same with what we did last time. We didn't changed the fitler coefficients, so Foton somehow changed the original filter design. So, this time, we 5. Deleted coefficients like we did on Tuesday (see elog #3774). But Foton couldn't read the file correctly this time. Foton seemed to be unbeatable. Even if we replaced the sampling rate, Foton kept saying 2048! (This is maybe because Foton's default value is 2048Hz. Everytime Foton notice some editting in the file, he destroys everything. He hates editting) The problems were always associated with the sampling rate, so 6. Got back to step4 and undo-ed the replacement. 7. Foton could read it this time, so I changed the sampling rate one by one using Foton GUI. 8. Checked filters using Foton's Bode Plot.(Not for all, but some that had problem before) 9. Splitted SDSEN filters to SDSEN, SUSSIDE, and SDCOIL. 10. Put some missing whitening filters, and 28HzELPs. BS, PRM, SRM didn't have any 28HzELP for SDCOIL. ITMX and ITMY SDCOIL had SimDW/InvDW which doesn't make sense(SIDEs don't have analog DW). So, I deleted and replaced with 28HzELP. F2A issue: We failed in sending F2A filters to new filter files. These are a little bit complicated because TO_COIL_X_X filters were named ULPOS,URPOS etc before. Also, MC3 didn't have any F2As, so maybe we should but the same F2As as MC1/2. Note that every F2As are different, and TO_COIL matrix have UL,UR,LL,LR order(not same as INMATRIX). Also, SRM had f2pv instead of F2A! Next work: - Check whole filters by actually measuring transfer function between SENs and COILs. - Damp MC suspentions, and lock MC. - Measure openloop TF and compare with the designed. How do you read a Foton filter file: When you open up a Foton filter file, you see filters like this. ################################################################################ ### modulename ### ################################################################################ # SAMPLING modulename samplingrate # DESIGN modulename n filterdesign # DESIGN modulename n filterdesign ### ### modulename n xy z v w filtername gain a1 a2 b1 b2 modulename n xy z v w filtername gain a1 a2 b1 b2 a1 a2 b1 b2 n: filter number 0 for FM1, 1 for FM2, ... , 9 for FM10 x: Input Switching setting 1 Always On 2 Zero History y: Output Switching setting 1 Immediately 2 Ramp 3 Input Crossing 4 Zero Crossing z: number of filters cascaded. v: if y=2, (Ramp Time(sec))*(samplingrate) if y=3 or 4, Tolerance w: (Timeout(sec))*(samplingrate) Note that v and w are changed when sampling rate is changed. Transfer function will be; H(1/z)=G*(1+b1/z+b2/z/z)/(1+a1/z+a2/z/z) z=exp(s/fs) where fs is the sampling frequency. Reference: Kiwamu Izumi: "Notes about Digital Filters," http://tamago.mtk.nao.ac.jp/izumi/green/DigitalFilter.pdf 3770 Sat Oct 23 14:42:01 2010 yutaSummaryCDSdamped MC suspensions After replacing filters, MC suspensions damped last night. Further measurement next time. Attachment 1: dam.png 3785 Tue Oct 26 12:45:20 2010 yutaHowToCDSmaking a new master file for medm screens (Joe, Yuta) In elog #3708, we showed how to edit all the similar medm screens easiliy. But if there are no master files you want to edit in /opt/rtcds/caltech/c1/medm/master/ directory, you can make one. Say, you want to edit all the similar medm screens named C1SUS_NAME_XXX.adl. 1. Copy one of C1SUS_NAME_XXX.adl to /opt/rtcds/caltech/c1/medm/master/ directory as C1SUS_DEFAULTNAME_XXX.adl. 2. Go to that directory and sed -i 's/NAME/DEFAULTNAME/g' C1SUS_DEFUALTNAME_XXX.adl 3. Add "_XXX.adl" to file_array list in generate_master_screens.py 4. Edit C1SUS_DEFUALTNAME_XXX.adl 5. Run ./generate_master_screens.py That's all!! 3787 Tue Oct 26 16:02:55 2010 yutaHowToCDSthings to do after making a new Simulink model (Joe,Yuta) Things to do after making a new Simulink model. 1. ssh c1sus, go to /opt/rtcds/caltech/c1/core/advLigoRTS/ and run  bash ./makestuff.sh c1SYS makestuff.sh does;  make uninstall-daq-$*   make clean-$* make$*   make install-$* make install-daq-$*   make install-screens-$* sed -i 's/RO $$.*SW[12]R.*$$/\1/' /opt/rtcds/caltech/c1/target/$*/*epics/autoBurt.req If you don't need to re-install DAQs or screens, just run line 2,3,4, and 7 and go to step #6. 2. ssh c1sus, go to /opt/rtcds/caltech/c1/scripts/ and run  sudo ./startc1SYS For now, you have to put "1" in "BURT Restore" in GDS screens with in 5-10 secs. 3. Now the DAQ channel numbers are changed. So, go to /cvs/cds/rtcds/caltech/c1/chans/daq/ and run  ./activateDAQ.py activateDAQ will activate the following DAQ channels for every optics with data rate 2048Hz; ULSEN_OUT URSEN_OUT LRSEN_OUT LLSEN_OUT SDSEN_OUT SUSPOS_IN1 SUSPIT_IN1 SUSYAW_IN1 4. Restart fb. See this wiki page. Basically you what have to do is kill and restart daqd in fb and restart mx_streams in c1sus. 5. DONE! Burt restore if you want. 6. If you don't need to re-install DAQs or screens; a. Go to /opt/rtcds/caltech/c1/target/c1SYS/c1SYSepics and run  sudo rmmod c1SYSfe b. Go to /opt/rtcds/caltech/c1/target/c1SYS/bin/ and run  sudo insmod c1SYSfe.ko 3788 Tue Oct 26 17:31:17 2010 yutaUpdateCDSfixed OPLEV stuff and MCL filters (Joe, Yuta) Background: We are currently working on getting rid of "white stuff" in MEDM screens. Today, we fixed OPLEV stuff, MCL filters, and time stamps. What we did: 1. Plugged in OPLEV cables to ADC2. (See this wiki page for wiring) 2. Connected ADC2 and OPLEV in Simulink model and fixed MEDM screens for OPLEVs (Attached #1). 3. Put MCL filters for BS,ITMX,ITMY,PRM,SRM. They don't need them, but just for getting rid of "white stuff." They are connected to the ground, so the outputs are always 0. 4. Fixed "TIME_STRING"s in MEDM screens so that they show current time correctly. You only need to put text monitor with channel "C1:FEC-DCU_NODE_ID_TIME_STRING" into master files(DEFAULTNAME things) and run generate_master_screens.py. It will automatically sets DCU ID correctly!! (Great work, Joe!) See this wiki page for more info on making MEDM screens. 5. Checked OPLEV for MC2 by pointing a laser pointer to QPD. (For MC2, OPLEV is just a transmission beam position monitor) Each quadrant looked like they are connected to the right channel numbers. Plan: - figure out what C1:SUS-NAME_MODE_SW1 does and fix - fix Whitening, Dewhitening ON/OFF button in main MEDM screens, so that they switch every channels' filters - make a new screen for MC (like the old one C1IOO_ModeCleaner.adl) - create a new mark for new MEDM screens Attachment 1: optlevMC2.png 3805 Thu Oct 28 03:39:58 2010 yutaUpdateIOOgot very stable MC locking (Rana, Suresh, Jenne, Kiwamu, Kevin, Yuta) Summary: Last night we locked MC by feeding back the signal to NPRO PZT. But it was not so stable. We wanted more gain to lower the seismic motion, but we don't need high gain in high frequency part(>~1kHz) because it may cause something bad(NRPO PZT oscilatting, PMC not able to catch up with the NPRO frequency change, etc). So, we put DC gain boost today. It successfully made MC locking stable! What we did: 1. Lowered the main laser temperature from 32.2° C to 31.8° C. When we increased the laser temperature, PMC transmission get lower. 32.2° C was on the cliff, so we put it to plateau region. 2. Lowered the gain of PMC servo (2dB instead of 8dB last night), because PMC was oscillating. We got 5.3V OMC transmission. 3. Made 3Hz pole, 30Hz zero filter and put in NPRO PZT servo loop. 0dB at DC, -20dB at high frequency (see Kevin's elog #3802) 4. Put more gain to NPRO PZT servo loop to compensate -20dB at high frequency. In a word, we put DC gain boost. Attachment #1 is the MEDM screen screenshot for MC servo. 5. Aligned the beam into QPD at MC2 trans. We put lens in front of the QPD. Now, we can see the actual motion of the beam, and resonance peaks(Attachment #2; not locked at the highest). (We added 30Hz LPF after each 4 quadrant inputs to reduce noise) Plan: - optimize MC suspension alignments - activate OL DAQ channels - reduce RFAM - install tri-mod box - QPD signal at MC2 should be more high(currently, ~7counts which equals to ~4mV) - change temperature of X-end laser to get green beat Attachment 1: C1IOO_MC_SERVO20101028.png Attachment 2: MCrocks!.png 3807 Thu Oct 28 04:28:50 2010 yutaUpdateGreen Lockingchecked frequency counter SR620 (Kiwamu, Yuta) Background: For green locking, we are planning to feedback frequency differential signal to ETM suspension for the final configuration. We don't have ETM suspension control system right now, so we are going to feedback the signal to X-end laser frequency for a test. We have two loops for the servo; 1. coarse locking using frequency counter, feeding back to the laser temperature 2. using VCO, feeding back to the laser PZT Today, we checked frequency counter SR620 and see how to get the small beat note signal(-48dBm; see elog #3771). What we did: 1. Using Marconi(RF signal generator), put RF signals to SR620 and see how small signal SR620 can see. It depends on the frequency. For 80MHz signal, you need more than about -9dBm. 60MHz >-12dBm 70MHz >-10dBm 80MHz >-9dBm 90MHz >-8dBm 100MHz >-7dBm Since we are going to lock the frequency difference between X-end and PSL to 80MHz, we need at least +40dBm amp before putting the signal into SR620. RF amplifier ZHL-32A has around +28dBm +28dB gain at 80MHz, so we need 2 of them. 2. Marconi -> ZHL-32A -> ZHL-32A -> SR620 and see how small 80MHz signal SR620 can see. Around -68dBm. This should be enough. 3. SR620 has "STRIP CHART" output on the rear panel. The output voltage is proportional to the mean frequency of the input. The output range is 0-8V. So in order to get 4V for 80MHz, set SCALE to 20MHz. Plan: - find green beat again and see if SR620 can see it with double ZHL-32A configuration 3813 Thu Oct 28 20:08:26 2010 yutaUpdateGreen Lockingrevised RF amp cascading Background: Yesterday, I said I will use ZHL-32A for amplifying beat note signal, but as Koji pointed out, ZHL-32A is for medium high power. So I changed my mind to use ZFL-1000LN instead. ZFL-1000LN is a low noise RF amp whose maximum power is 3dBm. Also, we included a splitter in our consideration. What I did: 1. Set up a new setup. ZFL-1000LN has a gain of +24dB at 80MHz and splitter ZFRSC-42 has a loss of -6dB. So; beat note signal -> ZFL-1000LN -> ZFL-1000LN -> ZFRSC-42 => SR620 and VCO 2. Measured frequency-output relation. When the input signal was 80MHz -48dBm, the output was -8.7dBm. For other frequencies; 60MHz -3.3dBm 70MHz -5.7dBm 80MHz -8.7dBm 90MHz -5.5dBm 100MHz -3.5dBm So, we can see frequency up to >100MHz by SR620 using this setup. 3. Checked harmonics peak levels of the output using an RF spectrum analyzer. When the input signal was 80MHz -48dBm, the height of the peaks were; 80MHz -8.8dBm 160MHz -30dBm 240MHz -42dBm Other peaks were smaller than the 3rd harmonics. Also, RF PD that detects beat note signal has a cut-off frequency at around 100MHz. So, we don't need to worry about wave transformation for this setup.  Quote: ZHL-32A is a high power (well..., actually middle power) amplifier with the max output power of +29dBm (~1W!). It seems to be overkill. Your signal is so small so you don't need ZHL-32A, but can use small amp which we may have somewhere in the lab. And the description: "RF amplifier ZHL-32A has around +28dBm gain at 80MHz" The unit is wrong. Yes. I corrected my previous elog. 3814 Thu Oct 28 21:20:11 2010 yutaUpdateCDSFlaky fb, tried DAQ re-install, but no help Summary: Unfortunately, fb is flakier than normal. We can't use dataviewer and diaggui now. I thought it might be because editting .ini files(list of DAQ channels) in /cvs/cds/rtcds/caltech/c1/chans/daq/ without using GUI was doing something wrong. So, I re-installed DAQ, but it didn't help. What I did: 1. ssh c1sus, went to /opt/rtcds/caltech/c1/core/advLigoRTS/ and ran make uninstall-daq-c1SYS make install-daq-c1SYS It didn't help. More than that, MC suspension damping went wrong. So; 2. Rebooted c1sus machine. I restored MC suspension damping by doing this. (Similar thing happened Tuesday when we were trying to lock MC) Conclusion: Editting .ini DAQ channel list file wasn't wrong. (or, I failed in finding anything wrong right now)  Quote: Attempted Fixes: Yuta may try restoring the old DAQ channel choices and see if that makes a difference. 3815 Thu Oct 28 23:17:15 2010 yutaSummaryCDS[EMERGENCY] accidentally deleted daqd Rana showed me that if c1sus machine runs c1mcs stuff(and c1x02 stuff) only, we can use dataviewer without crashing fb. Also, if we set correct NDS server and port(fb/8088), we can use diaggui on every machine. During my investigation on what he did, I accidentally deleted daqd...... I am very very sorry. I don't know if it helps or not, but all I have is the following information: [Backup?] /opt/rtcds/caltech/c1/target/fb/daqd.25sep10 [What I deleted] -rwxr-xr-x 1 controls controls 6583071 Oct 1 11:57 daqd [help message for daqd existed] CDS Data Acquisition Server, Frame Builder, version 2.0 California Institute of Technology, LIGO Project Client communication protocol version 11.4 Usage: daqd [-f <input frame file name>] [-c <configuration file (default --HOME/.daqdrc)>]

[-s <frame writer pause usec (default -- 1 sec)>]

This executable compiled on:
Fri Oct  1 10:33:18 PDT 2010
Linux fb 2.6.34.1 #7 SMP Fri Sep 24 14:09:53 PDT 2010 x86_64 Dual-Core AMD Opteron(tm) Processor 8220 AuthenticAMD GNU/Linux

3828   Fri Oct 29 18:37:33 2010 yutaSummaryCDSdaqd and current CDS status

Background:
Before Joe left(~ 1 hour ago), fb was working for a while. But after he left, daqd core dumped.
This is maybe because we started c1sus and c1rms again for a delay measurement, just before he left.

What I did:
I restarted IOP(c1x02) and FE models.
Now it seems OK (we can use dataviewer and diaggui), but daqd reports bunch of errors like;

CA.Client.Exception...............................................
Warning: "Identical process variable names on multiple servers"
Context: "Channel: "C1:SUS-ITMX_TO_COIL_0_3_INMON", Connecting to: 192.168.113.85:42367, Ignored: c1susdaq:42367"
Source File: ../cac.cpp line 1208
Current Time: Fri Oct 29 2010 18:07:39.132686519
..................................................................

tp node xx invalid  (xx is 38 to 36)

Current CDS status:

 MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant ... ...

Below is an example of how the color code works:

3829   Sat Oct 30 05:27:53 2010 yutaSummaryCDSCDS time delay measurement

Motivation:
We want to know the time delay of CDS in the IOP scheme.

Setup:

What I did:
1. Plugged out SCSI cable from ADC card 2 and DAC card 0 on C1SUS machine.
DAC card 0 is DAC 0

2. Measured tranfer function between ADC and DAC by SR785 and compared with the downsampling filter in IOP with 65534Hz(=4x16384Hz) sampling frequency.

As ADC_0_0 corresponds to PRM ULSEN input and DAC_0_0 corrsponds to ULCOIL output, we turned all the filters off and set gains to 0 or 1 so that TF between ULSEN to ULCOIL will be ideally 1. (see this wiki page for channel assigns)

The filter coefficients for the down sampling filter was found in;
It was named feCoeff4x.

static double feCoeff4x[9] =
{0.014805052402446,
-1.71662585474518,    0.78495484219691,   -1.41346289716898,   0.99893884152400,
-1.68385964238855,    0.93734519457266,    0.00000127375260,   0.99819981588176};

3. Calculated the time delay dt using the following formula;
dt = [pm - pc]/f/360deg    (pm: measured phase, pc: calculated phase from feCoeff4x, f: frequency)

4. Measured TF between the SCSI cables to estimate the effect of the cables and others.
Disconnected SCSI cables from ADC and DAC, and connected A aad B(see setup).
I measured both when input coupling of SR785 is DC and AC and see what happens.

Result:
[time delay of the CDS]  (left, middle)
The time delay gets larger with frequency. The time delay seems to be -175 usec at DC.
However, the gain seems a little different from my expectation(feCoeff4x). So, there are maybe other filters I don't know.
I neglected TF of upsampling this time.

[cable and other effect]  (right)
The effect to the time delay measurement was tiny by a factor of 10^4 to 10^3 (few nsec).
But the total cable length was about 5 m and assuming signal speed is 0.6c, delay will be about 30 nsec.
I don't know what's happening.

Plan:
- make a model that does not go through IOP and see the delay caused by IOP

By the way:
fb daqd is still running for hours!
Every FEs are running(c1sus,rms,mcs).

3838   Mon Nov 1 15:47:15 2010 yutaSummaryCDSCDS time delay measurement

Background:
I measured CDS time delay last week, but because of my lack of understanding the system, it was incorrect.
IOP has an anti-aliasing filter before downsampling from 64kHz(65536Hz) to 16kHz(16384Hz) and also has an anti-imaging filter before upsampling from 16kHz to 64kHz.
So, I should have take feCoeff4x into account twice.

Result:
TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.

Plan:
- make AWG(, diaggui TF measurement, tdssine) work
- check input/output filter switching (using tdssine & tdsdmd)
- measure openloop TF of MC suspension damping
- divide it with my expectation and see if there are any filters I don't know

 Quote: Unsatisfactory. Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice. I attached the slides I made during my visit for March LVC '09. P.5 would be useful.

3841   Mon Nov 1 19:32:08 2010 yutaSummaryCDSfb crashed? during c1ioo and c1mcs connection at ASC

Frame builder died again!!

Background:
We want to do angle to length measurement to optimize the beam position and increase visibility of MC locking.
In order to do A2L measurement, we need excitation point, but AWG is currently not working.
The better way is to use LOCKIN stuff like we had for OMC and put it to C1IOO WFS.
A software oscillator in LOCKIN shakes the suspension, and demodulate the length signal.
We can choose whatever DOF to shake, whatever signal to demodulate. It would be useful not just for A2L.

What I did:

I started to put C1IOO WFS signal into C1SUS MC suspension RT model, but after compiling new c1mcs, fb crashed.
Looks like daqd and mx_streams are running, but DAQ is not working(red).
I don't know how to restart in a new way!

ELOG V3.1.3-