40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 121 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  17048   Fri Jul 29 22:37:54 2022 KojiUpdateIOOWFS investigation

I wanted to check what's wrong with the WFS.

I played with MC2 misalignment to check the error signals.
MC2 pitch and yaw misalignment optically produce a vertical translation and horizontal rotation of the cavity axis at the waist, respectively. So it is thought to be a more separated excitation of the cavity axis.
Then I noticed that WFS2 error signals in general has high (~100%) pitch-yaw coupling. So it was suspicious.

I went to the rack and found that WFS2 SEG4 RF input (labeled "8") was not completely inserted. (Attachment 1)
It seemed that the LEMO connector or the receptacle didn't latch properly anymore and could be easily pulled.
I gave some elbow grease to fix this but in vain. I ended up to use LEMO-BNC adapters which somehow offered a robust connection.

Desipite the insightful discovery, this was not the intrinsic solution to the issue. I checked the past signal history, but I don't think this loose connection caused the missing signal.


Next, I needed to go a bit deeper. The WFS sensors are supposed to be adjusted to I phase where the PDH signal maximally shows up. And all the segments are supposed to have the same sign in terms of the PDH signal.

I've unlocked the IMC and turned on MC2 tickling. This swept the cavity over the resonances.
WFS1 SEG1I~3I showed about the same waveform, but SEG4 Q shows the PDH signal rather than SEG 4 I.
Then tried the same test for WFS2. The SEG4 I signal has the sign-flipped PDH signal compared to WFS2 SEG1I-SEG3I.

I quickly adjusted the demod phase of WFS1 SEG4 and WFS2 SEG4 to correct them,

WFS1 SEG4 103.9-> -20
WFS1 SEG4 -58  -> 120

This in fact made the pitch and yaw separated but flipped (Pitch signal shows up in WFS1Y and yaw signal shows up in WFS1P. Same for WFS2)

These modifications were reverted upon my leaving.


Now things are much more subtle now. And I need to do a more careful quantitative analysis of the demodulation phases / input matrix / output matrix.

Note: It seems that I had worked on IMCWFS on Dec 21, 2016

Attachment 1: PXL_20220730_040900843.jpg
PXL_20220730_040900843.jpg
Attachment 2: PXL_20220730_041216848.jpg
PXL_20220730_041216848.jpg
  17050   Sat Jul 30 12:48:18 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

> it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1.

- OK. Your new MCAutolocker does not reflect the lock status to C1:IOO-MC_LOCK. This causes FSS Slow to go crazy when the IMC is not locked. Can you fix that?

- So C1PSL_SLOW.adl screen, which spawns by the "SLOW Servo" button on the FSS screen, has no effect on the FSS SLOW servo anymore. It is obsolete. At least the screen (or the link to the screen) should be removed. (Work on it once you are back.)

- Also, please make a wiki page and copy the description on the previous page.

  17053   Tue Aug 2 01:10:26 2022 KojiUpdateIOOWFS investigation

Continued to work on the WFS repair

Demod phase adjustment:

- Use the PDH signal to adjust the demodulation phase to have uniform signals between the segments.

- Excited laser frequency at 1234Hz by injecting 10mVpp into IMC Servo Board IN2. The input was enabled on the MC Servo screen and given the input gain of 0dB.

- Looked at the ~real time spectrum in WFS1/2 SEG1/2/3/4 I&Q after the phase rotators. Changed the demod phases 1) to have ~0deg transfer function between C1:IOO-MC_F to C1:IOO-WFSi_Ij 2) to minimize the freq signal in Q phases.
(See Attachment 1)

- Resulting change of the demod phases:

WFS1 SEG1  52.0 -> 38.0deg
WFS1 SEG2  54.0 -> 53.0deg
WFS1 SEG3  16.6 -> 33.2deg
WFS1 SEG4 103.9 ->-37.1deg

WFS2 SEG1  17.0 -> 57.8deg
WFS2 SEG2  26.6 -> 51.5deg
WFS2 SEG3  24.5 -> 44.0deg
WFS2 SEG4 -58.0 ->103.7deg

SEG4 of both WFSs had significant phase rotation. A quick check of the power spectrum indicates that the Q signals have significantly (<x1/10) lower signals (Attachment 2/3/4). So that's good.

Transfer function measurement

Now the ASCPIT/ASCYAW of the MC1/2/3 suspension were excited and the transfer functions to WFS1/2 SEG1/2/3/4 and MC Trans P/Y were measured. The analysis will come later.

Again here the Q signals have significantly lower sensitivity to the mirror motion. So it is consistent with the above observation of the spectra.

However, the quick check of the transfer functions indicated that the conventional input matrices result in the flipped dependence of the combined error signals in pitch and yaw.
This might indicate that some of the cables were not inserted into the demod board properly although the cables at the demod boards show no indication of anomaly. (See the photos in ELOG 17048)

It might be the case that the cable had been inserted with a special unusual arrangement.

In any case, this can be fixed at the input matrix. Native change of the input matrix made WFS1PIT/WFS1YAW/WFS2PIT/WFS2YAW/MC2Trans YAW servos running (after some adjustment of the servo signs).
The MC2TRANS PIT servo didn't seem to settle and run away no matter which sign is used.

It's probably better to look at the sensing matrix and figure out the proper input/output matrix carefully. So at this moment, no WFSs are working.

Note that I left the new demod phases in the system


During the transfer function measurement some filters were turned off to make the shaking smoother:

IMC ASC filters were turned off to make the FResp flat:
- MC1 ASCP/Y FM1/FM5 OFF
- MC2 ASCP/Y FM1/FM5/FM6 OFF
- MC3 ASCP/Y FM1/FM5 OFF

60Hz comb OSEM Input filters were also turned off to make the transfer functions simpler:
- MC1 INPUT FM2 OFF (60Hz comb)
- MC2 INPUT FM2 OFF (60Hz comb)
- MC3 INPUT FM2 OFF (60Hz comb)


cf. Past IMCWFS commissioning http://nodus.ligo.caltech.edu:8080/40m/12684

Attachment 1: 220801_IMC_WFS_DEMOD.pdf
220801_IMC_WFS_DEMOD.pdf
Attachment 2: 220801_IMC_WFS_DEMOD2.pdf
220801_IMC_WFS_DEMOD2.pdf
Attachment 3: WFS1.png
WFS1.png
Attachment 4: WFS2.png
WFS2.png
  17055   Wed Aug 3 15:01:13 2022 KojiUpdateGeneralBorrowed Dsub cables

Borrowed DSUB cables for Juan's SURF project

- 2x D25F-M cables (~6ft?)

- 2x D2100103 ReducerCables

Attachment 1: PXL_20220803_215819580.jpg
PXL_20220803_215819580.jpg
  17059   Thu Aug 4 21:58:18 2022 KojiUpdateIOOWFS investigation

OK... It seems that all the 6 dof of the IMC WFS servo loops were closed with some condition...

