40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 218 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  6016   Sat Nov 26 07:22:20 2011 sureshUpdateComputers 

c1sus has been shutdown so that the optics dont bang around.  This is because the watch dogs are not working.

  6015   Sat Nov 26 07:18:11 2011 SureshUpdateIOOMC WFS related changes to c1ioo model

What I did:

    I have changed the c1ioo model such that the signals which are demodulated in the WFS lockin (the SIG inputs) are now picked up just after the input matrix.  This permits us to put a notch filter at the excitation frequency into the WFS servo filterbanks and thus prevent the excitation of all the actuators when we wish to excite just one of them. 

 

The Problem:

    I had followed the procedure of determining the TF coefs between actuators (MC1,2,3 P and Y ) and sensors (WFS1, 2 and MC2Trans P and Y)  and found the output matrix by inverting this TF coef matrix. However these matrices, once substituted for the heuristically determined matrices were always unsuccessful in keeping the WFS servo lock.  The reason appeared to be that when the loops are closed the exitation of one actuator led to the excitation of all actuators through the cross couplings in the output matrix.    In order to prevent this we need a notch filter in the servo filter banks.   But then we will not be able to see the sensor response after the servo filters since the response at 10Hz would be blocked from reaching the lockins.  So I shifted the point at which we sample the sensor response to a point before the WFS servo filters. 

The solution:

a) shift the point where the lockin input signals are picked up in the c1ioo model.

b) retune the lockin servo phases to minimise Q phase

c) edit the WFS lockin scripts to ensure that the 10Hz notch is turned on

d) measure the TF coefs and compute the -1*inverse

e) plug it into the output matrix and tweak the gains to ensure a stable lock

f) examine cross talk by comparing the expected TF in each loop with the expected loop TF.

 

Current state:

  I have completed steps a to e above.  The loops are stable and the error signal is suppressed (see attached pdf files)

To be done:

  The open loop transfer function has to be compared with expected OLTF to be sure we have minimised cross talk.

 

Attachment 1: WFS_err_20111127.png
WFS_err_20111127.png
Attachment 2: cioo_20111127.png
cioo_20111127.png
  6014   Sat Nov 26 02:15:42 2011 MirkoUpdateSUSNot adaptive, still cool

[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz

PendulumQ0.1HzWithElip2comma5HzLpWfsOnCorrectedShape.pdf

Filter shape:

VirtualPendulumFilterShape.pdf

This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.

 

 

Attachment 3: SetupVirtualPendulumV2.png
SetupVirtualPendulumV2.png
  6013   Sat Nov 26 02:05:43 2011 MirkoUpdateCDSBeware of fancy filter modules

 

We replaced the complicated Cheby filter module with three separate filter modules. Probably the filter doesn't need to be so complicated, but rather not change too many things at once. The new filter modules are called:
Ch1, Ch2, Ch3 and are in filter module 3,9, and 10 of the C1:SUS-MC?_SUSPOS filters. The coherence with these filters is fine. Someone should look into the possibility of simplifying these filters.

It would be good to check for numerical problems in other filters!

  6012   Fri Nov 25 23:25:24 2011 MirkoUpdateIOOF2A filter for MC

Quote:

Woo. Pretty crazy. The numerators should only be ~10% larger than the denominator below 1 Hz. Let's try again.

 [Rana, Mirko]

I redid this calculation. The idea behind it is to get rid on any pitch that is introduced by applying longitudinal feedback to the mirrors. This coupling happens because the center of percussion for pitch , which is identical with the point where the wires lift off of the mirror, is above the center of mass.

With the same values as before, just less faulty math and Q = 2 instead of 10 we end up with the following filters:

For the lower coils (red), compared to corresponding preexisting BS filters (black):

F2aForMCcomparedToBS.pdf

The upper coils' TF is just mirrored at the 0dB magnitude axis, and have a corresponding frequency response.

I switched the F2a filters on for all MC mirrors. For convenience they are split into F2aZeros and F2aPoles. Everything seems fine. The F2a filters seem to be off for ( all ?) other mirrors.

  6011   Fri Nov 25 22:11:12 2011 MirkoUpdateCDSBeware of fancy filter modules

[Rana, Den, Mirko]

It seems you can shoot yourself in the foot if your filter modules are too complex.

Den discovered this when looking into the C1:SUS-MC?_SUSPOS filter module named Cheby, consisting of cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501) by noticing that the coherence between input and output of the filter is low.

Cheby filter:

Cheby.png

CoherenceCheby.pdf

This is most likely due to the filter spanning more than the 16 orders of precision that the double data type spans.

