40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 157 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  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!?!?

 

  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.

  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.

  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.

  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

 

  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

  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.

 

  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.

 

 

  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.

  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.

 

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

  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

 

  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.

  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. 

 

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

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

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

  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.
  6003   Thu Nov 24 15:48:27 2011 IllustratorUpdateelogelogd gained an immunity to googlebot

elog_mario.png

golden-monkey.jpeg

 

 

  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.

  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.

  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.

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

 New RFAM mon calibration

  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.

 

 

  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

  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.

  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!

  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.

 

 

  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.

 

  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.

  6017   Sat Nov 26 10:55:40 2011 ranaUpdateCDSBeware of fancy filter modules

 

 Could be that what we're seeing is the noise floor of the Direct Form II filter structure (see Matt's 2008 elog) which shows an example (also see G0900928-v1 ).

 

  6019   Sat Nov 26 19:37:12 2011 DenUpdateGeneralfoton files

 I've checked foton files for small numbers. There are several other filters besides "Cheby" that are presented with small numbers. For example, "BTW0.01" in the LOCKING_Q, LOCKING_I modules,  "SeisDaytime"  in the SUP_MC3_SP_NOISE and others. The output of the commands is presented below.

>chans

>cat C1???.txt | grep e-23

 

SUP_MC3_SP_Y_NOISE 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC3_SP_YAW_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC3_SP_ROLL_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC3_SP_PIT_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_Y_NOISE 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_YAW_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_ROLL_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_PIT_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_Y_NOISE 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_YAW_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_ROLL_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_PIT_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_MC3_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC3_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC3_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC3_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -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

SUS_MC2_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC2_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC2_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000

SUS_MC2_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC1_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC1_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC1_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_SRM_SUSYAW 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_SRM_SUSPOS 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_SRM_SUSPIT 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_PRM_SUSYAW 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_PRM_SUSPOS 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_PRM_SUSPIT 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_ETMX_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_PIT_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_ROLL_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_YAW_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_Y_NOISE_FILT 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_PIT_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_ROLL_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_YAW_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_Y_NOISE_FILT 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

BS_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

BS_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

BS_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

BS_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_SUSYAW 3 21 4      0      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

PRM_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

PRM_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SRM_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SRM_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SRM_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

 

SRM_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

 
> cat C1???.txt | grep e-21
 
ASS_LOCKIN9_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN9_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN7_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN7_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN29_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN29_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN27_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN27_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN24_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN24_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN22_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN22_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN14_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN14_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN12_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN12_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
SUS_SRM_SUSSIDE 3 12 4  32768      0 Cheby         8.6572646852632e-21    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000
SUS_PRM_SUSSIDE 3 12 4  32768      0 Cheby         8.6572646852632e-21    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000
 
> cat C1???.txt | grep e-19
 
SUP_MC3_SP_Z_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC2_SP_Z_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_Z_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_YAW_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_ROLL_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_PIT_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUS_ETMX_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SUS_ETMX_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SUS_Z_NOISE_FILT 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUS_Z_NOISE_FILT 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
BS_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
BS_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMX_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMX_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMY_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMY_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
PRM_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
PRM_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SRM_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SRM_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000 
  6020   Mon Nov 28 06:53:30 2011 kiwamuUpdateCDSc1sus shutdown

I have restarted the c1sus machine around 9:00 PM yesterday and then shut it down around 4:00 AM this morning after a little bit of taking care of the interferomter.

Quote from #6016

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

  6021   Mon Nov 28 10:54:40 2011 ranaUpdateSUSF2A filter for MC

Our approach to making the F2A or F2P filters for the MC is to use the measured resonant frequencies and then calculating the appropriate mechanical dimensions of each suspension. This is basically because we don't have optical levers with normal incidence on these optics, but the method should be fine.

To find the formulas, I asked Gaby for her old cheat sheet: Its now in the DCC. Its only for Large optics, but you should be able to reconstruct the right ones for SOS by just changing the parameters.

  6022   Mon Nov 28 14:27:35 2011 JenneUpdateRF SystemEOM temp driver

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

  6023   Mon Nov 28 14:40:43 2011 KojiUpdateRF SystemEOM temp driver

