40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 241 of 355  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  1909   Sat Aug 15 05:08:55 2009 YoichiUpdateLockingFriday night locking
Summary: DD hand off fails for DRFPMI.

Tonight, I did a lot of house keeping work.

(1) I noticed that the reference cavity (RC) was locked to TEM10.
This was probably the reason why we had to increase the FSS common gain.
I re-locked the RC to TEM00. Now the common gain value is back to the original.

(2) The MC WFS did not engage. I found that c1dcuepics had the /cvs/cds mounting problem.
I rebooted it. Then MC WFS started working.

(3) After checking that the MC WFS QPDs are centered for direct reflection (the MZ half fringe method),
I locked the MC and tweaked the mirror alignment (mainly MC3) to offload the WFS feedback signals.
Now the MC locks to TEM00 robustly.

(4) Since the MC mirror alignment is touchy recently, I did not like the idea of mis-aligning MC2
when you do the LSC PD offset adjustment. So I modified the LSCoffset script so that it will close
the PSL shutter instead of mis-aligning MC2.

(5) I changed the PD11_Q criteria for success in the alignment scripts because PD11_Q is now lower
than before due to the lower laser power.

(6) Since today's bootfest, some epics values were not properly restored. Some of the PD gains were
unmatched between I and Q. I corrected these with the help of conlog.

(7) By checking the open loop TFs, I found that the short DOFs have significantly lower UGFs than before,
probably due to the lower laser power. I increased the gains of MICH, PRCL and SRCL by a factor of 2 for
the full configuration.
For the DRM configuration the changes I made were:

PRC -0.15 -> -0.3
SRC 0.2 -> 0.6
MICH 0.5 -> 0.5

(8) I locked the DRFPMI with arm offsets, then adjusted the demodulation phases of PD6,PD7,PD8 and PD9 (DD PDs)
to minimize the offsets in the error signal, while locked with the single demodulation signals.

Change log:
PD6_PHASE 201 -> 270
PD7_PHASE 120 -> 105
PD8_PHASE 131 -> 145
PD9_PHASE -45 -> -65


(9) I ran senseDRM to get the sensing Matrix for the short DOFs using DD signals in DRM configuration.

(10) Still the DD hand off fails for DRFPMI. It succeeds for DRM.
  1913   Sat Aug 15 22:50:18 2009 ClaraUpdateLockingMode Cleaner is out of lock again

It was fine when I came in earlier today, but I just got back from dinner, and it's not good. I looked in dataviewer, and it seems to have been sliding out for the past couple of hours... Here is a picture:

MC_trans.png

I swear I am not responsible this time... all I've been doing is working in the control room.

  1914   Sun Aug 16 04:33:11 2009 ClaraUpdateLockingMode Cleaner is out of lock again

Quote:

It was fine when I came in earlier today, but I just got back from dinner, and it's not good. I looked in dataviewer, and it seems to have been sliding out for the past couple of hours... Here is a picture:

MC_trans.png

I swear I am not responsible this time... all I've been doing is working in the control room.

 Mode cleaner bounced back on its own about 2 hours ago.

  1930   Wed Aug 19 23:57:35 2009 robUpdateLockingreport

 

locking work proceeding apace tonight.

diagonalized DRM with setDDphases & senseDRM

initial locks are fairly quick, aqstep script succeeds reliably.

first part of cm_step (handoff CARM-> MCL) usually works.

tuning up later parts of cm_step (presumably due to optical gain changes resulting from MOPA decline). 

got to arm powers ~60.

  1955   Thu Aug 27 12:34:48 2009 YoichiUpdateLockingup to arm power 70
Last night, I tried to run locking scripts.
The power went up to 70 a couple of times .
Then it failed to switch to RF CARM.
I was too tired at that time to figure out what is the problem with the switching.
But it seemed to me that the problem could be solved by some gain tweaking.
Looks like the IFO is back to a good state.
  1959   Fri Aug 28 12:56:17 2009 YoichiUpdateLockingRF CARM hand off problem
Last night, the lock script proceeded to the RF CARM hand-off about half of the time.
However, the hand off was still unsuccessful.

It failed instantly when you turn on the REFL1 input of the CM board, even
when the REFL1 input gain was very low, like -28dB.

I went to the LSC rack and checked the cabling.
The output from the PD11_I (REFL_2) demodulation board is split
into two paths. One goes directly to the ADC and the other one goes
to an SR560. This SR560 is used just as an inverter. Then
the signal goes to the REFL1 input of the CM board.

I found that the SR560 was set to the A-B mode, but B input was open.
This made the signal very noisy. So I changed it to A only mode.
There was also a 1/4 attenuator between the PD11_I output and the SR560.
I took it out and reduced the gain of SR560 from 10 to 2.
These changes allowed me to increase the REFL1 gain to -22dB or so.
But it is still not enough.

