40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 229 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  5580   Fri Sep 30 03:14:18 2011 kiwamuUpdateCDSsuspension became crazy : c1sus rebooted

Quote from #5579

Then we restarted daqd.

[Suresh / Kiwamu]

The c1lsc and c1sus machine were rebooted.

 

- - (CDS troubles)

 After we restarted daqd and pressed some DAQ RELOAD buttons the c1lsc machine crashed.

The machine didn't respond to ssh, so the machine was physically rebooted by pressing the reset button.

Then we found all the realtime processes on the c1sus machine became frozen, so we restarted them by sshing and typing the start scripts.

However after that, the vertex suspensions became undamped, even though we did the burt restore correctly.

This symptom was exactly the same as Jenne reported (#5571).

We tried the same technique as Jenne did ; hardware reboot of the c1sus machine. Then everything became okay.

The burt restore was done for c1lsc, c1asc, c1sus and c1mcs.

 

- - (ITMX trouble)

During the trial of damping recovery, the ITMX mirror seemed stacked to an OSEM. The UL readout became zero and the rest of them became full range.

Eventually introducing a small offset in C1:SUS-ITMX_YAW_COMM released the mirror. The amount of the offset we introduced was about +1.

  5579   Fri Sep 30 02:56:56 2011 kiwamuUpdateCDSC1IOO.ini and C1LSC.ini files reverted

[Suresh/Kiwamu]

We found that the C1LSC.ini and C1IOO.ini file had been refreshed and there were a few recorded channels in the files.

So we manually recovered C1LSC.ini file using the daqconfig GUI screen.

For the C1IOO.ini file we simply replaced it by the archived one which had been saved in 22nd of September.

Then we restarted daqd.

  5578   Fri Sep 30 01:18:39 2011 kiwamuUpdateASCC1ASS : status update

Now the C1ASS servos are working fine.

However at the end of the scripts sometimes it changes the DC force (e.g. C1:SUS-ITMX_PIT_COMM and so on) by a wrong amount.

So for this bug, it misaligns the suspensions a lot. I will take a look at the script tomorrow.

Quote from #5543

However then I found the ASS_Xarm servo was not healthy.

  5577   Thu Sep 29 20:37:12 2011 MirkoUpdateComputersNew c1oaf c-code: Breaking in new way

[Mirko, Jenne]

Programmed a new implementation of the LMS in C. Compiles fine in gcc. The full code still kills c1lsc computer. Tried to go through the code uncommenting more and more. Not perfect in reproducability. The attached version should compile and keep c1oaf running, but not actually produce an adaptive filter. At some point the code just keeps c1oaf from starting up. Leaves the c1lsc computer in working order. At some point I got error messages like ..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_BS_Name08", Connecting to: 192.168.113.62:50970, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.219208306
..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_BS_Name09", Connecting to: 192.168.113.62:50970, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.225999915
..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_ETMX_SW1R", Connecting to: 192.168.113.62:50970, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.243037042
..................................................................

This usually indicates that there are multiple carepeater running. Didn't find where that would be. After rebooting c1lsc and c1sus a couple of times everything seems fine.

Attachment 1: ADAPT_XFCODE11-09-29---20-12.c
// LMS algorithm adaptive filtering for the Caltech 40m -- Sept. 2011 by M. Prijatelj

#define nDOF 8
#define nWIT 21
#define nTAPS 1000

void ADAPT_XFCODE(double *in, int inSize, double *out, int outSize) {

//First the DOFs and their switches
//int nDOF=8;
... 136 more lines ...
  5576   Thu Sep 29 12:56:27 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

[Mirko, Den, Jenne]

We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm? 

Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different?

Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

  5575   Thu Sep 29 11:25:55 2011 JenneUpdateAdaptive FilteringTried new c-code, Fail.

[Mirko, Jenne]

Mirko edited the c-code to use Den's stuff that he put in the elog last night.  We then tried to compile and install, but it crashed c1lsc again.  We reverted to the simple, working c-code, pushed the physical reset button on c1lsc, and things started getting better.  The suspensions had the same problem as last night...we had to do a soft shutdown of c1sus to get things better again. 

I did a by-hand burt restore for all of the models on c1lsc and c1sus, since the auto burt restore isn't working.

  5574   Thu Sep 29 03:43:20 2011 kiwamuUpdateASCwrong channel assignment on IPPOS

The channels for IPPOS had been assigned in a wrong way.

Because of this, C1:ASC-IP_POS_X_Calc corresponds to the actual vertical motion and C1:ASC-IP_POS_Y_Calc is for the horizontal motion.

We should fix the database file to get the correct vertical/horizontal corrdinate.

  5573   Thu Sep 29 00:16:35 2011 DenUpdateComputersSegmentation fault fixed.

The OAF c-code crashed because of the segmentation fault. We've created arrays of static variables

    static int pst[nDOF];
    static int isFirst[nDOF];
    static adaptive_filter_state state[nDOF];

an tried to give in the to the ITERATE - function their current values

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, pst[i], isFirst[i], state[i]);

ITERATE function was declared as

double ITERATE(double *datIn, int nIn, int pst, int isFirst, adaptive_filter_state state) {}

Here the segmentation fault comes out. Static variables are meant to be created only once but here in the function ITERATE we try to create them once again in a local form, because we give the variables by their values.

Instead, we must give the variables by their pointer, then the variables won't be created again during the function call and will be changed in the function.

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, &pst[i], &isFirst[i], &state[i]);

       double ITERATE(double *datIn, int nIn, int *pst_s, int *isFirst_s, adaptive_filter_state *state_s)

