40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 80 of 335  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  13773   Fri Apr 20 00:26:34 2018 gautamUpdateALSFibers switched out


I think the dominant cause for the fact that we were seeing huge swing in the power coupled into the fiber was that the beam being sent in was in fact not linearly polarized, but elliptically polarized. I've rectified this with the help of a PBS. Fiber has been plugged into my polarization monitoring setup. Let's monitor for some long stretch and see if the situation has improved.


  • The new fiber mount I ordered, K6XS, arrived today. I like it - it has little keys with which all DoFs can be locked. Moreover, it is compatible with the fixed collimators which IMO is the easiest way to achieve good mode-matching into the fiber. It is basically a plug-and-play replacement for the mounts we were using. Anyways, we can evaluate the performance over the coming days.
  • I installed it on the PSL table (started work ~10pm, HEPA turned up to maximum, PSL shutter closed).
  • But even with the new rotational DoF locking feature, I saw that slight disturbances in the fiber caused wild fluctuations in my polarization monitoring setup PD outputs. This was a useful tool through the night of checking the polarization content in the two special axes - Aidan had suggested using a heat gun but shaking the fiber a bit works well too I think.
  • The PM980 fiber has an alignment key that is aligned with the slow axis of the fiber - so it is a useful alignment reference. But even by perturbing the roational alignment about the vertical by +/-15 degrees, I saw no improvement in this behavior. So I began to question my assumption that the input beam itself had clean polarization content.
  • Since my pickoff beam has gone through a QWP and two PBSs, I had assumed that the beam was linearly polarized.
  • But by putting a PBS just upstream of the input fiber coupler, I could see a beam at the S-port with an IR card (while I expected the beam to be P-polarized).
  • OK - so I decided to clean up the input polarization by leaving this PBS installed. With this modification to the setup, I found that me shaking the fiber around on the PSL table didn't affect the output polarization content nearly as dramatically as before!!yes
  • The state I am leaving it in tonight is such that there is ~100x the power in the P-polarization output monitor as the S-polarization (PER ~ 20dB). I didn't try and optimize this too much more for now, I want to observe some long term trend to see if the wild power fluctuations have been mitigated.
  • The output coupler is mounted on the inferior K6X mount, and so there is the possibility that some drift will be attributable to rotation of the output coupler in it's mount. Thermally driven length changes / time varying stresses in the fiber may also lead to some residual power fluctuations. But I don't expect this to be anywhere near the ~25% I reported in the previous elog.
  • The rejected beam from the PBS was measured to be ~300 uW. I haven't dumped this properly, to be done tomorrow.
  • HEPA turned back down to 30%, PSL enclosure closed up, PSL shutter re-opened ~0030am.
  • Note that the EX and EY fiber coupled beams are also likely subject to the same problem. We have to double check. I think it's better to have a PBS in front of the input fiber coupler as this also gives us control over the amount of light coupled into the fiber.

Power budget:

Power in Measured power (Ophir, filter OFF)
@Input coupler, before PBS 4.4 mW
P-pol content @ input coupler 4.06 mW
S-pol (rejected) from PBS 275 uW
@Output coupler 2.6 mW (MM ~65%)


  4882   Sat Jun 25 00:00:28 2011 SonaliUpdateGreen LockingFibre Coupling.

 What I did today.

1. I tried to align the IR input beam by aligning the two mirrors, to couple input light into the fibre.

2.I was unsuccessful for a long time even though I tried a lot of tricks.

3. I also tried to use the optical fault locator to superpose the IR beam spot onto the beam spot of the other laser to facilitate effective coupling.

4.But the crucial point was to superpose the input beam path in the perfect direction of the output beam path and not just the beam spot.(the input cone and the output cone are perfectly aligned).

5.After one whole day of trial and thought, I managed to couple light into the fibre, and saw the output beam spot on the screen-camera-monitor set-up which we had arranged. Eurekka !!;)

6.I then used a power meter to measure the input beam power and the output beam power.

7.It was a disappointing 2% . I had read in project reports of many students of a 20% success.

8.After a lot of subtle tweaking of the mirrors using the knobs, I managed to increase the percentage of output beam to 12%.

9. This is a workable level.

10.A day of lot of new learning! Pictures of the setup are attached.:)


Attachment 1: Fibre_coupling_successful_24_june.jpg
Attachment 2: Beam_output_on_screen.jpg
  3859   Thu Nov 4 03:13:46 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

[Kiwamu, Suresh]

We decided to use the 1064nm beam reflected from the Y1-1037-45-P mirror after the collimation lens following the doubling crystal for coupling into the optical fiber (ref 3843 and 3847 ).

We replaced a beam dump which was blocking this beam with a Y1-1037-45-P mirror and directed the beam into the fiber coupler with another Y1-1037-45-P.  The power in this beam was about 1W.  This has been stepped down to 10mW by introducing a reflective ND filter of OD=2.  The reflected power has been dumped into a blade-stack beam dump.

Steve has ordered the The Visual Fault Locator from Fluke.  It is expected to arrive within a day or two.



  3865   Thu Nov 4 19:00:57 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

The Fluke Visual Fault locator (Visifault) arrived and I used it to couple 1064nm light into the single mode fibre at the south-end-table.

Procedure used:

When the output end of the fiber is plugged into the Visifault the light emerges from at the south end (input side for 1064nm).  This light is collimated with the fiber coupler at that end and serves as a reference for the optical axis along which the 1064 light must be directed.  Once the two beams (red and 1064) are overlapped with the beam steering mirrors, the Visifault was disconnected from the fiber and the  fibre output ( 1064 at the PSL table) is maximized by walking the beam at the input end and adjusting the collimation at the input.

The output of the fiber has been collimated with a fiber coupler.

7.5mW are incident on the input end and 1.3mW have been measured at the output.    This output power is adequate for the observing the beats with PSL NPRO.




  8183   Wed Feb 27 14:39:59 2013 AnnalisaUpdateLSCFibre laid for RFPD audio

 [Annalisa, Jenne, Rana, Steve]

We installed the fibres on cable trays the 1Y2 and the Control Room.

Still to do: find a power supply for the Fiboxes and plug everything in.

  315   Wed Feb 13 20:37:11 2008 JohnUpdateLSCFibre locking - Fiber
Sam and I observed fringes in the light reflected from the Y arm. These fringes are due to the sidebands and not the carrier. To improve matters we plan to reduce the RF AM and increase our modulation index.
  272   Sat Jan 26 02:08:53 2008 JohnOmnistructureLSCFibres
There is now a fibre running from the SP table to the ISCT at the Y-end. In the coming days I will try to mode match the beam from this fibre into the arm through ETMY. To achieve this I will be altering the optical layout of this table.
  296   Mon Feb 4 22:01:57 2008 JohnSummaryLSCFibres auxiliary locking - Fibers
I managed to couple ~75% of the light transmitted from the y arm, through the fibre, back to the SP table. I hoped that this would be a good way to match the beam from the fibre into the arm. Still no flashes. It looks like the cameras just aren't sensitive enough.
  10860   Wed Jan 7 02:54:09 2015 JenneUpdateLSCFiddling with DARM filters

One of the things that we had talked about last night was the totally tiny amount of phase margin that we have in the CARM and DARM loops.  DARM seemed to be the most obnoxious loop last night, so I focused on that today, although the CARM and DARM loops are pretty much identical.

