40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 190 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  1423   Tue Mar 24 19:55:24 2009 JenneUpdateLSCNew PO DC

[Rana, Jamie, Jenne]

SPOB DC hasn't been so good lately, so we installed a new PO DC PD on the PO table.  We used a 30% reflecting beam splitter (BS1-1064-30-1025-someotherstuff).  We didn't check with a power meter that it's a 30% BS, but it seems like that's about right.  The beamsplitter is as close as we could get to the shutter immediately in front of the regular POB/SPOB PD's, since that's where the beam gets narrow.   The new picked-off-pickoff beam goes to a Thorlabs 100A PD.  We haven't yet checked for reflected beams off the PD,  but there is a spare razor blade beam dump on the table which can be used for this purpose.  The output of this PD goes to the LSC rack via a BNC cable.  (This BNC cable was appropriated from it's previous "use" connecting a photodiode from the AP table to a bit of air just next to the LSC rack.)  Our new cable is now connected where the old SPOB DC cable used to be, at the input of a crazy Pomona Box tee.

For reference, the new levels of POB DC and SPOB DC, as measured by their BNC DC out connections is ~4mV each.  Since the beamsplitter is 70% transmissive, we used to be getting about 5.7mV on each PD.

The new photodiode puts out about 40mV, but it has an ND1.0 filter on, so if more gain is needed, we can take it off to get more volts.

 

  1424   Tue Mar 24 23:23:05 2009 ranaUpdateLSCNew PO DC
We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other
input of the splitter was open (not terminated). Using 50m Ohm devices without terminated inputs is illegal. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
the splitter and ran the cable straight. So expect some change in the SPOB gain and phase plus some shame.
  1456   Mon Apr 6 21:50:43 2009 ranaUpdateLSCArm Locking via pushing MC2
Inspired by our 'No Refcav' scheme here, I was inspired to re-explore the idea of locking the
CARM DOF using only feedback to the MC/laser. Last week I got this to work on the single arm and
full IFO at Livingston.
I also estimate the MC noise there.

Today I found the settings to allow X-arm locking here without any feedback to the ETM or ITM:

- Set the LSC Output Matrix to feed the XARM signal to MC2.
- Turn OFF the input of the LSC-ETMX filter bank (this does not disable tickling).
- Turn OFF FM7 (0.1:10) in MC2-MCL.
- Turn ON MC2-LSC with a gain of 0.2 and FM3 FM4 FM5.

That's enough to lock the arm - its pretty stable. This also assumes that the LSC-MC2 bank has its nominal gain of -0.178.

To determine the gain of +0.2 in the MC2-LSC filter bank, I measured the TF from MC2->PD3_I and from ETMX->PD3_I. I adjusted
the gain to be equal at 150 Hz for acquisition and the sign to be opposite to account for the (-) in LSC-MC2. The TF is
attached.

After locking, I type a zero into the MC2-MCL filter bank and that shuts off the feedback from the MC servo to MC2. This is
now topologically similar to the standard CM servo configuration.

The second attachment has the trends of this locking. You can see that the MC_F goes off into the weeds, but the MCL signal
does not so much. I think maybe the MC length is drifting a lot - not the arm.

The third attachment shows the spectra.
Attachment 1: mc2-xarm.pdf
mc2-xarm.pdf
Attachment 2: Untitled.png
Untitled.png
Attachment 3: nohands.pdf
nohands.pdf
  1549   Tue May 5 14:02:16 2009 robUpdateLSCDARM DC response varies with DARM offset

Note the effect of quadrature rotation for small offsets.

Attachment 1: DARM_DARM_AS_DC_2.png
DARM_DARM_AS_DC_2.png
Attachment 2: DARM_DARM_AS_DC_3.png
DARM_DARM_AS_DC_3.png
Attachment 3: DARM_DARM_AS_DC_2.pdf
DARM_DARM_AS_DC_2.pdf
Attachment 4: DARM_DARM_AS_DC_3.pdf
DARM_DARM_AS_DC_3.pdf
  1575   Tue May 12 01:11:55 2009 YoichiUpdateLSCDARM response (DC Readout)
