40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 209 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  619   Tue Jul 1 21:54:05 2008 KojiUpdateGeneralRe: Abs. Length Meas. setup
I tried to look for the beating in the signal from the PD but I couldn't find. I had the temperature of the laser initially set to 40deg and then slowly increased by one degree. The manual of the laser says the frequency should change by several GHz. The problem is then that our PD is limited to no more than 30Mhz.

Although the two beams seem to overlap quite well, we might still need a better matching of the injected beam.


Alberto


Quote:
o The position of the iris was adjusted so as not to disturub the beam for OMCR CCD.

o The RF spectrum analyzer was returned to the place of the network analyzer.


Quote:

In the process of making this report, I noticed that one of the iris apertures is about disturbing the beam for OMCR CCD. I will check this before I go to Hanford. Also an RF spectrum analyzer is at the AP table. I try to return this near the PSL on Monday morning.
  5652   Tue Oct 11 19:11:25 2011 kiwamuUpdateLSCRe: BS actuator reponse at low frequency : measured

I think the precision due to the loop gain uncertainty is something like 0.1% at 0.1 Hz. It's not the issue.

The real issue was the loud motion of MICH, which degrades the coherence of the measurement.

Also last night I tried the fringe hopping technique and gave it up for several reasons.

 

(uncertainty due to the loop gain)

When MICH is locked, the signal at C1:LSC-MICH_OUT can be expressed in frequency domain by
 
     MICH_OUT = G / (1+G) * (1 / A) * X + G / (1+G) * (1 / H) * (1 / A) * S,                 [1]
 
where G is the open loop gain, A is the actuator response, H is the sensor transfer function (constant factor),
X is the natural (unsuppressed) motion of MICH and S is an excitation injected at C1:LSC-MICH_EXC.
When the natural motion of MICH X is smaller than the excited displacement S/H, dividing MICH_OUT by S gives
 
   [Transfer function] = S / MICH_OUT
                                 = (1+G) /G * H * A
 
At low frequency the open loop gain is always big, so that the transfer function can be approximated to
 
   [Transfer function] ~ H *A
 
This approximation is valid with a precision of 1/G.
In my case yesterday, the open loop gain at 0.1Hz was about 103 or more than that, so the uncertainty due to the loop gain was 0.1% or even less.
 

(Effect from the MICH motion)

In the equation [1], it is shown that the MICH motion X shows up together with the excitation signal.
Actually this MICH motion term was not completely negligible and eventually this term disturbs the measurement resulting in a low coherence.
In order to get a high coherence in the measurement, X should be smaller than the excited displacement S/H,
 
      X << S / H
 
This the reason why I had to inject a big excitation signal. Although the coherence around 1Hz turned out to be still low due to the loud natural motion in MICH.
The excitation was already close to 0.1 um level in terms of peak-to-peak displacement, and I wasn't able to increase it any more because the MICH signal would run into a nonlinear regime.
In the worst case I lost the lock due to a too much excitation.
 
 
(Fringe hopping technique)
 
Actually I tried and gave up this technique. That's why I did the in-loop measurement.
My feeling is that this technique is not suitable for the 40m.
What I tried was to flip the sign of the MICH control such that the fringe hops from the dark fringe to the neighbor bright fringe or vice versa.
Difference in the control signal (C1:LSC-MICH_OUT) was supposed to give us the amount of signal which drives the actuator by exactly quarter of the laser wave length.
However this technique turned out to be not good because
    (1) BS actuator is too strong
          => expected difference in the control signal is quite small.
          => \lambda / 4 / A ~ 12 counts, where A is the actuator DC response of about 2.2e-8 [m/counts].
   (2) MICH motion was too loud
         => I saw such a tiny 12 counts difference in the control signal, but once the hopping is done the control signal immediately fluctuated and it was really hard to precisely measure it.
         => It's simply because MICH was loud, and the actuator tried to suppress the motion and it resulted such an immediate signal fluctuation in the control signal

Quote from #5649

This seems like an error prone method for DC responses due to the loop gain uncertainty. Better may be to use the fringe hopping method (c.f. Luca Matone) or the fringe counting method

 

  4948   Wed Jul 6 18:15:26 2011 kiwamuUpdateSUSRe: BS oplev spectra

[Steve / Kiwamu]

Motivation:

 Since the oplevs were the ones we haven't carefully tested, so the oplevs need to be checked.

This checking is also a part of the suspension optimizations (see the minutes of the last 40m meeting).

 In this work Steve will check two things for all the oplevs :

    1. Noise level including the dark noise, electrical noise and ADC noise to just make sure that the noise are blow the signal levels below ~ 30Hz.

    2. The spectra of the signals to make sure there are no funny oscillations and unexpected structures

 

Measurement :

  To check the things listed above, we take two kinds of oplves' spectra :

     1. "dark noise" when the He-Ne beam is blocked.

     2. "signals" when the optics are damped by only OSEMs

 We did these checks on the BS oplev today (see the last entry).

All of them are fine, for example the dark noise (including electrical noise and ADC noise) are below the signal levels.

And no oscillation peak was found. Steve will go through all of the oplevs in this way.

Quote from #4947

Healthy BS oplev

  13479   Fri Dec 15 00:26:40 2017 johannesUpdateCDSRe: CDS recovery, NFS woes
Quote:

Didn't touch Xarm because we don't know what exactly the status of ETMX is.

The Xarm is currently in its original state, all cables are connected and c1auxex is hosting the slow channels.

  4611   Tue May 3 13:22:13 2011 LeoUpdateSUSRe: DRMI prep : suspension diagnostic