In order not to change significantly Matt's code and use his notations we can add in the ITERATE function

    int pst = *pst_s;
    int isFirst = *isFirst_s;
    static adaptive_filter_state state;
    state = *state_s;

..................................Matt's code.........................................

    *pst_s = pst;
    *isFirst_s = isFirst;
    *state_s = state;

I've tested the program, now it does not give any segmentation faults and conserves memory that it uses.

  5572   Wed Sep 28 22:30:01 2011 JenneUpdateAdaptive FilteringOAF is disabled

I am leaving the OAF disabled, so there should be nothing that goes to the suspensions from the OAF. 

Disabled for the OAF means all the outputs are multiplied by 0 just before the signals are sent back over to the LSC system to be summed in and sent to the suspensions.  So 0 times anything should mean that the OAF isn't injecting signals.

In other news, while Mirko was trying to figure out the c-code, I began making a new OAF screen.  It is still in progress, but it's in c1oaf/master/C1OAF_OVERVIEW.adl  If you open it up, you can see for yourself that the OAF is disabled.  (Eventually I'll put an enable/disable button on the LSC screen also, but that hasn't happened yet.)

  5571   Wed Sep 28 22:25:25 2011 JenneUpdateComputersTorturing control computers. Fine again now

Quote:

[Mirko, Jenne]

We tried to run an extended version of Matt's LMS adaptive filter c-code. We got the extension to compile separately in gcc first. Then after some tweaking of the code we could make-install c1oaf with the c-code.

This killed c1lsc (the FE computer running c1oaf). Not responding to ssh or even pings. We replaced the bad c-code with harmless code, then reset c1lsc via the hardware button. While looking for c1lsc we discovered the problem with c1iscy network card (see previous entry).

After c1lsc reboot, restart of the FB, and a BURT restore not ok yet

 We had lots of trouble damping the Vertex Suspensions after this craziness.  A symptom was that even if all of the damping servos on an optic were OFF, and I turned the watchdog on (LSC is disabled, so no OAF siganls, no LSC signals), there were signals going to the coils. 

We did a reboot of the c1sus computer, did another BURT restore, and the optics started damping happily.   Burt restore, at least for c1susepics and c1mcsepics, seems to not be happening automatically.  I thought it was supposed to happen when the model was restarted?

Things now appear to be normal again.

  5569   Wed Sep 28 21:28:34 2011 MirkoUpdateComputersTorturing control computers. Fine again now

[Mirko, Jenne]

We tried to run an extended version of Matt's LMS adaptive filter c-code. We got the extension to compile separately in gcc first. Then after some tweaking of the code we could make-install c1oaf with the c-code.

This killed c1lsc (the FE computer running c1oaf). Not responding to ssh or even pings. We replaced the bad c-code with harmless code, then reset c1lsc via the hardware button. While looking for c1lsc we discovered the problem with c1iscy network card (see previous entry).

After c1lsc reboot, restart of the FB, and a BURT restore not ok yet

  5568   Wed Sep 28 21:23:23 2011 MirkoUpdateComputersISCY FE network card / cable not ok

[Mirko,Jenne]

We discovered that the left network cable is not rigidly connected to the back of the ISCY FE computer. You can easily pull it out a mm disconnecting it. It should click rigidly in place. Not clear if it's the cable or the network card.

  5567   Wed Sep 28 18:39:50 2011 MirkoUpdatePEMBLRM seismic channels in c1pem

[Mirko,Jenne]

Created 5-band BLRMS for seismometer data (Gur1, Gur2 and STS1 each in x,y,z respectively) and accelerometer 1 through 6.

Bands are:
0.1Hz-0.3Hz
0.3Hz-1Hz
1Hz-3Hz
3Hz-10Hz
10Hz-30Hz
each with a fitting 4th order butterworth bandpass.

Data is recorded at 256Hz as e.g. C1:PEM-ACC1_RMS_RMS_0p3_1_OUT_DQ. For the 75 channels we have that corresponds to the data rate of just 1.2 16kHz channels.

c1pem execution time increased fom 6-7us to 15-16us out of 480us available.

  5566   Wed Sep 28 15:33:58 2011 SureshUpdateComputer Scripts / Programsediting database files for medm screens and restarting the slow c1psl machine

I changed the names on a switch(SW1) in the C1:PSL-FSS screen.  To do this I had to edit the psl.db database file in the directory /cvs/cds/caltech/target/c1psl.  After this change, when I executed this screen, all fields in the C1PSL_FSS screen went blank.  As the change to database file takes effect only after we restart the C1PSL machine (slow machine) I went ahead and reset the c1psl machine.  I then used the burttoday to locate the most recent snapshot files and then used burtgooey to restore all the values in the c1psl.snap file.

Everything back to normal now.

 

  5565   Wed Sep 28 14:15:40 2011 JenneUpdateComputersEdits to c1pem, c1oaf