I measured the DARM response with DC readout.

This time, I first measured the open loop transfer function of the X single arm lock.
The open loop gain (Gx) can be represented as a product of the optical gain (Cx), the filter (Fx), and the suspension response (S), i.e. Gx = Cx*Fx*S.
We know Fx because this is the transfer function of the digital filters. Cx can be modeled as a simple cavity pole, but we need to know the finesse to calculate it.
In order to estimate the current finesse of the XARM cavity, I ran the armLoss script, which measures the ratio of the reflected light power between the locked and the unlocked state. Using this ratio and the designed transmissivity of the ITMX (0.005), I estimated the round trip loss in the XARM, which was 170 ppm. From this number, the cavity pole was estimated to be 1608Hz.
Using the measured Gx, the knowledge of Fx and the estimated Cx, I estimated the ETMX suspension response S, which is shown in the first attachment.
Note that this is not a pure suspension response. It includes the effects of the digital system time delay, the anti-imaging and anti-aliasing filters and so on.

Now the DARM open loop gain (Gd) can also be represented as a product of the optical gain (Cd), the filter (Fd) and the suspension response (S).
Since the actuations are applied again to the ETMs and we think ETMX and ETMY are quite similar, we should be able to use the same suspension response as XARM for DARM. Therefore, using the knowledge of the digital filter shape and the measured open loop gain, we can compute the DARM optical gain Cd.
The second attachment shows the estimated DARM response along with an Optickle prediction.
The DARM loop gain was measured with darm_offset_dc = 350. Since we haven't calibrated the DARM signal, I don't know how many meters of offset does this number correspond to. The Optickle prediction was calculated using a 20pm DARM offset. I chose this to make the prediction look similar to the measured one, though they look quite different around the RSE peak. The input power was set to 1.7W in the Optickle model (again this is just my guess).

It looks as if the measured DARM response is skewed by an extra low pass filter at high frequencies. I don't know why is it so.
Attachment 1: SUS_Resp.png
SUS_Resp.png
Attachment 2: DARM_Resp.png
DARM_Resp.png
  1576   Tue May 12 01:22:51 2009 YoichiUpdateLSCArm loss
Using the armLoss script (/cvs/cds/caltech/scripts/LSC/armLoss), I measured the round trip loss (RTL) of the arms.

The results are:
XARM: RTL= 171 (+/-2) ppm
YARM: RTL = 181 (+/-2) ppm

To get the results above, I assumed that the transmissivity of the ITMs are the same as the designed value (0.005).
This may not be true though.
  1577   Tue May 12 15:22:09 2009 YoichiUpdateLSCArm Finesse

Quote:

It looks as if the measured DARM response is skewed by an extra low pass filter at high frequencies. I don't know why is it so.


One large uncertainty in the above estimate is the cavity pole of X-arm because I simply assumed that the ITMX reflectivity to be the designed value.
I think we can directly measure the X-arm finesse from Alberto's absolute length measurements (i.e. from the width of the resonant peaks in his scans).
By looking at Alberto and Koji's posts (elog:1244 elog:838), it looks like the FWHM of the peaks are around 3kHz. With the FSR ~ 3.8MHz, it gives a finesse of about 1300, which is reasonable.
Alberto, can you check your data and measure the FWHM more precisely ?
Note that we want to measure the FWHM of the peak in the *power* of the beat signal. The beat amplitude is proportional to the electric field *amplitude* of the transmitted auxiliary laser. What we need to get a finesse is the FWHM of the transmitted laser *power*. Thus we need to take the power of the beat signal.
  1591   Fri May 15 17:30:00 2009 robUpdateLSCarms, coils, locks

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

Attachment 1: armslock_no_int.png
armslock_no_int.png
  1592   Sat May 16 16:20:33 2009 robUpdateLSCarms, coils, locks, #2

Quote:

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

 There appear to be at least two independent problems: the coil balancing for ETMY is bad, and something about ITMX is broken (maybe a coil driver). 

