40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 208 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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. 

  3323   Thu Jul 29 17:12:48 2010 josephb, kiwamuUpdateCDSRe:Working out ADC/DAC/BO wiring

We have installed  4 BO boards, 3 DAC boards and 1 ADC board for new C1SUS.

They are on the 1Y5 rack. 

 

 DSC_2302.png

  5838   Mon Nov 7 22:20:18 2011 kiwamuUpdateGreen LockingRe:YARM length fluctuation

A nice plot !

Can you put another y-axis on the right hand side of the same plot  in terms of the cavity displacements ?

And can you also measure a more important spectrum, namely the suppressed error signal ?

Quote from #5837

I measured the power spectrum of channel C1:GCY_SLOW_SERVO1_IN1, which is the PZT driving voltage.

  4080   Mon Dec 20 23:32:58 2010 kiwamuUpdateIOORe:checking out & closing the vacuum chambers

  2740   Wed Mar 31 11:52:32 2010 kiwamuSummaryGreen LockingRe:conversion efficiency of PPKTP

Good point. There is a trick  to avoid a divergence.

Actually the radius of the cylindrical wave is set to the spot size at the surface of the crystal instead of an actual beam waist. This is the idea Dmass told me before.

So that the radius is expressed by w=w0(1+(L/2ZR)2)1/2, where w0 is beam waist, L is the length of the crystal and ZR is the rayleigh range.

In this case the radius can't go smaller than w0/2 and the solution can not diverge to infinity.

Quote:

Question:

Why does the small spot size for the case (A) have small efficiency as the others? I thought the efficiency goes diverged to infinity as the radius of the cylinder gets smaller.

 

 

 

  4090   Wed Dec 22 21:38:47 2010 kiwamuConfigurationVACRe:slow pumpdown at 12 hours

I stopped the pumping at 9:30 pm. Now we are at 29 torr.

Quote: from  #4089

How to stop pumping:

1,  close RV1 manual valve with torque wheel

2, close V3

3, turn off roughing pumps RP1 & RP3

4, disconnect metal hose connection to butterfly valve

 

  4038   Thu Dec 9 22:04:40 2010 kiwamuUpdateSUSRe:strange ETMX suspension

[Koji, Osamu and Kiwamu]

We checked the ETMX suspension and found the UR OSEM was close to the magnet.

So we rotated the UR OSEM so that it won't touch the magnet any more.

We will check the resonant frequencies again by taking the spectra.

--

  In fact the ETMX stacked when we applied a big angular offset to Yaw direction.

This was because that the magnet was actually touching the UR OSEM.

The earthquake stops were fine, they weren't touching the test mass.

Also we looked at the wire and the standoffs, they seemed fine.

Quote: #4036
We are going to inspect the suspension today.

  2606   Tue Feb 16 11:12:51 2010 kiwamuUpdateGreen LockingRe:take some optics away from the ETM end table

Quote:

Quote:

In the last two days Steve and I took some optics away from the both ETM end table.

This is because we need an enough space to set up the green locking stuff into the end table, and also need to know how much space is available.

Optics we took away are : Alberto's RF stuff, fiber stuff and some optics obviously not in used.

The picture taken after the removing is attached. Attachment1:ETMX, Attachment2:ETMY

And the pictures taken before the removing are on the wiki, so you can check how they are changed.

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

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.

  3457   Mon Aug 23 18:18:22 2010 kiwamuConfigurationSUSRe:watchdogs off

Now watchdogs are back.

The suspensions are well damped.

  2447   Tue Dec 22 18:42:40 2009 Sanjit, KojiConfigurationAdaptive FilteringReadded DAQ channels to active list

Sometimes back we modified /cvs/cds/caltech/chans/daq/C1ASS.ini to save some of the channels. The file was reverted to default after the recent changes in ASS.

We again uncommented and made acquire=1 to save the following three channels using daqconfig:

C1:ASS-TOP_ERR_MCL_IN1_2048

C1:ASS-TOP_PEM_15_IN1_2048

C1:ASS-TOP_PEM_18_IN1_2048

The script automatically created a back up in /cvs/cds/caltech/chans/daq/archive

 

  889   Tue Aug 26 19:07:37 2008 YoichiHowToComputersReading data from Agilent 4395A analyzer through GPIB from *Linux* machine