[Mirko, Jenne]

Mirko edited c1pem to have some new BLRMS channels.

I added a master Enable switch to the c1oaf.

Both were compiled, and restarted.  fb rebooted.  All looks okay (hopefully)

  5564   Wed Sep 28 13:30:01 2011 JenneUpdatePSLPMC was unlocked

Relocked the PMC.  MC came back immediately.

  5563   Wed Sep 28 07:46:42 2011 steveUpdateSUSDsub connections at the back of 1X5 are fixed

 

 I'm turning  the sus damping  off for Dsub connection fix at  the back of 1X5 rack

The plan is to install 4-40 jack screws to lock connector positions.

All dewittening(or called coil driver) and wittening D sub connectors are locked with two 4-40 socket head screws

  5562   Wed Sep 28 07:36:41 2011 steveUpdateSUSITMY damping restored

ITMY suspention damping restored

  5561   Wed Sep 28 02:42:04 2011 kiwamuUpdateCDSsome DAQ channel lost in c1sus : fb, c1sus and c1pem restarted

Somehow some DAQ channels for C1SUS have disappeared from the DAQ channel list.

Indeed there are only a few DAQ channels listed in the C1SUS.ini file.

I ran the activateDQ.py and restarted daqd.

Everything looks okay.  C1SUS and C1PEM were restarted because they became frozen.

  5560   Wed Sep 28 00:06:21 2011 JenneUpdateSUSWatchdog rearmed

Quote:

I came to the control room and found the PMC and IMC were unlocked. ==> Relocked
I found the watch dogs of the vertex suspensions are tripped.

I checked the data for the past 6 hours and found they are independent events.
The unlock of the MCs occured 4 hours ago and the watchdogs tripped 2 hours ago.

The suspension damping was restored at around 7:50PM PDT.

 Oops, I should have noticed all of those things.  Several hours of computer-battle exhausted me.  Thanks Koji.

  5559   Tue Sep 27 20:02:19 2011 KojiUpdateSUSWatchdog rearmed

I came to the control room and found the PMC and IMC were unlocked. ==> Relocked
I found the watch dogs of the vertex suspensions are tripped.

I checked the data for the past 6 hours and found they are independent events.
The unlock of the MCs occured 4 hours ago and the watchdogs tripped 2 hours ago.

The suspension damping was restored at around 7:50PM PDT.

  5558   Tue Sep 27 15:33:03 2011 JenneUpdateComputersMaking models, wreaking havoc

[Jenne, Mirko, Den]

We have entered into an adventure in model compiling.  What follows is a stream-of-consciousness report of what the hell we're doing, so Jamie can figure it out and fix it if everything goes to hell.

Note that for the first part of things, we have used a new version of the Adaptive XFCODE, which Mirko and Den modified last night to be able to handle multiple control signal inputs.  

On c1lsc, make uninstall-daq-c1oaf, make clean-c1oaf, make c1oaf.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:RFM_OAF_MCL

On c1sus, make uninstall-daq-c1sus, make clean-c1sus, make c1sus.  (This was an accident.  I should have been making c1rfm.  Oops.)  Then make install-c1sus.  It looks like this automatically did make install-daq-c1sus and make install-screens-c1sus, so I'm not doing those. 

On c1sus, make uninstall-daq-c1rfm, make clean-c1rfm, make c1rfm.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:IOO-RFM_MCL


On c1ioo, make uninstall-daq-c1ioo, make clean-c1ioo, make c1ioo.  No errors.

On c1lsc, make c1oaf.  Here's some of the ouptut, with some of the error stuff:

: warning: ISO C90 forbids mixed declarations and code
/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2954: warning: ISO C90 forbids mixed declarations and code
make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.34.1-cs'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf'
make: *** [c1oaf] Error 2

Again on c1lsc, make clean-c1oaf, make c1oaf.  Here are some things:

Warning:  variable "sysnum" is used but not declared.

In file included from build/c1oafepics/c1oaf.i:38:
src/include/fmReadCoeff.h:4:1: warning: "NO_FM10GEN_C_CODE" redefined
<command-line>: warning: this is the location of the previous definition

build/c1oafepics/c1oaf.i:5156: warning: passing argument 2 of 'strcpy' discards qualifiers from pointer target type
/usr/include/string.h:127: note: expected 'const char * __restrict__' but argument is of type 'volatile char *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../../include/drv/inputFilterModule1.h:5: note: expected 'double *' but argument is of type 'long unsigned int *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2780: warning: ISO C90 forbids mixed declarations and code

make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[1]: *** [default] Error 2
make: *** [c1oaf] Error 2

Again, on c1lsc, make clean-c1oaf, make c1oaf.  More errors, pretty similar.  Then we changed the name of the adaptive filtering code, so maybe it will work now?  We had called the block "TOP_XFCODE", but that was the name of the old .c code.  The block used to be called "XFCODE", in a subsystem "TOP".  So now we named the .c code "ADAPT_XFCODE" since the block is "XFCODE", and the subsystem is "TOP".

Again, on c1lsc, make clean-c1oaf, make c1oaf.  Errors, they look the same.

Mirko is now modifying c1oaf.mdl to look more like the old version, with only one control signal input, so that we can use the old XFCODE that has been around for years.

