40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 142 of 341 Not logged in
ID Date Author Type Category Subject
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
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.

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.

Quote:

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?

 Quote: *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. )

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

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.

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

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

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.

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.

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.

/opt/rtcds/caltech/c1/rtbuild/src/fe/c1lsc/c1lsc.c

3881// Bit2Word:  LSC_cdsBit2Word1                                                                                                               3882{ 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 3900}; 3901lsc_cdsbit2word1 = 0; 3902for (ii = 0; ii < 16; ii++) 3903{ 3904if (ins[ii]) { 3905lsc_cdsbit2word1 += powers_of_2[ii]; 3906} 3907} 3908}

3946// Bit2Word:  LSC_cdsBit2Word2                                                                                                               3947{                                                                                                                                            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                                                                                                                          3965};                                                                                                                                           3966lsc_cdsbit2word2 = 0;                                                                                                                        3967for (ii = 0; ii < 16; ii++)                                                                                                                  3968{                                                                                                                                            3969if (ins[ii]) {                                                                                                                               3970lsc_cdsbit2word2 += powers_of_2[ii]; 3971} 3972} 3973}

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:

https://bugzilla.ligo-wa.caltech.edu/bugzilla3/show_bug.cgi?id=553

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.

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

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.

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

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:

• disabling the float denormalization fix

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

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];             end     % 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];     disp(f)     pause(0.001) end % plot the results close all figure 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
11340   Mon Jun 1 10:26:53 2015 ericqUpdateCDSRCG Upgrade Imminent

### We are planning on upgrading the 40 CDS system to the latest version of the LIGO RCG software, in three weeks when Jamie is back in town.

Jamie and I spoke last week, to hash out a general plan for upgrade and preperations I can make in the meantime.

Preparation of our models for the upgrade includes;

• Check if any of the default RCG parts (filter modules, etc.) have substantially different default behavior / ports
• Cleaning up unterminated/hanging connections in the diagrams (Jamie tells me RCG is more strict about this now)
• Going through all of the build logs for our models to find what custom blocks are being pulled in from the userapps svn
• Confirm all of our running blocks and models are committed to svn
• In a new, isolated, folder, checkout the latest version of the userapps repo
• See what blocks have changed, and what model changes might be neccesary.

Once we think we know what needs to be changed in our models, we can check out the latest version of the RCG source, without linking it as the active version, and create a new build directory, without touching the old one, and create new copies of the 40m models with the neccesary modifications. This way, we can work on getting all of the 40m models compiled, without touching any of the live, running, systems

Once our models are compiling successfully, we can work on building daqd, nds, mxstream, etc.

Additionally, we want to have some set of tests and diagnostics, to make sure we have not introduced unwanted behavior.

To this end I will create some test models and DTT templates, where a series of measurements can be run, like

• OLTF/delay measurement of a single all-digital loop within one model
• OLTF/delay measurements of a few all-digital loops split across two models, using IPC communcation, RFM, dolphin
• Hook up DAC -> resistor/amplifier/??? -> ADC, to check things like DAC output, ADC noise levels, IOP delays.

I'll run these test before touching anything, and make sure I understand all of the results, so that an apples-to-apples comparison can be made after the upgrade is complete.

Updates will be posted as I hash things out. I'm sure we have not yet thought of everything to think about and test, so ideas and feedback are very welcome.

11342   Mon Jun 1 20:05:36 2015 ranaUpdateCDSRCG Upgrade Imminent

 Quote: Additionally, we want to have some set of tests and diagnostics, to make sure we have not introduced unwanted behavior.  To this end I will create some test models and DTT templates, where a series of measurements can be run, like OLTF/delay measurement of a single all-digital loop within one model OLTF/delay measurements of a few all-digital loops split across two models, using IPC communcation, RFM, dolphin Hook up DAC -> resistor/amplifier/??? -> ADC, to check things like DAC output, ADC noise levels, IOP delays. I'll run these test before touching anything, and make sure I understand all of the results, so that an apples-to-apples comparison can be made after the upgrade is complete.

I got goosebumps just imagining this.

2198   Fri Nov 6 18:52:09 2009 peteUpdateComputersRCG ETMY plan