The Y-arm becomes significantly misaligned during long locks, causing the arm power to drop.  This misalignment tracks directly with the DC drive on ETMY.  Power returns to the maximum after breaking and re-establishing lock.

ITMX alignment wanders around sporadically, as indicated by the oplevs and the X-arm transmitted power.  Power returns to previous value (not max) after breaking and re-establishing lock.

Both loops have integrators.

Attachment 1: twoproblems.png
twoproblems.png
Attachment 2: coil_imbalanceETMY.png
coil_imbalanceETMY.png
Attachment 3: ITMXalignment.png
ITMXalignment.png
  1650   Thu Jun 4 01:32:20 2009 robConfigurationLSCAS port mode scan

Here is a set of mode scans of the AS port, using the OMC as a mode scanner.  The plot overlays various configurations of the IFO.  

To remove PZT nonlinearity, each scan was individually flattened in fsr-space by polynomial (3rd order) fitting to some known peak locations (the carrier and RF sidebands).
 

Attachment 1: modes.png
modes.png
  1661   Mon Jun 8 18:22:27 2009 AlbertoDAQLSCAdded PD11 I amd Q slow channels

I just added two slow channels to C0EDCUEPICS to monitor the input of PD11. The names are:

[C1:LSC-PD11_I_INMON]
[C1:LSC-PD11_Q_INMON]

  1667   Thu Jun 11 03:15:15 2009 AlbertoUpdateLSCDD Handoff attempts

Pete, Alberto,

tonight we worked on the tuning of the double demod phases for the handoff of the short DOFs control signals.

Only MICH can now undergo the handoff. PRC can't make it.

Basically, we tuned the PD6 demod phase and reduced the offset in PD6_I. Then we tuned the relative gain of PD6_I and PD2_I so that the two open loop transfer function of the control loops would match. We tried that in several ways and several times but without success.

I guess we're missing to do/check something.

  1669   Thu Jun 11 22:14:10 2009 AlbertoUpdateLSCDD Handoff for the Short DOFs completed

This afternoon I tuned the handoff script for the SRC, after that Rob eralier during the day had already adjusted that for PRC. To do that, I followed the procedure in the Wiki.

  • I measured the OL transfer function of the single demod path and of the double demod path and tuned thier gains so that they matched
  • I tuned the double demod pahses of PD_7 and PD_8 in order to reduce the offset in the PD_x_I signals

After that the SRC could get locked with the double demod signals. the open loop transfer function emasurement on the PRC loop showed that it was nearly unstable. Rob reduced a little its gain to improve the stability.

The DD handoff is now working and we can get back to locking the interferometer.

  1685   Thu Jun 18 23:20:40 2009 robSummaryLSCI-Q ratio with RF detected DARM

This is a ratio of PD1_I to PD1_Q (so a ratio of the two quadratures of AS166), measured in an anti-spring state.  It's not flat because our set up has single sideband RF heterodyne detection, and using a single RF sideband as a local oscillator allows one to detect different quadratures by using different RF demodulation phases.   So the variation in frequency is actually a measure of how the frequency response of DARM changes when you vary the detection quadrature.  This measure is imperfect because it doesn't account for the effect of the DARM loop.

Even though you can choose your detection quadrature with this setup, you can't get squeezed quantum noise with a single RF sideband.  The quantum noise around the other (zero-amplitude) RF sideband still gets mixed in, and negates any squeezing benefits.

Attachment 1: IQratio.jpg
IQratio.jpg
  1878   Mon Aug 10 17:27:47 2009 robConfigurationLSCTRX, TRY gain

 

These are the settings which determine the transmon (eg, TRX) amplitude, and which are updated by the matchTransMon scripts.

For the X arm

 

op440m:AutoDither>tdsread C1:LSC-TRX_GAIN C1:LSC-LA_PARAM_FLT_01 C1:LSC-LA_PARAM_FLT_00
0.0023
0.155
119.775

 

For the Y arm

op440m:AutoDither>tdsread C1:LSC-TRY_GAIN C1:LSC-LA_PARAM_FLT_04 C1:LSC-LA_PARAM_FLT_03
0.00237196
-0.116
19.9809


  1929   Wed Aug 19 18:02:22 2009 JenneUpdateLSCRF PDs aligned