Here are the free-swinging spectra for the BS, ETMX, ETMY, ITMX, ITMY, MC1, MC2, MC3, and PRM chambers.  Kiwamu left the suspensions free for 5 hours this weekend, starting at Sat Apr 30 00:15:26 2011.

This is GPS time 988 182 941.  Quick tip: you can do local to GPS time conversions using lalapps_tconvert, which is a lot like tconvert but with special powers.  It is installed on pianosa.

$ lalapps_tconvert Sat Apr 30 00:15:26 2011

988182941

I generated these figures with the attached Python script, measure.py.

Notice that the C1:SUS-ITMX_SENSOR_UL and C1:SUS-MC3_SENSOR_UL spectra fall as 1/f.  Jenne suggested that this might indicate that there is a loose electrical connection.

Also, notice that C1:SUS-ETMY_SENSOR_LR, C1:SUS-ITMY_SENSOR_LL, and C1:SUS-PRM_SENSOR_SIDE are a lot noisier above 10 Hz.

Attachment 1: BS.png
BS.png
Attachment 2: ETMX.png
ETMX.png
Attachment 3: ETMY.png
ETMY.png
Attachment 4: ITMX.png
ITMX.png
Attachment 5: ITMY.png
ITMY.png
Attachment 6: MC1.png
MC1.png
Attachment 7: MC2.png
MC2.png
Attachment 8: MC3.png
MC3.png
Attachment 9: PRM.png
PRM.png
Attachment 10: SRM.png
SRM.png
  4613   Tue May 3 15:04:20 2011 kiwamuUpdateSUSRe: DRMI prep : suspension diagnostic

Jenne went through all the suspension racks and pushed all the connectors.

After pushing them, we had a quick look at those spectra and found no funny noise spectrum except for C1:PRM-SENSOR_UL.

We then checked connection around the SCSI cables and eventually found the connection between ADC_card_0 and a SCSI was loose.

We put short standoffs on the ADC card so that the screws from the SCSI can nicely reach to the ADC card. Now everything looks fine.

SUS diagnostic is quite useful !

Quote from #4611

Notice that the C1:SUS-ITMX_SENSOR_UL and C1:SUS-MC3_SENSOR_UL spectra fall as 1/f.  Jenne suggested that this might indicate that there is a loose electrical connection.

  5153   Tue Aug 9 11:33:33 2011 kiwamuUpdateSUSRe: ETMX free swinging data

I believe that the 17 Hz broad structure on SIDE is just because of a bad rotational angle of the SIDE OSEM.

The same structure had been observed on the EMTY_UR, and the structure became narrower after we repositioned/rotated the OSEM yesterday.

My guess is that the SIDE OSEM is now in a place where the OSEM is quite sensitive to the bounce mode

and creating the broad structure due to a bi-linear coupling between the bounce mode and low frequency signals.

Quote from #5150

There is something defintely wrong with the side sensor.  It might be the electronics as it also has this problem with it slow channel readings (my previous elog today). 

  5221   Sat Aug 13 02:31:42 2011 kiwamuUpdateSUSRe: ETMY hopefully good again

I guess the ETMY suspension is still fine. Their OSEM DC voltage and the free swinging spectra look healthy.

It could be a failure in the initial guess for fitting.

Quote from #5216

I'm no longer convinced that ETMY is healthy. I can't fit the peaks to get the input matrix.

  5237   Mon Aug 15 13:16:50 2011 JenneUpdateSUSRe: ETMY hopefully good again

Quote:

I guess the ETMY suspension is still fine. Their OSEM DC voltage and the free swinging spectra look healthy.

It could be a failure in the initial guess for fitting.

Quote from #5216

I'm no longer convinced that ETMY is healthy. I can't fit the peaks to get the input matrix.

 Turns out I was missing a critical step in the process...running makeSUSspectra.m  After I do that, everything is back under control, and ETMY looks fine. 

I'm almost done doing the peak-fitting and matrix inversion for all optics.

  1753   Wed Jul 15 18:22:15 2009 KojiUpdateCamerasRe: GigE Phase Camera

Quote:

Koji recommended that we use the optical setup pictured below.  Although it uses fewer optics, I can't think of a way to test the phase camera using this configuration because any modulation of the wavefront with a lens or whatever would be automatically corrected for in the PLL so I think I'll have to stick with the old configuration.

I talked with Zach. So this is just a note for the others.

The setup I suggested was totally equivalent with the setup proposed in the entry http://131.215.115.52:8080/40m/1721, except that the PLL PD sees not only 29.501MHz, but also 1kHz and 59.001MHz. These additional beating are excluded by the PD and the PLL servo. In any case the beating at 1kHz is present at the camera. So if you play with the beamsplitter alignment you will see not only the perfect Gaussian picture, but also distorted picture which is resulted by mismatching of the two wave fronts. That's the fun part!

The point is that you can get an equivalent type of the test with fewer optics and fewer efforts. Particularly, I guess the setup would not be the final goal. So, these features would be nice for you.

  3340   Sat Jul 31 10:12:05 2010 kiwamuUpdateVACRe: How to stop and start slow pumpdown

I resumed the pumping down. It started from 9:55 am.

  3341   Sat Jul 31 14:59:33 2010 kiwamuUpdateVACRe: How to stop and start slow pumpdown

I stopped the pumping at 14:50 pm because I was going back home. I did the same procedure as Koji wrote down (see here).

The P1 pressure reached 32 Torr.

Koji will take over the pumping shift tonight. 

  4921   Thu Jun 30 11:36:54 2011 JamieUpdateSUSRe: ITMX whitening, ETMX left free swinging

Quote:

While closing up the whitening shop for the night, I noticed that the ITMX whitening state (Whitening "On") is opposite that of all other suspensions (they all have Whitening "Off").  I don't know which way is correct, but I assume they should all be the same.  Once all the whitening and BO testing is done, we should make sure that they're all the way we want them to be.

This was certainly my fault, probably left over from early debugging of my BO switch check script.  I've turned the ITMX whitening all off, to match the other suspensions.

Quote

Also, Koji and I are leaving ETMX free swinging.  That's the way we found it, presumably from Jamie's BO testing at the end station today.  We don't know what the optic's story is, so we're leaving it the way we found it.  Jamie (or whomever left it free swinging), can you please restore it when it is okay to do so?  Thanks!

Again, this was my fault.  Sorry.  I just accidentally left this off when I finished yesterday.  Much apologies.  I've turned the ETMX watchdog back on.

  5338   Fri Sep 2 17:57:18 2011 kiwamuUpdateSUSRe: ITMY released without opening chambers

It stacked again . We should take a closer look at it.

Quote from #5326

The ITMY mirror was released. The OSEM readouts became healthy.

 

  4627   Wed May 4 15:22:39 2011 kiwamuUpdate Re: Intermittent MC3 UL PD signal

I went push all the possible connectors for the MC3 shadow sensors including the SCSIs, flat cables and satellite box.

Also I put screws on them so that they won't become loose any more.

As a result UL_PDMON dropped from 0.6 V to 0.490 V and it becomes stable so far.

I didn't strain relief the cables but we must do it at some point before going into the full locking test.

Quote from #4625

The attached plot shows the 30 day trend of the MC3 UL PD signal. The signal dropped to zero at some point but now it is close to the level it was a few weeks ago. There still could be a problem with the cable.

The rest of the MC1,2,3 PD signals looked ok.

 

  7570   Wed Oct 17 19:35:58 2012 KojiUpdateComputersRe: Lots of new White :(

Solved. The power code of c1iscaux was loose.
Has anyone worked around the back side of 1Y3?


I looked into the problem. I went around the channel lists for each slow machines and found the variables are supported by c1iscaux

controls@pianosa:/cvs/cds/caltech/target/c1iscaux 0$ cd /cvs/cds/caltech/target/c1iscaux
controls@pianosa:/cvs/cds/caltech/target/c1iscaux 0$ grep C1:IF *
C1IFO_STATE.db:grecord(ai,"C1:IFO-STATE")

It seemed that the machine was not responding to ping. I went to 1Y3 and found the crate was off. Actually this is not correct.
The key was on but the power was off. I looked at the back and found the power code was loose from its inlet.
Once the code was pushed in and the crate was keyed, the white boxes got back online.

Just in case I burtrestored these slow channels by the snapshot at 6:07am on Sunday.

  7574   Thu Oct 18 08:00:40 2012 jamieUpdateComputersRe: Lots of new White :(

Quote:

Solved. The power code of c1iscaux was loose.
Has anyone worked around the back side of 1Y3?


I looked into the problem. I went around the channel lists for each slow machines and found the variables are supported by c1iscaux

controls@pianosa:/cvs/cds/caltech/target/c1iscaux 0$ cd /cvs/cds/caltech/target/c1iscaux
controls@pianosa:/cvs/cds/caltech/target/c1iscaux 0$ grep C1:IF *
C1IFO_STATE.db:grecord(ai,"C1:IFO-STATE")

It seemed that the machine was not responding to ping. I went to 1Y3 and found the crate was off. Actually this is not correct.
The key was on but the power was off. I looked at the back and found the power code was loose from its inlet.
Once the code was pushed in and the crate was keyed, the white boxes got back online.

Just in case I burtrestored these slow channels by the snapshot at 6:07am on Sunday.

I was working around 1Y2 and 1Y3 when I wired the DAC in the c1lsc IO chassis in 1Y3 to the tip-tilt electronics in 1Y2.  I had to mess around in the back of 1Y3 to get it connected.  I obviously did not intend to touch anything else, but it's certainly possible that I did.

  5173   Wed Aug 10 14:30:55 2011 kiwamuUpdateIOORe: MC A2L alignment

I modified a set of the automated MC locking scripts which are dedicated for the low power MC.

Currently there are three scripts like the usual MC locking scripts:

(1)mcup_low_power, (2) mcdown_low_power and (3) autolockMCmain40_low_power.

I ran those scripts on op340m as usual and so far they are running very well. The lock acquisition is quite repeatable.

I hope theses scripts always bring the lock condition to the same one and hence the LOCKIN signals don't change by every lock.

 

- To run the script

  log into op340m and run autolockMCmain40m_low_power

Quote from #5167

And the MC settles into a new position when the MC-PSL servo loop was disturbed by random denizens in the lab.  Requiring us to start over again.

 

  5238   Mon Aug 15 14:07:39 2011 kiwamuUpdateIOORe: MC misaligned a lot

The leveling was still okay. The MC mirrors were realigned and now they all are fine.

We will go ahead for the vertex alignment and extraction of the pick-off beams.

 

Here is a summary of the spot measurement.

    Feb 26 2011      May 08 2011 Aug 2 2011  Aug 10 2011 (in air) [NEW!!] Aug 14 2011 (in air)
MC1 pit [mm]   1.6   1.9  1.93 -0.858 -0.2
MC2 pit [mm]   6.4   9.0 9.03 -0.844 -0.8
MC3 pit [mm]   1.4   2.0 2.01 -1.03 -0.1
MC1 yaw [mm]   -1.5   -1.7 -1.72 -0.847 -1.1
MC2 yaw [mm]   1.0   0.2 0.178 0.582 0.6
MC3 yaw [mm]   -1.3   -1.9 -1.87 -1.06 -1.1

 

Quote from #5236

Anyways we should check the leveling of the IOO table and the spot positions on the MC mirrors again to make sure.

 

  4643   Thu May 5 15:28:23 2011 kiwamuUpdateLSCRe: MI locking : calibration of BS and ITMs actuators

They are the DC responses.

I put the resonant frequencies that Leo reported in the wiki to obtain the DC response.

The resonant frequencies I used are :

  f_BS = 0.957 Hz

  f_ITMX = 0.966 Hz

  f_ITMY = 0.988 Hz

Also I assumed that all the Q-values are 5 due to the damping.

Quote:

I've got confused

1) Are these the DC responses of the coils? If that is true, we need to specify the resonant frequency of each suspension to get the AC response.

2) Are these the AC responses well above the resonant freqs? In that case, The responses should be x.xxx / f^2 [m/counts]