- Measured the transfer functions from ASCPIT/YAW_EXC of each suspensions to WFS segs.
- FInd the proper input matrix for PIT and YAW for WFS1 and WFS2
- Closed loops one by one => This was not so successful because the loop shape was quite conditional.
- Closed WFS1/WFS2 loops one by one only with FM4 (0.8Hz Zero / (100Hz pole)^2). Adjust the gains to have the UGF at a few Hz.

- Found that the separation between WFS1P and WFS2P was not good. This caused instability of these loops when the gains were matched. I ended up lowering the gain of WFS1P by a factor of 10. This made the loop OK to work. FM3 (Integrator below 0.8Hz) worked fine.

- FM9 Rolloff filters (RLP12) makes the loops unstable.

- The MC2 spot loops (MC2_TRANS_PIT/YAW) are supposed to be slow loops. From the time series behavior it looks they are working.


MEDM Snapshots (Attchaments 1~4)

Attachment 1: Screenshot_2022-08-04_22-10-57.png
Screenshot_2022-08-04_22-10-57.png
Attachment 2: Screenshot_2022-08-04_22-11-16.png
Screenshot_2022-08-04_22-11-16.png
Attachment 3: Screenshot_2022-08-04_22-11-53.png
Screenshot_2022-08-04_22-11-53.png
Attachment 4: Screenshot_2022-08-04_22-12-39.png
Screenshot_2022-08-04_22-12-39.png
  17060   Thu Aug 4 22:14:20 2022 KojiUpdateIOOWFS investigation

Sensing matrix measurement

MCx_ASCyyy_EXC was shaken with the amplitude of 3000 cnt. Measure the transfer functions to each segment of the WFS I&Q demod outputs.

- Pitch excitations consistently indicated WFS1 SEG2&3 / SEG1&4, and WFS2 SEG 1&2 / SEG 3&4 are the pairs.
- Yaw excitations consistently indicated WFS1 SEG1&2 / SEG3&4, and WFS2 SEG 1&4 / SEG 2&3 are the pairs.

---> WFS1P matrix {1,-1,-1,1}, WFS1Y matrix {1,1,-1,-1}, WFS2P matrix {1,1,-1,-1}, WFS2Y matrix {-1,1,1,-1}

Now look at the servo input. The following lists show the important numbers for the actuation to sensor matrices. The numbers were the measured transfer function between 7~10Hz and the unit is 1/f^2 [cnt/cnt].

CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, -77.4602 +/- 18.4495
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -22.6042 +/- 5.289
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.0007949 +/- 0.00019046
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -60.5557 +/- 14.1008
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -206.3526 +/- 47.1332
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.00027094 +/- 6.6131e-05

CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 57.8636 +/- 35.3874
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -185.079 +/- 104.679
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, 0.00089367 +/- 0.00052603
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -349.7898 +/- 202.967
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -193.7146 +/- 111.2871
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.003911 +/- 0.0023028

CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 65.5405 +/- 14.305
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, 78.8535 +/- 17.1719
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.00087661 +/- 0.00020837
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -130.7286 +/- 29.6898
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, 129.0654 +/- 28.6328
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, -0.00024944 +/- 5.9112e-05

Put these numbers in the matrix calculation and take the inverse for pitch and yaw separately.

We obtained

WFS1P    WFS2P    MCTP    
-4.017   -4.783   -7.306e5   MC1P
 3.611   -5.252   -2.025e5   MC2P
 7.323   -1.017   -6.847e5   MC3P

WFS1Y    WFS2Y    MCTY    
-3.457   -4.532   -5.336e5   MC1Y
-0.1249   0.3826   2.635e5   MC2Y
-5.714    1.076   -4.578e5   MC3Y

Basically we can put these numbers into the output matrix. The last column corresponds to the spot position servo and we want to make this slow.
So used x1e-5 values (i.e. removed e5) instead of these huge numbers.

 

Attachment 1: IMC_SUS_channels_TF.pdf
IMC_SUS_channels_TF.pdf
Attachment 2: IMC_WFS_channels_TF.pdf
IMC_WFS_channels_TF.pdf
Attachment 3: IMC_WFS_segment_TF.pdf
IMC_WFS_segment_TF.pdf
Attachment 4: IMC_WFS_220804.xlsx
  17061   Thu Aug 4 22:14:38 2022 KojiUpdateIOOWFS investigation

WFS/MCTRANS_QPD Power Spectra

Attachment 1: HEPA ON

WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is largely contaminated by the other WFS loops.
MC2 TRANS YAW is slightly contaminated but not much compared to the one for pitch.

Attachment 2: HEPA OFF

Again, WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is still contaminated but better.
MC2 TRANS YAW is not contaminated.


Observation

WFS1/2 signals are largely disturbed when PSL HEPA is ON. Probably the amount of HEPA air flow was not optimized.
Above 1Hz, invacuum suspension are quieter than the beam incident on the IMC.

The dirty WFS signals are fedback to the mirrors. Due the large motion of the beam and also the imperfection of the actuator matrix cause the MC2 spot rather moves than stabilized.

This means that the WFS loops should leave the mirrors untouched above 1Hz i.e. The loop bandwidths should be low (~<0.1Hz). (Yes I know)
However, the simple gain reduction (x10) does make the servos unstable. So more adjustment is necessary. (<-Not for today)

Attachment 1: Screenshot_2022-08-04_22-17-19.png
Screenshot_2022-08-04_22-17-19.png
Attachment 2: Screenshot_2022-08-04_22-18-45.png
Screenshot_2022-08-04_22-18-45.png
  17062   Thu Aug 4 22:32:31 2022 KojiUpdateIOOUpon leaving the lab (WFS investigation)

Upon leaving the lab:

- HEPA is ON at the original speed (i.e. same speed at 5PM today)

- WFS servo is ON, partly because we want to see how stable it is. It is not handled with the autolocker right now.
So there is a possibility that the WFS servo goes wild and make the IMC totally misaligned (and does not come back)
In such a case, go to the WFS servo screen and push "CH" (clear history) of each servo filters.

  17063   Fri Aug 5 12:42:12 2022 KojiUpdateIOOIMC WFS: Overnight observation

The IMC lock survived overnight and the WFS servo loops kept it aligned. The IMC was unlocked in the morning.
The left 6 plots are the WFS servo outputs and the right most two plot show the transmission and reflection of the IMC.

If the WFS is making the lock unstable under high seismic conditions, please turn the loops off.

 

Attachment 1: Screen_Shot_2022-08-05_at_12.04.01.png
Screen_Shot_2022-08-05_at_12.04.01.png
  17068   Tue Aug 9 15:50:22 2022 KojiUpdateBHDBHD fringe contrast improved from 43% to 74%

For both 40m/17020 and 40m/17024, what does the contrast mean if the numbers are leaking out to ~-100cnt?
Also how much is it if you convert this contrast into the mode matching?

  17072   Wed Aug 10 19:36:45 2022 KojiBureaucracyGeneralLab cleaning and discovery

During the cleaning today, we found many legacy lab items. Here are some policies what should be kept / what should be disposed

Dispose

  • VME crates and VME electronics as long as they are not in use
  • Eurocard SUS modules that are not in use.
  • Eurocard crates (until we remove the last Eurocard module from the lab)
  • Giant steel plate/palette (like a fork lift palette) along the Y arm. (Attachment 1)
  • An overhead projector unit.