The coherence is fine when one splits the filter in two, giving every cheby1 filter its own module. The coherence is also fine when you use the Cheby filter in a 2kHz system, although the freq. response looks very odd

Black: 16kHz, Red 2kHz (yes the filter was converted correctly, no text file editing there)

ChebyAt16kHzBlackand2kHzRed.png

The problem occurs on c1lsc as well as c1sus computer.

 

Looking into the foton files actually points to a precision problem, with the huge range of scale covered in there:

C1:MCS 16kHz (Cheby: Original filter with low coherence. CHbyTST & ChebyTST: Original filter split amongst two filter modules)
################################################################################
### SUS_MC3_LSC                                                              ###
################################################################################
# DESIGN   SUS_MC3_LSC 0 zpk([0],[30],0.333333,"n")
# DESIGN   SUS_MC3_LSC 1 cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 2 cheby1("LowPass",2,0.1,3)gain(1.13501) \
#                       
# DESIGN   SUS_MC3_LSC 3 cheby1("LowPass",2,0.1,3)gain(1.13501)cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
###                                                                          ###
SUS_MC3_LSC 0 12 1  32768      0 30:0.0          9.942903833923793  -0.9885608209680459   0.0000000000000000  -1.0000000000000000   0.0000000000000000
SUS_MC3_LSC 1 21 3      0      0 CHbyTST     9.095012702673064e-18  -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 2 12 1  32768      0 ChebyTST    1.228759186937126e-06  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
                                                                 -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 4 12 8  32768      0 BounceRoll     0.9991466189294013  -1.9996634951844035   0.9997010181703262  -1.9999611719719754   0.9999999999999997
                                                                 -1.9999303040590390   0.9999684339228864  -1.9999605309876360   0.9999999999999999
                                                                 -1.9999248796830529   0.9999668732412945  -1.9999594299327190   1.0000000000000002
                                                                 -1.9996385459838455   0.9996812069238987  -1.9999587601905868   1.0000000000000000
                                                                 -1.9996161812709703   0.9996978939989944  -1.9999163485656493   0.9999999999999999
                                                                 -1.9998855694973159   0.9999681878303275  -1.9999154056705493   0.9999999999999998
                                                                 -1.9998788577090287   0.9999671193335300  -1.9999137972442669   1.0000000000000000
                                                                 -1.9995951159123118   0.9996843310430819  -1.9999128255920269   1.0000000000000000

C1:OAF 2kHz
###############################################################################
### YARM_IN                                                                  ###
################################################################################
# DESIGN   YARM_IN 0 zpk([0],[30],0.333333,"n")
# DESIGN   YARM_IN 3 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)
# DESIGN   YARM_IN 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
# DESIGN   YARM_IN 8 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)zpk([],[10],1,"n")
###                                                                          ###
YARM_IN  0 12 1   4096      0 30:0.0           9.56649943398763  -0.9119509539166185   0.0000000000000000  -1.0000000000000000   0.0000000000000000
YARM_IN  3 12 4   4096      0 Cheby       1.829878084970283e-16  -1.9828889048300398   0.9830565293861987   2.0000000000000000   1.0000000000000000
                                                                 -1.9868188576622443   0.9875701115261976   2.0000000000000000   1.0000000000000000
                                                                 -1.9940934073784453   0.9954330165532327   2.0000000000000000   1.0000000000000000
                                                                 -1.9781245722853238   0.9784022621062476   2.0000000000000000   1.0000000000000000

Attachment 1: ChebyTST3.png
ChebyTST3.png
  6010   Fri Nov 25 20:41:48 2011 ranaUpdateSUSMC watchdogs

It seems as if someone was looking into this on Wednesday, but as there's no elog, I think probably not.

Tonight we noticed that, in fact, the watchdogs don't work for any of the corner optics (I confirmed that they do work for the ETMs).

Whether the switch for the coil drivers is enabled or disabled, the voltage monitor on the coil drivers responds to the digital signals.

I tried restarting the c1susaux process, hitting reset on the crate, and also keying the crate. The +5V light on the front of the crate is flickering somewhat, but I'm not sure if this is new or not since the power outage. The next step is to track the Xycom signal from the card over to the coil driver to find where the signal is failing to happen.

Since its not working for any of the corner optics, I suspect the crate and not the cards. If that's the issue this will be a painful fix. We are sort of assuming that this is due to the power outage, but in fact, I cannot tell when the last time was that someone rigorously verified the working of these switches. [

I][B]We had better get ready for upgrading our SLOW controls, Jamie.[/B][/I]

Quote:

