40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 205 of 348  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  4245   Thu Feb 3 16:08:06 2011 AidanUpdateComputer Scripts / ProgramsRCG VCO frequency error

Joe and I were looking at the RCG VCO algorithm to determine if we could adapt it to run at a faster rate (you can currently change its frequency at 1Hz). I noticed that the algorithm that is used to calculated the values of sine and cosine at time T1  is a truncated Taylor series which uses the values of sine and cosine calculated at time T1 - Delta t . I was concerned that there would be an accumulating phase error so I tested the algorithm in MATLAB and compared it to a proper calculation of sine and cosine. It turns out that at a given 'requested' frequency there is a constantly accumulating phase error - which means that the 'actual' frequency of the RCG VCO is incorrect. So I have plotted the frequency error vs requested VCO frequency. It gets pretty bad!

 Here's the code I used:

dt = 1/16384;

diffList = [];
% set the frequencies

flist = 1:5:8192;
for f = flist;
    % get the 'accurate' values of sine and cosine
    tmax = 0.05;
    time1 = dt:dt:tmax;
    sineT = sin(2.0*pi*f*time1);
    cosineT = cos(2.0*pi*f*time1);
    % determine the phase change per cycle
    dphi = f*dt*2*pi;
    cosT1 = 1:numel(time1);
    sinT1 = 0*(1:numel(time1));
    % use the RCG VCO algorithm to determine the values of sine and cosine
    for ii = 1:numel(time1) - 1;                 
        cosNew = cosT1(ii)*(1 - 0.5*dphi^2) ...
                      - (dphi)*sinT1(ii);
        sinNew = sinT1(ii)*(1 - 0.5*dphi^2) ...
                      + (dphi)*cosT1(ii);
        cosT1(ii+1) = [ cosNew];
        sinT1(ii+1) = [ sinNew];
    % extract the phase from the VCO values of sine and cosine
    phaseT = unwrap(angle(cosineT + i* sineT));
    phaseT1 = unwrap(angle((cosT1 + i*sinT1)));
    % determine the phase error for 1 cycle
    diff = phaseT1 - phaseT;
    % determine the frequency error
    slope = (diff(2) - diff(1))/(dt);
    diffList = [diffList, slope];

% plot the results

close all
orient landscape
loglog(flist, abs(diffList/(2.0*pi)))
xlabel('Requested VCO Frequency (Hz)')
ylabel('Frequency error (Hz)')
grid on

print('-dpdf', '/users/abrooks/VCO_error.pdf')

Attachment 1: VCO_error.pdf
  7046   Fri Jul 27 16:32:17 2012 JamieUpdateCDSRCG bug exposed by simple c1tst model

As Den mentioned in 7043, attempting to run the c1tst model was causing the entire c1iscey machine to crash.  Alex came over this morning and we spend a couple of hours trying to debug what was going on.

c1tst is the simplest possible model you can have: 1 ADC and 2 filter modules.  It compiles just fine, but when you tried to load it the machine would completely freeze.

We eventually tracked this down to a non-empty filter file for one of the filter modules.  It turns out that the model was crashing when it attempted to load the filter file.  Once we completely deleted all the filters in the module, the model would run.  But then if you added back a filter to the filter file and tried to "load coefficients", the model/machine would immediately crash again.

So it has something to do with the loading of the filter coefficients from the filter file.  We tried different filters and it didn't seem to make a difference.  Alex thought it might have something to do with zeros in some of the second-order sections, but that wasn't it either.

There's speculation that it might be related to a very similar bug that Joe reported at LLO a month ago: https://bugzilla.ligo-wa.caltech.edu/bugzilla/show_bug.cgi?id=398

Things we tried, none of which worked:

  • adding a DAC
  • turning on/off biquad
  • disabling the float denormalization fix

This is a real mystery.  Alex and I are continuing to investigate.

  3564   Mon Sep 13 10:22:48 2010 josephbUpdateCDSRCG bugs/feature request wiki page

I've started a wiki page under the Upgrade 09/New CDS section regarding known bugs and pending feature requests for the Real Time Code Generator.   It can be found at http://lhocds.ligo-wa.caltech.edu:8000/40m/Bugs_and_Pending_Feature_requests_for_the_RCG.  If you have any ideas to improve the RCG or encounter a bug in the code generation process (say a particular part doesn't work inside subsystems for example), please note them here.

Currently there are bugs with excitation points (they don't work inside of a subsystem block) and tags (they don't respect scope and only 1 "from" tag for each "goto" tag connected to the output of a subsystem block).

  2540   Thu Jan 21 17:23:30 2010 josephb,alex,kojiHowToComputersRCG code fixes

In order to see the Contec DO-32L-PE Digital output PCIe card with the new controls, we had to add the CDO32 part to the CDS_PARTS.mdl file in control /cds/advLigo/src/epics/simLink/ directory on megatron, as well as create the actual model mdl file (based on cdsDio.mdl) in the control/cds/advLigo/src/epics/simLink/lib directory. 

The CDO32.pm file (in /home/controls/cds/advLigo/src/epics/util/lib) has existed for some time, it was just missing the associated pieces in simlink.  However, Alex also checked out a newer version Dio.pm in the process.  As we are not using this part at this time, it should be fine.

The code now compiles and sees the digital output card.

You need a special care on this block as it turned out that the code does not compiled if the "constant" block is connected to the input. You must use appropriate block such as bitwise operator, as shown below.