All of the LSC RF PDs have been aligned.  I didn't really change much of anything, since for all of them, the beam was already pretty close to center.  But they all got the treatment of attaching a Voltmeter to the DC out, and adjusting the steering mirror in both pitch and yaw, finding where you fall off the PD in each direction, and then leave the optic in the middle of the two 'edges'.

Before aligning each set (PO, Refl, AS), I followed the procedure in Rob's new RF photodiode Wiki Page

Also, for superstitious reasons, and in case I actually bumped them, I squished all of the ribbon cable connectors into the PDs, just in case.

  1966   Thu Sep 3 23:41:32 2009 AlbertoConfigurationLSCPOX (PD3) aligned

Today I aligned the beam to PD3 (POX) since Steve had moved it.

The DC power read 1.3mV when the beam was on the PD.

  1999   Thu Sep 24 20:17:05 2009 ranaSummaryLSCComparison of Material Properties for the new RFPD Mounts
  Steel Brass Aluminum Delrin
Density (kg/m^3) 7850 8500 2700 1420
CTE (ppm/C) 12 19 23 100

Young's

Modulus

(GPa)

200 110 69 2
Hardness        
Color grey gold light silver any

 

  2016   Tue Sep 29 01:50:10 2009 robConfigurationLSCnew modulation frequencies

Mode cleaner length measured tonight.

 

33196198

132784792

165980990

199177188

[Tag by KA: modulation frequency, MC length]

  2101   Fri Oct 16 03:16:50 2009 rana, robSummaryLSCfunny timing setup on the LSC

While measuring the Piezo Jena noise tonight we noticed that the LSC timing is setup strangely.

Instead of using the Fiber Optic Sander Liu Timing board, we are just using a long 4-pin LEMO cable which comes from somewhere in the cable tray. This is apparent in the rack pictures (1X3) that Kiwamu has recently posted in the Electronics Wiki. I think all of our front ends are supposed to use the fiber card for this. I will ask Jay and Alex what the deal is here - seems like to me that this can be a cause for timing noise on the LSC.

We should be able to diagnose timing noise between the OMC and the LSC by putting in a signal in the OMC and looking at the signal on the LSC side. Should be a matlab script that we can run whenever we are suspicious of this. This is an excellent task for a new visiting grad student to help learn how to debug the digital control system.

Attachment 1: 1X3_1.JPG
1X3_1.JPG
  2104   Fri Oct 16 13:25:18 2009 KojiSummaryLSCfunny timing setup on the LSC

Could be this.

http://ilog.ligo-la.caltech.edu/ilog/pub/ilog.cgi?group=detector&task=view&date_to_view=10/02/2009&anchor_to_scroll_to=2009:10:02:13:33:49-waldman

Quote:

We should be able to diagnose timing noise between the OMC and the LSC by putting in a signal in the OMC and looking at the signal on the LSC side. Should be a matlab script that we can run whenever we are suspicious of this. This is an excellent task for a new visiting grad student to help learn how to debug the digital control system.

 

  2111   Sun Oct 18 22:05:40 2009 kiwamuUpdateLSCLSC timing issue

Today I made a measurement to research the LSC timitng issue as mentioned on Oct.16th.

*method

I put the triangular-wave into the OMC side (OMC-LSC_DRIVER_EXT) by AWG,

then looked at the transferred same signal at the LSC side (LSC_DARM_IN1) by using tdsdata.

I have compared these two signals in time domain to check whether they are the same or not.

In the ideal case it is expected that they are exactly the same.

 

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

Attachment 1: rough.png
rough.png
Attachment 2: detail.png
detail.png
  2113   Sun Oct 18 23:02:03 2009 KojiUpdateLSCLSC timing issue

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

Quote:

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

 

  2114   Mon Oct 19 10:00:52 2009 kiwamuUpdateLSCRE: LSC timing issue

Of course I know there is a downconversion in OMC signal from 32k to 16k.

But I was just wondering if the delay comes from only downconversion.