I wanted to check the CM open loop TF before the hand-off, but I could
not do that because the lock was lost instantly as soon as I enabled the
test input B of the CM board.
Something is wrong with the board ?

Using the PD11_I signal going into the ADC, I measured the transfer functions
from the CM excitation (digital one) to the REFL_DC (DC CARM signal) and PD11_I.
The TF shapes matched. So the PD11_I signal itself should be fine.

We should try:
* See if flipping the sign of PD11_I signal going to REFL1 input solve the problem.
* Try to measure the CM analog TF again.
* If the noise from the servo analyzer is a problem, try to increase the input gains
of the CM board and reduce the output gain accordingly, so that the signal flowing
inside the CM board is larger.
  1960   Fri Aug 28 13:49:07 2009 robUpdateLockingRF CARM hand off problem

Quote:
Last night, the lock script proceeded to the RF CARM hand-off about half of the time.
However, the hand off was still unsuccessful.

It failed instantly when you turn on the REFL1 input of the CM board, even
when the REFL1 input gain was very low, like -28dB.

I went to the LSC rack and checked the cabling.
The output from the PD11_I (REFL_2) demodulation board is split
into two paths. One goes directly to the ADC and the other one goes
to an SR560. This SR560 is used just as an inverter. Then
the signal goes to the REFL1 input of the CM board.

I found that the SR560 was set to the A-B mode, but B input was open.
This made the signal very noisy. So I changed it to A only mode.
There was also a 1/4 attenuator between the PD11_I output and the SR560.
I took it out and reduced the gain of SR560 from 10 to 2.
These changes allowed me to increase the REFL1 gain to -22dB or so.
But it is still not enough.

I wanted to check the CM open loop TF before the hand-off, but I could
not do that because the lock was lost instantly as soon as I enabled the
test input B of the CM board.
Something is wrong with the board ?

Using the PD11_I signal going into the ADC, I measured the transfer functions
from the CM excitation (digital one) to the REFL_DC (DC CARM signal) and PD11_I.
The TF shapes matched. So the PD11_I signal itself should be fine.

We should try:
* See if flipping the sign of PD11_I signal going to REFL1 input solve the problem.
* Try to measure the CM analog TF again.
* If the noise from the servo analyzer is a problem, try to increase the input gains
of the CM board and reduce the output gain accordingly, so that the signal flowing
inside the CM board is larger.



I'd bet it's in a really twitchy state by the time the script gets to the RF CARM handoff, as the script is not really validated up to that point. It's just the old script with a few haphazard mods, so it needs to be adjusted to accomodate the 15% power drop we've experienced since the last time it was locked.

The CM servo gain needs to be tweaked earlier in the script--you should be able to measure the AO path TF with the arm powers at 30 or so. I was able to do this with the current SR785 setup earlier this week without any trouble.

The 1/4 attenuator is there to prevent saturations on the input to the SR560 when there's still a CARM offset.

Not sure if flipping the sign of PD11 is right, but it's possible we compensated the digital gains and forgot about it. This signal is used for SRCL in the initial acquisition, so we'd have noticed a sign flip.
  1969   Mon Sep 7 23:18:01 2009 AlbertoUpdateLockingSome locking attempts

Tried to lock the interferometer but arm power didn't get over 65.

Tonight, after the weekend, I resumed the work on locking.

When I started the Mode Cleaner was unlocked because the MZ was also unlocked.

I aligned the MZ and the transmitted power reached about 2.5

Initially the interferometer lost lock at arm power of about 3-4. It looked like the alignment wasn't good enough. So I ran the alignment scripts a few times, first the scripts for the single parts and in the end the one for the full IFO.

Then I also locked again the MZ and this time the transmitted power got to about 4.

In the following locking attempts the the arm power reached 65 but then the lock got lost during the handing of CARM to C1:LSC-PD11_I

I'll keep working on that tomorrow night.

  2011   Mon Sep 28 02:24:05 2009 ranaUpdateLockingMC1/3 Dewhitening found OFF: Turned back ON

While trying to make the OAF work, I found that the XYCOM switches for MC1/3 have been set in the bad way for awhile. This means that the hardware filters were bypassed and that MC1 & MC3 were moving around too much at high frequency and possibly causing trouble with the locking. I have put them back into the default position.

On Friday, Jenne and I were playing around with turning the dewhitening off/on to see if it efffected the OAF stability. At the time, I didn't pay too much attention to what the state was. Looks like it was in the wrong state (hardware bypassed) when we found it. For the OAF work, we generally want it in that bypassed state, but its bad because it makes noise in the interferometer. The bits in question are bits 16-23 on the XYCOM screen.