(Q tells me via email that the phase budget has the same ~14 degree discrepancy between what we expect and what we measure as his estimate last night.  However, the Caltech network issues prevented his posting an elog.)

So, we definitely need to figure out where this 14 deg is going, but for now, I wanted to see if I could recover a couple of extra degrees just by modifying the filters.

The original filters do seem to eat a lot of phase:


The short version of the story is that I didn't leave the filters changed at all.  I reverted back to the last version of the filter file from Monday night, so currently everything is as it was.

I tried increasing the Q of the zeros on the cyan and brown filters, which would sacrifice some gain at ~20 Hz, but hopefully win us 10+ degrees of phase.  This gave me a dip of about a factor of 2 between the new and old filters (all servo filters combined added up to this factor of 2 in magnitude) between ~20Hz - 70Hz. 

When we were locked using DARM for just the Yarm (for the UGF servo commissioning), I took a spectra of the error signal (which was POY) as a reference, then loaded in my new filters.  For the most part, the spectra didn't change (which is good, since the magnitude of the filter didn't change much.).  The spectra was bigger though between 50-70Hz, in kind of a sharp bandpass-looking shape that I wasn't expecting.    I don't know exactly why that's happening.

Anyhow, we tried the new filters once or twice with the full IFO, but kept losing lock.  Since I clearly haven't put in enough thought yet for these (particularly, how much suppression do we really need? what are our requirements???), I reverted back to the filter file from last night.  We continued locking, and checking out the new UGF servo that Diego is elogging about.

  14703   Wed Jun 26 20:45:03 2019 gautamUpdateCamerasField of view options

For the beam spot position tracking, I am wondering if there is any benefit to going for a wider field of view and getting the OSEMs in the frame? It may provide some "anchor points" against which whatever algorithm can calibrate the spot position against. But there are also several point scatterers visible in the current view, and perhaps the Gaussiam beam profile moving over them and tracking the scattered intensity from these point scatterers serves the same function? I don't know of a good solution to have a "switchable" field of view configuration in the already cramped camera enclosure though.

Also, I think it may be useful to have a cron job take a picture of MC2 and archive it (once a week? or daily?) to have some long term diagnostic of how the scattered light received by the camera changes over several months.


The GigE is focused now and I have closed the lid. I'm attaching a picture of the MC2 beam spot, captured using GigE at an exposure time of 400µs

  10474   Tue Sep 9 00:34:34 2014 JenneUpdateLSCFiguring out where to do DARM->AS55

This afternoon, after Q and Manasa finished recovering from the activities of the morning, I aligned the IFO, and went to the Yend to touch up the alignment of the green to the arm.  I don't know if it was the alignment (I didn't do the PSL table), or I happened to have a good combination of laser temperatures, or what, but the Yend ALS noise was super good.  After that, the low frequency noise contribution is different lock-to-lock, and I haven't discerned a pattern yet.

One thing that we want to try is to get DARM to AS55 so that we're entirely off of ALS (assuming we've already gotten CARM to sqrtInvTrans).  However, according to Q's simulations, we have to get past arm power of a few before we are within the AS55 linewidth.  I have a DTT running showing me the phase between AS55 and ALSdiff as I reduce the CARM offset, but I haven't been able to get close enough to see the sign flip when CARM is on sqrtInvTrans.  If I just sweep through with both CARM and DARM on ALS, I see the sign flip.  I've tried a few different things, but I have not successfully gotten a transition to AS55 while the arm powers were above 1.  Empirically,  I think I want them at at least 3 or 4.

Koji suggested locking the DRMI rather than PRMI, to widen the AS55 linewidth, but I haven't tried that tonight.  Maybe tomorrow night.

I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet.  Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run.  I'll need to look into this when I'm not so sleepy.

Q, can you please work on figuring out the phase tracker gain tracker?  It will be nice to have that functional so we don't have to fret about the phase tracker gains. 

Manasa, can you please estimate what kind of mode matching we have on the PSL table between the arm greens and the PSL green?  We *do not* want to touch any optics at this point.  Just stick in a power meter to see how much power we're getting from each beam, and then think about the peak height we see, and what that might tell us about our mode overlap.  If we determine it is total crap, we can think about measuring the beams that go either toward the camera, or the DC PDs, since neither of those paths require careful alignment, and they are already picked off from the main beatnote path.  But first, what is our current efficiency?  Yarm is first, then Xarm, since Yarm seems worse (peak height is larger for non-00 modes!)

  10478   Tue Sep 9 14:25:46 2014 jamieUpdateLSCFiguring out where to do DARM->AS55


I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet.  Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run.  I'll need to look into this when I'm not so sleepy.

We developed a fairly sophisticated lockloss script at the sites, which you could try using as well.  It's at:


It requires a reasonably up-to-date install of cdsutils, and the tconvert utility.  It uses guardian at the sites to determine when locklosses happen, but you can use it without guardian by just feeding it a specific time to plot.  It also accepts a list of channels to plot, one per line.

  5128   Fri Aug 5 20:44:26 2011 jamieMetaphysicsTreasureFilm crew here Monday morning

Just a reminder that a film crew will be here Monday morning, filming Christian Ott for some Discovery channel show.

They are slated to be here from 8am to 12:30pm or so.  They will take a couple of shots inside the lab, and the rest of the filming should be of Christian in the control room (which they will "clean up" and fit with "sexy lighting").  I will try to be here the whole time to oversee everything.

  7092   Mon Aug 6 17:15:15 2012 JenneUpdateASSFilter banks not working

I was trying to load some filters into the ASS so that I can try it out, but for some reason the filter banks aren't working - clicking the on/off buttons doesn't do anything, filters (which exist in the .txt file generated by foton) don't load.

I've emailed cds-announce to see if anyone has any ideas.

  7099   Tue Aug 7 00:22:10 2012 JenneUpdateASSFilter banks working


I was trying to load some filters into the ASS so that I can try it out, but for some reason the filter banks aren't working - clicking the on/off buttons doesn't do anything, filters (which exist in the .txt file generated by foton) don't load.

I've emailed cds-announce to see if anyone has any ideas.


When the network / fb went bad this afternoon, I had been working on the ASS model, shortening the names of the filter banks to fix the problem from elog 7092.  I wanted to finish working on that, so the ASS model is now rebuilt with slightly shorter names in the filterbanks (which fixes the problem of the filter banks not working).


I mentioned this to Jamie the other day, but here's the error that you get when the GoTo/From tags aren't working:

>>rtcds make c1ass
### building c1ass...
Cleaning c1ass...
Parsing the model c1ass...
IPC 9 8 is ISHME
IPC 10 9 is C1:RFM-LSC_TRX
IPC 10 9 is IPCIE
IPC 11 10 is C1:RFM-LSC_TRY
IPC 11 10 is IPCIE

INPUT XARM_LSC_in is NOT connected

INPUT YARM_LSC_in is NOT connected

***ERROR: Found total of ** 2 ** INPUT parts not connected

make[1]: *** [c1ass] Error 255
make: *** [c1ass] Error 1

I don't know why these tags weren't working, but there was a GoTo tag on the output of the LSC shmem block, and then Froms on each of the XARM_LSC_in and YARM_LSC_in.  The other day I played around with a bunch of different things (grounding inputs, terminating outputs, whatever), but finally replacing the tags with identical ones freshly taken from CDS_PARTS made it happy. 

  5730   Mon Oct 24 19:48:16 2011 MirkoUpdateAdaptive FilteringFilter execution time