Quote:

 BS = 3.69e-08 [m/counts]
 ITMX = 8.89e-09 [m/counts]
 ITMY = 9.22e-09 [m/counts]

 

  1373   Mon Mar 9 11:09:33 2009 AlbertoUpdateComputersRe: Not even data retrieval working

Quote:
Although getting the regular DAQ data works, we can't get any testpoints.

I tried restarting tpman several times; there's no inittab on fb40m for this so we should get Alex to set one up when he comes.
I also tried various power cycles and reboots: daqawg, daqctrl, etc. I also notice that Osamu's setup of new stuff is connected to
the same rack and power strips as all of our sensitive DAQ machines. We should find out if there was any hardware installed in the
last couple days; it would be easy to accidentally unplug or damage on of our fibers.

I moved the old tpman.log over to tpman.log.090308. It starts out with a header and then just lists when each TP is requested.

When restarting tpman it puts the following into the terminal:
fb:controls>./tpman &
[1] 1037
fb:controls>VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
Channel list length for node 0 is 4168
Test point manager (31001001 / 1): node 0
which is OK?; its the same startup outputs that are in the old log file. It would be nice if there was not and error message about the RFM.
Requesting new testpoints via tdsdata, dtt, or the diag command line doesn't seem to work. tpman doesn't spit anything out although 'tp show 0'
does show that the TP is selected.

Once Alex fixes the 'tpman' issue, we should make sure to put an inittab or startup script in there so that tpman writes a log
file and also archives its old log files upon a restart.


Alex fixed the problem. It was caused by the awgtpman running on kami1.martian which conflicted with the tpman in fb0.

Killing awgtpman on kami1 allowed for the tpman on tp0 to work properly again.

If more test points are needed, Alex suggested to tune the GDS settings accordingly.
What this actually means, I still have to understand it.
  2920   Wed May 12 10:33:32 2010 kiwamuUpdateGreen LockingRe: Reflection from ETM and ITM !

The procedure you wrote down as a standard is right.   I explain reasons why we didn't do such way. 

For our situation, we can rotate the polarization angle of the incident beam by using a HWP in front of the Faraday.  

This means we don't have to pay attention about the PBS_in because the rotation of either PBS_in or the HWP causes the same effect (i.e. variable transmission ). This is why we didn't carefully check the PBS_in, but did carefully with the HWP.

Normally we should take a maximum transmission according to a instruction paper from OFR, but we figured out it was difficult to find a maximum point. In fact looking at the change of the power with such big incident (~1W) was too hard to track, it only can change 4th significant digit ( corresponds to 1mW accuracy for high power incident ) in the monitor of the Ophir power meter. So we decided to go to a minimum point instead a maximum point, and around a minmum point we could resolve the power with accuracy of less than 1mW.

After obtaining the minimum by rotating the HWP, we adjusted the angle of PBS_out to have a minimum transmission.

And then we was going to flip the Faraday 180 deg for fine tuning, but we didn't. We found that once we remove the Faraday from the mount, the role angle of the Faraday is going to be screwed up because the mount can not control the role angle of the Faraday. This is why we didn't flip it.

Quote:

I could not understand this operation. Can you explain this a bit more?

It sounds different from the standard procedure to adjust the Faraday:

1) Get Max transmittion by rotating PBS_in and PBS_out.

2) Flip the Faraday 180 deg i.e. put the beam from the output port.

3) Rotate PBS_in to have the best isolation.

 

 

  2921   Wed May 12 12:25:11 2010 KojiUpdateGreen LockingRe: Reflection from ETM and ITM !

??? I still don't understand. What principle are you rely on?

I could not understand why you rotated the HWP to the "minimum" transmission
and then minimized the transmission by rotating the output PBS. What is optimized by this action?

Probably there is some hidden assumption  which I still don't understand.
Something like:
Better transmission gives best isolation, PBS has some leakage transmission
of the S-pol light, and so on.

Tell me what is the principle otherwise I don't accept that this adjustment is "to get a good isolation with the Faraday".

P.S. you could flip the faraday without removing it from the V-shaped mount. This does not roll the Faraday.

Quote:

The procedure you wrote down as a standard is right.   I explain reasons why we didn't do such way. 

For our situation, we can rotate the polarization angle of the incident beam by using a HWP in front of the Faraday.  

This means we don't have to pay attention about the PBS_in because the rotation of either PBS_in or the HWP causes the same effect (i.e. variable transmission ). This is why we didn't carefully check the PBS_in, but did carefully with the HWP.

Normally we should take a maximum transmission according to a instruction paper from OFR, but we figured out it was difficult to find a maximum point. In fact looking at the change of the power with such big incident (~1W) was too hard to track, it only can change 4th significant digit ( corresponds to 1mW accuracy for high power incident ) in the monitor of the Ophir power meter. So we decided to go to a minimum point instead a maximum point, and around a minmum point we could resolve the power with accuracy of less than 1mW.