I have updated the snapshot and set the screen in the appropriate settings. I used a swept sine measurement to verify the filter state. In the attached plot, green corresponds to XYCOM green and red corresponds to red.

Attachment 1: C1SUS_SRM_XYCOM1.png
C1SUS_SRM_XYCOM1.png
Attachment 2: Untitled.png
Untitled.png
  2027   Wed Sep 30 02:01:28 2009 robUpdateLockingweek

It's been a miserable week for lock acquisition, with each night worst than the last.  The nadir was around Sunday night, when I couldn't even get a PRM to lock stably, which meant that the auto-alignment scripts could not finish successfully.  It now appears that was due to some XYCOM mis-settings. 

We've also been having problems with timing for c1susvme2.  Attached is a one-hour plot of timing data for this cpu, known as SRM.  Each spike is an instance of lateness, and a potential cause of lock loss.  This has been going on for a quite a while.

Tonight we also encountered a large peak in the frequency noise around 485 Hz.  Changing the MZ lock point (the spot in the PZT range) solved this.

 

Attachment 1: srmcpu.png
srmcpu.png
  2030   Thu Oct 1 03:12:56 2009 robUpdateLockingsome progress

Good progress in IFO locking tonight, with the arm powers reaching about half the full resonant maximum. 

Still to do is check out some weirdness with the OMC DAC, fix the wireless network, and look at c1susvme2 timing.

  2037   Thu Oct 1 15:42:55 2009 robUpdateLockingc1susvme2 timing problems update

Quote:

We've also been having problems with timing for c1susvme2.  Attached is a one-hour plot of timing data for this cpu, known as SRM.  Each spike is an instance of lateness, and a potential cause of lock loss.  This has been going on for a quite a while.

 

 

Attached is a 3 day trend of SRM CPU timing info.  It clearly gets better (though still problematic) at some point, but I don't know why as it doesn't correspond with any work done.  I've labeled a reboot, which was done to try to clear out the timing issues.  It can also be seen that it gets worse during locking work, but maybe that's a coincidence.

Attachment 1: srmcpu2.png
srmcpu2.png
  2040   Fri Oct 2 02:55:07 2009 robUpdateLockingmore progress

More progress with locking tonight, with initial acquisition and power ramps working.  The final handoff to RF CARM still needs work.

I found the wireless router was unplugged from the network--just plugging in the cable solved the problem.  For some reason that RJ45 connector doesn't actually latch, so the cable is prone to slipping out of the jack.

 

  2047   Sat Oct 3 14:53:24 2009 robUpdateLockingmore progress

Late last night after the ETMY settled down from the quake I made some more progress in locking, with the handoff to RF CARM succeeding once.  The final reduction of the CARM offset to zero didn't work, however.

  2048   Mon Oct 5 02:51:08 2009 robUpdateLockingalmost there

Working well tonight: the handoff of CARM to RF (REFL2I), successful reduction of CARM offset to zero, and transition control of MCL path to the OUT1 from the common mode board.  All that's left in lock acquisition is to try and get the common mode bandwidth up and the boost on.

  2056   Tue Oct 6 01:41:20 2009 robUpdateLockingDC Readout

Lock acquisition working well tonight.  Was able to engage CM boost (not superboost) with bandwidth of ~10kHz.  Also succeeded once in handing off DARM to DC readout.

  2081   Mon Oct 12 17:14:39 2009 robUpdateLockingstability

Last night, 2+ hour lock, probably broken by me driving too hard (DARM_EXC).

Attachment 1: transpow.png
transpow.png
  2092   Wed Oct 14 16:59:37 2009 robUpdateLockingdaytime locking

The IFO can now be locked during the daytime.  Well, it's locked now.

  2093   Wed Oct 14 23:02:41 2009 ranaUpdateLockingdaytime locking

This is huge.    Five hours of lock only interrupted by intentional break from transfer function abuse.

Attachment 1: a.png
a.png
  2097   Thu Oct 15 09:23:07 2009 steveSummaryLockingnever had it so good

Awesome 5 hrs of locking  Rob!

Attachment 1: 5hlock.jpg
5hlock.jpg
  2100   Thu Oct 15 17:12:00 2009 ranaSummaryLockingnever had it so good

 

  2141   Mon Oct 26 03:57:06 2009 robUpdateLockingbad

Lock acquisition has gone bad tonight. 

The initial stage works fine, up through handing off control of CARM to MCL.  However, when increasing the AO path (analog gain), there are large DC shifts in the C1:IOO-MC_F signal.  Eventually this causes the pockels cell in the FSS loop to saturate, and lock is lost. 

  2148   Tue Oct 27 01:45:02 2009 robUpdateLockingMZ