And I can not find any significant noise in both signals because I use the triangular, which cause the higer harmonics and can hide the timing noise in frequency domain.

So I'm going to make the same measurement by using sinusoidal instead of triangular, then can see the noise in frequency domain.

 

Quote:

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

Quote:

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

 

 

  2122   Mon Oct 19 23:14:32 2009 kiwamuUpdateLSCLSC timing issue

I measured the noise spectrum of LSC_DARM_IN1 and OMC-LSC_DRIVE_EXC by using DTT,

while injecting the sin-wave into the OMC-LSC_DRIVE by AWG.

The attached are the results.

No significant differences appears between OMC and LSC in this measurement.

It means, in this measurement we can not figure out any timing noise which might be in LSC-clock.

In addition there are the noise floor, whose level does not change in each 3-figures. The level is about ~4*10^{-8} count/sqrt[Hz]

(The source of the noise floor is still under research.)

Attachment 1: SPE20Hz.png
SPE20Hz.png
Attachment 2: SPE200Hz.png
SPE200Hz.png
Attachment 3: SPE2kHz.png
SPE2kHz.png
  2126   Tue Oct 20 16:35:24 2009 robConfigurationLSC33MHz Mod depth

The 33MHz mod depth is now controlled by the OMC (C1:OMC-SPARE_DAC_CH_15).  The setting to give us the same modulation depth as before is 14000 (in the offset field).

  2145   Mon Oct 26 18:49:18 2009 kiwamuUpdateLSCOMC-LSC timing issue

According to my measurements I conclude that LSC-signal is retarded from OMC-signal with the constant retarded time of 92usec.
It means there are no timing jitter between them. Only a constant time-delay exists.

(Timing jitter)
Let's begin with basics.
If you measure the same signal at OMC-side and LSC-side, they can have some time delay between them. It can be described as followers.

exp1.png
where tau_0 is the time delay. If the tau_0 is not constant, it causes a noise of the timing jitter.

(method)
I have injected the sine-wave with 200.03Hz into the OMC-LSC_DRIVE_EXC. Then by using get_data, I measured the signal at 'OMC-LSC_DRIVE_OUT' and 'LSC-DARM_ERR' where the exciting signal comes out.
In the ideal case the two signals are completely identical.
In order to find the delay, I calculated the difference in these signals based on the method described by Waldman. The method uses the following expression.
exp2.png
Here the tau_s is the artificial delay, which can be adjusted in the off line data.
By shifting tau_s we can easily find the minimal point of the RMS, and at this point we can get tau_0=tau_s.
This is the principle of the method to measure the delay.  In my measurement I put T=1sec. and make the calculation every 1sec. in 1 min.


(results)
Attachment is the obtained results. The above shows the minimum RMS sampled every 1sec. and the below shows the delay in terms of number of shifts.
1 shift corresponds to Ts (=1/32kHz).  All of the data are matched with 3 times shift, and all of the minimum RMS are completely zero.
Therefore I can conclude that LSC-signal is retarded from OMC-signal with constant retarded times of 3*Ts exactly, and no timing jitter has been found.
 

Attachment 3: OMC_LSC60sec.png
OMC_LSC60sec.png
  2146   Mon Oct 26 19:12:50 2009 kiwamuUpdateLSCdiagnostic script for LSC timing

The diagnostic script I've written is available in the 'caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src'.

To run the script, you can just execute 'run_OMC_LSC.sh' or just call the m-file ' OMC_LSC_timinig.m'  from matlab.

 

NOTES:

The script destructs the lock of DARM and OMC, be careful if you are working with IFO.

  2153   Tue Oct 27 19:37:03 2009 kiwamuUpdateLSCcron job to diagnose LSC-timing

I set a cron job on allegra.martian to run the diagnostic script every weekend.

I think this routine can be helpful to know how the trend of timing-shift goes

The cron runs the script on every Sunday 5:01AM and diagnostics will take about 5 min.

 

! Important:

During the running of the script, OMC and DARM can not be locked.