After obtaining the minimum by rotating the HWP, we adjusted the angle of PBS_out to have a minimum transmission.

And then we was going to flip the Faraday 180 deg for fine tuning, but we didn't. We found that once we remove the Faraday from the mount, the role angle of the Faraday is going to be screwed up because the mount can not control the role angle of the Faraday. This is why we didn't flip it.

Quote:

I could not understand this operation. Can you explain this a bit more?

It sounds different from the standard procedure to adjust the Faraday:

1) Get Max transmittion by rotating PBS_in and PBS_out.

2) Flip the Faraday 180 deg i.e. put the beam from the output port.

3) Rotate PBS_in to have the best isolation.

 

 

 

  5776   Tue Nov 1 16:02:15 2011 kiwamuUpdateSUSRe: SUS input matrix diagonalizer REMOVED from crontab

Quote:

It turns out that nodus doesn't know how to NDS2, so I can't run diagAllSUS as a cron job on nodus. To further complicate things, no other machines can run the elog utility, so I am going to have to do something shifty...

 Actually in the last 40m meeting we discussed the SUS diagnosis and decided not to post the results on the elog.

Alternatively we will have a summary web page which will contain all the information (sensitivity, UGF monitors, etc.,) and will be updated everyday like GEO.

This will be a place where we should post the SUS results every week.

So we don't need to worry about the cron-elog job, and for running the scripts you can simply use one of the lab machines as a cron host.

Once you get the scripts running on a machine as a cron job, it will be the point where we should quit developing the SUS diagonalizer and pass it to the web summary people.

  4195   Mon Jan 24 13:08:07 2011 kiwamuUpdateGreen LockingRe: X arm locked !

Quote: #4192

Also, the PLL diagram seems to show that you have a 1/f^2 loop: 1/f from the SR560 and 1/f from the Hz->rad conversion ??

Well, the diagram I drew is true. I also have been confused by this 1/f^2 issue in our PLL.

As Rana pointed out, the open-loop TF should become 1/f^2 over most of the frequency range, but it still remains 1/f above 5kHz for some reasons. 

 Need more investigations.

e_pll_oltf.png

 At the beginning I tried phase-locking the VCO to the beat note without any external filters (i.e. SR560 see here), but I never succeeded.

It was because the hold-in range of the PLL was not sufficiently wide, it could stay locked within frequency range of less than +/- 1MHz from the center frequency of 80 MHz.

This is obviously not good, because the beat note typically fluctuates by more than +/- 3MHz in time scale of 1 sec or so.

  So I decided to put an external filter, SR560,  in order to have a larger DC gain and a higher UGF.

Somehow I unconsciously tuned the SR560 to have a pole at 1Hz with the gain of 2000, which shouldn't work in principle because the open-loop will be 1/f^2.

However I found that the PLL became more robust, in fact it can track the input frequency range of +/- 5MHz.

The open-loop TF is shown above. For comparison I plotted also the open-loop TF wehn it's without the SR560.

I checked the frequency of the VCO output when it was phase-locked to a Marconi, it was healthy (i.e. the same frequency as the input signal from Marconi).

  4196   Mon Jan 24 14:27:13 2011 kiwamuUpdateGreen LockingRe: X arm locked !

Quote: #4193

So, how is the IR error signal stabilized when the IR is brought in to the resonance?

I can see the linear trend of 0.1V/s from 5s to 10s.  This corresponds to 100kHz/s and 13nm for the residual beat drift and the arm length motion, respectively. That sounds huge.

 I haven't yet taken any data for the IR fluctuation when the Xarm is locked by the green locking.

You are right, the DC drift was due to a lack of the DC gain. But don't worry about that, because this issue has been solved.

 


(DC gain issue)

  The lack of DC gain was because I put an IIR filter called ''DC block" that I made. It has 1/f shape below 30mHz and becomes flat above it.

The purpose of this filter was to avoid a DC kick when it starts feeding back to ETMX.

Usually the output signal from the PLL has an offset, typically ~5V, then this offset is also acquired into the ADC and eventually kicks ETMX through the feedback.

So when I took the time series data I enabled the 'DC block', that's why it drifts slowly.

 After taking the time series, I found that without this 'DC block' technique, the lock can be achieved by appropriately subtracting the offsets with epics numerical values.

This subtraction technique, of course, gave me more stable lock at DC.

 


(open loop transfer function)

Here is the open-loop TF of the arm locking I measured last night:

masslock_oltf.png

The IIR filter chain has the following poles and zeros:

     pole 0.1Hz, 1000Hz,

   zero 1Hz, 30Hz

For the fitting I assume that the ETMX pendulum has a resonance at 1Hz with Q of 5. Also I put the cavity pole at 24 kHz, assuming the finesse is 80 at 532 nm.

I just fitted the gain and the time delay by my eyes.

If I believe the result of the fitting, whole time delay is 330 usec, which sounds pretty large to me.

  4413   Fri Mar 18 16:06:30 2011 kiwamuUpdateGreen LockingRe: Y arm plan for today

We use Alberto's laser for the Y end Green Locking.

Quote:

 Which laser are we going to use,  Alberto's laser or MOPA laser ?

 

  4414   Fri Mar 18 16:31:11 2011 Suresh UpdateGreen LockingRe: Y arm plan for today

The reason for using Alberto's laser is that some amount of work has already gone into characterising its phase noise.  Ref elog entry 2788

  5125   Fri Aug 5 15:11:24 2011 kiwamuUpdateSUSRe: cross coupling

There is a page on the 40m wiki explaining the procedure.

  http://blue.ligo-wa.caltech.edu:8000/40m/OSEM_adjustment_proceedure

 