I succeeded in reading data from Agilent 4395A analyzer, who's floppy is crappy, through GPIB from a Linux machine using
agilent 82357B USB-GPIB interface.
I installed the linux GPIB driver to one of the lab. laptops (the silver DELL one currently sitting on the 4395A analyzer).
I wrote an initialization script for the USB-GPIB interface and a small python script for reading data from the analyzer.

[Usage]

1. Connect the USB-GPIB interface to the laptop and the analyzer.
2. Run /usr/local/bin/initGPIB command (it takes about 10sec to complete).
3. Run /usr/local/bin/getgpibdata.py > data.txt to save data from the analyzer to a text file.

The data format is explained in the comments of getgpibdata.py
This method is way faster than the unreliable floppy. The data is transfered in a few sec.

I'm now writing a wiki page on this
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB

I will install the same thing into the other DELL laptop soon.
Let me know if you have trouble with this.
  9597   Tue Feb 4 17:40:19 2014 manasaUpdateGeneralReady for pump down??

Quote:

* PRM suspension has not been behaving well. PRM is being kicked around every 5-10 seconds when the PRC is aligned (as seen on REFL camera). We are not sure where this is coming from. The first time we saw this happening was when we were trying to lock PRC at low power even before we took the heavy doors off. So we are pretty sure this is not caused by the foil cover on the OSEMs. We tried turning ON/OFF the oplev servo, turning ON/OFF the damping loops and also checked the connections in the feedthrough and satellite box for the PRM. The OSEM sensor values for the suspension also seem to match the ones on the wiki.

 

This is solved.

The ASC for PRC for left turned ON. Turning it OFF solved the problem.

If there is no feedback regarding the POP alignment or anything to check with modified PRC length, we will close tomorrow morning.

  9598   Tue Feb 4 23:01:24 2014 JenneUpdateGeneralReady for pump down??

 

 This sounds great! The only suggestion that I have is for checking POP. If you have the beam on the camera, you can hold a card in front of each mirror, and find out where the edge of the beam is. Introduce the card from the side, and watch for the point where you just start to see the beam on the camera be obstructed. Repeat for the other side, and you have an idea of the centering of the beam. 

I think this is most important for the in-vac mirrors, since the beam is large-ish, and we have to hit both steering mirrors at ~45 degrees.

  9601   Wed Feb 5 15:26:57 2014 manasaUpdateGeneralReady for pump down??

Quote:

 

 This sounds great! The only suggestion that I have is for checking POP. If you have the beam on the camera, you can hold a card in front of each mirror, and find out where the edge of the beam is. Introduce the card from the side, and watch for the point where you just start to see the beam on the camera be obstructed. Repeat for the other side, and you have an idea of the centering of the beam. 

I think this is most important for the in-vac mirrors, since the beam is large-ish, and we have to hit both steering mirrors at ~45 degrees.

 [EricQ, Manasa]

This check was done and we had to move one of the steering mirrors in pitch. Else, everything was just fine.

In-vacuum pictures of PR2 and PR3 new positions were taken. MC spot positions measured to be < 1mm and oplevs were centered.

  14390   Tue Jan 8 19:13:39 2019 JonUpdateUpgradeReady for pumpdown tomorrow

Everything is set for a second pumpdown tomorrow. We'll plan to start pumping after the 1pm meeting. Since the main volume is already at 12 torr, the roughing phase won't take nearly as long this time.

I've added new channels for the TP1 analog readings (current and speed) and for the two N2 tank pressure readings. Chub finished installing the new regulator and has run the transducer signal cable to the vacuum rack. In the morning he will terminate the cable and make the final connection to the Acromag.

Gautam and I updated the framebuilder config file, adding the newly-added channels to the list of those to be logged. We also set up a git repo containing all of the Python interlock/interfacing code: https://git.ligo.org/40m/vacpython. The idea is to use the issue tracker to systematically document any changes to the interlock code.

  11488   Mon Aug 10 22:18:19 2015 IgnacioUpdateIOOReady to do some online mode cleaner subtraction

I'm attaching a SISO IIR Wiener filter here for reference purposes that will go online either tonight or tomorrow evening. This is a first test to convince myself that I can get this to work, MISO IIR filters are close to being ready and will soon be employed. 

This Wiener filter uses the STS-X channel as a witness and MCL as target. The bode plot for the filter is shown below,

The performance of the FIR and IIR Wiener filters and the ammount of subtraction achive for MCL is shown below,

 

Output from quack to be loaded with foton: filter.zip

K bye.

Attachment 1: stsx.png
stsx.png
Attachment 2: performance.png
performance.png
Attachment 3: filter.zip
ELOG V3.1.3-