Koji, Joe, and I are planning to try controlling the ETMY, on Monday or Tuesday.  Our plan is to try to do this with megatron out of the RFM loop.   The RCG system includes pos, pit, yaw, side, and oplevs.  I will use matrix elements as currently assigned (i.e. not the ideal case of +1 and -1 everywhere).   I will also match channel names to the old channels.   We could put buttons on the medm screen to control the analog DW by hand.

This assumes we can get megatron happy again, after the unhappy RFM card test today.  See Joe's elog immediately before this one.

We first plan to test that the ETMY watchdog can disable the RCG frontend, by using a pos step (before connecting to the suspension).   Hopefully we can make it work without the RFM.  Otherwise I think we'll have to wait for a working RFM card.

We plan to disable the other optics.  We will disable ETMY, take down the ETMY frontend, switch the cables, and start up the new RCG system.  If output looks reasonable we will enable the ETMY via the watchdog.   Then I suppose we can put in some small steps via the RCG controller and see if it damps.

Afterwards, we plan to switch everything back.
2243   Wed Nov 11 20:46:07 2009 peteUpdateCDSRCG ETMY phase I update

The .mdl code for the mdc and mdp development modules is finished.  These modules need more filters, and testing.  Probably the most interesting piece left to do is putting in the gains and filters for the oplev model in mdp.  It might be OK to simply ignore oplevs and first test damping of the real optic without them.   However, it shouldn't be hard to get decent numbers for oplevs, add them to the mdp (plant) module, and make sure the mdc/mdp pair is stable.  In mdp, the oplev path starts with the SUSPIT and SUSYAW signals. Kakeru recently completed calibration of the oplevs from oplev cts to radians:   1403  .  From this work we should find the conversion factors from PIT and YAW to oplev counts, without making any new measurements.  (The measurements wouldn't be hard either, if we can't simply pull numbers from a document.)  These factors can be added to mdp as appropriate gains.

I've also copied mdc to a new module, which I've named "sas" to address fears of channel name collisions in the short term, and replaced the cpu-to-cpu connections with ADC and DAC connections.  sas can be the guy for the phase I ETMY test.  When we're happy with mdc/mdp, we hopefully can take the mdc filter file from chans, replace all the "MDC" strings with "SAS", and use it.

2233   Wed Nov 11 01:33:52 2009 peteUpdateCDSRCG ETMY code update

I've added the side coil to the model controller and plant, and the oplev quad to the model controller and plant.  After the megatron wipe, the code now lives in /home/controls/cds/advLigo/src/epics/simLink.  The files are mdc.mdl (controller) and mdp.mdl (plant).  These RCG modules go at 16K with no decimation (no_oversampling=1 in the cdsParameters block) so hopefully will work with the old (16K) timing.

I've loaded many of the filters, there are some eft to do.  These filters are simply copied from the current frontend.

Next I will port to the SUS module (which talks to the IO chassis).  This means channel names will match with the current system, which will be important when we plug in the RFM.

11347   Mon Jun 8 15:51:31 2015 ericqUpdateCDSRCG Diagnostics

I've started making some model changes for RCG diagnostic tests.

I put some blocks down in C1TST and C1RFM to test the delays of all-digital loops and one loop with a direct DAC->ADC (which currently uses a janky 1-pin lemo -> BNC -> 2-pin lemo situation (which will be improved)).

Here's what C1TST looks like now.

I've taken TFs of all three loops. The all digital loops are flat on the order of microdBs.

The delay in loop A (single loop, one model) is consistent with one 16k cycle, plus or minus 0.25 nsec.

The delay in loop C (single loop, two models connected via RFM) is consistent with two 16k cycles, plus or minus 0.5 nsec.

I haven't yet grabbed the whitening and AA/AI shapes for loopB, to calibrate the real delay.

All of these files currently live in /users/ericq/2015-06-CDSdiag, but I'll make somewhere outside of the user directory to collect all of these tests soon.

Attachment 1: newTST.png
11435   Wed Jul 22 14:10:04 2015 ericqUpdateCDSRCG Diagnostics

Now that we've seemed to landed on a working configuration, I've re-ran the tests first described in ELOG 11347. I've also compared the real filtering of filter modules to their designs.