Toyed around some more with the adaptive filters.

Execution time:

nTaps    Downsampling factor     Execution time average / max in ca. 3 min [us], (480 us available)
1000     16                                110 / 150
2000     16                                280 / 340
3000     16                                380 / 470
4000     16                                Over limit

Now we are running with Downsampling 32, 4000 Taps => max 410us execution time.

I tried to desynchronize the downsampled operations of the filters of the different DOFs. That however increased execution time by about 10%. So I undid that.


  3802   Thu Oct 28 02:01:51 2010 KevinUpdatePSLFilter for 2W Laser

[Rana and Kevin]

I made a low pass filter for the piezo driver for the 2W laser that is now installed. The filter has a pole at 2.9 Hz. The transfer function is shown in attachment 1.

Attachment 2 shows the outside of the filter with the circuit diagram and attachment 2 shows the inside of the filter.

Attachment 1: tf.PDF
Attachment 2: outside.jpg
Attachment 3: inside.jpg
  3707   Wed Oct 13 17:12:33 2010 josephb, yutaUpdateCDSFilter name length problem found and fixed

The missing filter files for ULPOS, URPOS, and so forth for the mode cleaner optics was due to the length of the names of the filters. 

This was not a problem for the c1sus model because it was using its own name as the first 3 letters of its designation.  A filter for the sus model would be called something like BS_TO_COIL_MTRX_0_0, while for the mcs it would be called SUS_MC1_TO_COIL_MTRX_0_0, an extra 4 characters.

However, the c1mcs model used the "top_name" feature which uses a subsystem box within the simlink model to rename all the channels.  Apparently in the filter file, this means it has to add the top name to the front of everything, adding an additional 3 characters.  This pushed things over the length limit.