Additionally there are several old elogs about the cross-coupling minimization, which can be useful for us:

[1] "SUS ranking from measured data", iLog by Osamy (Aug.22 2005)

[2] "TF from position to sensors for ETMX ", iLog by Osamu (Aug.25 2005)

[3] "Further OSEM tweaking", iLog by Rana (Oct.3 2006)

Quote from #5123

We need a plan how to minimize cross coupling in the OSEMs now

 

  3414   Thu Aug 12 18:30:08 2010 kiwamuUpdateCDSRe: current status

Yes.  

The medm screen C1SUS_GDS_TP.adl showed some numbers which correspond to that I wrote  on the outputs.

But I still could not get any physical voltage coming from the DACs.

Quote:

 When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything? 

  2374   Wed Dec 9 21:09:28 2009 kiwamuUpdateSUSRe: free swinging spectra of ETMY and ITMX

Okay, now the data are attached. At that time I just wanted to say like the follower.

- - -

In the free-swinging spectra around ~0.5Hz, you can see the two resonances, which come from pitch and yaw mode of the pendulum.

Note that, the vertical and the horizontal axis are adjusted to be the same for the two plots in the figure .

And I found that

* the floor levels are almost the same (the factor of about 1.5 or something like that) compared to the past.

* however the peak heights for two resonances are several 10 times smaller than the past.

* this tendency are shown in all of the data (ITMX, ETMX, ETMY).

If such variation of the peak heights is cased by the seismic activity, it means the seismic level change by several 10 times. It sounds large to me.
 

Quote:

Where is the plot for the trend?
It can be either something very important or just a daydream of you.
We can't say anything before we see the data.

Quote:

By the way I found a trend, which can be seen in all of the data taken today and yesterday.

The resonances of pitch and yaw around 0.5Hz look like being damped, because their height from the floor become lower than the past.

I don't know what goes on, but it is interesting because you can see the trend in all of the data.

 

 

Attachment 1: Pitch-Yaw_modes.png
Pitch-Yaw_modes.png
  2375   Thu Dec 10 00:46:15 2009 KojiUpdateSUSRe: free swinging spectra of ETMY and ITMX

Well, I get the point now. It could be either seismic or change in the suspension Q.

The pendulum memorizes its own state for a period of ~ Q T_pend. (T_pend is the period of the pendulum)
If the pendulum Q is very high (>104), once the pendulum is excited, the effect of the excitation can last many hours.

On the other hand, in our current case, we turned on the damping once, and then turned off the damping.
Again it takes ~Q T_pend to be excited. 

In those cases, the peak height is not yet before in equilibrium, and can be higher or lower than expected. 

So, my suggestion is:
Track the peak height along the long time scale (~10hrs) and compare between the previous one and the current one.
This may indicate whether it is equilibrium or not, and where the equilibrium is.

Quote:

If such variation of the peak heights is cased by the seismic activity, it means the seismic level change by several 10 times. It sounds large to me.

 

  3315   Thu Jul 29 10:39:43 2010 kiwamuUpdateSUSRe: installation of in-vac optics

I updated the last entry about the in-vac work (see here)

  3092   Sun Jun 20 18:28:25 2010 kiwamuUpdateGreen LockingRe: lock with PDH box

On the wiki I summarized about the modification of the PDH box which is currently running on the end PDH locking. 

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

The box was newly labeled "G1" standing for "Green locking #1".

Quote:

by using a modified PDH box the green laser on the X-end station is locked to the arm cavity.

  4922   Thu Jun 30 11:40:21 2011 JamieUpdateIOORe: misc. MC work

Quote:

Jamie has started to revert the "ALTPOS" effect on the MC mirrors. So far, the screens and SLOW channels have been fixed, but the fast channels still say "ALTPOS" in the dataviewer instead of "MCL".

 The framebuilder just needed to be restarted to pull in the fixed channel names.  I restarted the framebuilder and now the channels (C1:SUS-MC2_MCL_*) are showing up properly.

  5005   Wed Jul 20 19:48:03 2011 JamieUpdateSUSRe: oplev gains today

 

 We have been modifying models that need to have their channels renamed to run activateDQ when Joe's post_build_script to is run. 

The trick is to integrate things to get the post_build_script running after every model build (getting it hooked in to the make file somehow).  We're working on it.

 I've added the following epics channels to sus_single_control model using the epicsOutput part:

  • OL_SUM
  • OL_PITCH
  • OL_YAW

These channels are now all available.  I'm not exactly sure how to ensure that they're being trended.  I'll check that tomorrow.

  3614   Tue Sep 28 00:07:45 2010 kiwamuConfigurationVACRe: slow vent has started

(Koji, Yuta, Kiwamu)

P1_history_100927.png

Now the pressure at P1 is 740 torr, which is close to the atmospheric pressure of 760 torr.

We changed the air cylinder twice in this evening, and the last cylinder ran out at about 23:00 pm.

We left it as it is. Steve is going to make a final touch for it tomorrow morning.

  2529   Tue Jan 19 03:27:47 2010 kiwamuUpdateElectronicsRe: triple resonant circuit for EOM

1. You are right, the gain for the single resonant circuit was about 9.3 in my measurement.

But the reason why the triple is better than the single resonant circuit comes from the transformer.

The impedance can be degraded by a loss of the transformer, because it got worse after applying the transformer in the past measurement.

Also I definitely confirmed that the circuit had the impedance of 7.2 kOhm at the resonance of 52.9MHz without the transformer.

So it shall give the gain of 12, but did not after applying the transformer.

 

2.  Yes, I think we need some variable components just in case.

 