First, we completely took out the .c code entirely.  Now the c1oaf.mdl is just signals and matricies, no c-code is called.  We did make clean-c1oaf, make c1oaf, and pretty much all of the same errors are present.
 

We took out the buses, and did make clean-c1oaf, make c1oaf, and we got a whole lot of warnings, but no "Error 2"'s.  This seems good.  We're going to try replacing those buses with Muxes, and see how that goes.

Now we're going to try to install the c1oaf, because maybe all the errors and shit we're seeing is just useless crap, and there aren't actually problems...here we go!

That seemed to work, and the c1oaf model on the GDS status screen seems happy.  Numbers are moving around, which is my only current diagnostic.

Okay, now Mirko is going back to the full, new c1oaf, but replacing the Buses with Muxes. 

Did a make clean-c1oaf, make c1oaf, got errors again.

Once again removed the .c code.  Just put in a matrix instead. Did make clean-c1oaf, make c1oaf.  No errors. 

Den did a reorganization of the .c code, and we put it back in to the simulink model.  Trying again the making stuff.  Fail..Basically the same errors as before.

Next up:  Putting in .c-code, but something which basically does nothing.  Just defines all the outs as zeros.  Make stuff.  Still had problems, same errors.  Grrrr, argh. 

Found the RCG manual:  T080135-v4.  In it, when talking about including c-code, it had an example of totally simple code.  We tried out their version of simple code, and it worked.  No errors!  Now to figure out what is same and different between our simple code and theirs.

 PUT THE RIGHT STUFF in the Block Properties for the c-code, including name of the .c file, and path to the .c file.  This is critical!!  Now we can make some of our simple versions work, but not all.  We're slowly increasing complexity of our c-code...

 At some point in the last hour, I tried a make install-c1oaf, and then checked the screens, and they all had bad white boxes.  So even though the model seemed to compile (at one point), the channels and screens aren't happy yet.  But that's really a project for after the code compiles happily.

Okay, some progress was made to get the c-code running, and compiling, but it's not all there yet.  We're putting in a simple, useless version of the c-code so we can try compiling everything else.

Everything is compiled, installed, there are no red lights on the GDS_STATUS screen.  All seems okay for locking for tonight.

 

  5557   Tue Sep 27 11:52:33 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

 

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

 Suresh makes a fine point.  I think the channel between c1ioo and c1mcs should always have had to go through the c1rfm model.  I don't know why it wasn't.  Anyhow, I have changed things so that there is one signal passing from c1ioo to c1rfm, and that signal is split in two, and goes to both c1oaf and c1mcs.  The naming convention I used last night is the one I kept:  C1:IOO-RFM_MCL goes from c1ioo to c1rfm, and then C1:RFM-OAF_MCL goes from c1rfm to c1oaf, and C1:RFM-MCS_MCL goes from c1rfm to c1mcs. 

We can't compile until Mirko and I figure out what to do with the OAF model though.  Mirko, Den and I were looking at the c1oaf model, to make sure it is ready to compile, and I'm not sure that it is.  And we need everything with common channel names to be compiled at the same time, so I can't compile any of the models today, until we get this figured out.

The problem is thus:  The old TOP_XFCODE that mevans wrote back in 2008 takes in a certain number of inputs, calculates the new filter coefficients, and spits out the filtered signals.  Back in those days, we only ever gave the adaptive system one control (target) signal at a time.  Now, we want to be able to do multiple, if we so desire.  I don't know exactly how to do this yet.  Either we need to modify the code to make it a super-code, or we can have one copy of the code for each control signal (MC_F, XARM, YARM, DARM, MICH, etc...).  Do we want to have one code adapt everything at once, and have a giant MIMO system, or do we want to have many SISO-like systems in parallel (SISO-like, because each one would take in one control signal, and many seismometer signals, and output many filtered seis signals, but it wouldn't be combining control signals together)? 

Either one of these options could be waaay to computationally tough for the computer.  The old computer was basically railed when we had one adaptive block, with one control signal and 7 seismometers.  7 was the max number of auxiliary channels we could use.  So, how much faster are the new computers?? Do we need to have one OAF per DoF that we want to filter? 

  5556   Tue Sep 27 11:43:59 2011 JenneUpdateelogElog has been dying a lot lately...

WTF?

  5555   Tue Sep 27 09:47:52 2011 SureshUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

 

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

  5554   Tue Sep 27 08:51:29 2011 PaulUpdateSUSOplev filter optimization for 2 poles and 2 zeros

Quote:

Quote:

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.

Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:

1) Limit the gain peaking at the upper UGF to 6 dB.

2) Minimum phase margin of 45 deg.

3) Minimum gain margin of 10 dB.

4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.

5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.

6) Looser noise contraint above 50 Hz for the non TM loops.

 I moved two matlab scripts into the folder /cvs/cds/rtcds/caltech/c1/scripts/SUS/Oplev_filter_optimization

These are the function 'filter_optimiser_zeros_and_poles.m', and the example script to run the function 'run_filter_optimiser.m'. Type 'help filter_optimiser_zeros_and_poles.m' to get details about the function.

I haven't implemented the new weights yet. I've pasted them into the the file header to remind me/us of the work to be done on the function.

  5553   Tue Sep 27 04:13:22 2011 kiwamuUpdateLSCtonight's locking activity