Quote:
Tonight we also encountered a large peak in the frequency noise around 485 Hz. Changing the MZ lock point (the spot in the PZT range) solved this.


This again tonight.

It hindered the initial acquisition, and made the DD signal handoff fail repeatedly.
  2152   Tue Oct 27 18:19:14 2009 robUpdateLockingbad

Quote:

Lock acquisition has gone bad tonight. 

The initial stage works fine, up through handing off control of CARM to MCL.  However, when increasing the AO path (analog gain), there are large DC shifts in the C1:IOO-MC_F signal.  Eventually this causes the pockels cell in the FSS loop to saturate, and lock is lost. 

 This problem has disappeared.  I don't know what it was. 

The first plot shows one of the symptoms.  The second plot is a similar section taken from a more normal acquisition sequence the night before.

All is not perfect, however, as now the handoff to RF CARM is not working.

Attachment 1: MCF_issue.png
MCF_issue.png
Attachment 2: no_MCF_issue.png
no_MCF_issue.png
  2154   Wed Oct 28 05:02:28 2009 robUpdateLockingback

LockAcq is back on track, with the full script working well.  Measurements in progress.

  2162   Thu Oct 29 21:51:07 2009 robUpdateLockingbad

Quote:

Quote:

Lock acquisition has gone bad tonight. 

The initial stage works fine, up through handing off control of CARM to MCL.  However, when increasing the AO path (analog gain), there are large DC shifts in the C1:IOO-MC_F signal.  Eventually this causes the pockels cell in the FSS loop to saturate, and lock is lost. 

 This problem has disappeared.  I don't know what it was. 

The first plot shows one of the symptoms.  The second plot is a similar section taken from a more normal acquisition sequence the night before.

All is not perfect, however, as now the handoff to RF CARM is not working.

 

The problem has returned.  I still don't know what it is, but it's making me angry. 

Attachment 1: itsback.png
itsback.png
  2163   Fri Oct 30 04:41:37 2009 robUpdateLockingworking again

I never actually figured out exactly what was wrong in entry 2162, but I managed to circumvent by changing the time sequence of events in the up script, moving the big gain increases in the common mode servo to the end of the script.  So the IFO can be locked again.

  2271   Sun Nov 15 18:42:10 2009 AlbertoUpdateLockingInterferometer fully locked for 3331 seconds

This afternoon, I tried to lock the interferometer again after a few days.

After a couple of failed attempts, and relocks of the MZ, the interferometer stayed locked continuously for about 50 minutes, with arm power of about 92.

I just wanted to check the status of the interferometer so I didn't do any particular measurement in the meantime.

  2325   Wed Nov 25 03:05:15 2009 robUpdateLockingMeasured MC length

Quote:

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.

 

 

Locking has gone sour.  The CARM to MCL handoff, which is fairly early in the full procedure and usally robust, is failing reliably. 

As soon as the SUS-MC2_MCL gain is reduced, lock is broken.  There appears to be an instability around 10Hz.  Not sure if it's related.

  2332   Wed Nov 25 14:29:08 2009 robUpdateLockingMeasured MC length--FSS trend

Quote:

Quote:

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.

 

 

Locking has gone sour.  The CARM to MCL handoff, which is fairly early in the full procedure and usally robust, is failing reliably. 

As soon as the SUS-MC2_MCL gain is reduced, lock is broken.  There appears to be an instability around 10Hz.  Not sure if it's related.

 Five day minute trend.  FAST_F doesn't appear to have gone crazy.

Attachment 1: FSStrendpowerjump.png
FSStrendpowerjump.png
  2333   Wed Nov 25 15:38:08 2009 robUpdateLockingMeasured MC length

Quote:

Quote:

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.

 

 

Locking has gone sour.  The CARM to MCL handoff, which is fairly early in the full procedure and usally robust, is failing reliably. 

As soon as the SUS-MC2_MCL gain is reduced, lock is broken.  There appears to be an instability around 10Hz.  Not sure if it's related.

 Whatever the locking problem was, the power of magical thinking has forced it to retreat for now.  The IFO is currently locked, having completed the full up script.  One more thing for which to be thankful.

  3072   Sat Jun 12 19:41:04 2010 AlbertoUpdateLocking40m Upgrade Optickle Model

I wrote down the settings according to which I tuned the optickle model of the 40m Upgrade.

Basically I set it so that:

  1. PRC alone anti-resonant for the carrier and resonant for both sidebands
  2. SRC alone resonant for the carrier and resonant for the f2 sideband

In this way when the carrier becomes resonant in the arms we have:

  1. carrier resonant in PRC and anti-resonant in SRC
  2. f1 resonant in PRC and non resonant in SRC
  3. f2 resonant in SRC