If you want to lock OMC and DARM in the early morning of weekend, just log in allegra and then comment out the command by using 'crontab -e'

 

 

  2167   Mon Nov 2 10:56:09 2009 kiwamuUpdateLSCcron job works succesfully & no timing jitter

As I wrote on Oct.27th, the cron job works every Sunday.

I found it worked well on the last Sunday (Nov.1st).

And I can not find any timing jitter in the data, its delay still stay 3*Ts.

  2174   Wed Nov 4 16:49:32 2009 AlbertoUpdateLSCArm Cavity Finesse Measurement

I'm going to work on the X arm to measure the arm cavity finesse.

The idea is to measure the cavity transfer function to estimate the frequency of its cavity pole. That should be a more accurate measurement than that based on the cavity decay time.

I'm starting now and I'm going to inject a swept sine excitation on the OMC_ISS_EXC input cable laying on the floor nearby the AP table (see pic).

DSC_0952.JPG

In orderf to do that I disconnected the cable from the OMC breakout box laying on the floor. I'm going to plug the cable back in as soon as I'm done.

  2175   Wed Nov 4 18:35:19 2009 AlbertoUpdateLSCArm Cavity Finesse Measurement

Quote:

I'm going to work on the X arm to measure the arm cavity finesse.

The idea is to measure the cavity transfer function to estimate the frequency of its cavity pole. That should be a more accurate measurement than that based on the cavity decay time.

I'm starting now and I'm going to inject a swept sine excitation on the OMC_ISS_EXC input cable laying on the floor nearby the AP table (see pic).

DSC_0952.JPG