Keep

  • Spare Eurocard crates / ISC/PZT Eurocard modules
  • Boxes of old 40m logbooks behind the Y arm (see Attachment 2/3).
  • Ink-plotter time-series data (paper rolls) of 1996 IFO locking (Attachment 4). Now stored in a logbook box.
  • A/V type remnants: Video tapes / video cameras / casette tapes as long as they hold some information in it. i.e. Blank tapes/blank paper rolls can be disposed.
Attachment 1: steel_plate.jpg
steel_plate.jpg
Attachment 2: logbook1.jpg
logbook1.jpg
Attachment 3: logbook2.jpg
logbook2.jpg
Attachment 4: paper_plots.jpg
paper_plots.jpg
  17077   Fri Aug 12 02:02:31 2022 KojiUpdateGeneralPower Outage Prep: nodus /home/export backup

Took the backup (snapshot) of /home/export as of Aug 12, 2022

controls@nodus> cd /cvs/cds/caltech/nodus_backup
controls@nodus> rsync -ah --progress --delete /home/export ./export_220812 >rsync.log&

As the last backup was just a month ago (July 8), rsync finished quickly (~2min).

  17079   Mon Aug 15 10:27:56 2022 KojiUpdateGeneralRecap of the additional measures for the outage prep

[Yuta Koji]

(Report on Aug 12, 2022)

We went around the lab for the final check. Here are the additional notes.

  • 1X9: The x-end frontend machine still had the AC power. The power strip to which the machine is connected was disconnected from the AC at the side of the rack. (Attachment 1)
  • 1X8: The vacuum rack still supplied the AC to c1vac. This was turned off at the UPS. (Attachment 2)
  • 1X6: VMI RFM hub still had the power. This was turned off at the rear switch. (Attachment 3)
  • PSL: The PSL door was open (reported above). Closed. (Attachment 4)
  • 1Y2: The LSC rack still had the DC power. The supplies were turned off at the KEPCO rack (the short rack). (Attachment 5)
    Note that the top-right supply for the +15V is not used. (The one in the empty slot got busted). We may need some attention to the left-most one in the second row. It indicated a negative current. Is this just the current meter problem or is the supply broken?
  • Control room: The CAD WS was turned off.

I declare that now we are ready for the power outage.

Attachment 1: PXL_20220812_234438097.jpg
PXL_20220812_234438097.jpg
Attachment 2: PXL_20220812_234655309.jpg
PXL_20220812_234655309.jpg
Attachment 3: PXL_20220812_234748559.jpg
PXL_20220812_234748559.jpg
Attachment 4: rn_image_picker_lib_temp_b5f3e38d-796c-4816-bc0e-b11ba3316cbe.jpg
rn_image_picker_lib_temp_b5f3e38d-796c-4816-bc0e-b11ba3316cbe.jpg
Attachment 5: PXL_20220812_235429314.jpg
PXL_20220812_235429314.jpg
  13941   Mon Jun 11 18:10:51 2018 Koji UpdateelogComparison of the analytical and finesse values of TMS and FSR.

Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?

  2613   Thu Feb 18 15:39:16 2010 Koji and SteveConfigurationVACvalve condition: ALL OFF

As preparation for the upcoming planned power outage we turned turbos, RGA off and closed valves.

IFO chamber is not pumped now. Small leaks and out gassing will push the pressure up slowly. At 3 mTorr of P1 the PSL output shutter

will be closed by the interlock.

It is OK to use light in the IFO up to this point.

  7736   Wed Nov 21 01:31:37 2012 Koji, AyakaUpdateLockingalignment on ETMX table

Since the transmission beam on ETMXT camera seemed to be clipped, we checked the optics on ETMX table.

We aligned the lens so that it is orthogonal to the beam, then the beam shape looks fine.

output.nv12.bmp

Also we removed some an-used optics which were used for fiber input.

  2259   Thu Nov 12 17:24:29 2009 Koji, Joe, PeterConfigurationCDSETMY CDS test started

We started the test of the new CDS system at ETMY.

The plan is as follows:
We do the ETMY test from 9:30 to 15:00 at ETMY from Nov 12~17. This disables the ETMY during this period.
From 15:00 of the each day, we restore the ETMY configuration and confirm the ETMY work properly.


Today we connected megatron to the existing AA/AI modules via designated I/F boxes. The status of the test was already reported by the other entry.

During the test, c1iscey was kept running. We disabled the ETMY actuation by WatchDog. We did not touch the RFM network.

After the test we disconnected our cables and restored the connection to ICS110B and the AI/AA boards.

The WatchDog switches were released.

The lock of the ETMY was confirmed. The full interferometer was aligned one by one. Left in the full configuration with LA=off.

  3054   Tue Jun 8 00:38:22 2010 Koji, KiwamuUpdateIOOimproved Gaussian beam in new IOO

The shape of the beam spot in the new input optics got much much better 

As Alberto and Kiwamu found on the last week, the beam spot after MMT1 had not been good. So far we postponed the mode measurement due to this bad beam profile.

Today after we did several things in the vacuum chamber, the beam spot became really a good Gaussian spot. See the attachment below.

There were two problems which had caused the bad profile:

(1)  a steering mirror after MMT1 with the incident angle of non 45 deg

(2) clipping at the Faraday.

 

Also MCT_QPD and MCT_CCD were recovered from misalignment  

Tomorrow we are going to restart the mode matching. 

 


(what we did)

* We started from checking the shape of the beam going out from the BS chamber. There still were some stripes which looked like an interference on the spot. 

* We found a steering mirror after MMT1 had the incident angle of non 45 deg. In fact the mirror had a large transmission. After we made the angle roughly 45 deg, the stripes disappeared.

However the spot still didn't look a good Gaussian, it looked slightly having a bump on the horizontal profile.

* Prior to moving of some optics in the vacuum, we ran the A2L_MC scripts in order to check the beam axis. And it was okay.

* To recover the MCT, we steered one of the vacuum mirrors which was located after the pick off mirror.  And after aligning some optics on the AP table, finally we got MCT recovered.

 * We rearranged MC_refl mirrors according to the new optical layout that Koji has made. At the same time the mirrors for IFO_refl was also rearranged coarsely.

 * We leveled the optical table of the MC chamber by moving some weights. Then we locked the MC again and aligned it. We again confirmed that the beam axis was still fine by running the A2L scripts.

 * We found the beam going through Faraday was off-centered by ~5mm toward the west. So we moved it so that the beam propagates on the center of it. 

 * Then looking at the beam profile after MMT1, we found that the profile became really nicer. It showed a beautiful Gaussian. 

In the attachment below, the top panel represents the horizontal profile and the bottom one represents the vertical profile.

The blue curves overlaid on the plot are fitted Gaussian profile, showing beautiful agreements with the measured profile.

Attachment 1: 2010-6-7_2.png
2010-6-7_2.png
  2915   Wed May 12 02:35:13 2010 Koji, Rana, KiwamuUpdateGreen LockingReflection from ETM and ITM !

