40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 209 of 327  Not logged in ELOG logo
ID Date Author Type Category Subject
  5991   Wed Nov 23 18:28:09 2011 KojiUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

The following channels have been registered in c1iool0 database, and are now recorded by FB

C1:IOO-RFAMPD_11MHZ
C1:IOO-RFAMPD_29_5MHZ
C1:IOO-RFAMPD_55MHZ
C1:IOO-RFAMPD_DCMON
C1:IOO-EOM_TEMPMON
C1:IOO-EOM_HEATER_DRIVEMON


PROCEDURE

1) The EPICS database file has been edited to rename/add some channels

/cvs/cds/caltech/target/c1iool0/ioo.db

REMOVED
#grecord(ao,"C1:IOO-RFAMPD_VC")
#grecord(ai,"C1:IOO-RFAMPD_TEMP")
#grecord(ai,"C1:IOO-RFAMPD_DCMON")
#grecord(bo,"C1:IOO-RFAMPD_BIAS_ENABLE")
#grecord(bi,"C1:IOO-RFAMPD_BIAS_STATUS")
#grecord(calc, "C1:IOO-RFAMPD_33MHZ_CAL")
#grecord(calc, "C1:IOO-RFAMPD_133MHZ_CAL")
#grecord(calc, "C1:IOO-RFAMPD_166MHZ_CAL")
#grecord(calc, "C1:IOO-RFAMPD_199MHZ_CAL")

ADDED/EDITED
grecord(ai,"C1:IOO-RFAMPD_11MHZ")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S25 @")
...

grecord(ai,"C1:IOO-RFAMPD_29_5MHZ")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S26 @")

...
grecord(ai,"C1:IOO-RFAMPD_55MHZ")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S27 @")

...
grecord(ai,"C1:IOO-RFAMPD_DCMON")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S28 @")

...
grecord(ai,"C1:IOO-EOM_TEMPMON")
                                                
        field(DTYP,"VMIVME-3113")                                               
        field(INP,"#C1 S29 @")

...
grecord(ai,"C1:IOO-EOM_HEATER_DRIVEMON")

        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S30 @")

2) The channels have been added to the frame builder database

/cvs/cds/rtcds/caltech/c1/chans/daq/C0EDCU.ini

[C1:IOO-RFAMPD_11MHZ]
[C1:IOO-RFAMPD_29_5MHZ]
[C1:IOO-RFAMPD_55MHZ]
[C1:IOO-RFAMPD_DCMON]
[C1:IOO-EOM_TEMPMON]
[C1:IOO-EOM_HEATER_DRIVEMON]

Note that this C0EDCU.ini is the file that has been registered in

/cvs/cds/rtcds/caltech/c1/target/fb/master

3) burt restore request files were updated

RFAM related settings were removed as they don't exist anymore.

/cvs/cds/caltech/target/c1iool0/autoBurt.req
/cvs/cds/caltech/target/c1iool0/
saverestore.req

4) c1iool0 were rebooted. Framebuilder restarted. c1iool0 were burtrestored.

  5990   Wed Nov 23 16:55:57 2011 SureshUpdateIOOMC realigned

The PSL alignment into the MC was too poor for the autolocker to engage.  So retaining the last coil slider settings on the MC_Align screen that Kiwamu wanted, I have realigned the PSL beam and recentered the beam on the WFS.

When the WFS_MASTER was burtrestored after the recent power shutdown, the values loaded into the output matrix were not optimal.  When we switch on the WFS loops now, the MC_TRANS loops seem to push the WFS into away from the best possible coupling to PSL.  So I have switched them off for now.   Will load a new optimised output matrix and measure the transfer functions to see what is going on.

 

 

  5989   Wed Nov 23 16:48:39 2011 SureshUpdateGeneralcable cleanup

[Koji Suresh]

As part of the general lab clean up we removed many unused BNC cables (long and short) from around the SP table.  We removed one very long BNC cable which was connected on one side to an PEM input and not connected on the other side near the 1X2 rack..   There were several cables from an old SURF phase camera project which were still attached to a couple of RF amps on the SP tables and running towards the 1X6 rack. 

We also removed some unused power cables  plugged into a power distribution strip near Megatron.

 

  5988   Wed Nov 23 14:47:14 2011 JenneConfigurationEnvironmentAC in the IFO room was off

I turned it back on, maybe around 11am?  Definitely a little while before the 12:30 meeting.

EDIT by KI:

 Sorry, it's me. I was checking if AC was doing something bad on the ALS noise.

  5987   Wed Nov 23 13:53:36 2011 ZachUpdateGreen LockingSensor noise

The in-loop Y-Arm error signal looks equal to the beat note noise divided by the Y-Arm OL gain in the broadband-noise region (>20 Hz), which would be the case if the loop was dominated by sensor noise here.

I would re-check the Y-Arm dark noise, or at least check for coherence between the Y-Arm error signal and the beat signal above 20 Hz. The input-referred PDH box noise should not be flat there according to the LISO model, but that might be worth checking, too.

Yarm_ALS_2011Nov19_marked.png

  5986   Wed Nov 23 02:34:28 2011 MirkoUpdatePEMSeismic spectrum & Striptool

The Striptool for the BLRMS seismic channels is running now. Channels are ( still ) recorded as slow EPICS channels.

A big peak in the 0.1 - 0.3Hz seismic region in both GUR1 and STS1 irritated us for a while. I added an extra LP filter @ 0.05Hz to the RMS_LP modules.

SeismicSpectrum.pdf

 

  5985   Wed Nov 23 00:30:55 2011 ZachUpdateelogsucks

Tried the script 3 times and it didn't come back. Pkill'd and then scripted. That worked.

  5984   Wed Nov 23 00:30:14 2011 ZachUpdateRF SystemEOM temperature controller trials

[Jenne, Zach]

We did some testing of the prototype temperature controller. When I left it late last night, it was not working in conjunction with the real heater and PT100 mounted to the EOM, but had been tested using simulated loads (a spare heater and a potentiometer for the RTD).