TL;DR: No adverse, or even observable, differences have been witnessed.

As a reminder: In c1tst, there are three loops, called LOOPA, LOOPB, and LOOPC.

• LOOPA is a filter module feeding back onto its own input, with a unit time delay block
• LOOPB is a FM whose output goes to the DAC. In meatspace, the AI output is hooked up directly to an AA chassis input, and back to the FM in CDS
• LOOPC includes RFM connections to c1rfm and back again.

Here are the loop delay results, which measure the slope of the phase response of the OLTF. For the purely digital loops (A, C), we know the number of cycles we expect to compare the delay to.

At this time, I haven't done the adding up of cycles, zero-order-holds, etc. to get the delay we expect from the analog loop (B), so I've just looked at whether it changed at all.

Anyways, I've attached the code that analyzes data from DTT-exported text files containing the continuous phase data from the loop measurements.

Before:

Single Model loop cycles: 1.0000000+/-0.0000006, disparity: -0.00+/-0.25 nsec 2 Model RFM loop cycles: 1.9999999+/-0.0000013, disparity: 0.0+/-0.5 nsec ADC->DAC loop time: 338.2+/-0.4 usec

After:

Single Model loop cycles: 0.9999999+/-0.0000008, disparity: 0.02+/-0.29 nsec 2 Model RFM loop cycles: 2.0000001+/-0.0000011, disparity: -0.0+/-0.4 nsec ADC->DAC loop time: 338.18+/-0.35 usec

So, the digital loops take the number of cycles we expect, and there are no real differences after the upgrade.

Additionally, for all three loops, I created a simple 100:10 filter in foton, and injected broadband noise with awggui, to measure the real TF applied by the FM code. I want to turn this whole process into a single script that will switch the filter on and off, read the foton file, and compare the measured TF to the ideal shape.

In our system, before and after the upgrade, all three loops showed no appreciable difference from the designed filter shape, other than some tiny uptick in phase when approaching the nyquist frequency. This may be due to the fact that I'm comparing to the ideal analog filter, rather than what a 16kHz digital filter looks like.

What I've plotted below is the devitation from the ideal zpk(100Hz, 10Hz, 0.1) frequency response, i.e. Hmeasured / Hideal. The code to do this analysis is also attached, it estimates the TF by dividing the CSD of the filter input and output by the PSD of the input. The single worst coherence in any bin of all the measurements is 0.997, so I didn't really bother to estimate the error of the TF estimate.

Attachment 1: filterShapes.png
Attachment 2: CDS_diag_codes.zip
6356   Mon Mar 5 15:15:15 2012 DenUpdatePEMRCG

[Alex / Den]

I've encountered a problem that C1:PEM-SEIS_GUR1_X_IN1 is saved in the int format. It turned out that inside the code the signal is also in the int format.  It is not just a saving error. It should not be so as ADC works at 64k and the model runs at 2k.

Why? There is a bug somewhere in the generation of the code. c1pem.c looks suspicious to Alex because there is a mismatch in the ADC numbers with the simulink model.

Solution: upgrade to 2.4 version - most probably it was fixed there. If not, Alex will handle this problem.

6999   Sat Jul 21 14:48:33 2012 DenUpdateCDSRCG

As I've spent many hours trying to determine the error in my C code for online filter I decided to write about it to prevent people from doing it again.

I have a C function that was tested offline. I compiled and installed it on the front end machine without any errors. When I've restarted the model, it did not run.

I modified the function the following way

void myFunction()
{
if(STATEMENT) return;
some code
}

I've adjusted input parameters such that STATEMENT was always true. However the model either started or not depending on the code after if statement. It turned out that the model could not start because of the following lines

cosine[1] = 1.0 - 0.5*a*a + a*a*a*a/24 - a*a*a*a*a*a/720 + a*a*a*a*a*a*a*a/40320; sine[1] = a - a*a*a/6 + a*a*a*a*a/120 - a*a*a*a*a*a*a/5040;

When I've split the sum into steps, the model began to run. I guess the conclusion is that we can not make too many arithmetical operations for one "=" . The most interesting thing is that these lines stood after true if-statement and should not be even executed. Possible explanation is that some compilers start to process code after if-statement during its slow comparison. In our case it could start and then broke down on these long expressions.