The lock of PRMI wasn't so robust although it could stay locked for more than 10 minutes.

There have been 2-3Hz spikes in everywhere. It needs to be investigated.

 

(to do)

 + Diagnosis on the suspensions.

 + Check the beam centering on the RFPDs.

 + Check the f2a filters on PRM and BS.

 + Health check of the suspensions by locking some cavities and measuring the noise spectra for comparison.

 + Trying to use another signal port other than AS55.

 

(Spikes)

 The attached picture below is an example of the REFLDC and POXDC signals in time series.

This was when PRCL and MICH were locked by REFL33_I and AS55_Q respectively.

PRMI.png

Note that when PRMI is unlocked, REFLDC goes to ~ 5000 counts and POXDC goes within ADC noise of ~ 1 counts.

According to the POP camera it looked like something was oscillating in the YAW direction which coincided with the spikes.

I tried finding any suspicious angular motions in the ITMs, BS and PRM olevs, but none of them showed the 2-3 Hz feature.

  5552   Mon Sep 26 22:40:41 2011 JenneUpdateComputersWe now have BURT restore for slow channels
[Jenne, Koji]

After much Perl-learning and a few iterations, we have fixed the burt restore script, so that it actually does the slow channels. We have so far had one successful run, at 22:25, and the regular cron job should start doing the slow channels as of 23:07.
  5551   Mon Sep 26 20:04:03 2011 KojiUpdatePSLMC lock has been recovered

[Kiwamu Suresh Koji]

Some main parameters of the PSL has been recovered using Dataviewer and some screen snapshots, as seen in the screenshots below.

Attachment 1: snapshot1.png
snapshot1.png
Attachment 2: snapshot2.png
snapshot2.png
Attachment 3: snapshot3.png
snapshot3.png
  5550   Mon Sep 26 18:59:11 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

  5549   Mon Sep 26 17:49:51 2011 KojiUpdatePSLc1psl

[Koji Suresh]

c1psl has got frozen during our ezcaread/write business.
After the target was rebooted and we lost the previous setting as there was no burt snapshot for the slow targets since Dec 13, 2010.

It seems that burtrestore is essential for the bootstrapping of the MC servo, as the auto locker script refers the locking parameters
from the PSL setting values (C1PSL_SETTINGS_SET.adl).

Jenne is working on the recovery of the snap-shotting for the slow targets.

  5548   Mon Sep 26 17:49:21 2011 JenneUpdateComputersWe now have BURT restore for slow channels

Koji and Suresh found that there have not been any autoburt snapshots taken of slow channels since ~December 13th 2010.  Not good!

We have found an elog from Joe talking about autoburt changes from that day:  elog 4046

Joe pointed all of the autoburt stuff to the new directory system, so it now decides to take a snapshot of every system in the *new* target directory.  This means, since all of the aux things were left in the *old* target directory that none of them were getting snapshots taken.  I have added the old target path back to the autoburt cron file so that every hour it will search through both old and new target directories and take snapshots of everything in both. 

So, the systems which will now once again have autoburt snapshots taken are the following:

c1aux

c1auxex

c1auxey

c1dcuepics

c1iool0

c1iscaux

c1iscaux2

c1iscepics

c1losepics

c1omcepics

c1psl

c1susaux

c1vac1

c1vac2

 

I moved some old stuff (and especially things which would conflict with the new stuff) to the old target directory/oldfe/ :  c1ass, c1assepics, c1susvme1, c1susvme2, c1sosvme, c1iovme.

The following systems don't have an autoburt.req file, so don't get snapshots:  c0daqawg, c1daqctrl, c1dcu1, c1iscex, c1iscey.  If any of these need autoburts, we should create them.

All the new systems in the new target directory still have their autoburts working.

The first test of this will be in a few minutes, at 18:07:00 Pacific during the regular cron job.  Hopefully nothing crashes....

  5547   Mon Sep 26 16:42:08 2011 kiwamuUpdateSUSITMX ULSEN : fixed

The issue on the ITMX UL sensor has been fixed. It was because of a loose connection in the sensor signal path.

After the fix, the sensor responses completely changed and the suspension became unable to be damped with the new matrix.

At the moment the ITMX suspension is damped by the default input matrix.

we should do the free swinging test once again.

 


(details)

 The loose connection was found on the rear side of the 1X5 rack.

There is an adapter card on the rear side, where the driver and sensor signals are combined into a single cable.

I pushed the sensor cable (bottom right in the picture) and the noise disappeared.

connection.png

Note that I changed the labels on the adapter cards from the old X/Y convention to the new one.

After fixing the loose cable the ITMX suspension became unable to be damped.

So I put the input matrix back to the default and it immediately started damping happily. It means our new matrix is not valid any more.

 

 Here is the latest noise spectra of the ITMX sensors damped with the default input matrix.

As usual all of them are limited by the ADC noise above 20 Hz. (ADC noise is plotted in purple curve)

ITMXsensors.png

 

During the work I also pushed not only ITMX ones but also the cable for the rest of the optics in the adapter cards.

Then PRM became unable to be damped, so it implies the PRM suspension also used to be the same situation.

The input matrix of PRM has been also back to the default.

 