Attachment 1: CDO32.png
  1508   Thu Apr 23 13:55:43 2009 josephb, peterUpdateComputersRCG example

We successfully compiled and installed the Real time Code Generator "Hello World" example (which is a skeleton for the ETMX suspension controller) on megatron.  In order to get it to compile, we had to add a flag indicating the computer is stand alone, and not using a myrinet card at the moment.  This was done by adding the shmem_daq = 1 flag to the cdsParameters module.  The symptom was it was unable to find gm.h (and there is no installed /opt/gm directory).

It is called "sam".  It was installed to /cvs/cds/caltech/target/sam, and produced medm screens in /cvs/cds/caltech/medm/c1/sam.  As nothing points to these, I figure it won't harm any of the current configuration, but lets us play around a bit.  If by some strange reason, these do cause problems, feel free to remove them.

  1781   Wed Jul 22 20:11:26 2009 peteUpdateComputersRCG front end

I compiled and ran a simple (i.e. empty) front end controller on scipe12 at wilson house.  I hooked a signal into the ADC and watched it in the auto-generated medm screens. 

There were a couple of gotchas:

1. Add an entry SYS to the file /etc/rc.local, to the /etc/setup_shmem.rtl line, where the system file is SYS.mdl.

2. If necessary, do a BURT restore.  Or in the case of a mockup set the BURT Restore bit (in SYS_GDS_TP.adl) to 1.


  9498   Fri Dec 20 00:16:39 2013 KojiSummaryCDSRCG parsing bug?

A while ago, I noticed that the most significant bits of the LSC whitening DOs are not toggling.
I track this issue down and found what is happening. I need experts' help.

To illuminate the issue, terminators are connected to Bit15 of the Bit2Word blocks in the LSC model (attached screen shots).

The corresponding source file is found in c1lsc.c at the following location.
The last channels of the Bit2Word are connected to lsc_cm_slow (the filter module).
This is the source of the issue. This wrong assignment of the connections
can't be changed by connecting Go-From tags to the chennels.