Quote:

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

  6024   Mon Nov 28 15:00:20 2011 kiwamuUpdateGreen LockingY arm ALS engaged
Quote from #5894

  However I couldn't close the ALS loop somehow.

 Locking activity last night:

  It became able to close the ALS loop (beat-note signal was fed back to ETMY).

The UGF was about 60 Hz, but somehow I couldn't bring the UGF higher than that.

Every time when I increased the UGF more than 60 Hz, the Y end PDH was unlocked (or maybe ETMY became crazy at first).

Perhaps it could be a too much noise injection above 60 Hz, since I was using the coarse frequency discriminator.

Anyway I will try a cavity sweep and the successive noise budgeting while holding the arm length by the beat-note signal.

Another thing : I need a temperature feedback in the Y end green PDH loop, so that the PZT voltage will be offloaded to the laser temperature.

  6025   Mon Nov 28 15:43:36 2011 steveUpdateRF SystemEOM temp zoomed

Quote:

Quote:

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

 It is not working

  6026   Mon Nov 28 16:46:55 2011 kiwamuUpdateCDSc1sus is now up

I have restarted the c1sus machine and burt-restored c1sus and c1mcs to the day before Thank giving, namely 23rd of November.

Quote from #6020

I have restarted the c1sus machine around 9:00 PM yesterday and then shut it down around 4:00 AM this morning after a little bit of taking care of the interferometer.

  6027   Mon Nov 28 16:51:57 2011 kiwamuUpdateLSCmodulation frequency reset