Quote from #5546

Currently the damping of the ITMX suspension is intentionally disabled for the noise investigation.

 

  5546   Mon Sep 26 15:54:46 2011 kiwamuUpdateSUSITMX ULSEN shows jumps

Currently the damping of the ITMX suspension is intentionally disabled for the noise investigation.

Quote from #5544

 

However the spectra from ITMX showed a noise floor at very high level. This is because of strange jumps in the signal of the UL shadow sensor.

I will check some analog circuits for the UL sensor.

 

  5545   Mon Sep 26 15:15:45 2011 AnamariaUpdateLSCRealignment of REFL / Some 3f PRMI locking / Recycling Gain

A few comments on REFL table alignment and REFL165.

Last time we realigned the table was after the PZT work by Koji/Kiwamu; we made sure that the beam was going through optics satisfactorily and that we were reading reasonable numbers. I did use primarily a viewer to align onto PD, after which we used the voltage reading to center better around that spot. As desired, I could not see the beam once it was centered on the PD. I never touched the PBS unfortunately, so I never noticed it was not fixed. Sad.

I am very surprised to hear the reading from REFL165, since I was reading around 400mV from it a few days before. Something strange happened in the mean time. I hope not when I was plugging and unplugging at the power rack for the POY work. But I would not have needed to touch REFL165. Those cables should get some strain relief at the rack, by the way.

I thought about it, and I must admit that after we centered camera on REFL (paired with an alignment), we did not check the beam path later, even after we saw that the REFL beam had moved. We only did a quick by-viewer check that the beams were not off of the PDs.

Quote:

[Koji Suresh]

- The REFL path has been thoroughly aligned
Many optics had the spots not on the middle of the optic, including the PBS whose post was not fixed on the post holder.
We aligned the optical paths, the RF PDs, and the CCD. The alignment of the PD required the use of the IR viewer.
One should not trust the DC output as a reference of the PD alignment as it is not enough sensitive to the clipping.

We aligned the optical paths again after the reasonable alignment of PRM is established with the interferometer.
"Next time when you see REFL spot is not at the center of the camera, think what is moved!"

- The REFL165 PD is disconnected from the power supply
I found that the REFL165 PD is producing 7.5V output at the DC monitor no matter how the beam is blocked.
As I could not recover this issue by swapping the power connector at the LSC rack, I disconnected the cable
at the RFL165 PD side. I need to go through the PD power supply circuit next week.

 

  5544   Mon Sep 26 14:21:07 2011 kiwamuUpdateSUSITMX ULSEN shows jumps

Quote from #5534

As a suspension test I am leaving all of the suspensions restored and damped with OSEMS but without oplevs

According to the spectra, all of the suspensions had been damped with the OSEMs. The peaks around 1Hz are reasonably suppressed.

However the spectra from ITMX showed a noise floor at very high level. This is because of strange jumps in the signal of the UL shadow sensor.

I will check some analog circuits for the UL sensor.

 


(ITMX shadow sensors)

