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

  5529   Fri Sep 23 16:25:01 2011 steveUpdateVACvac rack UPS battery replaced

APC Smart -UPS 2200   model: SUA2200RM2U   batteries were replaced by compatible RBC43, 8x  12V5A

Attachment 1: P1080252.JPG
P1080252.JPG
Attachment 2: P1080254.JPG
P1080254.JPG
  5528   Thu Sep 22 23:18:51 2011 KojiSummaryLSCThe LSC screen modification

 

C1LSC_RFPD.adl screen was modified to have more information.

Attachment 1: C1LSC_RFPD.png
C1LSC_RFPD.png
  5527   Thu Sep 22 23:10:07 2011 SureshUpdateIOOproposed modifications to the C1IOO model

Rana advised that we put in a lockin-output matrix which will allow us to excite any combination of MC mirrors so that we can excite pure translations or rotations of the MC beam axis.  This would require us to direct a lockin output into all the three mirrors simultaneously with a +1 or -1 as needed in the matrix..

  5526   Thu Sep 22 23:02:15 2011 SureshUpdateIOOno light on WFS2. Realigned input onto both WFS

Rana noticed that the sum on WFS2 was about 10 times smaller than that on WFS1. Though the beam appeared centered on the DC QPD screens it was not really true.  When I went and checked the actual beam position it was landing on the metal enclosure of the WFS2 sensor and scattering back on to the diode. 

I also checked the power levels of light landing on the sensors  It was about 0.25mW in both cases.  This needs further investigation since the power split at the beam spitter is like 0.25mW onto WFS1 and 0.45 towards WFS2. The lost 0,20 mW has to be traced and we have to be sure that it is not scattered around on the table.

 

  5525   Thu Sep 22 22:55:01 2011 AnamariaUpdateLSCPOX channel = POY PD connected + Bad Rack

Keiko, Anamaria

We decided we needed a DC channel to sense the gain in the PRC, so we set to align POY55. It took a while because the beam was very weak, and it comes in upwards, so we used a couple of mirrors to bring to a reasonable flat level, and put it on the PD. Then we went to read the DC out and we got 1.3V stationary! Nonsense. We also realized there is no LO for this PD, or any other 55MHz PD, aside from REFL55. Oh well, we only wanted the DC for now. POY55 is aligned (decently).

Koji told me to try swapping the power cable, so I unplugged it at the rack and plugged it in another power card. And it worked! I then moved the DC out (back of rack) to follow the front, and it turns out POY55 diode is read on the POXDC channel. I plugged and unplugged it in disbelief, but it is what it is. At least we have a readout on the power level in PRC.

I attach a picture of the power cards for the LSC RFPDs, with the 3 I found to be bad, and showing current config. I had to move REFL11 and POY55 from their assigned spot.

The two on the lower left are bad in the sense that they put an offset on the PD and make the DC readout be 1.3V for no reason (when working, for example, POY55 read 60mV). The one on the lower right I had trouble with some time ago, it made the PD not read any voltage at all (when working it would read at least 100mV). Beyond that I have not investigated what is up, since I could find working plugins.

Attachment 1: RFPDpowerRack2.pdf
RFPDpowerRack2.pdf
  5524   Thu Sep 22 22:53:06 2011 SureshUpdateComputer Scripts / ProgramsActivated DAQ channels in C1IOO model and restared fb

To look at the WFS servo signals I was using test points in the servo filter banks.  This is not recommended for regular operation since acquiring the testpoint data at 16k loads the fb. Instead, I ran the daqconfig script from the scripts directory and activated the IN1_DQ, IN2_DQ and OUT_DQ channels in all the six servo filter banks (at 2048 Hz sampling rate) and then restarted the fb.   However the c1ioo Sun machine stopped responding after this.  Koji and I went in to see what was going on and the machine was not reponding to a keyboard plugged directly into the machine.  The screen display showed no reponse to our key press.  So we did a hardware reboot with the tiny switch in front of the machine.  It came up okay and all the c1ioo models were back in action.