We measured each of the reference resistors carefully, as I should have done in the first place since they are only 1% tolerance (I am using 100-ohm ones in series with ~15-ohm ones, so they have a variation of +/- an ohm or so, which is consequential). We calculated the estimated zero-signal resistance of the RTD, then used a trimpot to verify that the AD620 output behaved as expected. We realized that I didn't tie the 620's reference to ground, so the output was floating around by a lot. Once we did that, the readout was still not working properly, but eventually magic happened and we got an appropriate signal. I did find that there was a discrepancy between the estimated zero-signal resistance and that measured across the trimpot with the readout nulled---this may be caused by a small offset in the 620, but is not important so long as the output still scales properly.

Before trying it out again on the real McCoy, I tested the whole, closed-loop circuit with the spare EOM on Jenne's desk. The temperature oscillated at first, but a reduction of gain at the input stage of the driver allowed it to stabilize. The temperature of the EOM (sitting on the electronics bench) was kept constant with a control current that varied from ~40 - 70 mA, depending on how many people were around it, etc. This is pretty much perfect for the quiescent level, but that means that we might have to increase the baseline operating resistance of the PT100 (by changing the reference resistors) once it is sitting in a hot foam box. Otherwise, we will have no gain on the cooling side. I tested the circuit response by cupping my hands over the EOM to increase the temperature and ensuring that the current dropped so as to null the error signal. It worked pretty well, with a thermally-limited bandwidth of I would estimate around 0.1 Hz. 

I went to try it out on the PSL table, but again it didn't work. It turned out that this time I had broken one of the soldered connections from the broken-out D-sub cable to the (tiny) wires going to the PT100, so there was no temperature signal. I resoldered it, but I forgot that there is a thin insulating layer on the wire, so no connection was made. Frank tutored Jenne on how to properly strip these wires without damaging the core, but alas I didn't pay attention.

The RTD/heater/D-sub package lies in wait on Jenne's desk, where I have left an apologetic note. Once it is fixed, we should be able to finally hook it up for realz.

  5983   Wed Nov 23 00:00:53 2011 ZachSummaryGreen LockingSome issues on the Y end green PDH locking

Quote:

(AM transfer function)

 One of the suspicious noise source of the Y arm ALS was an AM effect in the Y end green PDH locking.