Here is the spectra of the ITMX shadow sensors taken during the damping test (#5534)- -

 ITMXspectra.png 

The UL sensor shows a unacceptable amount of noise.

 

Additionally I checked the time series of the ITMX shadow sensors and found ONLY the UL sensor frequently showed strange jumps in data.

Here is an example of the time series showing a jump ONLY in the UL sensor.

ITMX-sensors.png

It is possible that the jumps are coming from some circuits, since the rest of the sensors (including the oplevs) don't detect the same jump.

  5543   Mon Sep 26 12:41:27 2011 kiwamuUpdateASCC1ASS : status update

Quote from #5518
(to do)
 + optimization of the ETMY oplevs and OSEM damping.
 + evaluation of the performance of the C1ASS with a good damping.

The servo for aligning the Y arm is working fine with the coarse gain coefficients.

However then I found the ASS_Xarm servo was not healthy.

So the next step is to refine the X arm servo in C1ASS.

 

(some notes)

  + With the ETMY oplev the Y arm became quieter after we recovered the oplev whitening filter (#5523)

  + The Y arm alignment scripts can be run from the usual C1IFO_CONFIGURE screen.

   It will servo the spot positions on ITMY and ETMY, and align the input beam pointing. It brings the Y arm power to about 1.

 + The X arm servo is doing something funny. It doesn't bring the arm power up to 1.

   I thought the X arm didn't need any modifications because the X arm servo doesn't include PZT1 and PZT2.

   So it maybe a simple bug (for example, some switches are disable and so on)

 

  5542   Mon Sep 26 11:35:44 2011 steveUpdateCamerasarms cameras upgraded

The arm's CCD cameras were reset as picture shows last week.

The height adjustment only works at ITMX. Short post holders are ordered to make this feature  available on the rest.

The 75 ohms video and power supply cables are stress relieved. Solid cover can be attached now without  miss aligning cameras.

Attachment 1: P1080251.JPG
P1080251.JPG
  5541   Sat Sep 24 20:14:36 2011 KojiUpdateLSCRough estimation of the PR gain

 

POXDC (i.e. POY DCout)
PRM misaligned: 70cnt
CA resonant PRMI: ~8000cnt (max)

REFLDC

PRMI antiresonant = 5200cnt
PRMI resonant = ~3000cnt
==> Visivility = 0.6

PRM
Transmissivity: TR=0.0575, tR=sqrt(TR)


Rough estimation of the power recycling gain (assuming perfect mode matching)

PPRM_mialign = Pin tR2
PPRM_resonant = Pin [tR/(1-rR rMI)]2

G = tR2 PPRM_resonant / PPRM_mialign = 8000/70*0.0575 = 6.5

This is way too low compared with the design (G>40)
This corresponds to rMI2=0.885 (loss of 10%) in the power recycling cavity.
But this yields visibility of 16%, instead of 60% which we saw. This is inconsistent.


If mode matching is not perfect, effective incident power of PRMI decreases
and this discrepancy may be explained

Pin = Pjunk + (Pin-Pjunk)

PPRM_mialign = Pin tR2
PPRM_resonant = (Pin-Pjunk) [tR/(1-rR rMI)]2

PREFL_antires ~ Pin
PREFL_resonant = Pjunk+(Pin-Pjunk)[-rR+(tR2 rMI)/(1-rR rMI)]2

===>

PPRM_resonant / PPRM_mialign = (1-Rmm) /(1-rR rMI)2=8000/70
PREFL_resonant /PREFL_antires= Rmm+(1-Rmm)[-rR+(tR2 rMI)/(1-rR rMI)]2=0.6

here Rmm= Pjunk/Pin is the mode matching ratio

Solving the last two equations, we obtain

Rmm=0.6,
rMI2= 0.939 (loss of 4-5%)

Can we believe that the mode matching is 60% and the loss is 5%???

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

Quote:

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

Quote from #5332

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz

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

 

 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0972455 Hz 

 Zero 2 frequency = 6.50126 Hz 

Overall gain = 71970.1

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

 

  5539   Sat Sep 24 17:12:54 2011 KojiUpdateLSCRealignment of REFL / Some 3f PRMI locking / Recycling Gain

[Koji Suresh]

Activity on Friday evening

- The REFL path has been thoroughly aligned
As I did not like the REFL spot misaligned on the REFL CCD, we went to the AP table.
Many optics had the spots not on the middle of the optic, including the PBS whose post was not fixed on the post holder.
We aligned the optical paths, the RF PDs, and the CCD. The alignment of the PD required the use of the IR viewer.
One should not trust the DC output as a reference of the PD alignment as it is not enough sensitive to the clipping.

We aligned the optical paths again after the reasonable alignment of PRM is established with the interferometer.
"Next time when you see REFL spot is not at the center of the camera, think what is moved!"

- The REFL165 PD is disconnected from the power supply
I found that the REFL165 PD is producing 7.5V output at the DC monitor no matter how the beam is blocked.
As I could not recover this issue by swapping the power connector at the LSC rack, I disconnected the cable
at the RFL165 PD side. I need to go through the PD power supply circuit next week.

- PRMI alignment policy of the night

Kiwamu has aligned Y-arm some time ago (Thursday evening?). I decided not to touch ITMY.
So the Michelson is aligned by ITMX, PRC is aligned by PRM.

- Michelson locking

The short Michelson was locked with AS55Q and the MICH filter. We could use the gain of +/-20 for locking,
and could increase it up to ~+/-250. At the max gain, the all three integrators and the two resonant gains
could be activated. The sign depends on which fringe you want at the AS port (bright or dark).

In this condition, the output of the POXDC channel (which is actually the POY DC out -- c.f. This entry
is used to determine the internal power. It was ~70cnt.

- PRMI locking

Then the PRMI was locked. There was some confusion of the gains because of the limitters at the servo filters
(which yielded the locking with 1bit outputs no matter how much the gains were....)

After all, I decided to use REFL33I for the PRCL for the test. The PRCL gain was -0.3~-1.0 for the carrier lock, but
was highly dependent on the alignment. i.e. if accidentally hit the high power recycling gain, it oscillated easily
and the lock was lost. Probably this was the first 3f locking at the 40m in the current optical config, if
Kiwamu did not do that secretly. The SB lock was also obtained by flipping the sign of the PRCL servo.

The difficulty we had was the instability when the recycling gain became big. We were monitoring the POXDC
(i.e.DCout of the POY PD). When this exceeds 5000, many glitches appears in the LSC signals and disturbs the lock.
This was not the fringes from neither the arms nor the SRC.

The observed POY DC with the carrier resonant PRMI was 5000~8000vcnt (momentary).

  5538   Sat Sep 24 09:55:42 2011 KeikoUpdateIOOAM modulation mistery

From the night day before yesterday (Sep 22nd, Thursday night. Sorry for my late update), there are more AM modulations than I measured in the previous post. It is changing a lot, indeed! Looking at the REFL11 I and Q signals on the dataviewer, the signal offset were huge, even after "LSCoffset" script. Probably the modulation index of AM was same order of PM at that time. The level of AM mod index is changing a lot depending on the EOM alingment which is not very stable, and also on the environment such as temperature .

To reduce AM modulations, here I note some suggestions you may want to try :

* Change the SAM connectors between RF resonator and EOM to be a soft but short connector, so that the resonator box doesn't hung from the EOM.

* Change the RF resonator base to be stable posts. Now several black plates are piled to make one base.

* Install a temperature shield

* Also probably you want to change the BNC connector on the RF resonator to be SMA.

* Be careful of the EOM yaw alignment. Pitch seemed to be less sensitive in producing AM than yaw alignment.

 

Quote:

AM modulation will add offset on SRCL signal as well as PRCL signal. About 2% of the signal amplitude with the current AM level. MICH will not be affected very much.

From #5504, as for the AM modulation I checked the MICH and SRCL signals in addition to the last post for PRCL, to see the AM modulation effect on those signals. On the last post, PRCL (REFL11I) was found to have 0.002 while the maximum signal amplitude is 0.15 we use . Here, I did the same simulation for MICH and SRCL.

As a result, MICH signals are not affected very much. The AM modulation slightly changes signal slopes, but doesn't add offsets apparently. SRCL is affected more, for REFL signals. All the REFL channels get about 0.0015 offsets while the signal ampliture varies up to 0.002. AS55I (currently used for SRCL) has 1e-7 offset for 6e-6 amplitude signal (in the last figure) - which is the same offset ratio comparing with the amplitude in the PRCL case -

 

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

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

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

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

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

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

Quote from #5332

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz

  5536   Sat Sep 24 01:51:02 2011 ranaUpdateSUSOplev filter optimization for 2 poles and 2 zeros

Quote:

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.

Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:

1) Limit the gain peaking at the upper UGF to 6 dB.

2) Minimum phase margin of 45 deg.

3) Minimum gain margin of 10 dB.