In orderf to do that I disconnected the cable from the OMC breakout box laying on the floor. I'm going to plug the cable back in as soon as I'm done.

 Since I need to measure the transfer function between TRX and MC_TRANS_DC I picked off the beam going to RFAM PD to send it to a PDA255 photodiode (cannibalized from the AbsL's PLL) which I installed on the PSL table.

I centerd the beam on the PD and I was able to see the injected signal.

I think I'm ready to measure the transfer function.

Except for the RFAM PD everything is as before.

I'm gonna go grab dinner and I should be back to keep working on that in about one hour.

  2176   Wed Nov 4 21:46:18 2009 AlbertoUpdateLSCArm Cavity Finesse Measurement

Quote:

Quote:

I'm going to work on the X arm to measure the arm cavity finesse.

The idea is to measure the cavity transfer function to estimate the frequency of its cavity pole. That should be a more accurate measurement than that based on the cavity decay time.

I'm starting now and I'm going to inject a swept sine excitation on the OMC_ISS_EXC input cable laying on the floor nearby the AP table (see pic).

DSC_0952.JPG

In orderf to do that I disconnected the cable from the OMC breakout box laying on the floor. I'm going to plug the cable back in as soon as I'm done.

 Since I need to measure the transfer function between TRX and MC_TRANS_DC I picked off the beam going to RFAM PD to send it to a PDA255 photodiode (cannibalized from the AbsL's PLL) which I installed on the PSL table.

I centerd the beam on the PD and I was able to see the injected signal.

I think I'm ready to measure the transfer function.

Except for the RFAM PD everything is as before.

I'm gonna go grab dinner and I should be back to keep working on that in about one hour.

 Back from dinner. Taking measurements.

  2177   Wed Nov 4 23:17:51 2009 AlbertoUpdateLSCX Arm Cavity transfer Function

I measured the transfer function between MC_TRANS and TRX and I'm attaching the result.

ArmCavityTF02.png

That looks quite strange. Something's wrong. I'll repeat it tomorrow.

for the night I'm putting everything back. I'm also reconnecting the OMC_ISS_EXC and opening again the test switch on the ISS screen.

The RFAM monitor remains disable

  2178   Thu Nov 5 05:07:22 2009 ranaUpdateLSCX Arm Cavity transfer Function

I would have guessed that you have to calibrate the detectors relative to each other before trying this. Its also going to be tricky if you use 2 different kinds of ADC for this (c.f. today's delay discussion in the group meeting).

I think Osamu used to look at fast transmission signals by making sure the PD at the end had a 50 Ohm output impedance and just drive the 40m long cable and terminate the receiving end with 50 Ohms. Then both PDs go into the SR785.

 

  2184   Thu Nov 5 19:25:11 2009 AlbertoUpdateLSCX Arm Cavity transfer Function

Quote:

I would have guessed that you have to calibrate the detectors relative to each other before trying this. Its also going to be tricky if you use 2 different kinds of ADC for this (c.f. today's delay discussion in the group meeting).

I think Osamu used to look at fast transmission signals by making sure the PD at the end had a 50 Ohm output impedance and just drive the 40m long cable and terminate the receiving end with 50 Ohms. Then both PDs go into the SR785.

 

On Rana's suggestion I measured the trasfer function between the two photodiodes PDA255 that I'm using.

I took the one that I had on the end table and put it on the PSL table. I split the MC transmitted beam with a 50% beam splitter and sent the beams on the two diodes. (Rana's idea of picking off the beam and interposing the PDs before the ISS PDs was not doable: ISS PDs would be too close and there would be no room to install the PDA255 before them). See picture with the final setup.

DSC_0958.JPG


The transfer function also includes the 40m long cable that I was using for the Arm Cavity measurement.

Here's what I got. It looks rather flat. Yesterday the calibration was probably not the problem in that measurement.

PDA255CalibrationTF03.png
 I'm now going to install the PD back on the end table and measure the TFs between the excitation and several points of the loop.

(Trivia. At first, the PDs were saturating so Koji attached attenuation filters on to them. Suddenly the measurement got much nicer)

  2185   Thu Nov 5 22:30:09 2009 AlbertoUpdateLSCX Arm Cavity Transfer Function

It seems that just repeating the measurement was enough to get a good transfer function of the x arm cavity. Here's what I got.

XarmTF01.png

I'm going to fit the data on matlab, but at first sight, the pole seems to be at about 1.7KHz (that is where the phase is 45deg): as expected.

Probably it was useful to realign the beam on the Transmission PD. (btw, I'm using the PDA255 that was still on the X end table since the AbsL experiemtn that measured the arm length)

  2186   Thu Nov 5 23:09:34 2009 AlbertoUpdateLSCY Arm Cavity Transfer Function

As for the X Arm, this the transfer function I measured for the Y arm cavity.

YarmTF01.png

This time I'm using a different photodiode than the PDA255 on the Y end table.

The diode I'm using is the PDA520 from where TRY comes from.

I'm going to repeat the measurement with PDA255.

  2188   Fri Nov 6 00:24:06 2009 AlbertoUpdateLSCY Arm Cavity Transfer Function

Quote:

As for the X Arm, this the transfer function I measured for the Y arm cavity.

YarmTF01.png

This time I'm using a different photodiode than the PDA255 on the Y end table.

The diode I'm using is the PDA520 from where TRY comes from.

I'm going to repeat the measurement with PDA255.

 Measurement repeated with the PDA255 PD at the end but not big changes

YarmTF02.png

  2189   Fri Nov 6 00:40:29 2009 AlbertoUpdateLSCEverything put back as it was

I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.

The photodiode on the Y end is stilll connected.

Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.

I'm also running the Align Full IFO script.

  2208   Mon Nov 9 11:11:19 2009 AlbertoConfigurationLSCMC2 Watchdogs tripped

The MC2 watchdogs tripped. I just restored them.

I also had to relock the MZ and then the Mode Cleaner.

  2217   Mon Nov 9 15:11:02 2009 AlbertoUpdateLSCEverything put back as it was

Quote:

I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.

The photodiode on the Y end is stilll connected.

Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.

I'm also running the Align Full IFO script.

 

I removed the beam splitter and the PDA 255.

the beam path to the RFAM photodiode is clear again.

  2226   Tue Nov 10 13:02:36 2009 AlbertoUpdateLSCX and Y Arm Cavity Poles Measurement

From fitting the arm cavity transfer functions I got the following values for the cavity pole frequencies.

X ARM: fp_x = (1720 +/- 70) Hz

Y ARM: fp_y = (1650 +/- 70) Hz

Attached are the plots from the fitting.

Attachment 1: SummaryOfFits.pdf
SummaryOfFits.pdf SummaryOfFits.pdf
Attachment 2: CodeAndData.tar
  2247   Thu Nov 12 02:02:18 2009 ranaSummaryLSCArm Locking with no feedback to the ETM or ITM

Steps:

1) Turn off feedback to ETMY (the ETMY button on the LSC screen).

2) Put a 1 into the YARM->MC2 output matrix element on the LSC screen.

3) Turn off FM6 (comb), FM7 (0.1:10) on the MC2_MCL filter bank. This is to make the IOO-MCL loop more stable and to reduce the IOO-MCL low frequency gain.

4) Set the MC2-LSC gain to 0.5, turn the output ON, turn ON FM4 & FM5 & FM6 of the MC2-LSC filter bank.

5) Turn on the input of MC2-LSC and the arm should now lock.

6) After locking, set the MC2-MCL gain to zero. Hopefully with a few second ramp time.