3190   Sun Jul 11 20:11:48 2010 ranaSummaryPSLRC trend after the insulation removal

3232   Thu Jul 15 19:27:04 2010 ranaSummaryPSLRC trend after the insulation removal

As you can see, there was not much (if any) worsening of the laser frequency fluctuation from removing the RefCav insulation. The plots below are zooomed in:

I have used the same peak-to-peak scale so that its easy to compare the fluctuations before (LEFT) and after (RIGHT).

As you can clearly see, the laser frequency moves just as much now (the SLOW_DC) as it did before when it had the insulation. Only now the apparent (i.e. fake) RC temperature fluctuations are much larger. So this sensor is fairly useless as configured.

1970   Mon Sep 7 23:35:03 2009 ranaUpdatePSLRC thermal servo: PID script modified, database + screen added

I have added the records for the RC thermal PID servo into the psl/slowpid.db file which also holds the records for the SLOW servo that uses the NPRO-SLOW to minimize the NPRO-FAST. This new database will take effect upon the next PSL boot.

The perl script which runs the servo is scripts/PSL/FSS/RCthermalPID.pl. Right now it is using hard-coded PID parameters - I will modify it to use the on-screen values after we reboot c1psl.

The new screen C1PSL_FSS_RCPID.adl, the script, and the .db have been added to the SVN.

I have got some preliminary PID parameters which seem to be pretty good: The RCTEMP recovers in ~10 minutes from a 1 deg temperature step and the closed loop system is underdamped with a Q of ~1-2.

I'm leaving it running on op340m for now - if it goes crazy feel free to do a 'pkill RCthermalPID.pl'.

Attachment 1: Untitled.png
1957   Thu Aug 27 14:00:33 2009 ranaUpdatePSLRC thermal servo impulse response

I stepped the TIDALSET and looked at what happened. Loop was closed with the very low gain.

The RED guy tells us the step/impulse response of the RC can to a step in the heater voltage.

The GREY SLOWDC tells us how much the actual glass spacer of the reference cavity lags the outside can temperature.

Since MINCOMEAS is our error signal, I have upped his SCAN period from 0.5 to 0.1 seconds in the database and reduced its SMOO from 0.9 to 0.0. I've also copied over the Fricke SLOW code and started making a perl PID loop for the reference cavity.

Attachment 1: Untitled.png
1978   Tue Sep 8 20:15:33 2009 rana, jenneSummaryPSLRC temperature servo: Heater Voltage noise

We measured the voltage noise of the heater used to control the RC can temperature. It is large.

The above scope trace shows the voltage directly on the monitor outputs of the heater power supply. The steps are from the voltage resolution of the 4116 DAC.

We also measured the voltage noise on the monitor plugs on the front panel. If these are a true representation of the voltage noise which supplies the heater jacket, then we can use it to estimate the temperature fluctuations of the can. Using the spectrum of temperature fluctuations, we can estimate the actual length changes of the reference cavity.

I used the new fax/scanner/toaster that Steve and Bob both love to scan this HP spectrum analyzer image directly to a USB stick! It can automatically make PDF from a piece of paper.

The pink trace is the analyzer noise with a 50 Ohm term. The blue trace is the heater supply with the servo turned off. With the servo on (as in the scope trace above) the noise is much much larger because of the DAC steps.

Attachment 1: 09080901.PDF
1995   Wed Sep 23 19:36:41 2009 ranaUpdatePSLRC temperature performance

This first plot shows the RC temperature channels' performance from 40 days ago, before we disabled the MINCO PID controller. Although RCTEMP is supposed to be the out of loop sensor, what we really care about is the cavity length and so I've plotted the SLOW. To get the SLOW on the same scale, I've multiplied the channel by 10 and then adjusted the offset to get it on the same scale.

The second plot shows a period after that where there is no temperature control of the can at all. Same gain scaling has been applied to SLOW as above, so that instead of the usual 1 GHz/V this plot shows it in 0.1 GHz/V.

The third plot shows it after the new PID was setup.