4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.

5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.

6) Looser noise contraint above 50 Hz for the non TM loops.

  5535   Sat Sep 24 01:38:14 2011 kiwamuUpdateCDSc1scx and c1x01 restarted

[Koji / Kiwamu]

 The c1scx and c1x01 realtime processes became frozen. We restarted them around 1:30 by sshing and running the kill/start scripts.

  5534   Sat Sep 24 01:21:11 2011 kiwamuUpdateSUSdamping test

As a suspension test I am leaving all of the suspensions restored and damped with OSEMS but without oplevs

  5533   Fri Sep 23 18:00:54 2011 SureshUpdateIOOPSL beam realigned to MC

I noticed that the beam centering on the WFS had changed over night and the MC_TRANS_SUM was about 40k counts.  When well aligned this SUM is around 50-55k counts. So PSL coupling into MC was suboptimal. It was not clear whether the MC shifted or the PSL beam shifted. So I looked at the PSL ANG and POS QPDs. 

 trend.png

The plots above show the gradual drift of the PSL beam in vertical direction during the last 8hrs or so. But the last bit shows the adjustments I had to make to reobtain optimal alignment.  And these adjustments are not undoing the drift!  This would indicate that the MC axis has also shifted during the same time period. 

  5532   Fri Sep 23 17:57:34 2011 PaulUpdateSUSOplev filter optimization for 2 poles and 2 zeros

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I have a attached a plot showing the power spectrum and RMS curves for the optimization result for 2 zeros and 2 poles, optimized to give a minimal RMS below 20Hz.

I have also attached a plot showing the loop gain and the filter transfer function.

The noise spectrum shows that the optimised filter gives a better noise performance below 10Hz, but a servo oscillation at the UGF of 10 Hz means it injects a lot of motion around this frequency. Should I consider some more aggressive way to force the script to keep a decent phase margin?

The fminsearch results show that the 'optimized' solution is two resonant peaks:

 

 -- Optimisation completed after 571 iterations--

 Started with: 

 Pole 1 frequency = 1 Hz 

 Pole 2 frequency = 2 Hz 

 Zero 1 frequency = 0.1 Hz 

 Zero 2 frequency = 5 Hz 

Overall gain = 1 

 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz 

Overall gain = 71970.1 

 Initial RMS below 10 Hz = 5.90134e-06

 Remaining RMS below 10 Hz = 8.42898e-07

 

 

 

Attachment 1: optimised2p2z_v1.png
optimised2p2z_v1.png
Attachment 2: optimised2p2z_v1_TFs.png
optimised2p2z_v1_TFs.png
  5531   Fri Sep 23 17:31:14 2011 KatrinUpdateGreen LockingStray light reduction (Y)

I inserted several beam blocks and iris on the Y arm Green table. There was/is lots of stray light because a lot of the mirrors are not under an angle of incident of 45°. Some stray light is left since couldn't find an appropriate beam block/dump due to lack of space on the table.

 

  5530   Fri Sep 23 16:56:07 2011 MirkoUpdateLSCDesired MC modulation frequency measurement, tuning of modulation frequency

[ Mirko, Koji, Suresh ]

Looked into the modulation frequency that should pass the input MC. With a locked MC looked at the RF output of the PD in refl of the MC. Looked at the beat between 11MHz and 29.5MHz. Minimizing it by fine-tuning the 11MHz freq. ( which means maximizing the 11MHz transmission).

SB freq. [MHz]     Beat power [dBm]

11.065650          -75

11.065770          -80 (diving into spec. analyzer instrument noise)

11.066060          -80 (surfacing out of spec. analyzer instrument noise)

Set the freq. to the middle of the last two points: 11.065910MHz at 16:26.

ToDo: How big a problem is the AM?

ELOG V3.1.3-