A hard cap of 18 characters has been added to the FiltMuxMatrix.pm file (located in /cvs/cds/caltech/c1/, so that it will prevent this type of problem in the future by stopping at compile time and presenting a helpful error message.

I also fixed a bug with too many spaces in the feCodeGen.pl file when dealing with top_names and the filtMuxMatrix.pm preventing some .adl files from being generated.

Also of interest, MC3 appears to never have had F2A filters.  For the moment we're running without them, but since they're just a fine tuning it shouldn't affect locking tonight.


Improbability factor of mode cleaner suspensions working tonight: ~20


  995   Fri Sep 26 00:19:54 2008 JenneUpdatePSLFilter-action with the PMC
Written, but not posted on 24Sept2008:

PMC adventures for this evening

Today's mission was to make more progress on increasing the bandwidth of the PMC servo.

First order of business was to improve the performance of the 14.6kHz notch that Rana put in the PMC servo board a few weeks ago to remove the 14.6kHz body mode resonance of the PMC. Looking at the zoomed in TF that I posted Monday (elog #978), we see that there is still a remnant of a peak near 14.5kHz. A first gut-reaction is that the notch is not tuned properly, that we have just missed the peak. As previously noted in the elog, the peak that we are trying to notch out is at 14.68kHz (elog #874). By unlocking the PMC and measuring the transfer function between FP2 and OutMon (OutMon is the monitor for the high voltage going to the PMC's PZT), I measure the transfer function of the notch, and find that it is notching at 14.63kHz. So we're a teensy bit off, but the Q of the notch is such that we're still getting improvement at the peak frequency. After checking that we are hitting the correct frequency, I put a short (just some wire) around R21, which is the R in the RLC notch filter, to increase the depth of the notch. At the peak frequency of 14.68kHz, we see a 2.5dB improvement of the notch. At the actual notch frequency of 14.63kHz, we see a 3.2dB increase in the depth of the notch. So, shorting R21 helped a little, but not a lot. Also, it's clear that we don't get that much more improvement by being on the resonant frequency, so there's no need to go in and tune the notch on the board.

Second order of business was to investigate the 18.34kHz peak in the transfer function. (Rana spent some time Monday night measuring this peak, and determined that it was at 18.34kHz) We decided that the best plan was to re-implement the Pomona Box notch filter that had previously existed to remove a higher frequency body mode, but tuned for the 18.34kHz mode. I am still not entirely sure what this mode is, but clearly it's a problem by about 20dB (on the TF, the next highest peak is 20dB below the 18.34kHz peak). Unfortunately, while the components should, by Matlab calculations, give me an 18.3kHz notch, I ended up with something like a 21.7kHz notch. This notch is approximately -30dB at 21.7kHz, and -20dB at 18.3kHz. I still need to take transfer functions and power spectra of the PMC servo with this new filter in place to (a) confirm that it did some good, and (b) to determine how important it is that the notch be right-on. More likely than not, I'll take the filter out and fiddle with the capacitors until I get the correct notch frequency.

Third on the list was to lock everything back up (FSS, PMC) after my tinkering, and see what kind of gain we get. Rob and I fiddled with the PMC gain, and it looks like the servo oscillates just before we get up to the max slider gain of 30dB. Looking at the power spectra in DTT, we do not see any significant peaks that suggest oscillation, so it is likely that there is some investigation to be done at frequencies above the 7kHz that we were able to look at with DTT (which isn't surprising, since all of this work has been at 14kHz and higher).

A final note is that we see a feature around 9kHz in the transfer function, and it is not at all clear where it comes from. At this time, it does not seem to be the dominant feature preventing us from increasing the gain, but at some point if we want the bandwidth of the PMC servo to be 10kHz, we'll have to figure this one out.

Still on the PMC todo list:

  • Measure the new transfer function, see if 18.34kHz peak is reduced

  • Tune Pomona Box notch filter to 18.3kHz instead of the current 21.7kHz

  • Retake power spectra of different items on top of PMC, compare to see if there is any one configuration that it obviously better than the others.

  • Find out why the PMC still oscillates when we try to take it up to the max slider gain, and fix it.

PS, is anyone else having trouble getting to the elog from laptops on other parts of the Caltech network (but not LIGO network)? My laptop won't go to the elog, but I can get to the rest of the internet using the Caltech wireless. My computer stopped seeing the elog on Tuesday or so. Joe, do you have any inspiration? Thanks.
  522   Fri Jun 6 11:19:13 2008 CarynSummaryPEMFiltering MC_L and MC_F with PEM:ACC and microphone
Tried to filter MC_L and MC_F with acc/seis data and microphone data using wiener filter (levinson)

-Used get_mic_data.m and miso_filter_lev.m to make SISO filter for 2 minutes of IOO-MC_F data. Used PEM-AS_MIC signal as noise input data. Filters calculated at initial time were applied to later data in 1 hour intervals.
-microphone filter did not seem to filter MC_F very well in high frequency range using this filtering procedure.
-residual is larger than est (see MC_F pdf)
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-relation of max(rms(residual)) to N(order) is time sensitive (note-on graph, time interval is 1hour) (see MC_F pdf)
-Presumably, max(rms(residual)) should decrease as N increases and increase as time increases since the filter probably becomes worse with time. I think the reason this isn't always true in this case is that the max(rms(residual)) corresponds to a peak (possibly a 60Hz multiple) and the wiener filter isn't filtering out that peak very well.

-Used get_z_data.m and miso_filter_lev.m to make MISO filter for 2 minutes of IOO-MC_L used the following signals as noise input data
-Filter was applied to later data in 2hour intervals.
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-acc/seis filter seemed to filter MC_L OK for 128,256,512Hz srates. 64 Hz wasn't ok for certain N's after a period of time.
-residual is smaller than est for srates not 64Hz (see MC_L pdf)
-residual is larger than est for 64Hz at N=1448 for later times (see MC_L pdf)
-relation of max(rms(residual)) to N is not as time sensitive for higher sample rates (note-on graph, time interval is 2hours) (see MC_L pdf). Perhaps the levinson 64Hz sample rate filter doesn't do as well as time passes for these signals. When the filter didn't do well, the max(rms(residual)) seemed to increase with N.
-For 512Hz sample rate filter the max(rms(residual)) decreased with time. If the max(rms(residual)) were an indication of filter performance, it would mean that the 512Hz filter calculated at the initial time was performing better later as hours passed by! Perhaps max(rms(residual)) isn't always great at indicating filter performance.

Programming notes
-I had to modify values in do_all_time_lev.m to get the program to loop over the srates,N's,times I wanted
-do_all_time_lev.m is not as clean as do_all_lev.m
-for making the plots do_all_lev.m (which isn't really a procedure and is messy) has some examples of how to plot things from do_all_time_lev.m.
Attachment 1: MC_F.pdf
MC_F.pdf MC_F.pdf MC_F.pdf
Attachment 2: MC_L.pdf
MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf MC_L.pdf
Attachment 3: miso_filter_lev.m
function [s] = miso_filter_lev(N,srate,rat,z)
%MISO_FILTER_LEV(N,srate,z) uses miso_firlev to get levinson
%   FIR Wiener filter of order N-1, using impulse response of 
%   N/srate. z is a structure gotten from the get_data function. 
%   z(end) is the signal which is filtered using z(i) for all i.
%   'rat' is the fraction of z which will be put into filter
%   funtion. The data from z is downsampled using srate and 
%   detrended. Let rat=1. I don't have that part working yet.

... 107 more lines ...
Attachment 4: get_mic_data.m
%get_mic_data gets data for'C1:IOO-MC_F', 'C1:PEM-AS_MIC,
% Example:  z = get_mic_data('now',120,60)
%  start time is 't- d_t' so  d_t should be given in seconds. t should be given
%  as a number like 893714452. d is duration in seconds. get_mic_data saves
%  data to a file in current directory named 'temp_mic'. You will be asked to
%  save file as 'mic_(start_time)_(duration)'.

duration = d;

... 32 more lines ...
Attachment 5: do_all_time_lev.m
function[r] = do_all_time_lev(n,t0,int,duration,N,srate,rat,order,time,MC_L,MC_F,sample_rate)
%do_all_time explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and keeps track of the...
%max(rms(residual)) for each filter. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 215 more lines ...
Attachment 6: do_all_lev.m
function[r] = do_all_lev(n,t0,int,duration,n_N,int_N,n_srate,int_srate,rat,MC_L,MC_F)
%do_all_lev explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and graphs the rms of the cost
%function vs time. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 283 more lines ...
Attachment 7: do_all_plot.m
function[r] = do_all_plot(r,x,v)
 %do_all_plot plots variables contained in r(structure from
 %do_all_time_lev).Plots error(r.B.y) vs x. x can be
 %'s'(srate),'N'(order),'t'(time),'p'(impulse response). v can be 's','N','t'. 
 %example: do_all_plot(r,'s','t') makes a plot of error vs srate for
 %different times.


... 388 more lines ...
Attachment 8: miso_filter_int.m
function [s] = miso_filter_int(s,y)
%miso_filter_int inputs a filter and a structure array of data sets y, applies filter to data, and
%outputs a structure with fields: ppos(signal frequ spectrum),perr(cost
%function frequ spectrum),pest(signal estimate frequency
%spectrum),f(frequency),target(signal),est_darm(noise estimate),t(time).
%data file for which filter has been calculated is s (obtained using miso_filter). 
%y consists of data structures which will be filtered using
%filter from s. Then the power spectrum of the difference between signal and filtered-data is
%graphed for all the data files of y for comparison too see how well filter performs
%over time. Note if you want to create a y, take z1,z2,z3,etc. structures
... 120 more lines ...
  6049   Wed Nov 30 02:04:26 2011 rana, den, jenne, kiwamu, jzweizigUpdateCDSFiltering Noise issue tracked down ???

 You can read through all of our past tests to see what didn't work in tracking things down. As Den mentions, there was actually a lot of evidence that there was some double->single precision action in the filter calculation causing the noise we saw.

However, it turns out that this is NOT the case.

This afternoon I was so confused that I enlisted JZ to help us out. He came over and I tried to replicate the error. When looking at the time series, we noticed that it wasn't random noise; the signals seem to be getting clipped as they crossed zero. Sort of like a stiction problem. JZ left to go replicate the error on an offline system.

This turned out to be the important clue. As we examine the code we find this inside of fm10Gen.c:

if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

this is line is basically trapping the filter history at 1e-20, to prevent some kind of numerical underflow problem (?). Seems reasonable, except that some filters which have higher order low passing in them actually have an overall scale factor which can be small (even as small as 1e-23, as Den pointed out).

So the reason we saw such weird behavior is that the first filter in SUSPOS is an AC coupling filter. This takes the OSEM signal and remove the large mean value. Then the next filter multiplies it by 1e-23 before doing the filtering and you end up with this noise in the filter history.

I looked and this line is commented out in the new BiQuad code, but as far as I can tell this issue has been around in aLIGO, eLIGO, iLIGO, etc. for a long time and could have been causing many cases of excess noise whenever we ended up a tiny gain factor in an IIR filter. At the 40m, there are easily a hundred such cases.

For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

  6051   Wed Nov 30 11:04:26 2011 josephbUpdateCDSFiltering Noise issue tracked down ???


For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

According to the RCG SVN logs, the reason it was removed was a more general change done to the compiled code, not specific to just the biquad.  Basically, the ability to have an underflow number (subnormal) has been turned off completely by having any number that underflows set to zero. I'm not positive, but from a quick search looks that the smallest number before hitting is an underflow as a double is 2.2250738585072014e-308.

Alex's entry from the SVN log for 2663:

Added new fz_daz() function to turn on two bits in the FPU SSE control register.
Bits FZ (flush underflows to zero) and DOZ (denorms are zeros) are set to
avoid runaway code on float/double denorms (really small numbers).
Ref: http://software.intel.com/en-us/articles/how-to-avoid-performance-penalties-for-gradual-underflow-behavior/

SVN log 2664:

Removed +- 1e-20 limiting code, this is taken care of by setting FZ/DOZ bits
in the CPU SEE control register (see mathInline.h)

SVN log 2665:

Kill the underflows and roll down float denorms to zero,
see fz_doz() in mathInline.h.

  6052   Wed Nov 30 11:36:12 2011 DenUpdateCDSFiltering Noise issue tracked down ???


 if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

20 is indeed a random number. We can change it to 300. Alex said that during that iir filter calculations sometimes numbers are very small and if they are less then 1e-308 then a very slow code in the processor is executed and this will crash the online system. For single precision this number is 1e-38 and may be 10 years ago it was not decided for sure what to use - float or double. 20 will be "OK" for both but as we can see causes other problems.

Anyway, Alex removed this line from the code and added another code that sets the two proper bits in the MXCSR register and prohibits to the CPU to run the slow code. As far as I understand if the numbers are less then 1e-308 they become 0. Roughly, this is equivalent to 

 if((new_hist < 1e-308) && (new_hist > -1e-308)) new_hist = 0;

This is in 2.4 release. It is in the svn. I think we can install it and figure out if the problem is gone.


  7074   Wed Aug 1 22:37:21 2012 JenneUpdateASSFilters installed in the ASS

As part of trying to figure out what is going on with the ASS, I wanted to figure out what filters are installed on which lockins.

Each "DoF"(1-6) has a zpk(0.1,0.0001,1)gain(1000), which is a lowpass with 60dB of gain at DC, and unity gain at high frequencies.

For the lockins, since there are so many, I made a spreadsheet to keep track of them (attached). 

So, what's the point?  The point is, I think that all of the LOCKIN_I filter modules should be the same, with a single low pass filter.  The Q filter banks don't matter, since we don't use those signals, and the signals are grounded inside the model.  The phase of each lockin was / should be tuned such that all of the interesting signal goes to I, and nothing goes to Q.  The SIG filter modules seem okay, in that they're all the same, except for their band pass frequency.  I just need to check to see what frequency the ASS scripts are trying to actuate at, to make sure we're bandpassing the correct things.


Attachment 1: ASS_lockin_filters_1Aug2012.pdf
ASS_lockin_filters_1Aug2012.pdf ASS_lockin_filters_1Aug2012.pdf
  11590   Thu Sep 10 09:37:34 2015 IgnacioSummaryIOOFilters left on MCL static module

The following MCL filters were left loaded in the T240-X and T240-Y FF filter modules (filters go in pairs, both on):

FM7: SISO filters for MCL elog:11541

FM8: MISO v1 elog:11547

FM9: MISO v1.1 Small improvement over MISO v1

FM10 MISO v2 elog:11563

FM5 MISO v3.1 elog:11584 (best one)

FM6 MISO 3.1.1 elog:11584 (second best one)


  10239   Fri Jul 18 19:32:50 2014 AkhilSummaryElectronicsFilters used inside the Frequency Counter


 Thanks Koji , for your  hint for the brain teasing puzzle. I was looking into Filters that are usually used in devices like counters, DSO and other scopes. I found that , to improve the quality of the measurement one of the best approach  is averaging. I looked deeper into averaging and found out this:

There are two general use-cases for averaging . The first, successive sample averaging, takes a single acquisition and averages between its samples. The second, successive capture averaging, combines the corresponding  samples of multiple captures to create a single capture. Successive sample averaging is also called boxcar filtering or moving average filtering. In an implementation of this type of averaging each output sample represents the average value of M consecutive input samples. This type of averaging removes noise (one of the reasons the noise level was not bad: http://nodus.ligo.caltech.edu:8080/40m/10151) by decreasing the device's bandwidth(could be one of the reasons why the FC operates in 4 different frequency ranges). It applies an LPF function with a 3dB point approximated by  0.433 * s / M, where M is the number of samples to be averaged, and s is the sample rate in samples per second. 

Now I tried verifying the 3 dB points in the gain plots I generated :

For 1 s Sampling time : the 3 dB point for such a Boxcar filter should be at 0.433* 1/M. If we assume that it averages for 2 samples, M=2 which gives the 3dB point at 0.288 Hz but occurs somewhere between 0.3 and 0.4 Hz.  (http://nodus.ligo.caltech.edu:8080/40m/140619_120548/GainVsFreq.png)

For 0.1s Sampling time: the 3dB point should be at 2.17 Hz and in reality is 2.5 Hz(http://nodus.ligo.caltech.edu:8080/40m/140701_211904/gain.png).

Also, This type of filter will have very sharp nulls at frequencies corresponding to signals whose periods are integer sub-multiples of M/s. As seen my previous plots (http://nodus.ligo.caltech.edu:8080/40m/10118 , http://nodus.ligo.caltech.edu:8080/40m/10070) there are sharp nulls at frequencies

0.4 Hz for 1S sampling time and

at 1.5 Hz,3 Hz for 0.1 S sampling time as correctly predicted.

The moving average filter is  L-sample moving average FIR, with the frequency response as:   H(ω) = (1/L) (1 − e− jω L)/(1 − e− jω)..

There is an overall delay of (M - 1)/2 samples from such a length-M causal FIR filter. 

The expected bode plots for such a filter with L= 5 is attached(attachment 2).

Attachment 1: TheoreticalGainPlot.png
Attachment 2: TFexpected.png
  10246   Mon Jul 21 12:16:27 2014 AkhilSummaryElectronicsFilters used inside the Frequency Counter

The expected bode plots for such a filter with L= 4 is attached and compared with the measured.

RXA: When comparing two things, please put them onto the same plot so that they can be compared.

Attachment 1: FC_TF_Characterization.png
  3437   Wed Aug 18 19:19:38 2010 JenneUpdateSUSFinal 2 TTs suspended!

[Jenne, Yoichi]

The final 2 Tip Tilts (#1 and #5) have been suspended.  We have designated #5 the spare.  It looks like there might be a teensy bit of dust on the AR surface of the optic in #5, right near the edge of the coating.  Not a critical issue if this one is the spare, although we should see if we can blow it off with the Nitrogen.  Both #1 and #5's optics were suspended using the thicker wire, 0.0036" diameter.  This leaves 4/5 TTs with this thick wire, and 1 of the 5 has the thin wire.

To do still: Balance both #1 and #5, and then measure the modes of each.  Then we'll be ready to install them into the chambers, and we'll reserve #5 for shake table TFs for some later date.


  8113   Wed Feb 20 01:40:37 2013 ManasaUpdateAlignmentFinal IFO alignment- in progress

[Yuta, Sendhil, Jamie, Jenne, Rana]

1. After the MC centering, we tried to align the IFO using IPPOS and IPANG as reference. This did not recover the alignment perfectly. We were clipping at the BS aperture. Using TTs, we centered the beam at BS and PRM.
2. Using TTs, the beam was centered at ITMY and ETMY.
3. IPPOS and IPANG mirrors in-vacuum were aligned and were centered at the out-of-vacuum optics.
4. We checked the centering of the beam on optics in the BS and ITMY chamber. (Yuta will make an elog with the layout)
5. We retro-reflected ITMY at the BS and aligned ETMY such that we saw a couple of bounces in the arm cavity.
6. Using BS, the beam was steered to go through the center of ITMX and ETMX.
7. At this point we were able to see the MI fringes at the AS port.
8. We made fine alignments to the ITMX such that we saw MI reflected at the Farday.
9. We retro-reflected ITMX and aligned ETMX to see the beam bounce at the ITMX.
10. We aligned PRM such that PRC flashes. But we were not happy with the flashes (they were in higher order modes). We suspect that minor tuning of the input pointing might be necessary.
11. We closed for the day

  8338   Mon Mar 25 16:51:43 2013 ChloeUpdate Final QPD Circuit Design

This is the final version of the QPD circuit I'm going to build. After playing around with the spatial arrangement, this should fit into the box that I was planning to use, although it will be a rather tight fit. The pitch, yaw, and summing circuit will be handled with a quad op amp. Planning to meet with Eric tomorrow to figure out the logistics of building things.

In the meantime, I'm reading about designing the ECDL for my summer project with Tara. He sent me several papers to read so we can talk on Wednesday.

Attachment 1: IMG-20130325-00244.jpg
  11535   Fri Aug 28 00:59:55 2015 IgnacioUpdateIOOFinal SISO FF Wiener Filter for MCL

This is my final SISO Wiener filter for MCL that uses the T240-X seismo as its witness.

The main difference between this filter and the one on elog:11532 is the actual 1/f rolloff this filter pocesses. My last filter had a pair of complex zeroes at 2kHz, that gave the filter some unusual behavior at high frequencies, thanks Vectfit. This filter has 10 poles and 8 zeroes, something Vectfit doesn't allow for and needs to be done manually.

The nice thing about this filter is the fact that Eric and I turned this filter on during his 40 min PRFPMI lock last night, Spectra for this is coming soon.

This filter lives on the static Wiener path on the OAF machine, MCL to MC2, filter bank 7.

Anyways, the usual plots are shown below. 



T240-X (SISO)


Training data + Predicted FIR and IIR subtraction:


Online subtraction results:(High freq. stuff shown for noise injection evaluation of the filter)



Subtraction performace:

  14764   Tue Jul 16 15:17:57 2019 KojiHowToCDSFinal bit bug of the BIO CDS module

Yutaro talked about the BIO bug in KAGRA elog. http://klog.icrr.u-tokyo.ac.jp/osl/?r=9536

I think I made the similar change for the 40m model somewhere (don't remember), but be aware of the presense of this bug.

  14890   Tue Sep 17 14:43:59 2019 gautamHowToCDSFinal bit bug of the BIO CDS module

Came across this while looking up the BIO situation at 1Y2. For reference, the fix Koji mentions can be seen in the attached screenshot (one example, the other BIO cards also have a similar fix). The 16th bit of the BIO is grounded, and some bit-shifting magic is used to implement the desired output.


Yutaro talked about the BIO bug in KAGRA elog. http://klog.icrr.u-tokyo.ac.jp/osl/?r=9536

I think I made the similar change for the 40m model somewhere (don't remember), but be aware of the presense of this bug.

Attachment 1: Screen_Shot_2019-09-17_at_2.44.41_PM.png
  14941   Fri Oct 4 22:22:03 2019 gautamUpdateCDSFinal incarnation of latch.py

[KA, GV]

This elog is meant to be a summary of some of the many subtleties on the CM board. The latest schematic of the version used at the 40m can be found at D1500308 .

Latch logic:

  • There are several Binary Outputs and one Binary Input to the CM board.
  • The outputs control ENABLE/DISABLE switches and gains of amplifier stages, while the input reports whenever the limiter has been reached.
  • The variable gain feature is implemented by enabling/bypassing several cascaded fixed gain stages. So in order to change the gain of a single composite amplifier stage, multiple individual amplifier stages have to be switched.
  • This is implemented by the user interacting with the hardware via a "control word", consisting of a number of bits depending on the number of cascaded stages that have to be switched. 
  • This control word is sent to the device via modbus EPICS, which is an asynchronous communication protocol. Hence, it may be that the individual bits composing the control word get switched asynchronously. This would be disastrous, as there can be transient glitches in the gain of the stage being controlled. 
  • To protect against such problems, there is a latch IC in the hardware between the Binary Inputs to the board (= Binary Outputs from Acromags), and the actual switches (= MAX333) that enable/bypass the cascaded gain stages. The latch IC used is a SN74ALS573. This device acts as a bus, which transmits/blocks changes for multiple bits (= our control word) from propagating, depending on the state of a single bit (= the LATCH ENABLE bit). Thus, by controlling a single bit, we can guarantee that multiple bits get switched synchronously
  • In order to use this latch capability, we need some software logic that sets/disables the LATCH ENABLE bit. For our system, this logic is implemented in the form of a continuously running python 🐍 script, located at /cvs/cds/caltech/target/c1iscaux/latch.py. It is implemented as a systemctl service on the c1iscaux Supermicro. The logic implemented in this script is shown in Attachment #1. While the channels referred to in that attachment are for REFL1_GAIN, the same logic is implemented for REFL2_GAIN, AO_GAIN, and the SuperBoosts.
  • Some FAQ:
    1. Q: Why do we need the soft channels C1:LSC-REFL1_SET_LSB and C1:LSC-REFL1_SET_MSB?
      A: These soft channels are what is physically linked to the Acromag Binary Outputs. In order for our latch logic to be effective, we need to detect when the user asks for a change, and then disable the LATCH ENABLE bit (which is on by default, see FAQ #3) before changing the physical acromag channels. The soft channels form the protective layer between the user and the hardware, allowing latch.py to function.
    2. Q: Why is there an "_MSB" and "_LSB" soft channel? 
      A: This has to do with the mbboDirect EPICS channel type, which is used to control the multiple bits in our control word using a single input (= an MEDM gain slider). The mbboDirect data-type requires the bits it controls to have consecutive hardware addresses. However, the Acromag hardware addressing scheme is not always compatible with this requirement (see pg 33 of the manual for why this is the case). Hence, we have to artifically break up the control word into two separate control words compatible with the Acromag addressing scheme. This functionality is implemented in latch.py.
    3. Q: Why is the default state of LATCH ENABLE set to ON? 
      A: This has to do with the fact that all Binary Inputs, not just the multi-bit ones, to the CM board are propagated to the control hardware via a latch IC. For the single-bit channels, there is no requirement that the switching be synchronous. Hence, rather than setting up ~10 more single-bit soft channels and detecting changes before propagating them, we decided to leave the LATCH ENABLE ON by default, and only disable it when changing the multi-bit gain channels. This is the same way the logic was implemented in the VME state code, and we think that there are no logic reasons why it would fail. But if someone comes up with something, we can change the logic.

Acromag BIO testing:

During my bench testing of the Acromag chassis, I had not yet figured out mbboDirect and the latch logic, so I did not fully verify the channel mapping (= wiring inside the Acromag box), and whether the sitching behavior was consistent with what we expect. Koji and I verified (using the LED tester breakout board) that all the channels have the expected behavior 👏. Note that this is only a certification at the front-panel DB37 connectors of the Acromag chassis  testing of the integrated electronics chain including the CM board is in progress...

Attachment 1: LatchLogic.pdf
  14947   Tue Oct 8 03:19:14 2019 KojiUpdateCDSFinal incarnation of latch.py

Now with the CM board tested with the signal injected, it turned out that the latch logic was flipped. As the default state locked the digital levels, the buttons other than the mbbo channels were inactive.

By giving 0 to C1:LSC-CM_LATCH_ENABLE, the modification of the digital state is enabled. And with the value of 1, the digital bits on the board is locked.

In order to reflect this, latch.py was modified and now the controls are all activated.

  941   Thu Sep 11 11:29:14 2008 josephbConfigurationComputersFinal netgear switch in place in 1Y2
I've placed the final (of 4) Netgear prosafe 24 port switch at the very top of 1Y2. At that location, there are no holes left to screw into, so it has 4 rubber feet and is sitting on the top most signal generator. It has been plugged in and connected to the control room hub with a labeled cat6 ethernet cable.

Its IP address has been set to, and has the usual controls password if using the "Smart Wizard Discovery Tool" which comes on the Netgear CD. The CD can be found in the Equipment manuals filing cabinet under Netgear. This program unfortunately only runs on a window PC.

To Do: Fix the C1:ASC ethernet connection which is currently coming straight out the front door and connected to the 1X4 switch (again through the front door).
  8961   Fri Aug 2 21:59:36 2013 CharlesUpdateISSFinalized ISS Schematic (hopefully)

Attached is the finalized schematic. The general circuit topology should remain the same from this point forward, although individual component values are subject to change. I will also be adding some more annotations to ensure everything on the board is clear.

In general, I have finally included all of the correct components (i.e. front panel switches are now actually switches and front panel LEDs are now included). I also added an external 'Boost' switch, which can be used to enable or disable the boosts. The motivation for including this switch is that one might want to test functionality of the ISS without using the 'fancy' RMS detection and triggering circuitry. Additionally, one can disable the boosts when all the circuitry is stuffed in order to troubleshoot, so it essentially grants the board some flexibility in its operation.

I am now working on the PCB layout and I should hopefully have that done next week. 

Attachment 1: ISS_v3.pdf
ISS_v3.pdf ISS_v3.pdf ISS_v3.pdf ISS_v3.pdf ISS_v3.pdf
Attachment 2: ISS_v3-Power_Reg.pdf
  2983   Tue May 25 16:40:27 2010 josephb, alexUpdateCDSFinally tracked down why new models wouldn't talk to each other

The problem with the new models using the new shared memory/dolphin/RFM defined as names in a single .ipc file.

The first is the no_oversampling flag should not be used.  Since we have a single IO processor handling ADCs and DACs at 64k, while the models run at 16k, there is some oversampling occuring.  This was causing problems syncing between the models and the IOP.

It also didn't help I had a typo in two channels which I happened to use as a test case to confirm they were talking.  However, that has been fixed.

  8322   Thu Mar 21 09:53:46 2013 AnnalisaUpdateLockingFinding the beat note

 Yesterday I tried to find the beat note between the main PSL and the auxiliary NPRO, but I didn't :( 

Today I will do a better alignment of the two beams in the PD and try again.

  8323   Thu Mar 21 10:19:28 2013 KojiUpdateLockingFinding the beat note

Give us more info on the elog:
What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it?
How are you looking for the beat note? (on the scope? or spectrum analyzer?)
What was the scanned temp range?

Three points to be checked:

- Polarization

- Alignment

- Temperature

  8327   Thu Mar 21 13:11:42 2013 AnnalisaUpdateLockingFinding the beat note


Give us more info on the elog:
What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it?
How are you looking for the beat note? (on the scope? or spectrum analyzer?)
What was the scanned temp range?

Three points to be checked:

- Polarization

- Alignment

- Temperature

Experimental Setup

I'm using a 1611 New Focus PD (1 GHZ, with maximum input power 1mW), and the total power hitting on the PD is of about 0.650 mW.

The current of the NPRO laser is set to 1.38 A, so that the input power is 19 mW. The beam is initially damped by a 10% reflection BS and then it hits a 33% reflection BS (where it recombines with the PSL pick-off beam) with 2 mW power.

After this second BS the power is reduced to 0.592 mW.

The PSL pick-off hits on the 33% reflection BS with 65.5 uW power, and it exit with a 47 uW power.

I connected a power supply to apply a Voltage to the slow frequency BNC, in way to tune the laser frequency.

I'm using the AGILENT 4395A Spectrum analyzer to make the measurement. I tried to use the HEWELETT PACKARD 8591E spectrum analyzer, but the monitor didn't turn on.

The temperature spanned until now in only of about 10 deg C, because I realized that I needed a better alignment, so I added a lens in front of the PD and I did a better alignment. 

Moreover, the current of the laser is too low, so I need to increase it and add more beam splitters in the beam path to dump the beam, in way to don't reach the PD threshold.

I knew that both the beams are s-polarized, but maybe I can check it again.

Attachment 1: Beat_note_setup.jpg
  541   Wed Jun 18 18:26:19 2008 YoichiUpdatePSLFinding the optimal operation temperature for the NPRO by the slow act scan
Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later.
Attachment 1: FSS-slow-scan.pdf
  7953   Tue Jan 29 14:20:02 2013 KojiUpdateGeneralFiner rotation stage for optics characterization

A rotation stage has been ordered.

Newport Rotation Stage, 360° Coarse, 5° Fine Rotation, Micrometer  Newport 481-A
Newport Solid Insert for RSP-1T Rotation Stage Newport RSA-1TI
Newport Universal Mounting Plate, 2.56 in. x 2.56 in. x 0.5 in., 1/4-20 Thread  Newport UP-1A

Specification: Newport 481-A

  • Sensitivity: 15 arcsec
  • Graduations: 1 deg
  • Vernier: 5 arcmin
  • Fine travel range: 5 deg
  • With Micrometer
  15618   Thu Oct 8 08:37:15 2020 gautamUpdateComputer Scripts / ProgramsFinesse GUI

This looks cool, we should have something similar, can be really useful.

  15621   Thu Oct 8 18:40:42 2020 KojiUpdateComputer Scripts / ProgramsFinesse GUI

Is it better than Luxor? https://labcit.ligo.caltech.edu/~jharms/luxor.html

  14057   Thu Jul 12 14:06:39 2018 keerthanaUpdateelogFinesse and Analytical solution - Comparison

I tried to compare the cavity scan data we get from the Finesse simulation and that we expect from the Analytical solution. The diagram of the cavity I defined in Finesse is given below along with the values of different quantities I used. For the analytical solution I have used two different equations and they are listed below.

Analytical 1 - Blue Graph

\phi = \frac {2.L.\Omega_1}{c}

t_{cav} = \frac{t_e. t_f \exp^{-i\frac{\phi}{2}}}{1- r_f. r_e \exp^{-i\phi} }

T_{cav} = \left|{t_{cav}} \right|^2


Analytical 2 - Red Graph

F = \frac {4. r_f.r_e}{(1-r_f.r_e )^2}

\phi = \frac {2.L.\Omega_1}{c}

T_{cav} = \left|{t_{cav}} \right|^2 = \frac {(t_e.t_f)^2}{(1 - r_f . r_e)^2} \frac{1}{1+F(\sin\frac {\phi}{2})^2}

The graph obtained from both these solutions completely matches with each other.

Finesse Solution

The cavity which I defined in Finesse is shown below. The solution from Finesse and the Analytical solution also matches with each other. Another plot is made by taking the difference between Finesse solution and Analytical solution. The difference seems to be of the order of \approx 10^{-19}.

The Difference plot is also attached below.

Attachment 1: finesse_cavity.png
Attachment 2: Analytical1.pdf
Attachment 3: Finesse_Analytical.pdf
Attachment 4: Difference.pdf
  13915   Mon Jun 4 19:41:01 2018 keerthanaUpdate Finesse code for cavity scan

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

Attachment 1: Fig1.png
Attachment 2: Fig2.png
  13956   Wed Jun 13 18:08:36 2018 keerthanaUpdate Finesse code for cavity scan

The unit mentioned in the x-axis was wrong. So I have remade the graphs. The point where frequency equals to zero is actually the frequency corresponding to the laser, which is in the range of 1014 Hz and it caliberated as zero.


The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.


Attachment 1: finesse1.pdf
Attachment 2: finesse2.pdf
  12120   Wed May 18 01:10:22 2016 gautamUpdateCOCFinesse modelling

I've been working on putting together a Finesse model for the current 40m configuration. The idea was to see if I could reproduce a model that is in agreement with what we have been seeing during the recent DRFPMI locks. With Antonio and EricQs help, I've been making slow progress in my forays into Finesse and pyKat. Here is a summary of what I have so far.

  • Arm lengths were taken from some recent measurements done by yutaro and me 
  • Recycling cavity lengths were taken from Gabriele's elog 9590 - it is likely that the lengths I used have errors ~1cm - more on this later. Furthermore, I've tried to incorporate the flipped RC folding mirrors - the point being to see if I can recover, for example, a power recycling gain of ~7 which is what was observed for the recent DRFPMI locks.
  • I used Yutaro's most recent arm loss numbers, and distributed it equally between ITM and ETM for modeling purposes. 
  • For all other optics, I assumed a generic loss number of 25ppm for each surface

Having put together the .kat file (code attached, but this is probably useless, the new model with RC folding mirrors the right way will be what is relevant), I was able to recover a power recycling gain of ~7.5. The arm transmission at full lock also matches the expected value (125*80uW ~ 10mW) based on a recent measurement I did while putting the X endtable together. I also tuned the arm losses to see (qualitatively) that the power recycling gain tracked this curve by Yutaro. EricQ suggested I do a few more checks:

  1. Set PRM reflectivity to 0, scan ETMs and look at the transmission - attachment #1 suggests the linewidth is as we expect 
  2. Set ETM reflectivity to 0, scan PRM - attachment #2 suggests a Finesse of ~60  for the PRC which sounds about right
  3. Set ETM reflectivity to 0, scan SRM and verify that only the 55 MHz sidebands resonate - Attachment #3

Conclusion: It doesn't look like I've done anything crazy. So unless anyone thinks there are any further checks I should do on this "toy" model, I will start putting together the "correct" model - using RC folding mirrors that are oriented the right way, and using the "ideal" RC cavity lengths as detailed on this wiki page. The plan of action then is

  • Evaluating the mode-matching integrals between the PRC and the arm cavities as a function of the radius of curvature of PR2 and PR3
  • Same as above for the SRC
  • PRC gain as a function of RoC of folding mirrors
  • Mode overlap between the modes from the two arm cavities as a function of the RoC of the two ETMs (actually I guess we can fix RoC of ETMy and just vary RoC of ETMx).

Sidenote to self: It would be nice to consolidate the most recent cavity length measurements in one place sometime...

Attachment 1: arms.pdf
Attachment 2: PRC.pdf
Attachment 3: SRC.pdf
Attachment 4: Finesse_model.zip
  12130   Tue May 24 22:49:02 2016 gautamUpdateCOCFinesse modelling - mode overlap scans


Having played around with a toy finesse model, I went about setting up a model in which the RC folding mirrors are not flipped. I then repeated the low-level tests detailed in the earlier elog, after which I ran a few spatial mode overlap analyses, the results of which are presented here. It remains to do a stability analysis.

Overview of model parameters (more details to follow):

  • PRC length = 6.7727m (chosen using l_{PRC} = (N+\frac{1}{2})\frac{c}{2f_1}, N=0 - I adjusted the position of the PRM to realize this length in the model, while leaving all the other vertex optics in the same positions as in elog 9590
  • SRC length = 5.4182 (chosen using l_{SRC} = M\frac{c}{2f_2} but not l_{SRC} = N\frac{c}{2f_1}, M and N being integers, for M=2 - as above, I adjusted the position of the SRM to realize this in the model, while leaving all other vertex optics in the same positions as in elog 9590. It remains to be verified if it is physically possible to realize these dimensions in vacuum without any beam clipping etc but I think it should be possible seeing as the PRM and SRM had to be moved by less than 2cm from their current positions..
  • For the losses, I used the most recent numbers we have where applicable, and put in generic 25ppm loss for all the folding mirrors/BS/AR surfaces of arm cavity mirrors/PRM/SRM. Arm round trip loss was equally distributed between ITMs and ETMs
  • Arm lengths used: L_X = 37.79m, L_Y = 37.81m
  • To set the "tunings" of the various mirrors, I played around with a few configurations to see where the various fields resonated - it turns out that for PRM, ITMX, ITMY, ETMX and ETMY, the "phase" in the .kat file can be set as 0. while that for the SRM can be set as 90. In the full L1/H1 interferometer .kat files, these are tuned even further to the (tenth?!) decimal place, but I think these values suffice for out purposes.

Results (general note: positive RoC in these plots mean a concave surface as seen by the beam):

  • Attachments #1, #2 and #3 reproduce the low-level tests performed earlier for this updated model - i.e. I look at the arm transmission with no PRM/SRM, circulating PRC power with no ETMs, and circulating SRC power with no ETMs. Everything looks consistent here... In Attachment #2, there is no legend, but the (almost overlapping) red and green lines are meant to denote the +f1 and +f2 sidebands.
  • Attachments #4 and #5 are a summary of the mode-overlap scans for the PRC and SRC. What I did was to vary the radius of curvature of the RC mirrors (finesse only allows you to vary Rcx and Rcy, so I varied both simultaneously) and calculate the mode overlap between the appropriate pairs of cavities (e.g. PRX and XARM) in the tangential and saggital planes. The take-away here is that there is ~5% mode-mismatch going from an RoC of 1000m to 300m. I've also indicated the sag corresponding to a given RoC - these are pretty tiny, I wonder if it is possible to realize a sag of 1um? I suppose it is given that I've regularly seen specs of surface roughness of lambda/10?
  • Attachment #6 shows the PRC gain (calculated as T_PRC * (transmitted arm power with PRM / transmitted arm power without PRM) as a function of the RoC of PR2 and PR3. As a sanity check, I repeated this calculation with lossless HR surfaces (but with nominal 25ppm losses for AR surfaces of ITMs, and BS etc), shown in Attachment #7. I think these make sense too...
  • Attachment #8 - in order to investigate possible mode mismatch between the arm modes due to different radii of curvature of the ETMs, I kept the ETMY RoC fixed at 57.6m and varied the ETMY RoC between 50m and 70m (here, I've plotted the mode matching efficiency as a function of the RoC of the ETM in the X and Y directions separately - the mode overlap is computed as \frac{1}{\sqrt{2}}(x^2 + y^2) where x and y denote the overlap in the tangential and saggital planes respectively. It would seem that we only lose at most a couple of percent even if the RoCs are mismatched by up to 10m...
  • Attachment #9 - .kat file and the various pykat scripts used to generate these plots...

Next step is to carry out a stability analysis...

Attachment 1: armTransmission.pdf
Attachment 2: prcFSR.pdf
Attachment 3: srcTransmission.pdf
Attachment 4: modeMatchPRX.pdf
Attachment 5: modeMatchSRX.pdf
Attachment 6: PRCgainScan.pdf
Attachment 7: PRCgainLossless.pdf
Attachment 8: armModeMatchScan.pdf
Attachment 9: Finesse_files.zip
ELOG V3.1.3-