Summary: Even though the PID loop has more gain, the true limit to the daily fluctuations in the cavity temperature and the laser frequency are due to the in-loop sensors measuring the wrong thing. i.e. the out-of-loop temperature is too different from the in-loop sensor. This can possibly be cured with better foam and better placement of the temperature sensors. Its possible that we're now just limited by the temperature gradients on the can.

Attachment 1: Untitled.png
Attachment 2: Untitled.png
Attachment 3: e.png
954   Wed Sep 17 13:43:54 2008 YoichiConfigurationPSLRC sweep going on
I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.
957   Wed Sep 17 15:22:31 2008 YoichiConfigurationPSLRC sweep going on

 Quote: I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.

The measurement is still going on.
I will post an entry when it is done.
Thank you for the patience.
959   Wed Sep 17 17:58:35 2008 YoichiConfigurationPSLRC sweep going on
The cavity sweep is done. The IFO is free now.
2649   Mon Mar 1 22:38:12 2010 ranaUpdateComputersRC sensitivity to RIN

The overnight triangle wave I ran on the AOM drive turns out to have produced no signal in the FAST feedback to the PZT.

The input power to the cavity was ~10 mW (I'm totally guessing). The peak-peak amplitude of the triangle wave was 50% of the total power.

The spectral density of the fast signal at the fundamental frequency (~7.9 mHz) is ~0.08 V/rHz. The FAST calibration is ~5 MHz/V. So, since we

see no signal, we can place an upper limit on the amount of frequency shift = (5 MHz/V) * (0.08 V/rHz) * sqrt(0.0001 Hz) = 4 kHz.

Roughly this means that the RIN -> Hz coefficient must be less than 4 kHz / 5 mW or ~ 1 Hz/uW.

For comparison, the paper on reference cavities by the Hansch group lists a coefficient of ~50 Hz/uW. However, they have a finesse of 400000

while we only have a finesse of 8000-10000. So our null result means that our RC mirrors' absorption is perhaps less than theirs. Another possibility

is that their coating design has a higher thermo-optic coefficient. This is possible, since they probably have much lower transmission mirrors. It would be

interesting to know how the DC thermo-optic coefficient scales with transmission for the standard HR coating designs.

Attachment 1: Untitled.png
1986   Sat Sep 12 15:40:15 2009 ranaUpdatePSLRC response v. can temperature

I stepped the RC can temperature to see the response in the laser frequency. This gives a true measure of the thermal time constant of the RC. Its ~4 hours.

Since the RCPID screen now has a setpoint field, I can remotely type in 1 deg steps. The NPRO SLOW actuator locks the NPRO to the RC at long time scales and so we can use C1:PSL-FSS_SLOWDC to measure the RC length. By knowing what the step response time constant is, we can estimate the transfer function from can temperature to frequency noise and thereby make a better heater circuit.

Does the observed temperature shift make any sense? Well, John Miller and I measured the SLOW calibration to be 1054 +/- 30 MHz / V.

We know that the thermal expansion coefficient of fused silica, alpha = 5.5 x 10-7 (dL/L)/deg. So the frequency shift ought to be alpha * c / lambda = 155 MHz / deg.

Instead we see something like 110 MHz / deg. We have to take more data to see if the frequency shift will actually asymptote to the right value or not. If it doesn't, one possibility is that we are seeing the effect of temperature on the reflection phase of the mirror coatings through the dn/dT and the thermal expansion of the dielectric layers. I don't know what these parameters are for the Ta2O5 layers.

A more useful measure of the frequency noise can be gotten by just looking at the derivative in the first 30 minutes of the step, since that short time scale is much more relevant for us. Its 0.04 V / hour / (2 deg) =>  860 (Hz/s)/deg.

In the frequency domain this comes out to be dnu/dT = 860 Hz/deg @ 0.16 Hz or dnu/dT = 137 *(1/f) Hz / deg.

Our goal for the reference cavity frequency noise is 0.01 * (1/f) Hz/rHz. So the temperature noise of the can needs to be < 0.1 mdeg / rHz.

Attachment 1: Picture_2.png
Attachment 2: Untitled.pdf
11573   Fri Sep 4 08:00:49 2015 IgnacioUpdateCDSRC low pass circuit (1s stage) of Pentek board

Here is the transfer function and cutoff frequency (pole) of the first stage low pass circuit of the Pentek whitening board.

Circuit:

R1 = R2 = 49.9 Ohm, R3 = 50 kOhm, C = 0.01uF. Given a differential voltage of 30 volts, the voltage across the 50k resistor should be 29.93 volts.

Transfer Function:

Given by,

$H(s) = \frac{1.002\text{e}06}{s+1.002\text{e}06}$

So low pass RC filter with one pole at 1 MHz.

I have updated the schematic, up to the changes mentioned by Rana plus some notes, see the DCC link here: [PLACEHOLDER]

I should have done this by hand...

Attachment 1: circuit.pdf
12936   Mon Apr 10 15:37:11 2017 gautamUpdateCOCRC folding mirrors - v3 of specs uploaded

Koji and I have been going over these calculations again before we send a list of revised requirements to Ramin. I've uploaded v3 of the specs to the DCC page. Here is a summary of important changes.

1. Change in RoC specification - I condensed the mode-matching information previously in 8 plots into the following 2 plots. Between tangential and saggital planes, the harmonic mean was taken. Between X and Y cavities, the arithmetic mean was taken. Considering the information in the following plots, we decided to change the spec RoC from 600 +/- 50m to 1000 +/- 150m. The required sensitivity in sag measurement is similar to the previous case, so I think this should be feasible.

Why this change? From the phase map information at  /users/public_html/40m_phasemap/40m_TTI gather that we have 2 G&H mirrors, one with curvature ~ -700m and the other with curvature ~ -500m. An elog search suggests that the installed PR2 has RoC ~ -700m, so this choice of RoC for PR3 should give us the best chance of achieving optimal modematching between the RCs and arms as per the plots below.

2. Cavity stability checks - these plots confirm that the cavity remains stable for this choice of RoC on PR3...

3. Coating design - I've been playing around with the code and my understanding of the situation is as follows. to really hit low AR of 10s of ppms, we need many dielectric layer pairs. But by adding more pairs, we essentially become more susceptible to errors in layer thickness etc, so that even though the code may tell us we can achieve R_AR(532nm) < 50ppm, the minima is pretty sharp so even small perturbations can lead to much higher R of the order of a few percent. On the HR side, we need a large number of layer pairs to achieve T_HR(1064nm)=50ppm. Anyways, the MC studies suggest that for the HR coating design, with 19 layer pairs, we can be fairly certain of T_HR(1064nm)<100ppm and R_HR(532nm)>97% for both polarizations, which seems reasonable. In order to make the R_HR(532nm) less susceptible to errors, we need to reduce the number of layer pairs, but then it becomes difficult to achieve the 50ppm T_HR(1064nm) requirement. Now, I tried using very few layer pairs on the AR side - the best result seems to be with 3 layer pairs, for which we get R_AR(532nm)<1% and T_AR(1064nm)>95%, both numbers seem reasonable to me. In the spectral reflectivity, we also see that the minima are much broader than with large number of layer pairs.

First row below is for the HR side, second row is for the AR side. For the MC studies, I perturbed the layer thicknesses and refractive indices by 1%, and the angle of incidence by 5%.

If there are no objections, I would like to send this version of the specs to Ramin and get his feedback. Specifically, I have assumed values for the refractive indices of SiOand Ta2O5 from google, Garilynn tells me that we should get these values from Ramin. Then we can run the code again if necessary, but these MC studies already suggest this coating design is robust to small changes in assumed values of the parameters...

Attachment 1: PRC_modematch.pdf
Attachment 2: SRC_modematch.pdf
Attachment 3: TMS_PRC.pdf
Attachment 4: TMS_SRC.pdf
Attachment 5: PR3_HR_spectralRefl.pdf
Attachment 6: PR3_HR_MC_CDF_revised.pdf
Attachment 7: PR3_AR_spectralRefl_new.pdf
Attachment 8: PR3_AR_MC_CDF_new.pdf
12631   Mon Nov 21 15:34:24 2016 gautamUpdateCOCRC folding mirrors - updated specs

Following up on the discussion from last week's Wednesday meeting, two points were raised:

1. How do we decide what number we want for the coating on the AR side for 532nm?
2. Do we want to adjust T@1064nm on the HR side to extract a stronger POP beam?

With regards to the coating on the AR side, I've put in R<300ppm@1064nm and R<1000ppm@532nm on the AR side. On the HR side, we have T>97% @ 532nm (copied from the current PR3/SR3 spec), and T<50ppm @1064nm. What are the ghost beams we need to be worried about?

• Scattered light the AR side interfering with the main transmitted green beam possibly making our beat measurement noisier
• With the above numbers, accounting for the fact that we ask for a 2 degree wedge on PR3, the first ghost beam from reflection on the AR side will have an angular separation from the main beam of ~7.6 degrees. So over the ~4m the green beam travels before reaching the PSL table, I think there is sufficient angular separation for us to catch this ghost and dump it.
• Moreover, the power in this first ghost beam will be ~30ppm relative to the main green beam. If we can get R<100ppm @532nm on the AR side, the number becomes 3ppm
• Prompt reflection from the HR surface of PR3 scattering green light back into the arm cavity mode
• The current spec has T>97% @532nm. So 3% is promptly reflected at the HR side of PR3
• I'm not sure how much of a problem this really will be - I couldn't find the reflectivities of PR2 and PRM @532nm (were these ever measured?)
• In any case, if we can have T<50ppm @1064nm and R>99.9% @532nm, that would be better

So in conclusion, with the specs as they are now, I don't think the ALS noise performance is adversely affected. I have updated the spec to have the following numbers now.

HR side: T < 50ppm @1064nm, T>99.9% @532nm

AR side: R < 100ppm @1064nm and @532nm

As for the POP question, if we want to extract a stronger POP beam, we will have to relax the requirement on the transmission @1064nm on the HR side. But recall that the approach we are now considering is to replace only PR3, and flip PR2 back the right way around. Currently, POP is extracted at PR2, so if we want to stick with the idea of getting a new PR3 and extracting a stronger POP beam, there needs to be a major optical layout reshuffle in the BS/PRM chamber. Koji suggested that in the interest of keeping things moving along, we don't worry about POP for the time being...

Alternatively, if it turns out that the vendor can meet the specs for our second requirement (which requires 1.5% of lambda @632nm measurement precision to meet the 10+/-5km RoC tolerance on PR3), then we can ast for T<1000ppm @1064nm for the HR coating on PR2, and keep the coating specs on PR3 as above.

Attached is a pdf with the specs updated to reflect all the above considerations...

Attachment 1: Recycling_Mirrors_Specs_Nov2016.pdf
12219   Tue Jun 28 16:06:09 2016 gautamUpdateCOCRC folding mirrors - further checks

Having investigated the mode-overlap as a function of RoC of the PRC and SRC folding mirrors, I've now been looking into possible stability issues, with the help of some code that EricQ wrote some time back for a similar investigation, but using Finesse to calculate the round trip Gouy phase and other relevant parameters for our current IFO configuration.

To do so, I've been using:

1. Most up to date arm length measurements of 37.81m for the Y arm and 37.79m for the X arm
2. RoCs of all the mirrors from the phase map summary page
3. Loss numbers from our November investigations

As a first check, I used flat folding mirrors to see what the HOM coupling structure into the IFO is like (the idea being then to track the positions of HOM resonances in terms of CARM offset as I sweep the RoC of the folding mirror).

However, just working with the flat folding mirror configuration suggests that there are order 2 22MHz and order 4 44MHz HOM resonances that are really close to the carrier resonance (see attached plots). This seems to be originating from the fact that the Y-arm length is 37.81m (while the "ideal" length is 37.795m), and also the fact that the ETM RoCs are ~3m larger than the design specification of 57m. Interestingly, this problem isn't completely mitigated if we use the ideal arm lengths, although the order 2 resonances do move further away from the carrier resonance, but are still around a CARM offset of +/- 2nm. If we use the design RoC for the ETMs of 57m, then the HOM resonances move completely off the scale of these plots...

Attachment 1: C1_HOMcurves_Y.pdf
Attachment 2: C1_HOMcurves_DR.pdf
ELOG V3.1.3-