[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.

 

 

  6009   Fri Nov 25 20:03:05 2011 KojiUpdateIOOStochmon update

 New RFAM mon calibration

Attachment 1: stochmon_calib.pdf
stochmon_calib.pdf
  6008   Fri Nov 25 19:45:36 2011 Mirco, DenSummarySUSExcess Noise in Digital Filtering

Quote:

We are now trying to understand why the coherence between SUS-X_SUSPOS_IN1 and SUS-X_SUSPOS_OUT is lost below 1 Hz for X = MC1, MC2, MC3, BS, ITMX, ITMY, ETMX, ETMY, SRM. It is OKEY only for PRM but the different filteres are used there. For PRM - 30:0.0 and Bounce Roll, for all others - 30:0.0 and Cheby. The transfer functions between these two signals plotted in foton and fft tools are also not the same.

If we switch off all the filters between these 2 signals, than the coherence is one. If one of the filters is switched on, everything is also fine. But if there are several present, than they filter the signal in unexpected way.

Moreover it seems that the coherence is dependent on the input signal. The coherence is better with local dumping than without.

 We have done the following on the c1sus and c1lsc computers : provided excitation, let the signal pass through filters 30:0.0 and Cheby and plotted the coherence between in and out signals.

c1sus computer - coherence is corrupted

c1lsc computer - coherence is not corrupted

Attachment 1: sus_coh-crop.pdf
sus_coh-crop.pdf
Attachment 2: lsc_coh-crop.pdf
lsc_coh-crop.pdf
  6007   Fri Nov 25 18:45:31 2011 Den, RanaSummarySUSExcess Noise in Digital Filtering

We are now trying to understand why the coherence between SUS-X_SUSPOS_IN1 and SUS-X_SUSPOS_OUT is lost below 1 Hz for X = MC1, MC2, MC3, BS, ITMX, ITMY, ETMX, ETMY, SRM. It is OKEY only for PRM but the different filteres are used there. For PRM - 30:0.0 and Bounce Roll, for all others - 30:0.0 and Cheby. The transfer functions between these two signals plotted in foton and fft tools are also not the same.

If we switch off all the filters between these 2 signals, than the coherence is one. If one of the filters is switched on, everything is also fine. But if there are several present, than they filter the signal in unexpected way.

Moreover it seems that the coherence is dependent on the input signal. The coherence is better with local dumping than without.

Attachment 1: FiltNoise.png
FiltNoise.png
  6006   Fri Nov 25 17:52:28 2011 ranaUpdateIOOF2A filter for MC

Woo. Pretty crazy. The numerators should only be ~10% larger than the denominator below 1 Hz. Let's try again.

  6005   Fri Nov 25 12:46:13 2011 MirkoUpdateWienerFilteringWiener filtering tryout

Tried the wiener filter with the TF from p.5900

Tried it out with the TFs from p.5900:

WienerFiltering.pdf

Adding a filter element that compensates the acutator TF makes the MC lose lock.

  6004   Thu Nov 24 20:22:42 2011 MirkoUpdateIOOF2A filter for MC

I calculated the F2A filters for the input mode cleaner optics as described in T010140-01-D eq (4). On Ranas recommendation I added an s/ ( w_0 * Q ) term to the numerator.

The used values are:

w_0 = 2pi / s
h= 0.0009
D= 2.46957E-2
Q=10

UpperCoils.pdf

LowerCoils.pdf

I put theses filters into C1:SUS-MC1_TO_COIL_1_1 to _4_1 . For convenience split in Z and P. Well it doesn't work. After a few seconds the optic begins to swing wildly.

  6003   Thu Nov 24 15:48:27 2011 IllustratorUpdateelogelogd gained an immunity to googlebot

elog_mario.png

golden-monkey.jpeg

 

 

  6002   Thu Nov 24 15:27:15 2011 kiwamuUpdateCDSc1iscey hardware rebooted
The c1iscey machine crashed around 1:00 AM last night and I did a hard-ware reboot by pressing a button on the front panel of the machine.
After the reboot its been running okay so far.
The crash happened after I pressed the "Diag Reset" button on the CDS status screen.
  6001   Thu Nov 24 14:42:57 2011 KojiUpdateelogelogd gained an immunity to googlebot

I modified elogd.c as shown below in order not to allow to display all of the entries at once by specifying page number "0".

After this modification, elog seems to have survived 66 times of attacks by googlebots.

==============================

rossa:src>pwd
/cvs/cds/caltech/elog/elog-2.8.0/src

rossa:src>diff elogd.c_orig elogd.c
19912a19913,19917
>
>    /* KA */
>    if (page_n<1)
>      page_n = 1;
>

  6000   Thu Nov 24 14:05:10 2011 KojiUpdatePSLHEPA@50%

I left the HEPA at the 50% level @5AM, Nov 24

  5999   Thu Nov 24 13:54:31 2011 KojiUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Those clips for the readouts were the ones who popped out.
When I have restored the connections, I checked the schematic and the heater drive mon is clipped on the output side of the OP27.

Quote:

Jenne: The point you indicate for the heater monitor is a virtual ground--it will be driven to zero by the circuit if it's functioning properly; the readout should be done at the input pin (2, I think) to the BUF634.

Koji: This is odd, as I made a point of not attaching any clips directly to resistors for exactly this reason. I was also careful to trim resistor/capacitor leads so that they were not towering over the breadboard and prone to bending (with the exception of the gain-setting resistor of the AD620, which was changed at the last minute). At the end of the day, it is a breadboard circuit with Pomona "readout", so it's not going to be truly resilient until I put it on a protoboard. Another thing: I think the small Pomona clips are absolutely terrible, since they slip off with piconewtons of tension; I could not find any more regular clips, so I used them against my better judgment. 

 

  5998   Thu Nov 24 12:45:12 2011 ZachUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Jenne: The point you indicate for the heater monitor is a virtual ground--it will be driven to zero by the circuit if it's functioning properly; the readout should be done at the input pin (2, I think) to the BUF634.

Koji: This is odd, as I made a point of not attaching any clips directly to resistors for exactly this reason. I was also careful to trim resistor/capacitor leads so that they were not towering over the breadboard and prone to bending (with the exception of the gain-setting resistor of the AD620, which was changed at the last minute). At the end of the day, it is a breadboard circuit with Pomona "readout", so it's not going to be truly resilient until I put it on a protoboard. Another thing: I think the small Pomona clips are absolutely terrible, since they slip off with piconewtons of tension; I could not find any more regular clips, so I used them against my better judgment.

  5997   Thu Nov 24 10:27:07 2011 JenneUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Here is a drawing of where the monitors are coming from:

EOM_temp_sense_heater_drive_schematic_withMONs.png

 Since we can't put current into the ADC, the heater drivemon is measuring the input of the OP27, which is related to the amount of current sent to the heater.

Quote:

EOM TEMPMON and HEATER DRIVEMON have been hooked up to the the following channels.

C1:IOO-EOM_TEMPMON
C1:IOO-EOM_HEATER_DRIVEMON

 

  5996   Thu Nov 24 05:47:16 2011 KojiSummaryIOOStochmon running

Now stochmon for 11MHz and 55MHz is running. The calibration / noise measurement are going to be post later...

  5995   Thu Nov 24 05:10:00 2011 KojiUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

EOM TEMPMON and HEATER DRIVEMON have been hooked up to the following channels.

C1:IOO-EOM_TEMPMON
C1:IOO-EOM_HEATER_DRIVEMON 

What a fragile circuit...

I found some of the resistors popped up from the board because of the tension by the Pomona grabbers.
I tried to fix it based on the schematic (photo) and the board photo.

  5994   Thu Nov 24 02:23:43 2011 KojiSummaryGeneralGPIB<->WIFI

GPIB<->WIFI on Agilent Network Analyzer 4395A was broken.
The connection was fixed by replacing and configuring the LINKSYS bridge.

=======

Kiwamu and I have identified that the LINKSYS bridge was guilty.

I knew that we had another one in the bathroom, I configured it.

HOW TO CONFIGURE IT

  • You need a host with 192.168.1.*.
  • Connect the host and the LINKSYS directly
  • Open http://192.168.1.226/
  • Select 40MARS and infrastructure mode
  • Register it in the MAC filter of the 40MARS (see wiki and use your head)

The new unit works fine.

I checked the malfunctioning unit and the configuration was the same as the others.

The bad one detected the existence of 40MARS during the configuration, but it does not establish
the connection in the actual use. I am afraid that something is broken or some setting is lost
during the power supply shutdown.

  5993   Thu Nov 24 01:28:09 2011 kiwamuUpdateGeneral1X8 sorensen came back

Quote from #5963

 - 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.

 The 1X8 Sorensen's issue has been solved somehow.

 To investigate what is going on with the Sorensen in the 1X8 rack, I turned on the Sorensen.
Then this time it didn't show the current limit sign, the voltage went up to 15.0, where it is supposed to be.
Surprisingly this is exactly the same recovery process as we saw before (#5592).
  5992   Wed Nov 23 22:58:33 2011 KojiUpdateGeneralc1iscaux2 is back (re: recovery from the power shutdown)

Keying again did not help to solve the issue. I turned off the power at the back of the crate, and turn it on again.
Then the key worked again.

c1iscaux2 is burtrestored and running fine now.

Quote:

 - 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.

 

  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.

ELOG V3.1.3-