5.  For the impedance matching, I will select a transformer so that 55MHz is matched. In contrast I will leave two lower resonances as they are.

This is because 11MHz and 29.5MHz usually tend to have higher impedance than 55MHz. In this case, even if the impedance is mismatched, the gain for these can be kept higher than 11.

I will post the detail for this mismatched case tomorrow.

 

Quote:

The design looks very good. I have some questions.

1. As far as I remember, you've got the gain of slightly worse than 10 for a 55MHz single resonant case. Why your expectation of the gain (G=11) for the highest resonance better than this?

Supposing the loss exists only on the EOM, the other part of the LC network for the triple work as an inductor at the resonant frequency. This is just equivalent as the single resonant case. So the expected gain at 55MHz should coincides with what we already have. Probably, the resistance of 4 Ohm that is used here had too rough precision???

2. How can you adjust the resonances precisely?

Do we need any variable components for Cs and Ls, that may have worse quality than the fixed one, generally speaking.
I myself has no experience that I had to tune the commercial EOM because of a drift or whatever. I hope if you can adjust the resonance with a fixed component it should be fine.

3. Changing Cp. What does it mean?

Do you put additional cap for Cp?

4. The resonances for the lower two look very narrow. Is that fine?

This will show up in a better shape if we look at the transfer function for the gain. Is this right?

If we have BW>100kHz, it is sufficient.

5. Impedance matching for the lower two resonances.

Yep. You know this problem already.

 

 

  5105   Wed Aug 3 11:34:59 2011 kiwamuUpdateVACRe: vent

An important rule during the in-vac work :

   Do not change the incident axis of the X and Y green beams.

Because of the air flows and unusual pressure in the chambers, the DC alignment of the suspensions become less reliable in terms of the beam pointing reference.

The green beams will be considered as references during the vent.

Quote:

The vacuum system is coming up to atm. The vent was started with slow N2 flow.

  3330   Fri Jul 30 09:51:58 2010 kiwamuUpdateGreen LockingRe: waist positon of Gaussian beam in PPKTP crystals

Okay, I guess I understand what you want to know. I did the following steps.

1. calculated the conversion efficiency as a function of the waist size. I found w~50um was the optimum waist.

  Note: the confocal relation Zr = pi * wo^2/(lamba/n) = L/2  gives us almost the same optimum waist. 

elog #2735

efficiency_waist_edit.png

  2.  Did mode matching to get w=50um

elog #2959

elog #3188

PPKTPmode.png

PSL_doubling.png

  3. calculated the offset

elog #2850

mode_in_PPKTP.png 

 4. Moved the ovens

 

Quote:

I thought we cared about satisfying the confocal focusing parameter, that is to say we want to set Zr = 2L_crystal. If Zr changes inside the crystal, this is the number we care about..isn't it NOT the waist size, but the rayleigh range we care about? I am not entirely sure what youre response is saying you did...

  1. Calculate Zr = pi * wo^2/(lamba/n)
  2. Do mode matching to get this wo in free space
  3. Calculate the offset you need to move the oven by using n
  4. Move hte ovens

OR

  1. Calculate Zr = pi*wo^2/(lamba)
  2. Do mode matching to get this in free space
  3. Calculate the offset you need to move your ovens using n
  4. Move your ovens

I guess the waist size would also let me know - are you using 69 um or 53 um waist size?

 

  4321   Fri Feb 18 00:13:55 2011 kiwamuUpdateCDSRe:Daqd was rebuilt, now reverted.

THANK YOU, JOE !!! 

Quote:

As one of the trouble shooting steps for the daqd (i.e. framebuilder) I rebuilt the daqd executable.

  4724   Mon May 16 10:05:02 2011 kiwamuUpdatePhotosRe:ETMY optical bench

You are right. We should change or rotate the mirror mount.

Actually when Suresh and I were putting the mirror we rotated the mount  by 90 deg such that the fat side of the mount is at left had side.

It was because the fat side had been clipping the oplev beam when the fat side is at right.

At that moment we were blocking the green beam to only see the faint IR beam with a sensor card, so we haven't checked the green beam.

Anyway the mount is apparently not good for the green beam.

Quote from #4723

I didn't notice it the other day when I was working on putting in the trans QPD, but do we need to switch the mirror mount for the first turning mirror of the IR trans beam, which the green transmits through to go into the cavity?  It seems like we've set ourselves up for potential clipping.

 

  5508   Wed Sep 21 23:25:51 2011 kiwamuUpdateSUSRe:ITMY and SRM actuator response functions - fitting results

Did you take the 180 deg shift into your account ?

Since your measurement was done when the loop was closed, there must be an additional 180 deg phase shift (in other words, minus sign).

Quote from #5507

In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?

  5509   Wed Sep 21 23:44:45 2011 PaulUpdateSUSRe:ITMY and SRM actuator response functions - fitting results

Quote:

Did you take the 180 deg shift into your account ?

Since your measurement was done when the loop was closed, there must be an additional 180 deg phase shift (in other words, minus sign).

Quote from #5507

In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?

 I thought I had, but apparently not, and I'd made another error or two in the complex version of my fitting routine. I've fixed them now, thanks! I'll put up the new fitting results tomorrow morning.

  5537   Sat Sep 24 02:09:43 2011 kiwamuUpdateSUSRe:Oplev filter optimization for 2 poles and 2 zeros

Good work for the oplev noise simulations. Here are some comments/questions:

 (A) The noise looks suppressed but the open-loop transfer function doesn't look so good, because it doesn't have sufficient phase margins at the UGFs (0.01 and 10 Hz).

      I guess it is better to have a phase margin detector in your code so that the code automatically rejects a bad phase margin case.

      Actually since the number of data points are finite, the rms detector in the simulation can not always find a sharp loop oscillation.

 (B) The resultant poles and zeros seem canceling each other but the filter still has a structure. Is something wrong ?