A possible scenario is that: there is some amount of the offset in the PDH signal due to the AM at the modulation frequency,
and it allows the intensity noise to couple to the laser frequency, which we want to suppress.
 So we wanted to check if the measured AM (#2799) at 1064 nm  is still true at 532 nm.
The problem right now is that : every time we measured the AM transfer function by exciting the laser PZT with swept sine,
the transfer function varied by 20 dB, with average response of 50 dB. And there was no repeatability.
We were using the PD which is for the green PDH signal and the single-bounced light from ETMY.
The measurement was done in a frequency band of 100 - 400 kHz where we expect a couple of sharp notches.
Perhaps we should try the same measurement with IR first to make sure we are doing a right thing, and then do it with the frequency-doubled laser.

What is meant by the "average response of 50 dB"? Is this dB[ RIN / Hz ] or something? Also, do you mean the average over a broad band or the average response at the chosen modulation frequency over several trials? I don't really understand what measurement was done.

  5982   Tue Nov 22 23:06:13 2011 kiwamuUpdateSUSMC watchdogs

[Rana / Mirko / Kiwamu]

 The watchdogs on the MC suspensions are not working.

Switching off the watchdogs doesn't stop feeding signals to the suspensions.

For tonight, we will leave the controller of the MC suspensions switched off so that the computer won't smash the optics accidentally.

  5981   Tue Nov 22 20:45:21 2011 MirkoUpdateIOOMeasurement of the actuator matrix

Tried measuring the actuator matrix for MC1.

With the watchdogs tripped I cut the loops for pos, pitch and yaw open just before the servos. Then I injected a fixed sine at 0.4Hz into the three DOFs (suspos, suspit, susyaw) one by one, while looking into the error signal just before the servos.

 

                                                         Response DOF

                                     pos                 pit             yaw

Injection DOF pos          0.008417       0.00301        0.004975
                     pit            0.01295         0.01959        0.0158
                     yaw         0.007188        0.002152     0.0144

Inverting that and dividing by the norm gives us

 0.8322   -0.1096   -0.1669
-0.2456    0.2869   -0.2293
-0.3777    0.0118    0.4211

Somehow putting this into the 'To coil' matrix has an effect even with the watchdog tripped!?!?

 

  5980   Tue Nov 22 18:42:10 2011 kiwamuSummaryGreen LockingSome issues on the Y end green PDH locking

[Rana / Kiwamu]

 As a part of the ALS noise budgeting we took a look at the Y end PDH setup to see if we are limited by an effect from the Amplitude Modulation (AM).

Then we found two issues :
 (1) a big variation in AM transfer function from the laser PZT to the intensity of the frequency-doubled laser. We haven't figured out the reason yet,
 (2) some of the optics and their mounts need to be refined.

 


(AM transfer function)

 One of the suspicious noise source of the Y arm ALS was an AM effect in the Y end green PDH locking.
A possible scenario is that: there is some amount of the offset in the PDH signal due to the AM at the modulation frequency,
and it allows the intensity noise to couple to the laser frequency, which we want to suppress.
 So we wanted to check if the measured AM (#2799) at 1064 nm  is still true at 532 nm.
The problem right now is that : every time we measured the AM transfer function by exciting the laser PZT with swept sine,
the transfer function varied by 20 dB, with average response of 50 dB. And there was no repeatability.
We were using the PD which is for the green PDH signal and the single-bounced light from ETMY.
The measurement was done in a frequency band of 100 - 400 kHz where we expect a couple of sharp notches.
Perhaps we should try the same measurement with IR first to make sure we are doing a right thing, and then do it with the frequency-doubled laser.

 

(Y table setup needs more improvements)

  We found some optics and their mounts which need to be refined.
Here is a list which we briefly made at the time.
  • Use washers
  • Beam clipping in Green Faraday and the very last mirror
  • Use two screws and wide base plate
  • Tune PPKTP PID parameters
  • Remove flipper mirror
  • Move the mechanical shutter to where the beam size is smaller
  • Put a beam damp for the reflected light from the PD
  • Cable rack
  • Improve the incident angle on the last two launching mirrors
  5979   Tue Nov 22 18:15:39 2011 jamieUpdateCDSc1iscex ADC found dead. Replaced, c1iscex working again

c1iscex has not been running for a couple of days (since the power shutdown at least). I was assuming that the problem was recurrence of the c1iscex IO chassis issue from a couple weeks ago (5854).  However, upon investigation I found that the timing signals were all fine.  Instead, the IOP was reporting that it was finding now ADC, even though there is one in the chassis.

Since I had a spare ADC that was going to be used for the CyMAC, I decided to try swapping it out to see if that helped.  Sure enough, the system came up fine with the new ADC.  The IOP (c1x01) and c1scx are now both running fine.

I assume the issue before might have been caused by a failing and flaky ADC, which has now failed.  We'll need to get a new ADC for me to give back to the CyMAC.

  5978   Tue Nov 22 15:18:18 2011 kiwamuUpdateGreen Lockingbroad band noise depends on the gain of Y green PDH. and comaprator broken

Quote from #5970
Here is a plot of the latest noise : high frequency noise is still unknown.

(The broad-band noise vs. gain of the Y end green PDH)

 Last night I was trying to identify the broad band noise which is white and dominant above 20 Hz (#5970).

I found that the level of the noise depended on the servo gain of the Y end green PDH loop.

Decreasing the servo gain lowers the noise level by a factor of 2 or so. This was quite repeatable.

(I changed the gain knob of the PDH box from the minimum to a point where the servo starts oscillating)

 

(Malfunction in the comparator)

  However I had to give up further investigations because the comparator signal suddenly became funny: sometimes it outputs signals and sometimes not.

It seems the comparator circuit became broken for some reason. I will fix it.

  5977   Tue Nov 22 14:39:50 2011 JenneUpdateelogAfternoon elog restart

Gave the elog its afternoon / tea-time reboot, since it was hanging yet again.

  5976   Tue Nov 22 06:12:43 2011 ZachUpdateRF SystemPrototype temperature controller

Tonight I built a simpler version of what will be the new general-purpose precision temperature controller. This one is built on a breadboard and will be used for RFAM testing at the 40m until a better version is made. Some  differences between this version and the final one:

  • In the interest of time, this controller senses temperature using a DC wheatstone bridge, instead of the audio-frequency bridge of the final controller.
  • I eschewed the more complicated transistor current source in favor of a simple current buffer. In effect, using a constant-current source is not absolutely necessary, since we are not interested in constant current but rather a constant system temperature. In this sense, it doesn't matter if we have a transistor current source or a transistor voltage source or a current-buffered op amp voltage source; the loop will simply drive the heater with the proper current to keep the error signal nulled. 

So, how it works:

  1. The DC bridge drive voltage is supplied by a voltage-divided and buffered AD587 (low-noise 10-V reference).
  2. The reference resistors are just 1% metal film leaded resistors, but I have put some effort into making them quiet:
    1. Each resistor's body is wrapped in Al tape, and then all the resistors are taped together using Al tape, as well. This is to strongly couple them to each other thermally.
    2. All the reference resistors are embedded in some foam I found in the Bridge sub-B hallway. It's nothing fancy, but it keeps large advection currents from causing thermal drifts.
  3. The sensing element is a PT100 100-ohm RTD. Tempco is ~0.0037 1/K
  4. The bridge differential voltage is read out by an AD620 instrumentation amplifier with G = 100
  5. The AD620 output is fed directly to an OP27 with G = 0-20
  6. This is fed to an LF356 (FET-input op amp, to reduce the effects of bias current when the integrator is on) with a single pole at 0.1 Hz, switchable via jumper to DC for true integration
  7. This is summed with an offset via an OP27 summer (the offset determines the heater current with no signal---half the maximum current of ~120 mA is optimal)
  8. The summer output is buffered with a BUF634, which can provide well over the maximum current we can push through our heater, and the BUF634 directly drives the heater
  9. Between the BUF634 and the heater is a back-biased diode to ground. This is to prevent the current from going negative when the error signal is well below zero.

I have tested the circuit using a spare resistive heater and a potentiometer to simulate the RTD. First I tested the sensing and drive circuits separately, then I connected the sensor output to the drive input and modulated the potentiometer resistance while monitoring the current. The circuit behaved as expected.

When I got to the 40m, it struck me that the resistance I had chosen (115 ohms) corresponded to 40 C, which I realized might be above what we could reach with the current we can provide. I used the Newport 6000 via telnet to drive the heater at several current values and see what the resistance became. I found that with I = Imax/2 ~ 0.6, the resistance was around 113 ohms (it was ~111 at room temp). So, I switched the reference resistor in the leg above the PT100 from 115 -> 113.

I then plugged everything in while monitoring the heater current and AD620 output (error signal), and it seemed not to do anything. I was tired so I figured I'd leave it for tomorrow.

Here is a sketch of the schematic, as well as some pictures:

refres1.pngrefres2.pngproto_temp_ctrl.png

schematic.png

  5975   Tue Nov 22 04:02:47 2011 kiwamuUpdateIOOchanged MC alignment

I have changed the MC2_YAW DC bias because the PZT1_YAW was railing.

I also realigned the steering mirrors in zig-zag path since the mode cleaner tended to resonate with higher order modes after I have changed the MC2 bias.

  C1:SUS-MC2_YAW_COMM =  -1.1548    => -1.1208

  5974   Tue Nov 22 00:19:10 2011 kiwamuUpdateSUSc1auxey hadware rebooted

I found that the slow machine c1auxey, which controls and monitoring the ETMY suspension things, were not responding.

The machine responded to ping but I wasn't able to telnet to it.

I went down there and power-cycled it by keying the power of the VME rack, and then it came back and seems working properly.

I have no idea why it ran into such condition.

  5973   Mon Nov 21 22:51:55 2011 MirkoUpdateCDSc1pem model dead

Quote:

For some reason C1PEM doesn't seem to work anymore after a recompilation. It did recompile fine. We just changed some channel / subsystem names.

Tried reverting to the svn version. Doesn't work. Reboot C1SUS also no good.

 It is fine again. Thanks Jamie.

  5972   Mon Nov 21 17:48:36 2011 KojiUpdateIOORFAM monitoring test

Do we care about the AC? I thought what we care is the DC.

  5971   Mon Nov 21 17:07:34 2011 MirkoUpdateCDSc1pem model dead

For some reason C1PEM doesn't seem to work anymore after a recompilation. It did recompile fine. We just changed some channel / subsystem names.

Tried reverting to the svn version. Doesn't work. Reboot C1SUS also no good.

  5970   Mon Nov 21 16:08:04 2011 kiwamuUpdateGreen Locking2nd trial of Y arm ALS noise budget : broad band noise gone

Quote from #5930

Right now the fluctuation of the green beat-note seems mostly covered by unknown noise which is relatively white.

The 2nd trial of the Y arm ALS noise budgeting :

(Removal of broad band noise)

  + The broad band noise decreased somewhat after I fixed a broken connection in the discriminator.
  + I took a look at the frequency discriminator setup and found one of the SMA-BNC adapter was broken.
     This adapter was attached to one of the outputs of the 4-way power splitter, which splits the signal into the coarse and find discriminator paths.
     And this broken adapter was in the coarse path, which actually I am not using for the noise budget.
     Depending on the stress acting on the adapter it was creating broadband noise, even in the fine path.
     So I threw it away and put another SMA-BNC adapter.
 
Here is a plot of the latest noise : high frequency noise is still unknown.

Yarm_ALS_2011Nov19.png

I will add the dark noise of the broad-band beat-note PD  and the MFD read out noise on the budget.

  5969   Mon Nov 21 15:47:58 2011 MirkoUpdateIOOOsem loop shape

[Jenne, Mirko]

To reiterate: We changed the OSEM loop shape for MC1-MC3. Below in black is the old loop shape, which simulated pendulum response in there. In red is the new loop shape.

OsemFilterShape.pdf

The differences are due to extra filter in C1:SUS-MC?_SUSPOS module 6,7,9

6: Elliptical LP @ 2.5Hz
7: Inverse Chebychev HP @0.3Hz
8: 1st order LP @ 10Hz

This has the potential to be unstable, but is not. At some point these filters should be tuned further.

  5968   Mon Nov 21 14:35:28 2011 kiwamuUpdateIOORFAM monitoring test

REFL_RFAM.png

 This is a trend for a day long showing the REFL11/55 demod signals, REFLDC (corresponding to the MC transmitted power) and the PSL booth temperatire.

There are sudden jumps in the REFL55_I and REFL11_Q signals around 5:00 AM this morning, also at the same time the temperature suddenly went up.

But the quality of the signal turned out to be not so good because the fluctuation is still within 1 bit of the ADCs,

we have to try it again with a bigger gain in the analog whitening circuit.

Quote:

An RFAM measurement is ongoing

  5967   Mon Nov 21 14:15:25 2011 JenneUpdateIOORFAM monitoring test

Quote:

DO NOT CHANGE THE IFO ALIGNMENT UNTIL TOMORROW MORNING OR FURTHER NOTICE.

 [Mirko,  Jenne]

We're playing with the MC OAF, so we're actuating on MC2.  Again, FYI.

  5966   Mon Nov 21 12:48:00 2011 JenneUpdateIOORFAM monitoring test

I don't think I touched/adjusted/whatever anything, but I did open the PSL table ~5-10min ago to measure the size of the Kiwamu-Box, so if the RFAM stuff looks funny for a few minutes, it was probably me.  Just FYI.

  5965   Sun Nov 20 15:33:37 2011 ranaUpdateGeneralrecovery from the power shutdown

 restarted Apache on Nodus for the SVN as per wiki instructions

  5964   Sun Nov 20 15:11:09 2011 kiwamuUpdateIOORFAM monitoring test

DO NOT CHANGE THE IFO ALIGNMENT UNTIL TOMORROW MORNING OR FURTHER NOTICE.

Plus, MC has to be kept locked with the WFS.

 

An RFAM measurement is ongoing

 

 Since the Stochmon turned out to be tricky to calibrate the outputs, Koji and I decided to monitor the RFAMs using REFL11 and REFL55 RFPDs while the beam is single-bounced from PRM.
This is, of course, not a permanent RFAM monitor, but at least it gives us a long-term continuous RFAM information for the first time.
Before the measurement I ran the offset zeroing scripts, therefore any offsets from electronics must be tiny in the acquired REFL signals.
The measurement has begun from approximately 3:00 pm.
 
 Also I found C1LSC.ini file again became default (no channels had been acquired).
So I replaced it with an archived ini file and then restarted fb.
  5963   Sun Nov 20 14:48:55 2011 kiwamuUpdateGeneralrecovery from the power shutdown

Recovery from the power shutdown

 - Turned on the raid disk of linux1.

 - Woke linux1 up. No fsck this time.

 - Woke up all the lab machines.

 - Turned on all the electronics racks' AC powers

 - Woke up fb and then front end machine (the raid for fb had been already up as I turned on the AC powers)

 - Turned on all the electronics racks' DC powers (Sorensens, Kepcos, and etc.)

 - Turned on the Marcnois which is driving the RF generation box.

 - Woke up all the lasers (PSL and End lasers)

 - Some burtrestoring (c1ioo, c1sus, c1susaux, c1msc, c1psl, c1iool0, c1auxey, c1auxex, c1oaf, c1pem)

 - Ran autolockMC scripts on op340m => After relocking of PMC a lock of MC was acquired immediately.

 - Turned on the PZT HV drivers.

 

Some issues

 - One of the Sorensens in 1X8 rack is showing the current limit sign. This is exactly the same situation as we saw before (#5592).

       Currently it's off. It needs an investigation to find who is drawing such a large amount of current.

 - C1SCX is not properly running. Rebooting the machine didn't help. This needs to be fixed.

       The symptom is : (1) all the values are frozen in the screens. (2) the c1scx status screens shows NO SYNC sign. (3) however the timing board looks blinking happily.

 - One of the VME rack on 1X3 is not showing the +/-15V green LED lights.

   This is the one on very upper side of the rack, which contains the old c1lsc machine and c1iscaux2. If we are still using c1iscaux2, it needs to be fixed.

  5962   Sun Nov 20 13:51:54 2011 steveUpdateVACvacuum is back up after ac interruption

State condition: Vac Normal,          CC1 ~8e-6 Torr

The IFO pressure peaked at  8.3 mTorr after 2days of not pumping.

Attachment 1: notpumping.png
notpumping.png
  5961   Sat Nov 19 15:58:04 2011 MirkoUpdateIOOSome more looks into OSEM noise

[Den, Mirko]

We looked some more into the the OSEM signals and their coherence to the seismometer signals.

We were able to verify that the coherence OSEM sensor <-> seismometer signal goes down with increasing the OSEM gain. This seems to indicate that the OSEM FB add noise to the distance mirror <-> frame. We injected some noise into the OSEMs to see how the coherence behaves.

MC2 SUSPOS, 0.1Hz - 0.8Hz, 3mins each

Inj. amplitude   Time(UTC) Note

-                     21:35          Free swinging
-                     21:42          Big LF OSEM gain
-                     21:48          Small LF OSEM gain
150                     21:56          -"-
300                     22:00          -"-
900                     22:05          -"-

Free swinging:

FreeSwinging.png

High OSEM gain:


LocalDampingOn.pdf

Low OSEM gain:

LowOsemGain.pdf

LowOsemGainInj150.pdf

Low_LF_OSEM_Gain_Inj300.fig

LowOsemGainInj900.pdf

 

We left the filters that lower the OSEM gain below 0.3Hz on.

Attachment 2: High_Osem_Gain.pdf
High_Osem_Gain.pdf
Attachment 4: Low_LF_OSEM_Gain.fig
  5960   Sat Nov 19 12:57:55 2011 MirkoUpdateIOOMode cleaner noise projection

Quote:

Could use some more detail on how this measurement was done. It looks like you used the SUSPOS signal with the mirror moving, however, this is not what we want. Of course, the SUSPOS with the mirror moving will always show the mirror motion because the OSEMs are motion sensors.

Instead, what we want is to project how the actual OSEM noise in the presence of no signal shows up as MC length. For that we should use the old traces of the OSEM noise with no magnets and then inject that spectrum of noise into the SUSPOS filter bank with all the loops running. We can then use this TF to estimate the projection of OSEM noise into the MC length.

As far as improving the damping filter, the 2.5 LP is not so hot since it doesn't help at low frequencies. Instead, one can compute the optimal filter for the SUSPOS feedback given the correct cost function. To first order this turns out to be the usual velocity damping filter but with a resonant gain at the pendulum resonance. This allows us to maintain the same gain at the pendulum mode but ~3x lower gain at other frequencies.

In the past, we had some issues with this due to finite cross-coupling with the angular loops. It would be interesting to see if we can use the optimal damping feedback now that the SUS DOFs have been diagonalized with the new procedure.

 The measurement was done with the MC in lock and the OSEMS active.

1. I injected noise into MC1-3 SUSPOS_EXC at a level that domiated the SUSPOS output.
2. Then I calculated the coupling coefficients of the SUSPOS outputs to MC_F during the time the noise is injected.
3. Without noise injection I projected the SUSPOS outputs to MC_F by multiplying the coupling coefficients with the SUSPOS outputs.

All on 11-11-18. White noise inj. from 0.1Hz to 20Hz. Duration 4mins each.

DOF      Amplitude(counts)     Time(UTC)
MC1      200                           22:08
MC2      25                             22:25
MC3      25                             22:50

Some thoughts on this, bare with me:

As you say this does not show the dark / bright noise of the OSEMs. It shows the influence of the OSEMS output onto MC_F in normal operation of the MC. I would have expected that to be very low everywhere except at the pendulum resonance. Reason for that not to be true could either be the OSEMs having considerable gain off of the resonance, or noise intrinsic to the OSEMs knocking the mirrors around. Since we know the OSEM signal to MC_F TF we only need to compare the OSEM signal to OSEM noise to see the noise contribution to MC_F. We know from http://nodus.ligo.caltech.edu:8080/40m/5547 that the OSEM sensor bright noise is considerably below the OSEM signal above 0.1Hz in actual operation. We checked that the MC OSEM signals are above the noise in the reference above 0.1Hz by a factor 3-10.

We actually measured the cost function with the noise projection (valid to 10Hz). It's just the coupling coefficient, right?

CouplingMClengthsToMCF.pdf

 

Attachment 2: NpModeCleaner.pdf
NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf
  5959   Sat Nov 19 10:41:30 2011 ranaUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

I'm quite sure that this is not good: since MC2 can produce a signal in WFS1 and WFS2, it cannot be removed in this way from the actuation without introducing a significant cross-coupling between the MC_TRANS and WFS loops.

Really need loop TFs measured and compared with the model.

The WFS noise model will also show that we need to have a much lower UGF in the MCT loop since that sensor is just a DC QPD: it can never have as good of a sensing noise as a good WFS. In the current case with no Whitening, this is even more so.

  5958   Sat Nov 19 06:04:43 2011 SureshUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

Without adding significant amounts of noise to other WFS loops I have engaged the MC2_TRANS_PIT and YAW loops. 

After several attempts to measure the system response and computing the output matrix, none of which gave any useful results, I gave up on that and decided to find three orthogonal actuation vectors which enable us to close the loops.  So using the last good output matrix (below left side)  as a template, I rounded it off to the nearest set of orthogonal vectors and arrived at the following matrix (right side):

WFS_OUTMx_Lastgood.png        WFS_OUTMATRIX_20111118.png

 

I also decided that WFS1 and 2 need not drive MC2.  This is just to decouple the loops and minimise cross-talk.   This (albeit heuristic)  matrix seems to work pretty well and the real matrix is probably quite close to it.

I show below the suppressed error signals after tweaking the gains a bit.   The blue line is with no WFS, the green one with only WFS1 and 2 loops on, while the red is with all loops turned on.  The WFS1Yaw and MC2_Trans_pit loops might benefit from a more careful study to determine a better output matrix.

WFS_err_MC2T_on_OMx5_20111118.png

  5957   Sat Nov 19 01:26:16 2011 DenUpdateIOOMode cleaner noise projection

Quote:

Instead, what we want is to project how the actual OSEM noise in the presence of no signal shows up as MC length. For that we should use the old traces of the OSEM noise with no magnets and then inject that spectrum of noise into the SUSPOS filter bank with all the loops running. We can then use this TF to estimate the projection of OSEM noise into the MC length.

That's right. The easier problem arises if we consider one of  MC mirrors. The coherence between OSEM sensors and GUR1_X in free moving regime is equal to 0.9 at frequencies 0.1 - 1 Hz. But with local dumping coherence is 0.6. We have

Mirror -> Sensor -> Satellite Module -> Whitening -> ADC -> Computer -> DAC -> Dewhitening -> Satellite Module -> Actuator -> Mirror

Somewhere we produce noise that kills part of coherence. We can use this method with the injection of spectrum of noise into the SUSPOS filter bank only for one mirror and see how the coherence between OSEM sensor and GUR1_X will change. If the change is small, we deal with something else. It the coherence will change from 0.6 to ~0.4, than we have big OSEM noise.

It might be also the problem that the amplitude of COIL_OUT signal is ~25. If it is in counts we may have noise from DAC. 

  5956   Sat Nov 19 00:47:24 2011 ZachUpdateGreen LockingY-Arm locked with PDH Box #17

I installed the newly modified PDH box #17 and locked the Y-Arm.

I wasn't able to bring the REFL level down to the 30% that Kiwamu claimed to get, despite readjusting the alignment---I got ~40-45%. I attained a UGF of ~8 kHz, lower than the 20 kHz that Kiwamu said he got with the temporary setup, probably because the PDH box just isn't as fast. Despite that, it looks like the error suppression is actually better than before...

Here is an error spectrum:

error_sig_m_11_18_11.png

I have to admit that this calibration is worthy of suspicion and should be done more rigorously. I simply used the measured UGF frequency and known servo TF and PZT actuator gain to estimate the optical response. I am pretty confident that it's accurate to within a factor of 3 or so.

  5955   Sat Nov 19 00:34:36 2011 ZachUpdateRF Systemwhy the Newport 6000 isn't working

 I just figured out why the Newport 6000 isn't stabilizing the temperature. It is designed to drive a TEC, so that when the temperature is too high, it just applies a negative current. Of course, this doesn't work with a resistive heater; it just keeps heating it up more.

I'm not sure if Frank has actually used this with a restive heater before, but it doesn't appear that you can limit the low-current level or add an offset.

  5954   Sat Nov 19 00:09:02 2011 ZachUpdateRF SystemFoam house on EOM

Quote:

I used aluminum tape to attach the sensor and heater to the 40m's EOM, and we plugged in the controller.  It seems to be kind of working.  Zach figured out the GPIB output stuff, so we can talk to it remotely. 

I stole the Prologix wireless GPIB interface from the SR785 that's down the Y-Arm temporarily. The address is 192.168.113.108. (Incidentally, I think some network settings have been changed since the GPIB stuff was initially configured. All the Prologix boxes have 131.215.X.X written on them, while they are only accessible via the 192.168.X.X addresses. Also, the 40MARS wireless router is only accessible from Martian computers at 192.168.113.226---not 131.215.113.226).

In any case, the Newport 6000 is controllable via telnet. I went through the remote RTD calibration process in the manual, by measuring the exact RTD resistance with an ohmmeter and entering it in. Despite this, when the TEC output is turned on, the heating way overshoots the entered set temperature. This is probably because the controller parameters (gain, etc.) are not set right. We have left it off for the moment.

Here are a couple command examples:

1. Turning on the TEC output 

nodus:~>telnet 192.168.113.108 1234
Trying 192.168.113.108...
Connected to 192.168.113.108.
Escape character is '^]'.
TEC:OUT on
TEC:OUT
TEC:OUT?
++read eoi
1
 
2. Measuring the current temperature
 
TEC:T?
++read eoi
32.9837
 
3. Reading and then changing the set temperature
 
TEC:SET:T?
++read eoi
34.0000
TEC:T 35.0
TEC:SET:T?
++read eoi
35.0000
 
4. Figuring out that the temperature is unstable and then turning off the TEC (this is important)
 
TEC:T?
++read eoi
36.2501
TEC:OUT off
TEC:OUT?
++read eoi
0
 
(The "++read eoi" lines are the commands you give the Prologix to read the controlled device output.)
 
As I understand, Frank has some code that will pull data in realtime and put it into EPICS. This would be nice.
  5953   Fri Nov 18 23:44:33 2011 ranaUpdateIOOMode cleaner noise projection

Could use some more detail on how this measurement was done. It looks like you used the SUSPOS signal with the mirror moving, however, this is not what we want. Of course, the SUSPOS with the mirror moving will always show the mirror motion because the OSEMs are motion sensors.

Instead, what we want is to project how the actual OSEM noise in the presence of no signal shows up as MC length. For that we should use the old traces of the OSEM noise with no magnets and then inject that spectrum of noise into the SUSPOS filter bank with all the loops running. We can then use this TF to estimate the projection of OSEM noise into the MC length.

As far as improving the damping filter, the 2.5 LP is not so hot since it doesn't help at low frequencies. Instead, one can compute the optimal filter for the SUSPOS feedback given the correct cost function. To first order this turns out to be the usual velocity damping filter but with a resonant gain at the pendulum resonance. This allows us to maintain the same gain at the pendulum mode but ~3x lower gain at other frequencies.

In the past, we had some issues with this due to finite cross-coupling with the angular loops. It would be interesting to see if we can use the optimal damping feedback now that the SUS DOFs have been diagonalized with the new procedure.

  5952   Fri Nov 18 19:57:19 2011 MirkoUpdateIOOMode cleaner noise projection

 

Some more info on this:
 

f > 1 Hz:

At these frequencies the pendulum should be quieter than the stacks. By quite a bit actually since there is the stack resonance at a couple Hz. 'Glueing' them together via the local control is not wise. We put an elliptic LP ( 2.5Hz, 4th order 6dB) into the C1:SUS-MC?_SUSPOS pathes and MC-F got better above 1Hz

MC_ELP.png

Added an extra LP @ 10 Hz afterwards. Doesn't make a visible difference.

f < 1 Hz:

Now here is more stuff to consider.

1. The OSEMs glue the MC mirrors to the stacks
2. The pendulum TF should be 1
3. It shouldn't matter if the OSEMs do or do not act on the mirror at these frequencies, assuming they don't add extra noise.
4. Page http://nodus.ligo.caltech.edu:8080/40m/5547 seems to indicate OSEM sensor noise is so low it can be neglected.

Reduced OSEM gain below 1Hz:

If we reduce the gain in the OSEMs by adding additional HP filters ( cheby2, HP 0.3Hz, 6dB 4th order ) the happens:

1. MC length gets a bit more noisy at low frequencies - should be looked into some more
2. Coherence between the GUR1 seismometer and MC length goes up between 1E-2 and 1E-1 Hz:

( Ref is with low OSEM gain )

WithAndWithoutHPs.pdf

Possible explanation:

The stacks might be more correlatedly moving together than the pendulums. This would be not so nice for OAF test, but really fine for actually using the MC.
Todo: Measure the OSEM to seismometer coherences with high and low OSEM gains.

For reference the seismometer coherence with one another:
SeismCoh.pdf

 

 

  5951   Fri Nov 18 19:07:07 2011 JenneUpdateRF SystemFoam house on EOM

[Jenne, Zach, Frank]

Frank helped Zach and I cable up at PT-100 RTD, and make sure it worked with the Newport Model 6000 Laser Diode Controller.  We're using this rather than the Newport 3040 Temperature Controller because Dmass says the output of that isn't working.  So we're using just the temp control part of the Laser Diode controller.

The back of the controller has a 15-pin D-sub, with the following useful connections.  All others were left Not Connected. 

1 & 2 (same) - Pin 2 is one side of TEC output (we have it connected to one side of a resistive heater)

3 & 4 (same) - Pin 4 is the other side of the TEC output (connected to the other side of the resistive heater)

7 - connected to one side of PT-100 temp sensor

8 - connected to other side of PT-100 temp sensor

I used aluminum tape to attach the sensor and heater to the 40m's EOM, and we plugged in the controller.  It seems to be kind of working.  Zach figured out the GPIB output stuff, so we can talk to it remotely.

 

  5950   Fri Nov 18 16:37:14 2011 steveUpdateVACpreparing for ac power interruption

The vacuum is ready for no AC power for 1 hr on Sunday morning at 10am

 

I did the follwing:

 

Closed V1,  stopped the rotation of TP-1 maglev, waited till it reached 0 Hz_ rpm  and  turned it's controller off.

Closed V4 and stopped TP-2 rotating

Closed all annuloses and VA6

Closed VM1 and opened VM3 This means the RGA is being pumped by TP3. RGA is running in background mode. V5 will close instantly as the AC will be turned off.

VAC STATUS:  IFO envelope and annulosses are not pumped.  P1  pressure will reach 5-6 mTorr by Sunday morning.

                                 The PSL output shutter will be closed by the interlock at 3 mTorr

 

Kiwamu will turn off Piezo Jena PZT power supplies and computers Saturday.

I will be here around 1pm Sunday to star pumping. I will need EPICs MEDM running by than.

Attachment 1: planednopower.png
planednopower.png
  5949   Fri Nov 18 15:45:11 2011 MirkoUpdateIOOMode cleaner noise projection

[Rana, Den, Mirko]

Updated the MC noise projection to include the longitudinal motion of the MC mirrors.

WholeMCNoiseProjection.png

=> Lots of OSEM - local dampling noise!

Consistent with static wiener filter showing only benefits in the 1 - 4Hz region.

Attachment 2: WholeMCNoiseProjection.fig
  5947   Fri Nov 18 15:35:18 2011 kiwamuUpdateIOORF generation box : power switch malfunction

Jenne gave me a spare LED power switch .

I will replace the broken one on Monday.

By the way here is a picture album of the RF generation box which I took last night.

            

Quote from #5942

 The power switch button of the RF generation box is not properly working

  5946   Fri Nov 18 12:11:24 2011 ZachUpdateGreen LockingY end green PDH servo : it's okay

Quote:

 

 Another way to make a 1:100 pole:zero boost is to use resistors and capacitors in a Pomona box 

mixer -> LB box -> Pomona box -> PZT

Pomona Box =     R1 = 7.2 kOhm, C2 = 22 uF, R2 = 72 Ohms     (sr560 = $2400, pomona ~ $50)

 

For the RMS calculation, it would be good to notch out the harmonics. They don't matter since our ALS feedback will have notches at those frequencies.

I wouldn't bother...

  5945   Fri Nov 18 11:28:39 2011 ranaUpdateGreen LockingY end green PDH servo : it's okay

Quote:

Quote from #5914
So I have added an SR560 in the other input of the Newfocus servo box to make the filter shape 1/f^2.
I will post the servo shape and diagram later.

 Another way to make a 1:100 pole:zero boost is to use resistors and capacitors in a Pomona box 

mixer -> LB box -> Pomona box -> PZT

Pomona Box =     R1 = 7.2 kOhm, C2 = 22 uF, R2 = 72 Ohms     (sr560 = $2400, pomona ~ $50)

 

For the RMS calculation, it would be good to notch out the harmonics. They don't matter since our ALS feedback will have notches at those frequencies.

  5944   Fri Nov 18 11:16:08 2011 ranaUpdateIOOeom box

Quote:

I made a super sweet new foam box for our EOM.  It's awesome, and should be reasonably easy to duplicate.  Check out the PHOTOS!

 These are great photos and a nice box, but I fear from the photos that there's too much air getting in. How to pack it so that there's no air flow? How does the temperature sensors wires get in?

  5943   Fri Nov 18 08:29:35 2011 SureshUpdateIOOHEPA air-flow effect on WFS.

[Koji, Suresh]

    We investigated the effect of airflow from the HEPA filters on the PSL beam fluctuation and the resultant noise injected into the WFS loops.   The hint that the WFS are injecting PSL beam jitter into MC mirror motion lies in the MC2_TRANS_PIT and YAW signal's power spectrum shown here.  First, in the blue trace, which shows the spectrum when the WFS loops are off, we see that the WFS1 and WFS2 error signals have a different shape from that of MC2_TRANS.  Since WFS are affected by the PSL beam jitter while the MC2_TRANS_QPD is not, the WFS spectrum contain excess noise, while the MC2_TRANS signals show only the mirror motion.  Next, upon switching on the WFS1 and WFS2 loops, we notice that the MC2_TRANS  spectra acquire the same shape as the WFS spectra.  This shows that the excess noise from the beam jitter has been injected into the MC2 motion, and shows up in the MC2_TRANS spectra.

   To confirm these conclusions we repeated the above measurement with the HEPA fans at 0% (Blue trace), 20% (Red), 30% (Brown) and  100% (Green).   The plots are shown below.  We can see that there is no difference between 0 and 20% levels but beam jitter is visible at 30% HEPA level.  The WFS loops were ON during this time and we can can see the PSL noise injected in to MC2 motion (Green).

WFS_err_HEPA.png

 

The HEPA filter fans are now at 20%.  How can we be sure that they are really working at 20%, since we cannot see any difference between 0 and 20%?

Now that we have this quiet situation, we also investigated the effect (or lack thereof) of switching on the MC2_TRANS loops.  The figure below shows the spectra with all the loops turned off (Blue), with the WFS1 and WFS2  loops turned on (Green)  and with everything turned on (Red).   With the current output matrix, which is the same simple one as the one in this elog, we see some low frequency suppression.  But it also seems to add some noise into the other WFS loops.  I am not sure of this result, due the long duration of this measurement, the seimic noise level may have changed over the course of this measurement.

WFS_err_mc2t_effect.png

As they are not doing any good just now.  I have turned them off by setting the gain in MC2_TRANS PIT and YAW to zero.

 

  5942   Fri Nov 18 02:50:10 2011 kiwamuUpdateIOORF generation box : power switch malfunction

[Suresh / Kiwamu]

 The power switch button of the RF generation box is not properly working

For tonight we are leaving it as it is but it needs to be fixed at some point.

 

(the Story)

While I was working around the green broad-band RFPD, I noticed that the RFPD was detecting the 25 MHz modulation signal.
To confirm if it really comes from the modulation source, I switched OFF the RF generation box by pressing the blue LED power button on the rear side of it.
The 25 MHz signal in the RFPD disappeared. So it was indeed the 25 MHz modulation signal.
Then I pressed the LED button again to bring it ON, but the switch didn't stay in the clicked position.
Keeping pressing the button could make it ON but once I released my finger from it it became OFF.
So the mechanical thing in the LED button is not properly working.
I removed the box from the 1X2 rack to take a look at it.
With a help from Suresh we somehow managed to keep it ON after several trials of pressing it.

The temporary solution we decided is to leave it ON so that we can survive tonight.

The box was back in place. The MC is find and 11 MHz and 55 MHz seem okay.

 

Please be aware of it.

 

broken_power_switch.png

This is a picture showing the rear view of the RF generation box. The red arrow is pointing the blue LED switch button.

  5941   Fri Nov 18 01:51:37 2011 KojiUpdateIOOStochmon update

Update of the stochmon status

[Attachment 1: Circuit diagram]

- The new stochmon has a low noise amplifier (MAR-6SM) inside.
The RFAM signal from the PD has the power of -60~-50dBm, which is almost at the bottom of the sensitivity for the power detector.

- The band pass filters were doubled.

- I've suffered from some RF coupling from the power line as the power detector is quite sensitive to it.
The situation has been largely improved by the EMI filters in the power supply path, although the problem is still present.
The worst remaining problem is that we can not close the aluminum lid as it cause a huge sprious coupling.

 

[Attachment 2: Calibration result]

- The outputs were calibarted with Marconi. They showed the signals linear to dBm for the input powers between -70dBm and -10dBm.

- The calibration result was fitted with the empirical fit function. The function and the results are shown in the attachment.

[Attachment 3: Detection limit]

- The attached figure shows the power spectrum of the PD output. This measurement gives us the amount of the RF power given from the PD noise when there is no RF signal.

11MHz out passband noise: −72.7dBm ===> V11 = 2.0483
30MHz out passband noise: −64.6dBm ===> V30 = 1.9333
55MHz out passband noise: −71.2dBm ===> V55 = 2.0272

- Now 11MHz and 55MHz outputs seem indicating the power correctly, but the 29.5MHz output never provides useful information.
It is a constant value independent from the state of the incident beam. Strangely this problem disappears if the marconi is used
for the RF source. Thus this issue is not seen in the calibration measurement.

- So far, 11MHz, 29.5MHz, 55MHz, and DC outputs appear in the channels C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_133MHZ, C1:IOO-RFAMPD_166MHZ, and C1:IOO-RFAMPD_199MHZ.
They will be renamed.

Attachment 1: stochmon.pdf
stochmon.pdf
Attachment 2: stochmon_calib.pdf
stochmon_calib.pdf
Attachment 3: RFAM_PD_noise.pdf
RFAM_PD_noise.pdf
ELOG V3.1.3-