I then checked with the dataviewer to make sure that I can see the trends on the newly activated DQ channels.  They were all fine.

  5523   Thu Sep 22 20:12:54 2011 kiwamuUpdateSUSETMY oplev whitening engaged

The whitening filters for the ETMY oplevs are back.

The whitening board had been in the rack but the ADC was connected directly to the oplev interface board without going through the whitening board.

In fact the interface board and the whitening board had been already connected. So the ADC was making a shortcut.

I disconnected the ADC from the interface board and plugged it to the output of the whitening board.

Here is an example of the new open-loop transfer function with the whitening filters.

OLETMY_WF.png

 Note :

before the measurement I increased the control gain by an arbitrary number to obtain gain of more than 1 around 1 Hz.

Quote from #5521

I will check the whitening filters.

  5522   Thu Sep 22 18:33:01 2011 KojiSummaryLSCThe LSC screen modification

As per the request of Anamaria, I have added the slider of the demodulation phase for each RF PD screens.

Attachment 1: PD_screen.png
PD_screen.png
  5521   Thu Sep 22 17:48:20 2011 kiwamuUpdateSUSbad oplev on ETMY

It turned out the oplev controls on ETMY were just bad.

It looks like the whitening filters have been OFF and because of that the resultant open-loop was not crossing the unity gain.

I will check the whitening filters.

 

(open-loop transfer function)

The blue dots are the measured data points and the green curve is the fit.

Apparently the open-loop doesn't go above the unity gain, so the oplev had been doing nothing.

If we try to increase the overall gain it will oscillate because of the phase delay of more than 180 deg around 3 Hz.

The red curve is the expected one with the whitening filters (WFs) properly engaged.

Note that WF are supposed to have two zeros at 1 Hz and two poles at 10 Hz.

 OLETMY.png

Quote from #5518
(to do)
 + optimization of the ETMY oplevs and OSEM damping.

  5520   Thu Sep 22 17:29:42 2011 KeikoUpdateIOOAM modulation mistery

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 -

 

(1) MICH signals at AS port with AM m=0

AMmod0MICH.png

(2) MICH signals at AS port with AM m=0.003

AMmod1e-1MICH.png

(3) SRCL signals at AS/REFL port with AM m=0

AMmod0SRCL.png 

(3) SRCL signals at AS/REFL port with AM m=0.003

AMmod3e-3SRCL.png

AMmod3e-3SRCL-AS55I.png

 

Quote:

How about changing the x-axis of all these plots into meters or picometers and tell us how wide the PRC resonance is? (something similar to the arm cavity linewidth expression)

Also, there's the question of the relative AM/PM phase. I think you have to try out both I & Q in the sim. I think we expect Q to be the most effected by AM.

 

  5519   Thu Sep 22 15:53:37 2011 MirkoUpdateLSCRF modulation depth measurement again

Toyed around with the modematching some more today.

The outermost glass elements of the OSA are about 28cm apart.

With the OSA beeing a confocal cavity that should mean that the ROC of every mirror is 28cm on the cavity side. If the input surface is flat we need a 28cm focusing lens for good MM. If it's not we shouldn't need any MM.

Tried a f=250mm lens on different positions first. Got at best about 570mV (PD gain=10) in transmission of the OSA.

Then tried a f=1000mm lens. Best transmission 1.22V (7.2% transmission). SB were (PD gain =100) 11MHz: 87.2mV (m=0.17) , 55MHz: 59.2mV (m=0.14)

Lost the position while toying around. Left it then at 1.0V transmisison at 15:15 local time. Let's see how much it drifts. SBs for this were 11MHz: 52.8mV (m=0.17), 55MHz: 73.8mV (m=0.14)

[Ed by KA: If the carrier transmission was really 1.22V and 1.0V the modulation depths calculated are inconsistent with the measurement.]

Spacing between carrier 11MHz and 55MHz SBs seems consistent, and leads to a FSR measurement of 1.5GHz, also fine.

 

Update: After 90mins no change in carrier transmitted power. Next morning: Carrier transmission down by 10%.

DSC_3478.JPG

 DSC_3481.JPG

DSC_3480.JPG

ELOG V3.1.3-