The DARM offset for DC readout is optional, and doesn't change those conditions.

I also plotted the carrier and the sideband's circulating power for both recycling cavities.

I'm attaching a file containing more detailed explanations of what I said above. It also contains the plots of field powers, and transfer functions from DARM to the dark port. I think they don't look quite right. There seems to be something wrong.

Valera thought of fixing the problem, removing the 180 degree offset on the SRM, which is what makes the sideband rather than the carrier resonant in SRC. In his model the carrier becomes resonant and the sideband anti-resonant. I don't think that is correct.

The resonant-carrier case is also included in the attachment (the plots with SRMoff=0 deg). In the plots the DARM offset is always zero.

I'm not sure why the settings are not producing the expected transfer functions.

Attachment 1: optickleIFOworkingpoint.pdf
optickleIFOworkingpoint.pdf optickleIFOworkingpoint.pdf optickleIFOworkingpoint.pdf optickleIFOworkingpoint.pdf optickleIFOworkingpoint.pdf optickleIFOworkingpoint.pdf optickleIFOworkingpoint.pdf optickleIFOworkingpoint.pdf
  3074   Sun Jun 13 08:28:44 2010 valeraUpdateLocking40m Upgrade Optickle Model

 In my calculation of the digital filters of the optical transfer functions the carrier light is resonant in coupled cavities and the sidebands are resonant in recycling cavities (provided that macroscopic lengths are chosen correctly which I assumed).

  3075   Mon Jun 14 07:57:07 2010 albertoUpdateLocking40m Upgrade Optickle Model

Quote:

 

 In my calculation of the digital filters of the optical transfer functions the carrier light is resonant in coupled cavities and the sidebands are resonant in recycling cavities (provided that macroscopic lengths are chosen correctly which I assumed).

Carrier and SB (f2) shouldn't be resonant at the same time in the SRC-arms coupled cavity. No additional filtering of the GW signal is wanted.

The SRC macroscopic length is chosen to be = c / f2 - rather than = [ (n+1/2) c / (2*f2) ] - accordingly to that purpose.

  3079   Tue Jun 15 21:28:44 2010 albertoUpdateLocking40m Upgrade Optickle Model

Quote:

Quote:

 

 In my calculation of the digital filters of the optical transfer functions the carrier light is resonant in coupled cavities and the sidebands are resonant in recycling cavities (provided that macroscopic lengths are chosen correctly which I assumed).

Carrier and SB (f2) shouldn't be resonant at the same time in the SRC-arms coupled cavity. No additional filtering of the GW signal is wanted.

The SRC macroscopic length is chosen to be = c / f2 - rather than = [ (n+1/2) c / (2*f2) ] - accordingly to that purpose.

I calculated the frequency of the double cavity pole for the 40m SRC-arm coupled cavity.

w_cc = (1 + r_srm)/(1- r_srm) * w_c

where w_c is the arm cavity pole angular frequency [w_c = w_fsr * (1-r_itm * r_etm)/sqrt(r_itm*r_etm) ]

I found the pole at about 160KHz. This number coincides with what I got earlier with my optickle model configured and tuned as I said in my previous entry. See attachments for plots of transfer functions with 0 and 10pm DARM offsets, respectively.

I think  the resonance at about 20 Hz that you can see in the case with non-zero DARM offset, is due to radiation pressure. Koji suggested that I could check the hypothesis by changing either the mirrors' masses or the input power to the interferometer. When I did it frequency and qualty factor of the resonance changed, as you would expect for a radiation pressure effect.

Independently, Jan also calculated the pole frequency of the transfer function DARM / ASQ2 as we would expect it for the SRC-coupled cavity. He also found the pole at about 160KHz. I'm attaching the plot with the transfer function he calculated.
He also said that the little bump at the pole frequency is OK considering that our signal recycling cavity is not much shorter than the arms.

This gave me more confidence about my optickle model of the 40m. This is quite comforting since I used that model other times in the past to calculate several things (i.e. effects of higher unwanted harmonics from the oscillator, or, recently, the power at the ports due to the SB resonating in the arms).

I don't know anymore what Valera said that wasn't right.
Also, as he said, he set it for the carrier to be resonant in the SRC-arms couple cavity. But that is not our case.
Attachment 1: allTransferFunctions_DARMoff_0.pdf
allTransferFunctions_DARMoff_0.pdf allTransferFunctions_DARMoff_0.pdf allTransferFunctions_DARMoff_0.pdf
Attachment 2: allTransferFunctions_DARM2AS_10pmDARMoffset.pdf
allTransferFunctions_DARM2AS_10pmDARMoffset.pdf allTransferFunctions_DARM2AS_10pmDARMoffset.pdf allTransferFunctions_DARM2AS_10pmDARMoffset.pdf
Attachment 3: Jan_DARM2AS.pdf
Jan_DARM2AS.pdf
  3750   Thu Oct 21 05:51:10 2010 kiwamuUpdateLockingno green beat note

 Still I didn't see any beat note signals..

 With a help from Suresh, Yuta and Rana, I tried searching for the green beat note by changing the temperature of the X end NPRO.