I reset the modulation frequency to 11065910 Hz (#5530). It had been at 11065399 Hz probably since the power shut down.

  6028   Mon Nov 28 18:19:53 2011 kiwamuUpdateIOOStochmon seems working

Here is a 48 hours trend of the RFAM monitor (a.k.a StochMon):

RFAM_48hours.png

The upper plot is the DC output from the StochMon PD and the lower plot shows the calibrated RIN (Relative Intensity) at each modulation frequency.

I have downloaded minutes trends of StochMon for 48 hours staring from 6:00AM of Nov/24.

I followed Koji's calibration formula (#6009) to get the actual peak value (half of the peak-peak value) of the RF outputs and then divided them by the DC output to make them RIN.

It looks the RINs are hovering at ~ 4 x 10-4 and fluctuate from 1x10-4 to 1x10-3. Those numbers agree with what we saw before (#5616)

So it seems the StochMon is working fine.

Quote from #6009

 New RFAM mon calibration

  6030   Mon Nov 28 19:24:51 2011 JenneUpdateCDSBeware of fancy filter modules

[Rana, Jenne]

Some of the funniness is some kind of mysterious interaction between 2 filter modules in the filter banks.  Just FM1 (30:0.0) or just FM4 (Cheby, which is 2 cheby1's) has reasonable coherence.  Both FM1 and FM4 together doesn't do so well - the coherence goes way down.

Just FM1 (30:0.0)

SUSPOS_ETMY_30and0_measured_vs_idealTF.pdf

Just FM4 (Cheby)

SUSPOS_ETMY_Cheby_measured_vs_idealTF.pdf

 Both FM1 and FM4

SUSPOS_ETMY_30and0andCheby_measured_vs_idealTF.pdf

 All the coherences plotted together

SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf

You'd think that the signal encounters FM1, gets filtered, and that result is the signal sent to the next active filter module, FM4, so the 2 filter modules shouldn't interact.  But clearly there's some funny business here since engaging both makes things crappy. 

Matlab investigations to replicate this behavior offline are in progress.

  6031   Mon Nov 28 22:09:24 2011 ranaUpdateCDSBeware of fancy filter modules

To see what might be causing the problem, I used a version of the filter noise test matlab code that Matt had in the elog.

To see if it was a single precision problem, I just recast the input data:   x = single(x)

This is not strictly correct, since some of the rest of the operations are as double precision, but I think that attached plot shows that a casting from double to single is close to the right amount of noise to explain our excess noise problem in the 0.1-1 Hz region.

Den is going to interview Alex to find out if we have some kind of issue like this. My understanding was that all of our filter module calculations were being done in double precision (64 bit), but its possible that some single stuff has crept back in. Currently the FIR filtering code IS single precision and in the past, the SUS code which didn't carry the LSC signals (meaning ASC and damping) were done in single precision.

  6032   Tue Nov 29 02:09:15 2011 ZachUpdateRF SystemEOM temp stabilization fixed

I inspected the temperature stabilization circuit today to see why it wasn't working. It didn't make sense that it just kept railing the heater even though the error signal was negative (which should turn the heater current OFF).

It turns out that the LF356 (FET-input op amp) that serves as the filter stage for the heater driver was broken---I measured a full, railed positive output even though the input was negative. We didn't have any more LF356s, so I replaced it with an OPA604 (Burr-Brown FET-input), and all seemed to work fine.

Since we were having too much digitization noise, I also added a temperature monitor buffer using a non-inverting OP27 circuit with G=99. This makes the overall calibration ~7.6 V/K into the ADC.

Below is a time series showing that it is working. The circuit was turned on near the beginning, and you can see that the heater is railed at +10V until shortly after the error signal goes negative, at which point it adjusts and ultimately approaches a steady-state value of ~7.8V.

EOM_temp.png

I have no figures to demonstrate this, but it seems that even with this 100x increase in monitor gain, the error signal is still below the ADC noise level. This could be because the ambient temperature fluctuations are just that small on timescales of less than a few hours. I'm not sure if we really need to be able to see the temperature noise level above a few mHz, but if we do we will have to find some way to increase our dynamic readout range. 

Also, Koji told me where he stashed the nice protoboards, so I will get onto transferring this circuit onto one ASAP. Since it is working now, I think I'll leave it until after the TAC.

  6033   Tue Nov 29 04:47:49 2011 kiwamuUpdateCDSc1sus shut down again

I have shut down the c1sus machine at 3:30 AM.

  6035   Tue Nov 29 14:22:03 2011 ZachUpdateRF SystemEOM temp stabilization performance

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of time.

Here are both long-term (~13-hr) and short-term (1-hr) trends of the EOM temperature and the heater drive level. From the long trend you can see that the heater departed the steady value of ~7.8V that I observed last night to accommodate the diurnal heating of the lab in the morning---the temperature was held near zero offset.

From the short-term trend, there are 2 things to notice:

  1. We are still very close to the digitization noise level for both signals. This is bad, because we want to look at the residual noise level, etc.
  2. There appears to be some strange sort of disturbance of f~0.01-0.02 Hz. I'm not sure what causes the strange shape

Screen_shot_2011-11-29_at_1.33.50_PM.png Screen_shot_2011-11-29_at_1.34.06_PM.png

 

Finally, here is a trend over the last ~24 hours of the EOM temperature, heater drive level, and the 11- and 55-MHz Stochmon signals. I believe that the abrupt shelves noticeable on the Stochmon trends are when c1sus was turned on and shut down, respectively (I'm not sure why that causes the signals to die, but the times seem right, and nothing obvious happens to the EOM temp stabilization signals at either time). The controller was turned on at ~8:40 UTC, and you can see that the Stochmon signals quiet down a lot right at that time. There is some residual drift (common-mode to both RF frequencies), which is most likely caused by a drift in some other parameter (e.g. laser frequency or power).

Screen_shot_2011-11-29_at_1.41.03_PM.png

I took some relatively inconclusive power spectra and coherence measurements, but I'd rather wait until we have an uncontrolled data stretch with which to compare. I think what we should do now is disconnect the controller and then let it sit for a while.

 

  6036   Tue Nov 29 15:25:29 2011 steveUpdateRF SystemEOM temp stabilization performance

 It is not obvious what is working.

 

  6037   Tue Nov 29 15:30:01 2011 jamieUpdateCDSlocation of currently used filter function

So I tracked down where the currently-used filter function code is defined (the following is all relative to /opt/rtcds/caltech/c1/core/release):

Looking at one of the generated front-end C source codes (src/fe/c1lsc/c1lsc.c) it looks like the relevant filter function is:

filterModuleD()

which is defined in:

src/include/drv/fm10Gen.c

and an associated header file is:

src/include/fm10Gen.h
  6038   Tue Nov 29 15:57:43 2011 DenUpdateCDSlocation of currently used filter function

 

We are interested in the following question : Can the structures defined in fm10Gen.h (or some other *.c *.h files with defined as FLOAT variables) create single precision instead of double in the filter calculations?

 

typedef struct FM_OP_IN{
  UINT32 opSwitchE;     /* Epics Switch Control Register; 28/32 bits used*/
  UINT32 opSwitchP;     /* PIII Switch Control Register; 28/32 bits used*/
  UINT32 rset;          /* reset switches */
  float offset;         /* signal offset */
  float outgain;        /* module gain */
  float limiter;        /* used to limit the filter output to +/- limit val */
  int rmpcmp[FILTERS];  /* ramp counts: ramps on a filter for type 2 output*/
                        /* comparison limit: compare limit for type 3 output*/
                        /* not used for type 1 output filter */
  int timeout[FILTERS]; /* used to timeout wait in type 3 output filter */
  int cnt[FILTERS];     /* used to keep track of up and down cnt of rmpcmp */
                        /* should be initialized to zero */
  float gain_ramp_time; /* gain change ramping time in seconds */
} FM_OP_IN;  

 

  6039   Tue Nov 29 17:10:39 2011 DenUpdatedigital noiseSOS creation

One of the possibilities that we see a large low-frequency digital noise is due to Foton. I've checked the SOS coefficients that saves Foton with a Matlab coefficients. I used a 3 order low-pass cheby1 filter cheby1("LowPass",3,0.1,3) 

In matlab I generated SOS model using 3 approaches 


[A,B,C,D]=cheby1(3,0.1,3/1024) % create SS form

[sos,g]=ss2sos(A,B,C,D)  % convert to SOS form


[z, p, k]=cheby1(3,0.1,3/1024) % create ZPK form

[sos,g]=zp2sos(z,p,k)  % convert to SOS form


[b, a]=cheby1(3,0.1,3/1024) % create TF form

[sos,g]=tf2sos(b,a)  % convert to SOS form


As this is a 3 order filter, in the SOS representation we'll get 2 by 6 SOS - matrix. It is presented below. In each matrix place there 4 numbers - from the Foton file and obtained using these 3 methods.

GAIN

1.582261654653329e-07

1.582261654653329e-07

1.582261654653329e-07

1.582261655030947e-07

SOS-MATRIX

1              1.0000000000000000      #           0                                              #       1      #         -0.9911172660954457     #       0

1              1.0005663179617605      #           0                                              #       1      #         -0.9911172660954457     #       0

1              1.0000000000000000      #           0                                              #       1      #         -0.9911172660954457     #       0

1              0.9999894976396830      #           0                                              #       1      #         -0.9911172660997303     #       0

############################################################################################################

1              2.0000000000000000      #          1.0000000000000000         #       1      #        -1.9909750803252266      #      0.9911175825477769

1              1.9994336820732397      #          0.9994340026283055         #      1       #       -1.9909750803252262       #     0.9911175825477765

1              2.0000000000000000      #          1.0000000000000000         #      1       #       -1.9909750803252262       #     0.9911175825477765

1              2.0000105023603174      #          1.0000105024706190         #      1       #       -1.9909750803209423       #     0.9911175825434912

 

It seems that smth analog to zp2sos is used in Foton. We can see that due to representation error we have derivations in the 4 and 6 digits for SS and TF forms. This means that a pretty big mistake can run due to digital transforms even using double precision as in the Matlab test.

Alex Ivanov said that he'll fix that single precision problem and in the 2.5 release we won't have any FLOAT variables. Though we still do not understand how that variables declared as FLOAT can cause filter calculations. 

ELOG V3.1.3-