We succeeded in getting the reflected green beam from both ITMY and ETMY.

After we did several things on the end table, we eventually could observe these reflections.

Now the spot size of the reflection from ITMY is still big ( more than 1 cm ), so tomorrow modematching to the 40m cavity is going to be improved by putting mode matching telescopes on right positions.

An important thing we found is that, the beam height of optics which directly guides the beam to the cavity should be 4.5 inch on the end table.

 


(what we did)

* Aidan, Kevin and Kiwamu set the beam to be linearly polarized by rotating a QWP in front of the Innolight. This was done by monitoring the power of the transmitted light from the polarizer attached on the input of the Faraday of 1064 nm. Note that the angle for QWP is 326.4 deg.

* We put some beam damps against the rejected beam from the Faraday

* To get a good isolation with the Faraday we at first rotated the polarization of the incident beam so to have a minimum transmission. And then we rotated the output polarizer until the transmission reaches a minimum. Eventually we got the transmission of less than 1mW, so now the Faraday should be working regardless of the polarization angle of the incident beam. As we predicted, the output polaerizer seems to be rotated 45 deg from that of the input.

* Rana, Koji and Kiwamu aligned the PPKTP crystal to maximize the power of 532 nm.  Now the incident power of 1064 nm is adjusted to 250mW and the output power for 532 nm is 0.77mW. Actually we can increase the laser power by rotating a HWP in front of the Faraday.

* We injected the green beam to the chamber and aligned the beam axis to the ETMY without the modematching lenses, while exciting the horizontal motion of the ETM with f=1Hz from awg. This excitation was very helpful because we could figure out which spot was the reflection from the ETM.

* Once we made the reflected beam going close to the path of the incident beam, we then put the modematching lenses and aligned the steering mirrors and lenses. At this time we could see the reflected beam was successfully kicked away by the Faraday of 532 nm.

* Koji went to ITMY chamber with a walkie-talkie and looked at the spot position. Then he told Rana and Kiwamu to go a right direction with the steering mirrors. At last we could see a green beam from ITM illuminating the ETM cage.

* We excited the ITMY with f=2Hz vertically and aligned the ITM from medm. Also we recovered a video monitor which was abandoned around ETMY chamber so that we could see the spot on the ETM via the monitor. Seeing that monitor we aligned the ITM and we obtained the reclection from the ITM at the end table.

* We also tried to match the mode by moving a lens with f=400mm, but we couldn't obtain a good spot size.

 

  2290   Wed Nov 18 11:27:33 2009 Koji, josephbConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Quote:

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

 

It appears the front panel for the DAC board is mis-labeled.  Channels 1-8 are in fact 9-16, and 9-16 are the ones labeled 1-8.  We have put on new labels to reduce confusion in the future.

  2291   Wed Nov 18 12:33:30 2009 Koji, josephbConfigurationSUSETMY suspension conencted to megatron ADC/DAC

Hurraaaah!
We've got the damping of the suspension.
The Oplev loops has also worked!

The DAC channnel swapping was the last key!

DataViewer snapshot to show the damping against an artificial excitation was attached

Quote:

Quote:

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

 

It appears the front panel for the DAC board is mis-labeled.  Channels 1-8 are in fact 9-16, and 9-16 are the ones labeled 1-8.  We have put on new labels to reduce confusion in the future.

 

Attachment 1: Untitled.png
Untitled.png
  12640   Wed Nov 23 20:08:51 2016 Koji, ranaUpdateIOOMC WFS Demod/Whitening boards removed from the IOO rack

We removed one set of the MC WFS demod board and whitening board from the IOO rack for the investigation.
The MC WFS servo loops are disabled with the EPICS screens.
Let us know when you need the MC WFS boards to be returned to the rack.


This is to investigate the signal chain and fix some issues. We ramped down the -100 V supply for the WFS QPD bias (why is it so big?), but everything else is still on. Koji is doing demod board. Rana will upload a marked up WFS whitening board schematic soon.

  10162   Wed Jul 9 11:41:12 2014 KoushikUpdatePSLPMC local oscillator is going wonky

Quote:

Koushik replaced an ERA-5 in the PC path. We put the module back to the rack and found no change.
The epics LO level monitor monitor is still fluctuating from 6~11dBm. We need more thorough investigation
by tracing the signals everywhere on the board.

Despite the poor situation of the modulation, PMC was locking (~9PM). Rana suspect that the PMC demodulation
phase was not correctly adjusted long time. 

Koushik has the measured power levels and the photos of the board. I'll ask him to report on them.

 Updates from Koushik:

The power levels measured (before and after relacement of ERA-5) are as follows:

LO to Servo : Vout = 2.3 Vpp / Pout = 11.21 dBm at f = 35.5 MHz

RF to PC   :   Vout = 354 mVpp / Pout = -5.1 dBm at f= 35.5 MHz

The measurements were done using an oscilloscope with 50 ohms load impedance. Unfortunately the photos are not available from the camera.

  14621   Sat May 18 12:19:36 2019 KruthiUpdate CCD calibration and telescope design