The noise level after it goes through an RF amplifier (G=23dB) was about -70dBm at 50MHz.

This noise may cover the beat note signal.

I am going to post some details later.

  3754   Thu Oct 21 15:59:28 2010 kiwamuUpdateLockingno green beat note : details

Last night I tried searching for a beat note signal with two different PD trans impedance gains.

Although I didn't find a  beat note signal.

 


 

- (1. trans impedance gain = 2400)

 I started with a trans impedance resistance of R=2.4k, which is 10 times bigger resistance than the original.

The total PD gain should be about 960 [V/W] theoretically if we assume the responsibility of the PD is 0.4 [A/W].

Then I checked the bandwidth of the RFPD using Jenne laser.

The bandwidth was about 30MHz, which is 3 times narrower than the original. And it agrees with our expectation.

As Koji and I mentioned at the last weekly meeting, the cut off frequency of an RFPD follows inverse square root of the trans impedance resistance R.

 

 bw.png

where C is a capacitance of the photo diode. (See this)

I was expecting the signal level of  -50 dBm / rtHz with a 23dB RF amplifier, assuming the line width of the signal is 10kHz.

 

 


- (2. trans impedance gain = 240) 

 I also tried it with the original trans impedance gain (see this entry). 

 R = 240 [Ohm]

 G = 96 [V/W]

 BW = 100 [MHz]  (I didn't measure it in this time)

 expected signal level = -70 dBm/rtHz


Quote:

 Still I didn't see any beat note signals..

 

  3763   Fri Oct 22 18:15:21 2010 kiwamuUpdateLockingGreen era: found a green beat note finally

finally we found it !

 green_beatnote.jpg

  3766   Fri Oct 22 21:28:27 2010 AidanUpdateLockingGreen era: found a green beat note finally

Nice work!

Quote:

finally we found it !

 green_beatnote.jpg

 

  3771   Sun Oct 24 18:06:35 2010 kiwamuSummaryLockingsetup for green beat

green_beat_note.png

(notes on signal level)

 The signal level of the observed peak was -48dBm.

However I was expecting it is like -28dBm with some ideal assumptions.

There may be a 20dB unknown loss which sounds big to me.

 

The expectation was calculated by using the following simple math.

                       SIGNAL = A x Z x G_RF x sqrt(P1 / 2) x sqrt (P2 / 2)

 where A is the responsibility of the PD and Z is the trans impedance gain. G_RF is a gain of the RF amplifier.

The laser powers of green beams, P1 and P2, are divided by 2 due to a beam splitter. 

I was assuming the parameters are like:

           A = 0.39 [A/W]   (assuming 90% quantum efficiency at 532nm)

           Z = 240 [V/A]  

           P1 = 17 uW  (measured by Newport power meter)

           P2 = 30 uW (measured by Newport power meter)

           G_RF = 23 dB

 

  3774   Mon Oct 25 02:14:38 2010 KojiSummaryLockingsetup for green beat

- What is the actual photocurrent for the beam1 and beam2? We don't care how much power do you have before the BS, but care how much current do you have on the PD.

- How much is the visibility? There is mismatching of the beams. i.e. The beam diameter looked quite different. Also the beams are not TEM00 but have fringes probably comes from the TT mirrors. You maybe able to measure the visibility by the DC output, making the beat freq go through df=0 slowly.

- What is the measured gain of the RF amp? Does it include the voltage division by the output/input impedance?

---------------------

 The signal level of the observed peak was -48dBm.

However I was expecting it is like -28dBm with some ideal assumptions.

There may be a 20dB unknown loss which sounds big to me.

I was assuming the parameters are like:

           A = 0.39 [A/W]   (assuming 90% quantum efficiency at 532nm)

           Z = 240 [V/A]  

           P1 = 17 uW  (measured by Newport power meter)

           P2 = 30 uW (measured by Newport power meter)

           G_RF = 23 dB

  3800   Wed Oct 27 21:33:42 2010 SureshUpdateLockingGreen from the far end re-obtained

 

The mirror which was moved during the mode matching of PSL light to the MC (ref elog #3791) has been repositioned.  We once again have the green light from the NPRO on the X (south) arm available on the PSL table. 

This light was supposed to be collimated by the two plano convex lenses (f=200mm and f=50mm  ref to elog #3771) but it was converging.  So I moved the f=50mm lens backwards to make the beam collimated.  I checked the beam collimation by introducing an Al coated mirror infront of th PD and diverting the beam temporarily in a free direction.  I could then check the collinearity and collimation of both the green beams over a meter.  After alignment the mirror was removed and the light is now incident on the PD once again.  We can now proceed to look for green beats.

The power from the PSL NPRO was attenuated for the MC locking work of yesterday.  It has now been increased to the maximum by rotating the Half Wave Plate (HWP).  The power after the PSL is now about 450mW  (500mW - 10% picked off for the doubling).

 

 

 

  3804   Thu Oct 28 03:21:35 2010 SureshUpdateLockingAligned the MC2 transmission photodiode

Yuta and Suresh

The MC2 transmission is seen on the QPD

Once the laser was locked to the cavity, and the PMC was able to follow the laser (ref: elogs by Yuta and Rana today)  we had a steady TEMoo mode in the MC.  This gave us sufficient transmission through MC2 to be easily visible with an IR viewer and we were able to guide the beam on to the QPD.  The beam however seemed to over fill the QPD, a lens (f=180mm) was placed before the beam folding mirror and the spot sized reduced.   The the QPD was found to be not fixed to the table and this was also recitified.  The signal level is still low: total signal is just about 7 DAQ steps amounting to about 5mV.  Tomorrow we plan to work on the alignment of the PSL and MC and thus increase this signal.

A new channel to observe the length variations in the MC.

A long BNC cable was laid from the MC locking electronics next (southwards) to the PSL table to the DAQ cards picking up the signals from the PRM OSEMS.  This is to pick up one of the MC locking signals and collect it on a DAQ channel.  However as there are no spare DAQ channels currently available one of the PRM OSEM (UL and LL) photodiode channels was unplugged and replaced with the signal from the long BNC cable.   For identifying the correct DAQ channel we put in a 2 Vpp 10Hz signal with a function generator into this BNC.  Tow signals can be picked up in this fashion and they are available on PRM_LLSEN_IN1 and PRM_ULSEN_IN1. We plan to use this for improving the alignment of the MC tomorrow. 

The algorithm for this alignment is that if the beam from the PSL is not centered on the MC1 then tilting MC1 would result in a change in the length of the cavity as seen by the light.  Using this as feedback the spot could be precisely centered on the MC1 and then the MC alignment could be completed by moving MC2 and MC3 to reobtain TEM_oo within the cavity.

  3843   Tue Nov 2 00:17:01 2010 SureshConfigurationLockingTemporary changes to the Video Mux

Fiber coupling 1064 nm light at the end of X arm

This is 'work in progress'.  The attempt is to bring a few milliwatts of the 1064 nm light from the NPRO at the end of the South(X) Arm to the PSL table through an single mode optical fiber.  This would enable us to tune the two NPRO's to be less than 15 MHz apart by looking at their beat frequency before doubling.  Because we have a 1GHz bandwidth PD at 1064 nm, while the photodiode for green has a BW of about 30MHz.

A PBS (P-type) cube has been introduced into the beam of the X arm NPRO  (between the lamda/2 plate and the input lens of the doubling crystal).  By rotating the face of the PBS slightly away from normal incidence, I have diverted away 1.5mW of the 1064 light for coupling into the fiber. The beam has shifted slightly because of this and the green beam from the south arm has to be realigned to reach the PSL table.

A single mode fiber (Thorlabs SM980-5.8-125),  which was already laid half way, has been extended all the way to the PSL table. It runs along the  South arm in the cable tray. 

A pair of mirrors have been arranged in a zig-zag to steer the beam into a fiber coupler.  There was some hope that this coupler had been aligned at some point in the past and that attaching a fiber might result in some transmission.  But this is not the case and fiber coupler needs to be readjusted.

In order to see the light transmitted through the fiber, a camera has been set up on the PSL table.  Its output has been routed into the 'Ref Cavity reflected' video signal.  A video cable running from the ETMX to the Video-MUX used to be connected to the input channel 9 of the Video MUX.  This has now been shifted to output channel 25 of the MUX and disconnected from the camera at the ETMX.   The 'Ref Cav Refl.' video signal has been routed to the output channel 25.  The camera looking at the fiber output can now be seen on a local monitor at the end of the X arm and on the video monitor in the control room.

With the fiber disconnected, the 1064 nm beam was steered into the fiber coupler and its transmission maximised by observing  with an IR viewer.  The fiber was then connected and then the transmission at the PSL table was sought.  There was no transmission seen after a searching around this region for a few mins.

The plan is to purchase a Visual fault locator which would enable us to quickly get a rough alignment of the fiber coupler. A local vendor is listed as a distributor for this product from JDSU.  Contact info:

DuVac Electronics (EDGE)
Tel: 626-796-3291
Email: jack@duvac.com
1759 E Colorado Blvd
Pasadena, CA 91106

 

  3859   Thu Nov 4 03:13:46 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

[Kiwamu, Suresh]

We decided to use the 1064nm beam reflected from the Y1-1037-45-P mirror after the collimation lens following the doubling crystal for coupling into the optical fiber (ref 3843 and 3847 ).

We replaced a beam dump which was blocking this beam with a Y1-1037-45-P mirror and directed the beam into the fiber coupler with another Y1-1037-45-P.  The power in this beam was about 1W.  This has been stepped down to 10mW by introducing a reflective ND filter of OD=2.  The reflected power has been dumped into a blade-stack beam dump.

Steve has ordered the The Visual Fault Locator from Fluke.  It is expected to arrive within a day or two.

 

 

  3865   Thu Nov 4 19:00:57 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

The Fluke Visual Fault locator (Visifault) arrived and I used it to couple 1064nm light into the single mode fibre at the south-end-table.

Procedure used:

When the output end of the fiber is plugged into the Visifault the light emerges from at the south end (input side for 1064nm).  This light is collimated with the fiber coupler at that end and serves as a reference for the optical axis along which the 1064 light must be directed.  Once the two beams (red and 1064) are overlapped with the beam steering mirrors, the Visifault was disconnected from the fiber and the  fibre output ( 1064 at the PSL table) is maximized by walking the beam at the input end and adjusting the collimation at the input.

The output of the fiber has been collimated with a fiber coupler.

7.5mW are incident on the input end and 1.3mW have been measured at the output.    This output power is adequate for the observing the beats with PSL NPRO.

 

 

 

  3866   Thu Nov 4 19:26:51 2010 SureshUpdateLockingChanges to the Video MUX reversed

All the temporary changes to the video cables and the video MUX ( 3843 ) have been reversed and the system returned to its original state.

  4143   Wed Jan 12 17:22:47 2011 SureshConfigurationLockingMC demod phase adjusted to minimise the I output

[Koji, Suresh]

We wanted to check and make sure that the relative phase of the two inputs ( local oscillator and photodiode signal ) to the demod board is such that the Q output is maximised.   We displayed the I and  Q signals on the oscilloscope in XYmode with I along the X direction.  If Q is maximised (and therefore I is minimised) the oscillocope trace would be perfectly vertical since all the signal would be in Q and none in I. Initially we noted that the trace was slightly rotated to the CCW of the vertical and that a short cable was present in the PD input line.  Removing this rotated the trace CW and made it pretty much vertical.  The screen shot of the oscilloscope is below.

.TEK00000.PNG

  4155   Fri Jan 14 12:29:57 2011 KojiUpdateLockingNext steps for the green

These are the next steps for a better operation of the arm locking. They are suitable for the day time activities

Reconfiguration of the X-End table

- End transmission power monitor (CDS model exists, need to configure the PD)

- IR steering mirror for the transmon

- Restore/align end green beam

- Relocate the end trans CCD

- Connect the video output cable for the X-end CRT monitor

LSC Whitening

- LSC Whitening binary IO connection

 


They are not urgent but also good things to do

MC servo characterization

- Error signal: frequency noise

- Loop characterization

Arm cavity characterization with cavity sweep

- Arm finesse for 1064nm and 532nm

- Arm FSR measurement with 1064 (and optionally with 532nm simultaneously)

- Arm g-factor for 1064nm and 532nm

  4161   Sun Jan 16 02:20:59 2011 SureshUpdateLockingcomparing the PSL with the X-end-NPRO through the green beat

Objective:

      We wish to study the coherence of the two NPROs i.e. PSL and the X-end-NPRO by locking both of them to the X-arm and then observing the green beat frequency fluctuations. 

What we did:

   a) locked the PSL to the X-arm as described in 4153

   b) locked the x-end-NPRO to the X-arm with a PDH lock to the reflected green from the ETMX

   c) Obtained the green beat signal with a spectrum analyser as described in 3771

Observations:

   Please see the attached screen shots from the spectrum analyser.   They are taken with different BW and sweep range settings.  They give a estimate of the width of the green beat signal and the range of the frequency fluctuations of the beat-note.

P1160510.JPGP1160511.JPGP1160515.JPG

P1160516.JPG

 

Estimates:

   a) width of the beat note is less than 6KHz if measured over time scales of a few milli seconds

   b) the frequency fluctuations of the beat note are about 100KHz over time scales longer than 100ms

Next Step:

    We wish to record the beat note frequency as a function of time in order to establish the stability over time scale of a day.

 

 

ELOG V3.1.3-