Quote from #5332

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz

  5540   Sat Sep 24 17:45:56 2011 PaulUpdateSUSRe:Oplev filter optimization for 2 poles and 2 zeros

Quote:

 (B) The resultant poles and zeros seem canceling each other but the filter still has a structure. Is something wrong ?

Quote from #5332

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz

 Ah yes, well noticed. I think I have tracked this down to just a bug in printing of fitting results: It was just printing the pole results for the zeros too. The results for the same fit now read:

 

 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0972455 Hz 

 Zero 2 frequency = 6.50126 Hz 

Overall gain = 71970.1

EDIT: sorry, I forgot that when you write a reply, the author is still by default the person you are replying to unless you change it!

 

  5820   Sat Nov 5 04:30:21 2011 kiwamuUpdateGreen LockingRe:Passive summing box modifications

I think you also should check the PZT's capacitance of the 700mW LightWave because 2.36 nF is the one for the 1W Innolight laser.

Quote from #5807

To combat this, I propose we simply change the resistor in the modulation path from 1M to 10k. This leaves the feedback path TF unchanged, and changes the mod path into a sort of bandpass filter for the modulation frequency. The fact that the phase is near zero at fmod means we don't have to come up with some way to phase shift the signal for demodulation.

  2533   Tue Jan 19 23:26:07 2010 kiwamuUpdateElectronicsRe:Re: triple resonant circuit for EOM

Quote:

5.  For the impedance matching, I will select a transformer so that 55MHz is matched. In contrast I will leave two lower resonances as they are.

This is because 11MHz and 29.5MHz usually tend to have higher impedance than 55MHz. In this case, even if the impedance is mismatched, the gain for these can be kept higher than 11.

I will post the detail for this mismatched case tomorrow.

 

Here the technique of the impedance matching for the triple resonant circuit are explained.

In our case, the transformer should be chosen so that the impedance of the resonance at 55MHz is matched.

We are going to use the transformer to step up the voltage applied onto the EOM.

To obtain the maximum step-up-gain, it is better to think about the behavior of the transformer.

When using the transformer there are two different cases practically. And each case requires different optimization technique. This is the key point.

By considering these two cases, we can finally select the most appropriate transformer and obtain the maximum gain.

 

 


( how to maximize the gain ?)

Let us consider about the transformer. The gain of the circuit by using the transformer is represented by

eq1.png         (1)

Where ZL is the impedance of the load (i.e. impedance of the circuit without the transformer ) and n is the turn ratio.

It is apparent that G is the function of two parameters, ZL and n.  This leads to two different solutions for maximizing the gain practically. 

 

matching_edit.png

 

  - case.1 : The turn ratio n is fixed.

In this case, the tunable parameter is the impedance ZL.  The gain as a function of ZL is shown in the left figure above.

In order to maximize the gain, Z must be as high as possible.  The gain G get close to 2n when the impedance ZL goes to infinity.

There also is another important thing; If the impedance ZL is bigger than the matched impedance (i.e. ZL = 50 * n^2 ), the gain can get higher than n.

 

  - case.2 : The impedance ZL is fixed.

In contrast to case1, once the impedance ZL is fixed, the tunable parameter is n. The gain as a function of n is shown in the right figure above.

In this case the impedance matched condition is the best solution, where ZL=50*n^2. ( indicated as red arrow in the figure )

The gain can not go higher than n somehow. This is clearly different from case1.
 

 

( Application to the triple resonant circuit )

Here we can define the goal as "all three resonances have gain of more than n, while n is set to be as high as possible"

According to consideration of case1, if each resonance has an impedance of greater than 50*n^2 (matched condition) it looks fine, but not enough in fact.

For example if we choose n=2, it corresponds to the matched impedance of 50*n^2 = 200 Ohm. Typically every three resonance has several kOhm which is clearly bigger than the matched impedance successfully.

However no matter how big impedance we try to make,  the gains can not be greater than G=2n=4 for all the three resonance. This is ridiculous.

What we have to do is to choose n so that it matches the impedance of the resonance which has the smallest impedance.

In our case, usually the resonance at 55MHz tends to have the smallest impedance in those three. According to this if we choose n correctly, the other two is mismatched.

However they can still have the gain of more than n, because their impedance is bigger than the matching impedance. This can be easily understand by recalling the case1.

 

(expected optimum gain of designed circuit)

 By using the equation (1), the expected gain of the triple resonant circuit including the losses is calculated. The parameters can be found in last entry.

designed_response.png

The turn ratio is set as n=11, which matches the impedance of the resonance at 55MHz. Therefore 55MHz has the gain of 11.

The gain at 11MHz is bigger than n=11, this corresponds to the case1. Thus the impedance at 11MHz can go close to gain of 22, if we can make the impedance much big.

 

  2609   Tue Feb 16 16:24:30 2010 kiwamuUpdateGreen LockingRe:Re:take some optics away from the ETM end table

I put the TRY_PD back to the end table and aligned it. Now it seems to be working well.

Quote:

The PD Kiwamu removed from the Y table was TRY, which we still need.

My bad if he took that. By mistake I told him that was the one I installed on the table for the length measurement and we didn't need it anymore.

I'm going to ask Kiwamu if he can kindly put it back.

 I am going to put the PD back to the Y end table in this afternoon.

 

  3460   Mon Aug 23 22:11:52 2010 kiwamuUpdateTreasureRe:Seriously?

Woops, I am sorry about that. I've just cleaned them up.

Quote:

Bad CDS team. Bad. 

ELOG V3.1.3-