3881// Bit2Word:  LSC_cdsBit2Word1                                                                                                              
3883double ins[16] = {
3884        lsc_as110_logicaloperator4,
3885        lsc_as110_logicaloperator1,
3886        lsc_refl11_logicaloperator4,
3887        lsc_refl11_logicaloperator1,
3888        lsc_pox11_logicaloperator4,
3889        lsc_pox11_logicaloperator1,
3890        lsc_poy11_logicaloperator4,
3891        lsc_poy11_logicaloperator1,
3892        lsc_refl33_logicaloperator4,
3893        lsc_refl33_logicaloperator1,
3894        lsc_pop22_logicaloperator4,
3895        lsc_pop22_logicaloperator1,
3896        lsc_pop110_logicaloperator4,
3897        lsc_pop110_logicaloperator1,
3898        lsc_as165_logicaloperator4,
3899        lsc_cm_slow
3901lsc_cdsbit2word1 = 0;
3902for (ii = 0; ii < 16; ii++)
3904if (ins[ii]) {
3905lsc_cdsbit2word1 += powers_of_2[ii];

3946// Bit2Word:  LSC_cdsBit2Word2                                                                                                              
3948double ins[16] = {                                                                                                                          
3949        lsc_as55_logicaloperator4,                                                                                                          
3950        lsc_as55_logicaloperator1,                                                                                                          
3951        lsc_refl55_logicaloperator4,                                                                                                        
3952        lsc_refl55_logicaloperator1,                                                                                                        
3953        lsc_pop55_logicaloperator4,                                                                                                         
3954        lsc_pop55_logicaloperator1,                                                                                                         
3955        lsc_refl165_logicaloperator4,                                                                                                       
3956        lsc_refl165_logicaloperator1,                                                                                                       
3957        lsc_logicaloperator_cm_ctrl,                                                                                                        
3958        ground,                                                                                                                             
3959        ground,                                                                                                                             
3960        lsc_logicaloperator_popdc,                                                                                                          
3961        lsc_logicaloperator_poydc,                                                                                                          
3962        lsc_logicaloperator_poxdc,                                                                                                          
3963        lsc_logicaloperator_refldc,                                                                                                         
3964        lsc_cm_slow                                                                                                                         
3966lsc_cdsbit2word2 = 0;                                                                                                                       
3967for (ii = 0; ii < 16; ii++)                                                                                                                 
3969if (ins[ii]) {                                                                                                                              
3970lsc_cdsbit2word2 += powers_of_2[ii];


Attachment 1: Bit2Word1.png
Attachment 2: Bit2Word2.png
  9503   Fri Dec 20 11:40:13 2013 JamieSummaryCDSRCG parsing bug?

I submitted a bug report for this:


However, given how old our RCG version is (2.5 vs. 2.8 current deployed at the sites) I don't think we're going to see any traction on this.  Even if this is still a bug in 2.8, they'll only fix it in 2.8.  There's no way they're going to make a bug fix release for 2.5.

We need to upgrade.

  9505   Fri Dec 20 18:00:02 2013 KojiSummaryCDSRCG parsing bug?

The bug is still there but the incorrect bits are now overridden.

Attachment 1: Screenshot-c1lsc-LSC.png
  1801   Tue Jul 28 18:32:21 2009 KojiUpdateCDSRCG work

Peter and Koji,

We are constructing a setup for the new 40m CDS using Realtime Code Generator (RCG).
We are trying to put simulated suspensions and test suspension controllers on a different processors of megatron
in order to create a virtual control feedback loop. Those CDS processes are communicating
each other via a shared memory, not via a reflective memory for now.

After some struggles with tremendous helps of Alex, we succeeded to have the communication between the two processes.
Also we succeeded to make the ADC/DAC cards recognized by megatoron, using the PCI express extension card replaced by Jay.
(This card runs multi PCI-X cards on the I/O chasis.)

Next steps:
- Establish a firewall between the 40m network and megatron (Remember this)
- Make DTT and other tools available at megatron
- Try virtual feedback control loops and characterize the performance
- Enable reflective memory functionalities on megatron
- Construct a hybrid system by the old/new CDSs
- Controllability tests using an interferometer

o Each cdsIPC should have a correct shared memory address spaced by 8 bytes. (i.e. 0x1000, 0x1008, 0x1010, ...)

Note on MEDM
o At the initial state, garbage (e.g. NaN) can be running all around the feedback loops. They are invisible as MEDM shows them as  "0.0000".
To escape from this state, we needed to disconnect all the feedback, say, by turning off the filters.

Note on I/O chasis
o We needed to pull all of the power plugs from megatron and the I/O chasis once so that we can activate
the PCI-e - PCI-X extension card. When it is succeeded, all (~30) LEDs turn to green.

  1805   Wed Jul 29 12:14:40 2009 peteUpdateComputersRCG work

Koji, Pete 

Yesterday, Jay brought over the IO box for megatron, and got it working.  We plan to firewall megatron this afternoon, with the help of Jay and Alex, so we can set up GDS there and play without worrying about breaking things.  In the meantime, we went to Wilson House to get some breakout boards so we can take transfer functions with the 785, for an ETMX controller.  We put in a sine wave, and all looks good on the auto-generated epics screens, with an "empty" system (no filters on). Next we'll load in filters and take transfer functions.

Unfortunately we promised to return the breakout boards by 1pm today.  This is because, according to denizens of Wilson House, Osamu "borrowed" all their breakout boards and these were the last two!  If we can't locate Osamu's cache, they expect to have more in a day or two.

Here is the transfer function of the through filter working at 16KHz sampling. It looks fine except for the fact that the dc gain is ~0.8. Koji is going to characterize the digital down sampling filter in order to try to compare with the generated code and the filter coefficients.

Attachment 1: TF090729_1.png
Attachment 2: TF090729_1.png
  1819   Mon Aug 3 13:47:42 2009 peteUpdateComputersRCG work

Alex has firewalled megatron.  We have started a framebuilder there and added testpoints.  Now it is possible to take transfer functions with the shared memory MDC+MDP sandbox system.  I have also copied filters into MDC (the controller) and made a really ugly medm master screen for the system, which I will show to no one.

  1829   Tue Aug 4 17:51:25 2009 peteUpdateComputersRCG work

Koji, Peter


We put a simple pendulum into the MDP model, and everything communicates.  We're still having some kind of TP or daq problem, so we're still in debugging mode.  We went back to 32K in the .adl's, and when driving MDP,  the MDC-ETMX_POS_OUT is nasty, it follows the sine wave envelope but goes to zero 16 times per second.


The breakout boards have arrived.  The plan is to fix this daq problem, then demonstrate the model MDC/MDP system.  Then we'll switch to the "external" system (called SAM) and match control TF to the model.  Then we'd like to hook up ETMX, and run the system isolated from the rest of the IFO.  Finally we'd like to tie it into the IFO using reflective memory.

  1839   Wed Aug 5 17:41:54 2009 peteUpdateComputersRCG work - daq fixed

The daq on megatron was nuts.  Alex and I discovered that there was no gds installation for site_letter=C (i.e. Caltech) so the default M was being used (for MIT).  Apparently we are the first Caltech installation.  We added the appropriate line to the RCG Makefile and recompiled and reinstalled (at 16K).  Now DV looks good on MDP and MDC, and I made a transfer function that replicates  bounce-roll filter.  So DTT works too.

  1881   Mon Aug 10 17:49:10 2009 peteUpdateComputersRCG work - plans

Pete, Koji


We discussed a preliminary game plan for this project.  The thing I really want to see is an ETMX RCG controller hooked into the existing frontend via reflective memory, and the 40 m behaving normally with this hybrid system, and my list is geared toward this.  I suspect the list may cause controversy.

+ copy the MDC filters into SAM, and make sure everything looks good there with DTT and SR785.

+ get interface / wiring boards from Wilson House, to go between megatron and the analog ETMX system

+ test tying the ETMX pendulum and bare-bones SAM together (use existing watchdogs, and "bare-bones" needs defining)

+ work some reflective memory magic and create the hybrid frontend


In parallel with the above, the following should also happen:

+ MEDM screen design

+ add non-linear bits to the ETMX MDP/MDC model system

+ make game plan for the rest of the RCG frontend

  1826   Tue Aug 4 13:40:17 2009 peteUpdateComputersRCG work - rate

Koji, Pete


Yesterday we found that the channel C1:MDP-POS_EXC looked distorted and had what appeared to be doubled frequency componenets, in the dataviewer.  This was because the dcu_rate in the file /caltech/target/fb/daqdrc was set to 16K while the adl file was set to 32K.  When daqdrc was corrected it was fixed.  I am going to recompile and run all these models at 16K.  Once the 40 m moves over to the new front end system, we may find it advantageous to take advantage of the faster speeds, but maybe it's a good idea to get everything working at 16K first.

  1856   Fri Aug 7 16:00:17 2009 peteUpdateComputersRCG work. MDC MDP open loop transfer function

Today I was able to make low frequency transfer function with DTT on megatron.  There seems to have been a timing problem, perhaps Alex fixed it or it is intermittent.

I have attached the open loop transfer function for the un-optimized system, which is at least stable to step impulses with the current filters and gains.  The next step is to optimize, transfer this knowledge to the ADC/DAC version, and hook it up to isolated ETMX.

Attachment 1: tf_au_natural.pdf
tf_au_natural.pdf tf_au_natural.pdf
  1870   Sun Aug 9 16:32:18 2009 ranaUpdateComputersRCG work. MDC MDP open loop transfer function

This is very nice. We have, for the first time, a real time plant with which we can test our changes of the control system. From my understanding, we have a control system with the usual POS/PIT/YAW matrices and filter banks. The outputs go to a separate real-time system which is running something similar and where we have loaded the pendulum TF as a filter. Cross-couplings, AA & AI filters, and saturations to come later.

The attached plot is just the same as what Peter posted earlier, but with more resolution. I drove at the input to the SUSPOS filter bank and measured the open loop with the loop closed. The loop wants an overall gain of -0.003 or so to be stable.

Attachment 1: a.png
  1879   Mon Aug 10 17:36:32 2009 peteUpdateComputersRCG work. PIT, YAW, POS in MDP/MDC system

I've added the PIT and YAW dofs to the MDC and MDP systems.  The pendula frequencies in MDP are 0.8, 0.5, 0.6 Hz for POS, PIT, and YAW respectively.  The three dofs are linear and uncoupled, and stable, but there is no modeled noise in the system (yet) and some gains may need bumping up in the presence of noise.  The MDC filters are identical for each dof (3:0.0 and Cheby). The PIT and YAW transfer functions look pretty much like the one Rana recently took of POS, but of course with the different pendulum frequencies.  I've attached one for YAW.

Attachment 1: mdcmdpyaw.jpg
  2379   Thu Dec 10 09:51:06 2009 robUpdatePSLRCPID settings not saved

Koji, Jenne, Rob


We found that the RCPID servo "setpoint" was not in the relevant saverestore.req file, and so when c1psl got rebooted earlier this week, this setting was left at zero.  Thus, the RC got a bit chilly over the last few days.  This channel has been added. 


Also, RCPID channels have been added (manually) to conlog_channels. 

  2381   Thu Dec 10 09:56:32 2009 KojiUpdatePSLRCPID settings not saved

Note: The set point C1:PSL-FSS_RCPID_SETPOINT is 37.0 on C1PSL_FSS_RCPID.adl.

Now the temp is recovering with its full speed. At some point we have to restore the value of the FSS SLOW DC as the temp change drag it up.


Koji, Jenne, Rob

We found that the RCPID servo "setpoint" was not in the relevant saverestore.req file, and so when c1psl got rebooted earlier this week, this setting was left at zero.  Thus, the RC got a bit chilly over the last few days.  This channel has been added. 

Also, RCPID channels have been added (manually) to conlog_channels. 


Attachment 1: RC_TEMP.png
  1968   Mon Sep 7 20:05:18 2009 ranaUpdatePSLRCTEMP v. RMTEMP

Since ~Aug. 27, the reference cavity has been running with no thermal control. This is not really a problem at the 40m; a 1 deg change of the glass cavity

will produce a 5 x 10-7 strain in the arm cavity. That's around 20 microns of length change.

This open loop time gave us the opportunity to see how good our cavity's vacuum can insulation is.



The first plot below shows the RCTEMP sensors and the RMTEMP sensor. RMTEMP is screwed down to the table close to the can and RCTEMP is on the can, underneath the insulation. I have added a 15 deg offset to RMTEMP so that it would line up with RCTEMP and allow us to see, by eye, what's happening.

There's not enough data here to get a good TF estimate, but if we treat the room temperature as a single frequency (1 / 24 hours) sine wave source, then we can measure the delay and treat it as a phase shift. There's a ~3 hour delay between the RMTEMP and RCTEMP. If the foam acts like a single pole low pass filter, then the phase delay of (3/24)*360 = 45 deg implies a pole at a ~3 hour period. I am not so sure that this is a good foam model, however.

The colorful plot is a scatter plot of RCTEMP v. RMTEMP. The color denotes the time axis - it starts out blue and then becomes red after ten days.

  5643   Mon Oct 10 13:52:04 2011 kiwamuUpdateLSCRE: First attempt to estimate mode matching efficiency using interferometer

Quote from #5640

"^2"s are missing in the second equation, but the calculation results seem correct.

PRX and PRY have different mode matching because of the Michelson asymmetry.
Are individually estimated mode matching indicates any sign of reasonable mode mismatch?
(The difference can be very small because the asymmetry is not so big.)

- Thank you for the correction. The missing square operation has been added correctly on the last entry (#5639).

- As for the individual MM efficiency,
   I was assuming that the MM solutions are the same for PRX, PRY and the real PRC, so I haven't carefully checked differences between those cavities.
   However as you mentioned the difference in those cavities can be tiny due to the small 3 cm Schnupp asymmetry.
   Anyway I will briefly check it to make me sure.
  2114   Mon Oct 19 10:00:52 2009 kiwamuUpdateLSCRE: LSC timing issue

Of course I know there is a downconversion in OMC signal from 32k to 16k.

But I was just wondering if the delay comes from only downconversion.

And I can not find any significant noise in both signals because I use the triangular, which cause the higer harmonics and can hide the timing noise in frequency domain.

So I'm going to make the same measurement by using sinusoidal instead of triangular, then can see the noise in frequency domain.



You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?


*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.


*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )



  2688   Sat Mar 20 18:34:19 2010 kiwamuSummaryElectronicsRE:advantege of our triple resonant EOM

Yes, I found it.

Their advantage is that their circuit is isolated at DC because of the input capacitor.

And it is interesting that the performance of the circuit in terms of gain is supposed to be roughly the same as our transformer configuration.

  12509   Tue Sep 20 17:04:46 2016 SteveUpdateElectronicsREF33

REF33 was removed for taking picture of the bare C30362 InGaAs photodiode per Rana's request. All other rf photodiodes have their glass cover on.

Note: it is back to it's place but this pd will need alignment!

The small steering mirror was completly lose before it was removed.

Attachment 1: A005_-_20160920_135529_-_Shortcut.lnk.bmp
  9313   Wed Oct 30 01:22:56 2013 JenneUpdateLSCREFL 165 demod phase adjusted


For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.

 This of course changes our demod phase.  Rana plotted a 4th order elliptic filter in Matlab, and from the plot determined that we should expect around 60 degrees of difference in our phase. 

To actually set the phase, I locked PRMI on AS55Q and REFL33I (MICH gain = -8.0, PRCL gain = +0.05, with 1's in the matrix elements).  I then turned on the PRCL oscillation notch (564 Hz), and turned on the sensing matrix's drive at that frequency, and looked at the spectrum of REFL165. 

The previous REFL165 demod phase was 96 degrees, so I was looking around either 36 degrees or 156 degrees.  The phase that minimized the peak in the Q signal while driving PRCL was 37.5 degrees.  Good work Matlab/Rana.

I then looked at the transfer functions between REFL33 and AS55 and REFL165, to see if there were any sign flips that happened.  There were not.  As expected, it was just a little extra phase delay.

I was able to lock PRMI with REFL 165 again after this phasing, and I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.

  9491   Wed Dec 18 18:45:39 2013 JenneUpdateLSCREFL 165 demod phases

I checked out the REFL165 demod phase, and it looks like it was okay.  it was -20.9 degrees.  I turned on my sensing matrix oscillators, and maximized the PRCL signal in the REFL165_I_ERR channel, and got a pretty good maximization at +155 degrees.  I used this to lock the PRMI on sidebands, with MICH gain of +0.3, and PRCL gain of +0.1 . 

Since this is working, I'm leaving the REFL 165 phase here, at +155 degrees, although this is almost exactly 180 degrees from what Den left it at, so I'm not sure why I was not able to lock with a demod phase of -20.9.  (I tried all 4 permutations of signs, with gain values of the same magnitude (0.3 for MICH, 0.1 for PRCL), and wasn't able to lock.  I'll try to figure this out tomorrow, but it was time for the meeting, then the IFO has been busy doing more important things the rest of the afternoon.

Plan for checking:  Lock with demod phase of 155, measure TF to one of the other REFL diodes (11, 33 or 55), lock on that other REFL diode.  Then, change the REFL 165 demod phase back to -20.9, and measure the transfer function again.  Hopefully the answer is just that I was doing something dumb, and it works easily.  This test/measurement should only take a few minutes, but it'll make me happier knowing that things still work as they should.

  9979   Wed May 21 05:05:39 2014 JenneUpdateLSCREFL 165 vs 33 investigations

[Rana, Jenne]

We spent some time tonight looking at locking the PRMI with REFL165 vs. REFL33, while reducing the CARM offset. 

We were not able to lock the PRMI on REFL165 I&Q at small CARM offsets.  When locking at larger CARM offsets (about 100 counts, which is about 100nm) and then re-adjusting the REFL165 demod phase as I reduced the CARM offset, I saw that I had to significantly rotate the phase.  For PRMI only (no arms), the REFL165 demod phase was -138.5 deg.  When the PRMI was locked with a -100 count CARM offset, the optimal demod phase was -123 deg.  Then at -90 counts the phase was -113 deg.  At -70 counts, the phase was -108 deg, at -50 counts it was -98 deg, and at -40 it was -93 deg.  We want to go back and look at these more carefully, and in a more continuous way, by watching the sensing matrix calibration lines.  It's unclear to me right now why we're seeing this, but it's possible that we're getting some kind of extra 55MHz resonances.

REFL DC looks like it should be good - same slope and gain as sqrtTR, extra 20 or 30 deg of phase margin, so we think that we should be able to transition over to it, and then try engaging the AO path.  Tonight we had Den's new 1kHz lowpass engaged, and with this, everything looks nice and stable.

Game plan:  Bring CARM in until transmissions are at about 10ish, then try keeping CARM on sqrtInvTrans for the DC part, and engage the AC AO part with REFL DC.  We probably just need to try this for a while more to find just the right way to turn it on.

Need to think about demod phase rotation vs CARM offset as well as extra resonances, but this may take a while, and if we can just get the AO path engaged, that would be good.

  6378   Wed Mar 7 19:10:06 2012 kiwamuUpdateLSCREFL OSA : how the signal look like

Just a quick report on the REFL OSA.

The attached plot below shows the raw signal from the REFL OSA which Keiko installed in this afternoon.

When the data was taken the beam on the REFL OSA was a direct reflection from PRM with the rest of the suspended mirrors misaligned.

One of the upper and lower 11 MHz sidebands is resolved (it is shown at 0.12 sec in the plot) while the other one is still covered by the carrier tail.

The 55 MHz upper and lower sidebands are well resolved (they are at 0.06 and 0.2 sec in the plot).

One of the oscilloscopes monitoring the OSA signals in the control room has a USB interface so that we can record the data into a USB flash memory and plot it like this.


Quote from #6375

 I swap an OSA at PSL and OSA at REFL. It was because the PSL-OSA had a better resolution, so we place this better one at REFL. The ND filter (ND3) which was on the way to REFL OSA was replaced by two BSs, because it was producing dirty multiple spots after transmitting.


  6379   Wed Mar 7 20:06:23 2012 KojiUpdateLSCREFL OSA : how the signal look like

I'm puzzled why the 11MHz peak can be such high considering 1.7~2 times smaller the modulation depth.

  6382   Wed Mar 7 22:04:05 2012 kiwamuUpdateLSCREFL OSA : how the signal look like

I was also wondering about the same thing, comparing with what Mirko obtained before with the same OSA ( #5519).

Quote from #6379

I'm puzzled why the 11MHz peak can be such high considering 1.7~2 times smaller the modulation depth.


  6340   Wed Feb 29 04:23:14 2012 kiwamuUpdateLSCREFL OSA installed

I placed the OSA (Optical Spectrum Analyzer) on the AP table and this OSA will monitor the REFL beam.

Tomorrow I will do fine alignment of the OSA.


(some notes)

- a new 90% BS in the REFL path for limiting the REFL beam power

 I installed a 90 % beam splitter in the REFL path so that this BS limits the maximum power in the downstreams because we don't want to damage any more RFPDs.
The REFL beam has a power of about 610 mW and the BS has R = 94 % (the spec says 90 +/- 4 % ), resulting in a power of ~37 mW in the transmitted light.
Then the transmitted beam goes through the combination of a half-wave plate and PBS, which allows a fine adjustment of the power.
After passing through the lambda/2 + PBS, the beam is branched to four ways and each beam goes to the REFL RFPD, i.e. REFL11, 33, 55 and 165.
In the end each RFPD receives a laser power of 9 mW at maximum, which is reasonably lower than the power rate of the photo diodes (~17 mW ).
The new OSA uses the reflected light from the 90% BS.

- Squeezed the ABSL (ABSolute length Laser) path

 I squeezed the path of the ABSL in order to accommodate the OSA.
I tried to keep the same optical distances for some lenses, but I guess their mode matching must be different from what they used to be.
So be aware of it.

- Modification of the AS OSA path

 I have also modified the optical path of the AS OSA because there had been an extra zig-zag path which made the path more complex in unnecessary way.
Since I have squeezed the ABSL path, it allowed me to simplify the optical path. So I modified the path.

Quote from #6336

I am installing an OSA on the AP table and it's ongoing.

  6352   Mon Mar 5 05:39:36 2012 kiwamuUpdateLSCREFL OSA installed

The OSA for the REFL beam is now fully functional.

The only thing we need is a long BNC cable going from the AP table to the control room so that we can monitor the OSA signal with an oscilloscope.

The attached picture shows how they look like on the AP table. Both AS and REFL OSAs are sitting on the corner region.

Quote from #6340

I placed the OSA (Optical Spectrum Analyzer) on the AP table and this OSA will monitor the REFL beam.

Tomorrow I will do fine alignment of the OSA.

Attachment 1: APtable.png
  6384   Wed Mar 7 23:29:28 2012 keikoUpdateLSCREFL OSA observation

 kiwamu, keiko




We measure the REFL OSA spectrum when (1) direct reflection from the PRM (2) CR lock at PRC (3) SB lock at PRC. When CR lock, both SBs are reflected from the PRC and when SB lock (ref line), some SB is sucked by PRM and looked lower than the other two lines.


  11172   Wed Mar 25 18:46:14 2015 JenneUpdateLSCREFL PDs get more light

After discussions during the meeting today, I removed the PBS from the REFL path, which gives much more light to REFL11, REFL33 and REFL55.  Also, the ND1.5 in front of REFL165 was replaced with ND1.1, so that REFL165 now gets 50mW of light.  REFL11 gets about 1.3mW, REFL33 gets about 13mW and REFL55 gets about 12mW. 

No locking, and importantly no re-phasing of any PDs has been done yet. 

Here is an updated diagram of the REFL branching ratios.

Attachment 1: AS_REFL_branchingRatios_25Mar2015.png
  11176   Thu Mar 26 16:32:32 2015 JenneUpdateLSCREFL PDs get more light

Some more words on yesterday's REFL path work. 

The 90/10 BS that splits the light between REFL11 and REFL55 was placed back in August 2013, to compensate for the fact that REFL11 has a much larger RF transimpedance than REFL33.  See elog 9043 for details.

We had been operating for a long time with an embarrasingly small amount of light on the REFL PDs.  REFL11 used to have 80 uW, REFL33 used to have 400 uW and REFL55 used to have 700 uW.  REFL 165 was the only sane one, with about 15 mW of light.

After yesterday's work, the situation is now:

  Power incident [mW] PD responsivity [A/W] photocurrent [mA]
shot noise intercept
current [mA]
Ratio (photocurrent) /
(shot noise intercept current)
REFL 11 1.3 mW 0.7 0.91 mA 0.12 mA 7.6
REFL 33 13 mW 0.7 9.1 mA 0.52 mA 17.5
REFL 55 12 mW 0.7 8.4 mA 1.6 mA 5.3
REFL 165 50 mW 0.15 7.5 mA 1.06 mA 7.1

As an aside, I was foiled for a while by S vs. P polarizations of light.  The light transmitted through the PBS was P-pol, so the optics directing the beams to REFL11, 33 and 55 were all P-pol.  At first I completely removed the PBS and the waveplate, but didn't think through the fact that now my light would all be S-pol.  P-pol beam splitters don't work for S-pol (the reflection ratios are different, and it's just a terrible idea), so in the end I used the PBS to set the half waveplate so that all of my light was P-pol, and then removed the PBS but left the waveplate.  This means that all of the old optics are fine for the beams going to the 3 gold-box REFL PDs.  We don't have many S-pol beamsplitter options, so it was easier to use the waveplate to rotate the polarization. 

  9294   Fri Oct 25 21:28:49 2013 MasayukiUpdateLSCREFL PDs spectrum

 I measured the spectrum of the REFL165 output using AG4395A. As this entry we put the directional coupler between REFL165 output and demod board input, so I measure the signal from the coupler during the PRMI was locked.

 After measure REFL165, I also measured REFL55 output in order to make sure that the signal is not smaller than noise because of coupler. I terminated the couple output of coupler on the REFL165, and take signal from REFL55 output port directly. Both plots seems same except for around the resonant frequency of each PDs. From this plot we cannot say that the coupler reduce signal to spectrum analyser too much.

 After this measurement I reconnected the REFL165 to analyser and reconnected the REFL55 output to demod board.

Attachment 1: REFL.png
Attachment 2: REFLspe.zip
  16856   Mon May 16 13:22:59 2022 yutaUpdateBHDREFL and AS paths aligned at AP table

After Xarm and Yarm were aligned by Anchal et al, I aligned AS and REFL path in the AP table.
REFL path was alreasy almost perfectly aligned.

REFL path
 -REFL beam centered on the REFL camera
 -Aligned so that REFL55 and REFL33 RFPDs give maximum analog DC outputs when ITMY was misaligned to avoid MICH fringe
 -Aligned so that REFL11 give maximum C1:LSC-REFL11_I_ERR (analog DC output on REFL11 RFPD seemed to be not working)

AS path
 -AS beam centered on the AS camera. AS beam seems to be clipped at right side when you see at the viewport from -Y side.
 -Aligned so that AS55 give maximum C1:LSC-ASDC_OUT16 (analog DC output on AS55 RFPD seemed to be not working)
 -Aligned so that AS110 give maximum analog DC output

Attachment 1: REFLPOP.JPG
Attachment 2: POPAS.JPG
  6450   Tue Mar 27 02:46:28 2012 kiwamuUpdateIOOREFL beam available

The dump and some temporary mirrors were removed and now the REFL beam is available again.

I locked PRMI with REFL signals, it locked as usual.

Quote from #6440

Currently the REFL beam is bypassed by additional mirrors and blocked by a razor blade dump.

  6440   Fri Mar 23 01:59:59 2012 kiwamuUpdateIOOREFL beam currently unavilable

[Suresh / Kiwamu]

Currently the REFL beam is bypassed by additional mirrors and blocked by a razor blade dump.

Therefore the signals associated with the REFL ports (e.g. REFL11, REFLDC and etc.) are unavailable.

Just be aware of it.

  7514   Wed Oct 10 00:18:58 2012 JenneUpdateLockingREFL camera aligned

I moved some of the REFL optics on the AS table by a teeny bit to accomodate the new place that the REFL beam exits the chamber (none of this was done while we were at air....we were only dealing with the AS beam at the time, and were happy that REFL came out of the vacuum).

The REFL beam is now on the REFL camera (with PRMI aligned), and the beam is going toward the 4 REFL RF PDs, but it's not aligned to any of them.

I have some questions as to mystery optics on in the REFL path.  There is a 90% BS, and I don't know where the 10% reflection goes....is it going to beat against the AUX Stochino laser?

I have to go, and I didn't fix the videocapture script today, so pix tomorrow, I promise.

  9038   Tue Aug 20 01:28:47 2013 JenneUpdateLSCREFL investigations

According to the wiki, REFL 11 has a transimpedance of 4.08kV/A, and REFL 55 has a transimpedance of 615V/A.  This is a ratio of ~6.5 .  My optickle simulations from earlier this evening indicate that, at maximum, there is a ~factor of 2 more signal in REFL 11 than REFL 55.  This is a factor of order 10-15.  Then, REFL 55 has 15dB whitening gain, which is a factor of ~4.  So, this explains why we're seeing so much more digital signal on REFL11 than REFL55.

Tomorrow, I need to replace the 50/50 beam splitter that splits the beam between REFL55 and REFL11 (33 and 165 have already had their light picked off at this point).  I want to put in a 10% reflector, 90% transmission beamsplitter.  Steve, can you please find me one of these, and if we don't have one, order one? This will give us a little more light on 55, and less light on 11, so hopefully we won't be saturating things anymore.


  9040   Tue Aug 20 11:41:30 2013 KojiUpdateLSCREFL investigations

As I always tell everyone: Don't use a 10% reflector which produce ghost beams. Use a 90% reflector.

  9041   Tue Aug 20 11:52:20 2013 JenneUpdateLSCREFL investigations


As I always tell everyone: Don't use a 10% reflector which produce ghost beams. Use a 90% reflector. 

 Hmmm, yes, I forgot (bad me).  I'll find a 90% refl BS, and swap the positions of REFL11 and REFL55.

  9043   Tue Aug 20 18:42:57 2013 JenneUpdateLSCREFL investigations

I have done the swap in the REFL path.  First, I swapped the positions of REFL11 and REFL55.  Then, I swapped out the 50/50 BS for a 90% reflection BS.  (90% goes to REFL55, 10% goes to REFL11).  I also changed the aluminum dump that was dumping the old REFL165 path into a razor dump.

Before: REFL11 had 4.0mW, REFL55 had 3.1mW.  Now, REFL11 has 0.53mW, and REFL55 has 6.9mW.  REFL165 still has around 61mW of light, and REFL33 has 3.3mW (the things that were changed were after 165 and 33 in the REFL path). 

Now, the DC value of the REFL PDs are:  REFL165 = 10.4V, REFL33 = 110mV, REFL55 = 232mV, REFL11 = 18.6mV. 

As I was finishing aligning the beams onto all of the REFL diodes, Manasa asked for the IFO so she and Masayuki could continue their work on the Xarm, so I'll check the signals acquired a little later.

  8081   Wed Feb 13 22:09:26 2013 JenneUpdateAlignmentREFL is not clipped

We need to calculate whether this level of astigmatism is expected from the new active TT mirrors, but I claim that the beam is not clipped.

As proof, I provide a video (PS, why did it take me so long to be converted to using video capture??).  I'm just showing the REFL camera, so the REFL beam as seen out on the AS table.  I am moving PRM only.  I can move lots in pitch before I start clipping anywhere.  I have less range in yaw, but I still have space to move around.  This is not how a clipped beam behaves.  The clipping that I see after moving a ways is coincident with clipping seen by the camera looking at the back of the Faraday.  i.e. the first clipping that happens is at the aperture of the Faraday, as the REFL beam enters the FI.  

Also, I'm no longer convinced entirely that the beam entering the Faraday is a nice circle.  I didn't check that very carefully earlier, so I'd like to re-look at the return beam coming from TT1, when the PRM is misaligned such that the return beam is not overlapped with the input beam.  If the beam was circular going into the Faraday, I should have as much range in yaw as I do in pitch.  You can see in the movie that this isn't true.  I'm voting with the "astigmatism caused by non-flat active TT mirrors" camp. 

  8082   Thu Feb 14 00:10:12 2013 yutaSummaryAlignmentREFL is not clipped

Let's wait for astigmatism calculation.
In either case(clipping or astigmatism), it takes time to fix it. And we don't need to fix it because we can still get LSC signal from REFL.
So why don't we start aligning input TTs and PRMI tomorrow morning.

Take the same alignment procedure we did yesterday, but we should better check REFL more carefully during the alingment. Also, use X arm (ETMX camera) to align BS. We also have to fix AS steering mirrors in vacuum. I don't think it is a good idea to touch PR2 this time, because we don't want to destroy sensitive PR2 posture.

Calculations need to be done in in-air PRMI work:
  1. Explanation for REFL astigmatism by input TTs (Do we have TT RoCs?).
  2. Expected g-factor of PRC (DONE - elog #8068)
  3. What's the g-factor requirement(upper limit)?
    Can we make intra-cavity power fluctuation requirement and then use PRM/2/3 angular motion to break down it into g-factor requirement?
    But I think if we can lock PRMI for 2 hours, it's ok, maybe.
  4. How to measure the g-factor?
    To use tilt-and-measure-power-reduction method, we need to know RoC of the mirror you tilted. If we can prove that measured g-factor is smaller than the requirement, it's nice. We can calculate required error for the g-factor measurement.

  8348   Tue Mar 26 00:17:47 2013 JenneUpdateLockingREFL pickoff fraction

To see how much of the light that comes out of the REFL port actually goes to the PDs, I measured the power immediately after leaving the vacuum (~575mW) and in front of REFL11 (~5mW) and REFL55 (~6mW).

So, 0.01 of the power leaving the vacuum actually goes to the REFL PDs. This number will be useful when calculating the actual signals (in volts) that we expect to see.

  9673   Tue Feb 25 17:27:41 2014 JenneUpdateLSCREFL signals calibrated

I have recalibrated the REFL signals.

I first adjusted the demod phases until the I-signals lined up with the I-phase in the sensing matrix plot:


I then balanced the ITM drives by pushing on -1*ITMX and +1.015*ITMY, and seeing a minimum of MICH actuation in the I-phase of REFL55 (the PD I was locking with).

I then took a nice long measurement with DTT, and measured the peak heights in I and Q for each REFL diode.  I was driving PRM with 100 cts at 675.1Hz, and ITMX with 1000 cts at 452.1 Hz (and matching ITMY drive, to make pure MICH).  Knowing these numbers, and the actuator calibrations (PRM elog 8255, ITMs elog 8242), I know that I was driving PRCL by ~4.3 pm, and MICH by ~23 pm. 

For the I-phase calibrations, I find the peak height at the PRCL drive frequency, and divide 4.3 pm by that height.  For the Q-phase calibrations, I find the peak height at the MICH drive frequency, and divide 23 pm by that height.

This gives me the following calibrations:

  Calibration [picometers / count]
REFL 11 I    0.15
REFL 11 Q   21.6
REFL 33 I    1.06
REFL 33 Q  209
REFL 55 I    0.9
REFL 55 Q   27       
REFL 165 I    0.1
REFL 165 Q   11.6

 My calibrated REFL spectra then looks like:


ELOG V3.1.3-