I went through all the elog entries related to CCD calibration. I was wondering if we can use Spectralon diffuse reflectance standards (https://www.labsphere.com/labsphere-products-solutions/materials-coatings-2/targets-standards/diffuse-reflectance-standards/diffuse-reflectance-standards/) instead of a white paper as they would be a better approximation to a Lambertian scatterer.

Telescope design:
On calculating the accessible u-v ranges and the % error in magnification (more precisely, %deviation), I got %deviation of order 10 and in some cases of order 100 (attachments 1 to 4), which matches with Pooja's calculations. But I'm not able reproduce Jigyasa's %error calculations where the %error is of order 10^-1. I couldn't find the code that she had used for these calculations and I even mailed her about the same. We can still image with 150-250 mm combination as proposed by Jigyasa, but I don't think it ensures maximum usage of pixel array. Also for this combination the resulting conjugate ratio will be greater than 5. So, use of plano-convex lenses will reduce spherical aberrations. I also explored other focal length combinations such as 250-500 mm and 500-500mm. In these cases, both the lenses will have f-numbers greater than 5. But the conjugate ratios will be less than 5, so biconvex lenses will be a better choice.

Constraints: available lens tube length (max value of d) = 3" ; object distances range (u) = 70 cm to 150 cm ; available cylindrical enclosures (max value of d+v) are 52cm and 20cm long (https://nodus.ligo.caltech.edu:8081/40m/13000).

I calculated the resultant image distance (v) and the required distance between lenses (d), for fixed magnifications (i.e. m = -0.06089 and m = -0.1826 for imaging test masses and beam spot respectively) and different values of 'u'. This way we can ensure that no pixels are wasted. The focal length combinations - 300-300mm (for imaging beam spot), and 100-125mm (for imaging test masses) - were the only combinations that gave all positive values for 'd' and 'v', for given range of 'u' (attachments 5-6). But here 'd' ranges from 0 to 30cm in first case, which exceeds the available lens tube length. Also, in the second case the f-numbers will be less than 5 for 2" lenses and thus may result in spherical aberration.

All this fuss about f-numbers, conjugate ratios, and plano-convex/biconvex lenses is to reduce spherical aberrations. But how much will spherical aberrations affect our readings? 

We have two 2" biconvex lenses of 150mm focal length and one 2" biconvex lens of focal length 250mm in stock. I'll start off with these and once I have a metric to quantify spherical aberrations we can further decide upon lenses to improve the telescopic lens system.

Attachment 1: 15-25.png
15-25.png
Attachment 2: 25-25.png
25-25.png
Attachment 3: 25-50.png
25-50.png
Attachment 4: 50-50.png
50-50.png
Attachment 5: 30-30_for_1%22.png
30-30_for_1%22.png
Attachment 6: 10-12.5_for_3%22.png
10-12.5_for_3%22.png
  14633   Thu May 23 10:18:39 2019 KruthiUpdateCamerasCCD calibration

On Tuesday, I tried reproducing Pooja's measurements (https://nodus.ligo.caltech.edu:8081/40m/13986). The table below shows the values I got. Pictures of LED circuit, schematic and the setup are attached. The powermeter readings fluctuated quite a bit for input volatges (Vcc) > 8V, therefore, I expect a maximum uncertainity of 50µW to be on a safer side. Though the readings at lower input voltages didn't vary much over time (variation < 2µW), I don't know how relaible the Ophir powermeter is at such low power levels. The optical power output of LED was linear for input voltages 10V to 20V. I'll proceed with the CCD calibration soon.

Input Voltage (Vcc) in volts Optical power
0 (dark reading) 1.6 nW
2 55.4 µW
4 215.9 µW
6 0.398 mW
8 0.585 mW
10 0.769 mW
12 0.929 mW
14 1.065 mW
16 1.216 mW
18 1.330 mW
20 1.437 mW
22 1.484 mW
24 1.565 mW
26 1.644 mW
28 1.678 mW

Attachment 1: setup.jpeg
setup.jpeg
Attachment 2: led_circuit.jpeg
led_circuit.jpeg
Attachment 3: led_schematic.pdf
led_schematic.pdf
  14639   Sun May 26 21:47:07 2019 KruthiUpdateCamerasCCD Calibration

 

On Friday, I tried calibrating the CCD with the following setup. Here, I present the expected values of scattered power (Ps) at \thetas = 45°, where \thetas is scattering angle (refer figure). The LED box has a hole with an aperture of 5mm and the LED is placed at approximately 7mm from the hole. Thus the aperture angle is 2*tan-1(2.5/7) ≈ 40° approx. Using this, the spot size of the LED light at a distance 'd' was estimated. The width of the LED holder/stand (approx 4") puts a constraint on the lowest possible \thetas. At this lowest possible \thetas, the distance of CCD/Ophir from the screen is given by \sqrt{d^2 + (2'')^2}. This was taken as the imaging distance for other angles also.

In the table below, Pi is taken to be 1.5mW, and Ps and \Omega were calculated using the following equations:

  \Omega = \frac{CCD \ sensor \ area}{(Imaging \ distance)^2}            P_{s} = \frac{1 }{\pi} * P_{i} *\Omega *cos(45^{\circ})  

d (cm)

Estimated spot diameter (cm)

Lowest possible \thetas  (in degrees)

Distance of CCD/Ophir from the screen (in cm) \Omega (in sr)

Expected Ps at   \thetas = 45° (in µW)

1.0 1.2 78.86 5.2 0.1036 34.98
2.0 2.0 68.51 5.5 0.0259 8.74
3.0 2.7 59.44 5.9 0.0115 3.88
4.0 3.4 51.78 6.5 0.0065 2.19
5.0 4.1 45.45 7.1 0.0041 1.38
6.0 4.9 40.25 7.9 0.0029 0.98
7.0 5.6 35.97 8.6 0.0021 0.71
8.0 6.3 32.42 9.5 0.0016 0.54
9.0 7.1 29.44 10.3 0.0013 0.44
10.0 7.8 26.93 11.2 0.0010 0.34

 

                                 

 

 

 

 

 

 

 

 

 

On measuring the scattered power (Ps) using the ophir power meter, I got values of the same order as that of  expected values given the above table. Like Gautam suggested, we could use a photodiode to detect the scattered power as it will offer us better precision or we could calibrate the power meter using the method mentioned in Johannes's post: https://nodus.ligo.caltech.edu:8081/40m/13391.

 

Attachment 1: CCD_calibration_setup.png
CCD_calibration_setup.png
  14644   Fri May 31 01:38:21 2019 KruthiUpdateCamerasTelescope

[Kruthi, Milind]

Yesterday, we were able to capture some images of objects at a distane of approx 60cm (see the attachment), with the GigE mounted onto the telescope. I think, Johannes had used it earlier to image the ETMX (https://nodus.ligo.caltech.edu:8081/40m/13375). His elog entry doesn't say anything about the focal length of the lenses that he had used. The link to the python code he had used to calculate the lens solution wasn't working. After Gautam fixed it, I took a look at it. He has used 150mm (front lens) and 250mm (back lens) as the focal length of lenses for the calculation. Using the lens formula and an image of a nearby light source, with a very rough measurement, I found the focal lengths to be around 14 cm and 23 cm. So, I'm assuming that the lenses in the telescope are of same focal lengths as in his code, i.e 150mm and 250mm.

Attachment 1: telescope_mug_image.pdf
telescope_mug_image.pdf
  14651   Tue Jun 4 00:11:45 2019 KruthiUpdateCamerasGigE setup

Chub and I are trying to figure out a way to co-mount GigE into the existing cylindrical enclosure. I'm attaching a picture of the current setup that is being used for imaging MC2. As of now, I have thought of 3 possible setups (schematics attached); but I don't know how feasible they are. Let us know if you have any other ideas.


Update: The setup 3 would require us to use the 52cm long enclosure. It has a long breadboard welded to it, which makes it very convienient, but the whole setup becomes quite heavy and it's not that safe to install such heavy enclosure on top of the vaccuum system. Also, aligning its components would be more complicated than other setups.

I decided to start with the simple one, therefore, I tried implementing setup 1. Fitting in the analog camera horizontally alongside the telescope turned out to be tricky. Though I did manage to fit it in, it didn't leave any room to change the orientation of the beamsplitter. Like Koji suggested, I'll be trying the setup 2.

Attachment 1: MC2.pdf
MC2.pdf
Attachment 2: Setup_3.png
Setup_3.png
Attachment 3: Setup_1.png
Setup_1.png
Attachment 4: Setup_2.png
Setup_2.png
  14660   Sun Jun 9 21:24:00 2019 KruthiUpdateCamerasGigE setup

I managed to fit all the parts into the cylindrical enclosure without having to drill a hole in the enclosure to mount the analog camera (pictures attached); thanks to Koji for helping me find some fancy mechanical components (swivel post clamps, right angle post clamps and brackets). On Thursday, with Chub's help, I took a look at all the current analog camera positions with respect to the cylindrical enclosures. I think this setup gives me enough flexibility to align the components, as necessary, to be able to image the test masses/mirrors in all the cavities. I'll set it up for MC2 tomorrow.

 

Attachment 1: GigE_setup.jpg
GigE_setup.jpg
Attachment 2: GigE_setup_top_view.jpg
GigE_setup_top_view.jpg
  14663   Tue Jun 11 00:25:05 2019 KruthiUpdateCamerasGigE setup

[Kruthi, Milind]

Today, with Milind's help, I installed the analog camera into the MC2 enclosure [picture attached]; but it is not yet focused. We replaced the bulky angular bracket with a simple one, this saved a lot of space inside and it's easier to align other components now. I'll finish setting it up tomorrow.


Telescope design for MC2:  Instead of using two 3" long stackable lens tubes (SM2L30), we can use one 3" lens tube with an adjustable lens tube (SM2V10), as shown in the picture. This gives a flexibility to change the focal plane distance by 1" and also reduces the overall length of telescope from 9 inches to 6-7 inches. I decided to use two 150mm biconvex lens instead of a combination of 150mm and 250mm lenses, as the former combination results in lower focal plane distance for a given distance between the lenses.

Specifications of current telescope system (for future reference):

Focal length of lenses used  150mm & 150mm
Distance between the lenses 1cm - 2cm (Wasn't able to make more accurate measurement)

With the above telescope, assuming the MC2 mirror to be at a distance of approx 75cm, the focal plane distance will range from 7.9cm to 8.1cm. Using the adjustable lens tube, we can further make the fine adjustment.

Attachment 1: MC2_analog_setup.jpg
MC2_analog_setup.jpg
Attachment 2: telescope.pdf
telescope.pdf
  14665   Wed Jun 12 02:15:50 2019 KruthiUpdateCamerasGigE setup

[Koji, Kruthi]

Yesterday, Koji helped me clean all the optics that are being used for the setup. We tried aligning the cameras with the previous configuration we had, but after connecting the analog camera cables there wasn't much room to align the beam splitter. Today, I tried a different configuration and tested the alignment of analog camera, GigE, beam splitter and the mirror using a laser beam [pictures attached]. But the MC2 isn't locked to test if the whole setup is actually aligned with the mirror inside the vacuum. 

Also, with this setup, just by using posts of different lengths with the middle 90º-post-clamp, we will be able to move all the components. This way, we can easily image the beam spot in all the cavities.

Attachment 1: MC2_GigE_setup.jpg
MC2_GigE_setup.jpg
  14666   Wed Jun 12 21:55:34 2019 KruthiUpdateCamerasGigE setup

I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked). 

Quote:

[Koji, Kruthi]

Yesterday, Koji helped me clean all the optics that are being used for the setup. We tried aligning the cameras with the previous configuration we had, but after connecting the analog camera cables there wasn't much room to align the beam splitter. Today, I tried a different configuration and tested the alignment of analog camera, GigE, beam splitter and the mirror using a laser beam [pictures attached]. But the MC2 isn't locked to test if the whole setup is actually aligned with the mirror inside the vacuum. 

Also, with this setup, just by using posts of different lengths, we will be able to image the beam spot in all the cavities.

 

Attachment 1: MC2_analog_pic.jpg
MC2_analog_pic.jpg
  14674   Fri Jun 14 00:40:33 2019 KruthiUpdateCamerasGigE setup

Today, I tried aligning it further; I'm attaching a picture of it. We are not able to see all the 4 OSEMs yet. In the reference picture I had taken, before taking off the previous analog setup, the OSEMs are not seen. So, I don't really understand what the other 2 spots seen on the current screen are. Are they actually OSEMs?

I need a laptop next to MC2, so that I can have a look at it and make further alignments. So, I tried accessing the GigE attached to the telescope using Paola. The pylon app in it, throws an error, few seconds after running it in continuous shot mode, and disconnects the GigE; everything works fine on Rossa though. I'll put up further details soon.

Quote:

don't need to lock - make sure the 4 OSEMs are centered on the camera field just as we have for the arm cavity mirrors

Quote:

I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked). 

 

 

Attachment 1: Reference_image_taken_with_previous_analog_camera_setup.jpeg
Reference_image_taken_with_previous_analog_camera_setup.jpeg
Attachment 2: MC2_image.JPG
MC2_image.JPG
  14676   Sat Jun 15 00:03:26 2019 KruthiUpdateCamerasGigE setup

The analog camera is aligned and we are able to see all the 4 OSEMs (pictures attached). Due to secondary reflection from the beamspiltter (BS1-1064-33-2037-45S), when the MC2 is locked, we are getting a ghost image of the beam spot along with the primary image. 


The pylon app in Paola was reporting an error saying "0xE1000014: The buffer was incompletely grabbed". I followed the instructions given in this site, and changed the 'Packet Size' to 1500 and 'Inter-Packet Delay parameter' to a value greater than 20,000 (µs). This did the trick and I was able to use the continuous shot mode without any interruption. I'm attaching a picture of MC2 that I captured using GigE.

Quote:

Today, I tried aligning it further; I'm attaching a picture of it. We are not able to see all the 4 OSEMs yet. In the reference picture I had taken, before taking off the previous analog setup, the OSEMs are not seen. So, I don't really understand what the other 2 spots seen on the current screen are. Are they actually OSEMs?

I need a laptop next to MC2, so that I can have a look at it and make further alignments. So, I tried accessing the GigE attached to the telescope using Paola. The pylon app in it, throws an error, few seconds after running it in continuous shot mode, and disconnects the GigE; everything works fine on Rossa though. I'll put up further details soon.

Quote:

don't need to lock - make sure the 4 OSEMs are centered on the camera field just as we have for the arm cavity mirrors

Quote:

I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked). 

 

 

 

Attachment 1: mc2_GigE.pdf
mc2_GigE.pdf
Attachment 2: MC2_analog.jpeg
MC2_analog.jpeg
Attachment 3: MC2_analog_OSEMs.jpeg
MC2_analog_OSEMs.jpeg
  14692   Mon Jun 24 13:48:36 2019 KruthiConfigurationCDSGiada wireless connection

[Gautam, Kruthi]

This afternoon, Gautam helped me setup Giada to access the GigE installed for MC2. Unlike Paola, which was being used earlier, Giada has a better battery life and doesn't shutdown when the charger is unplugged. Gautam configured Giada to enable its wireless connection to Martian, just like Koji had configured Paola (https://nodus.ligo.caltech.edu:8081/40m/14672). We also rerouted  the ethernet cable we were using with the PoE adaptor from Netgear Switch in 1x2 to 1x6.

  14695   Tue Jun 25 11:54:47 2019 KruthiUpdateCamerasGigE

Turns out, focusing the GigE is actually a bit tricky. With pylon, everytime I change the exposure or the focus, I'm running into the error I had mentioned earlier in one of my elogs; so I tried using the python scripts to interact with the GigE. But whenever I try to change the focal plane distance by rotating the lens coupler, the ethernet cable connection becomes loose and the camera server needs to be relaunched every now and then. Also, everytime we want to change the distance between the lenses, the telescope needs to be dismantled and refocused again. I'll try to come up with a better telescope design for this.

Yesterday, I had focused the GigE using a low exposure time and small aperture of iris, to make sure that we are actually seeing a sharp image of the beam spot. I'm attaching a picture of the beam spot I had clicked while focusing it, unfortunately, I forgot to take a picture after I had focused it completely. I'm also attaching a picture of the final setup for future reference. 


Yesterday night, Rana asked me to lock the MC2. I figured that the PSL shutter was closed; I just opened it and was able to see the beam spot on the analog camera screen.

 

Attachment 1: MC2_GigE.pdf
MC2_GigE.pdf
Attachment 2: Cameras_final_setup.JPG
Cameras_final_setup.JPG
  14702   Wed Jun 26 19:12:00 2019 KruthiUpdateCamerasGigE

The GigE is focused now (judged by eye) and I have closed the lid. I'm attaching a picture of the MC2 beam spot, captured using GigE at an exposure time of 400µs.

What was the solution to resolving the flaky video streaming during the alignment process????

-> I think, the issue was with either the poor wireless network conection or the GigE-PoE ethernet cable.

Quote:

Turns out, focusing the GigE is actually a bit tricky. With pylon, everytime I change the exposure or the focus, I'm running into the error I had mentioned earlier in one of my elogs; so I tried using the python scripts to interact with the GigE. But whenever I try to change the focal plane distance by rotating the lens coupler, the ethernet cable connection becomes loose and the camera server needs to be relaunched every now and then. Also, everytime we want to change the distance between the lenses, the telescope needs to be dismantled and refocused again. I'll try to come up with a better telescope design for this.

Yesterday, I had focused the GigE using a low exposure time and small aperture of iris, to make sure that we are actually seeing a sharp image of the beam spot. I'm attaching a picture of the beam spot I had clicked while focusing it, unfortunately, I forgot to take a picture after I had focused it completely. I'm also attaching a picture of the final setup for future reference. 


Yesterday night, Rana asked me to lock the MC2. I figured that the PSL shutter was closed; I just opened it and was able to see the beam spot on the analog camera screen.

Attachment 1: MC2_GigE_image.pdf
MC2_GigE_image.pdf
  14708   Sat Jun 29 03:11:18 2019 KruthiUpdateCamerasCCD Calibration

Finding the gain of the Photodiode: The three-position rotary switch of the photodiode being used (PDA520) wasn't working, so I determined its gain by making a comparative measurement between ophir power meter and the photodiode. The photodiode has a responsitivity of 0.34 A/W at 1064 nm (obtained from the responsitivity curve given in the spec sheet using a curve digitizing software). Using the following equation, I determined the gain setting, which turned out to be 20dB.

\large Transimpedance\ Gain (V/A) = \frac{Photodiode\ reading (V)}{Ophir\ reading (W) * Responsitivity (A/W)}

Setup: Here a 1050nm (closest we have to 1064nm) LED is used as the light source instead of a laser to eliminate the effects caused by coherence of a laser source, which might affect our radiometric calibration. The LED is placed in a box with a hole of diameter 5mm (aperture angle = 40 degrees approx.). Suitable lenses are used to focus the light onto a white paper, which is fixed at an arbitrary angle and serves as a Lambertian scatterer. To make a comparative measurement between the photodiode (PDA520) and GigE, we need to account for their different sensor areas, 8.8mm (aperture diameter) and 3.7mm x 2.8 mm respectively . This can be done by either using an iris with a common aperture so that both the photodiode and GigE receive same amount of light , or by calculating the power incident on GigE using the ratio of sensor areas and power incident on the photodiode (here we are using the fact that power scattered by Lambertian scatterer per unit solid angle is constant). 

Calibration of GigE 152 unit: I took around 50 images, starting with an exposure time of 2000 \LARGE \mu s in steps of 2000, using the exposure_variation.py code. But the code doesn't allow us to take images with an exposure time greater than 100 ms, so I took few more images at higher exposures manually. From each image I subtracted a dark image (not in the sense of usual CCD calibration, but just an image with same exposure time and no LED light). These dark images do the job of usual dark frame + bias frame and also account for stray lights. A plot of pixel sum vs exposure time is attached. From a linear fit for the unsaturated region, I obtained the slope and calculated the calibration factor.

Equations:      \LARGE Power (P)=\frac{Photodiode\ reading(V)}{Transimpedance\ gain (V/W) * Responsivity (A/W)}                    \LARGE Calibration factor (CF) = \frac{P}{slope}

Result: CF = 1.91x 10^-16 W-sec/counts  Update: I had used a wrong value for the area of photodiode. On using 61.36 mm^2 as the area, I got 2.04 x 10^-15 W-sec/counts.

I'll put the uncertainities soon. I'm also attaching the GigE spectral response curve for future reference.

Attachment 1: calibration_setup.jpg
calibration_setup.jpg
Attachment 2: CCD_calibration_2.jpeg
CCD_calibration_2.jpeg
Attachment 3: GigE_spectral_response_curve.png
GigE_spectral_response_curve.png
Attachment 4: 152_calibration_plot.png
152_calibration_plot.png
  14732   Sun Jul 7 21:59:28 2019 KruthiUpdateCamerasGhost image due to beamsplitter

The beam splitter (BS1-1064-33-2037-45S) that is currently being used has an antireflection coating on the second surface and a wedge of less than 5 arcmin; yet it leads to ghosting as shown in the figure attached (courtesy: Thorlabs). I'm also attaching its spec sheet I dug up on internet for future reference.

I came across pellicle beamsplitters, that are primarily used to eliminate ghost images. Pellicle beamsplitters have a few microns thick nitrocellulose layer and superimpose the secondary reflection on the first one. Thus the ghost image is eliminated. 

Should we go ahead and order them? (https://www.thorlabs.com/newgrouppage9.cfm?objectgroup_id=898

https://www.edmundoptics.eu/c/beamsplitters/622/#28438=28438_s%3AUGVsbGljbGU1&27614=27614_d%3A%5B46.18%20TO%2077.73%5D)

Attachment 1: ghosting_schematic.png
ghosting_schematic.png
Attachment 2: Beamsplitter_spec.pdf
Beamsplitter_spec.pdf Beamsplitter_spec.pdf
  14733   Mon Jul 8 17:33:10 2019 KruthiUpdateLoss MeasurementOptical scattering measurements

I came across a paper (see reference) where they have used DAOPHOT, an astronomical software tool developed by NOAO, to study the point scatterers in LIGO test masses using images of varying exposure times. I'm going through the paper now. I think using this we can analyze the MC2 images and make some interesting observations.

Reference:  L.Glover et al., Optical scattering measurements and implications on thermal noise in Gravitational Wave detectors test-mass coatings Physics Letters A. 382. (2018)

  14752   Thu Jul 11 16:22:54 2019 KruthiUpdateGeneralProjector lightbulb blown out

I heard a popping sound in the control room; the projector lightbulb has blown out.sad

  14757   Sun Jul 14 00:24:29 2019 KruthiUpdateCamerasCCD Calibration

On Friday, I took images for different power outputs of LED. I calculated the calibration factor as explained in my previous elog (plots attached).

Vcc (V) Photodiode
reading(V)

Power incident on photodiode (W)

Power incident on GigE (W)
Slope (counts/​𝝁s)
Uncertainity in
 slope (counts/​𝝁s)
CF (W-sec/counts)
16 0.784 2.31E-06 3.89E-07 180.4029 1.02882 2.16E-15
18 0.854 2.51E-06 4.24E-07 207.7314 0.7656 2.04E-15
20 0.92 2.71E-06 4.57E-07 209.8902 1.358 2.18E-15
22 0.969 2.85E-06 4.81E-07 222.3862 1.456 2.16E-15
25 1.026 3.02E-06 5.09E-07 235.2349 1.53118 2.17E-15
  Average  2.14E-15

To estimate the uncertainity, I assumed an error of at most 20mV (due to stray lights or difference in orientation of GigE and photodiode) for the photodiode reading. Using the uncertainity in slope from the linear fit, I expect an uncertainity of maximum 4%. Note: I haven't accounted for the error in the responsivity value of the photodiode.

GigE area 10.36 sq.mm
PDA area 61.364 sq.mm
Responsivity 0.34 A/W
Transimpedance gain (at gain = 20dB) 10^6 V/W +/- 0.1%
Pixel format used Mono 8 bit

Johannes had reported CF as 0.0858E-15 W-sec/counts for 12 bit images, with measured a laser source. This value and the one I got are off by a factor of 25. Difference in the pixel formats and effect of coherence of the light used might be the possible reasons.

Attachment 1: CCD_calibration.png
CCD_calibration.png
  14758   Mon Jul 15 03:15:24 2019 KruthiUpdateLoss MeasurementImaging scatterometer

On Friday, Koji helped me find various components required for the scatterometer setup. Like he suggested, I'll first set it up on the SP table and try it out with an usual mirror. Later on, once I know it's working, I'll move the setup to the flow bench near the south arm and measure the BRDF of a spare end test mass.

  14759   Mon Jul 15 03:30:47 2019 KruthiUpdateCalibration-RepairWhite paper as a Lambertian scatterer

I made some rough measurements, using the setup I had used for CCD calibration, to get an idea of how good of a Lambertian scatterer the white paper is. Following are the values I got:

Angle (degrees) Photodiode reading (V)  Ps (W) BRDF (per str) % error
12 0.864 2.54E-06 0.334 20.5
24 0.926 2.72E-06 0.439 19.0
30 1.581 4.65E-06 0.528 19.0
41 0.94 2.76E-06 0.473 19.8
49 0.545 1.60E-06 0.423 22.5
63 0.371 1.09E-06 0.475 28

Note: All the measurements are just rough ones and are prone to larger errors than estimated.

I also measured the transmittance of the white paper sample being used (it consists of 2 white papers wrapped together). It was around 0.002

Attachment 1: BRDF_paper.png
BRDF_paper.png
  14766   Wed Jul 17 03:05:01 2019 KruthiUpdateASSMC spot position measurement scripts

[Kruthi, Gautam, Rana]

Gautam installed Atom text editor on Pianosa yesterday.


MC spot position measurement scripts (these can be found in /scripts/ASS/MC directory)

  • Changed the power threshold for MC2 lock loss check from 15000 to 12000 (volts) in the MeasureSpotPositions.py script. This is because, the C1:I00-MC_TRANS_SUM reads a value, usually, greater than 14000 and with 15000 as the threshold, the script will always say the MC isn't locked even though it is!. Also, to account for additional variation we have a margin of 2000.
  • Issues with datetime: though MeasureSpotPositions.py was creating a .dat file, MC_spotMeasurement_history.py threw an error because the .dat file's name was not in the required format. I fixed this bug.
  • Just running the MeasureSpotPositions.py doesn't enter the results into the log file, instead ./mcassMCdecenter should be run
  • MC_spotMeasurement_history.py just plots the spot positions (in mm) vs days since 2013, using the log file. It still has some bugs
  14768   Wed Jul 17 20:12:26 2019 KruthiUpdateCamerasAnother GigE in place of analog camera

I've taken the MC2 analog camera down and put another GigE (unit 151) in its place. This is just temporary and I'll put the analog camera back once I finish the MC2 loss map calibration. I'm using a 25mm focal length camera lens with it and it gives a view of MC2 similar to the analog camera one. But I don't think it is completely focused yet (pictures attached).

...more to follow

gautam - Attachment #3 is my (sad) attempt at finding some point scatterers - Kruthi is going to play around with photUtils to figure out the average size of some point scatterers.

Attachment 1: zoomed_out_gige.png
zoomed_out_gige.png
Attachment 2: osems_mc2.png
osems_mc2.png
Attachment 3: MC2.pdf
MC2.pdf
  14774   Thu Jul 18 22:03:00 2019 KruthiUpdateCamerasMC2 and cameras

[Kruthi, Yehonathan, Gautam]

Today evening, Yehonathan and I aligned the MC2 cameras. As of now there are 2 GigEs in the MC2 enclosure. For the temporary GigE (which is the analog camera's place), we are using an ethernet cable connection from the Netgear switch in 1x6. The MC2 was misaligned and the autolocker wasn't able to lock the mode cleaner. So, Gautam disabled the autolocker and manually changed the settings; the autolocker was able to take over eventually.

  14782   Fri Jul 19 22:48:08 2019 KruthiUpdate Dataviewer error

I'm not able to get trends of the TM adjustment test that Rana had asked us to perform, from the dataviewer. It's throwing the following error:

Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
Server error 7: connect() failed
datasrv: DataWrite failed: daq_send: Resource temporarily unavailable
T0=19-07-20-01-27-39; Length=600 (s)
No data output.

  14788   Sun Jul 21 02:07:04 2019 KruthiUpdateLoss MeasurementMC2 loss map

I'm running the MC2 loss map scripts on pianosa now. The camera server is throwing an error and is not grabbing snapshots :(

Update: I finished taking the readings for MC2 loss map. I couldn't get the snapshots with the script, so I manually took some 4-5 pictures.

  14791   Sun Jul 21 17:17:03 2019 KruthiUpdateLoss MeasurementMC2 loss map

The camera server keeps throwing the error: failed to grab frames. Milind suggested that it might a problem with the ethernet cable, so I even unplugged it and connected it again; it still had the same issue. One more thing I noticed was, it does take snapshots sometimes with the terminal command caput C1:CAM-ETMX_SNAP 1, but produces a segmentation fault when ezca.Ezca().write(C1:CAM-ETMX_SNAP, 1) ezca.Ezca().write(CAM-ETMX_SNAP, 1) is used via ipython. When the terminal command also fails to take snapshots, I noticed that the SNAP button on the GigE medm screen remains on and doesn't switch back to OFF like it is supposed to.

Quote:

Can you please be more specific about what the error is? Is this the usual instability with the camera server code? Or was it something new?

Quote:

The camera server is throwing an error and is not grabbing snapshots :(

ELOG V3.1.3-