Voila!

(A comment by KA - c.f. this entry )

Attachment 1: nohands-2.pdf
nohands-2.pdf
  2277   Mon Nov 16 17:35:59 2009 kiwamuUpdateLSCOMC-LSC timing get synchronized !

An interesting thing was happened in the OMC-LSC timing clock.

Right now the clock of the OMC and the LSC are completely synchronized.

 The trend data is shown below. At the first two measurements (Oct.27 and Nov.1),  LSC had constant retarded time of 3Ts (~92usec.).

The last measurement, on Nov.15, number of shifts goes to zero, this means there are no retarded time.

Also the variance between the two signal gets zero, so I conclude the OMC and the LSC are now completely synchronized.

The measurement on Nov.8 is somehow meaningless, I guess the measurement did not run correctly by an influence from megatron(?)

 

OMC-LSC.png

 

  2317   Mon Nov 23 21:30:29 2009 JenneUpdateLSCMeasured MC length

With Koji's help, I measured the length of the Mode Cleaner.

The new modulation frequencies (as quoted on the Marconi front panels) are: 

165.980580 MHz

 33.196116 MHz

132.784464 MHz

199.176696 MHz

The Frequency Counter readback is 165980584.101 Hz (a 4Hz difference).  All of the Marconi's front-panel frequencies read ###.##### MHz Ext, and the Frequency standard has it's "locked" light illuminated, and the 1pps input light blinking, so I think everything is still nicely locked to the frequency standard, and the frequency standard is locked to the GPS.

While changing the marconi's, I accidentally touched the MC's 29.5 MHz marconi.  It is set back to the nominal value (according to Kiwamu's rack photos) of 29.485MHz.  But the phase might be sketchy, although hopefully this doesn't matter since we don't do a double demodulation with it.

I also ran the scripts in the wiki page: How To/Diagonalize DRMI Length Control to set the DD Phases.

 

 

  2319   Tue Nov 24 08:00:16 2009 ranaUpdateLSCMeasured MC length

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

  2320   Tue Nov 24 10:36:21 2009 KojiUpdateLSCMeasured MC length

What I meant was the VCO driver, not the FSS box.

As for the frequency, all written numbers were the Marconi displays.
The number on the frequency counter was also recorded, and so will be added to the previous entry shortly... 

Quote:

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

 

  2350   Thu Dec 3 15:55:24 2009 AlbertoAoGLSCRF AM Stabilizer Output Power

Today I measured the max output power at the EOM output of one of the RF AM Stabilizers that we use to control the modulation depth. I needed to know that number for the designing of the new RF system.

When the EPICS slider of the 166 MHz modulation depth is at 0 the modulation depth is max (the slider's values are reversed : 0 is max, 5 is min; it is also 0 for any value above 5, sepite it range from 0 to 10).

I measured 9.5V from the EOM output, that is 32 dBm on a 50 Ohm impedance.

  2384   Thu Dec 10 13:10:25 2009 AlbertoConfigurationLSC166 LO Disconnected

I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.

I'm doing a couple of measurement and I'll put it back in as soon as I'm done.

ELOG V3.1.3-