40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 198 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  12407   Sat Aug 13 18:25:22 2016 gautamUpdateCOCRC folding mirrors - Numerical review

This elog is meant to summarize my numerical simulations for looking into the effects of curvature on the RC mirrors. I've tried to go through my reasoning (which may or may not be correct) and once this gets a bit more refined, I will put all of this into a technical note.


  • Both the G&H (PR2, SR2) and Laseroptik (PR3 SR3) are convex on the HR side with RoCs of approximately -600m and -700m (though as stated in the linked elog, I'm not actually sure if there are measurements of this number) EDIT AUG15: There are measurements for the Laseroptik mirrors here
    GV April 8 2017: This elog by Jenne suggests that the installed PR2 has an RoC of approximately -700m. Koji has uploaded the phase map data for the RC TT mirrors to
    /users/public_html/40m_phasemap/40m_TT and 
    /users/public_html/40m_phasemap/40m_TT2. The G&H mirror data seems to be in the former folder, and it looks like there are two mirrors, one with RoC of ~ -700m and the other with RoC of ~ -500m. Does this mean PR2 has RoC -700m and SR2 has RoC -500m?
  • As a result, both the PRC and SRC were close to instability
  • By flipping the folding mirrors, the instability has been mitigated, but at the expense of the non-ideal situation where the AR coated side and the substrate are now inside the recycling cavity
  • We would like to order some new folding mirrors. In order to avoid receiving convex mirrors from the vendor, we want to specify a concave curvature for the HR side
  • The aim of this investigation is to look at how concave we should make these mirrors, because although the cavity stability improves with concavity of the HR side, possible disadvantages of having too convex mirrors are:
    • ​Mode-mismatch between the recycling cavities and the arms
    • Astigmatism

The study:

  • I've built a Finesse model for the 40m, which has been used for all the numerical studies quoted here
  • In constructing this Finesse model, I've used the following sources to specify various paramaters:
    • ​RoCs, R, T and physical dimensions of 4 test-masses, PRM, SRM and BS: Core optics wiki page
    • Losses - arm losses from Yutaro's measurements in elog11857 and elog11818 (distributed equally between ITM and ETM). For other optics, a generic value of 25ppm was used
    • "Ideal" lengths for our current modulation frequency were used for the various cavities (37.795m for the arms, 6.753m for PRC, 5.399 for SRC)
    • The folding mirrors (PR2, PR3, SR2, SR3) are initialized as flat in the model
  • I performed some low-level checks (e.g. arm linewidth, PRC FSR etc) to check that the model was sensible
  • I then proceeded to investigate the effects of curvature on the folding mirrors. Specifically, I investigated the following:
    • What is the mode mismatch between the recycling cavity mode and the arm as a function of the RoC of the folding mirror?
    • What is the effect of the RoC of the folding mirrors on the round-trip gouy phase accumulated (and hence the transverse mode spacing) in the recycling cavities?
  • For now, the parameter space explored is from 300m concave to 1000m concave. An RoC of 1km for a 2" optic corresponds to a sag of ~0.3 microns. I will explore the 1km-10km concave space and update the results shortly


  • Attachments #1 and #2 show the mode mismatch between the recycling cavity and the arm for various curvatures. The colorbars have been normalized to span the same range in all the plots
  • For both the PRC and the SRC, if we have folding mirrors with an RoC of 1000m concave, we will have a mode mismatch of 2-3%. The number gets worse the more convex the mirror
  • Attachments #3 and #4 show the one-way accumulated Gouy phase. Here, I have varied the curvature of the folding mirrors along a specific axis at a time (i.e. I've assumed that the folding mirrors are identical). I've also added the transverse mode spacing as a second y-axis. I have yet to check how these numbers compare with the linewidth of the 00-mode for the various fields, but for 1km concave folding mirrors, the TMS is in the region of 2MHz 

To do:

  • I will extend the range of RoCs explored to 10km concave and post results - but I will have to check with EricG to make sure that it is feasible for us to specify curvatures in this range
  • I was trying to use the RT gouy phase as calcluated by my Finesse simulations to plug into some analytical expressions to try and generate plots like this for various RoCs of the folding mirrors, but if the TMS calculations suffice, I will abandon these efforts
  • What are the other specifications we need to worry about before placing an order? Some thoughts from Rana's earlier elog:
    • The coatings need to be dichroic to allow extraction of the green beam (but only PR3/SR3 is currently dichroic?)
    • Wedge angle on the AR side?
  • Are there any other obvious sanity checks I should carry out?


Attachment 1: PRX_consolidated.pdf
Attachment 2: SRX_consolidated.pdf
Attachment 3: Gouy_PRC.pdf
Attachment 4: Gouy_SRC.pdf
  12413   Tue Aug 16 11:51:43 2016 gautamUpdateCOCRC folding mirrors - Numerical review

Summary of roundtable meeting yesterday between EricG, EricQ, Koji and Gautam:

We identified two possible courses of action.

  1. Flip the G&H mirror (PR2/SR2) back such that the (convex) HR face is the right way round. We want to investigate what are the requirements on a new PR3/SR3 optic that will guarantee cavity stability and also give good mode matching.
  2. Order two new sets of mirrors (i.e. replace all 4 folding mirrors). In this case, we want to spec a flat (how flat is reasonable to specify? EricG will update us) PR3/SR3, and design a PR2/SR2 with some concavity that will guarantee cavity stability in the event PR3/SR3 deviates from flatness (but still within what we spec). The choice to make PR3 as close to flat as possible is because the angle of incidence in our arrangement means that any curvature on PR3 dominates astigmatism.

I have done some calculations to evaluate the first alternative. 

  • Based on yesterday's preliminary discussion, we felt it is not reasonable to spec mirrors with RoC > 4km (sag of ~80nm). So I restrict my analyses to the range 300m-4km
  • Koji has a measurement of the phase maps for the G&H mirrors. The measured curvature is ~-500m. In my simulations, I've tried to allow for error in this measurement, so I look at the range -450m to -700m for the G&H mirror.
  • The Gouy phase analysis suggests we should look for an RoC of +500m (concave) for the new PR3/SR3 to have a TMS of ~1.5 MHz. Anything flatter (but still concave) means the TMS gets smaller.
  • The mode-matching in this region also looks pretty good, between 98% and 99%
  • I will post results of the analysis for the second alternative here for comparison

Something else that came up in yesterdays meeting was if we should go in for 1" optics rather than 2", seeing as the beam spot is only ~3mm on these. It is not clear what (if any) advantages this will offer us (indeed, for the same RoC, the sag is smaller for a 1" optic than a 2").


Attachment #1: Mode-matching maps between PRX and Xarm cavities, PRY and Yarm cavities with some contours overlaid.  

Attachment #2: Mode-matching maps between SRX and Xarm cavities, SRY and Yarm cavities with some contours overlaid. 

Attachment #3: Gouy phase calculations for the PRC

Attachment #3: Gouy phase calculations for the SRC


Attachment 1: PRC_consolidated.pdf
Attachment 2: SRC_consolidated.pdf
Attachment 3: GouyPRC.pdf
Attachment 4: GouySRC.pdf
  12414   Tue Aug 16 16:38:00 2016 gautamUpdateCOCRC folding mirrors - Numerical review

Here are the results for case 2: (flat PR3/SR3, for purpose of simulation, I've used a concave mirror with RoC in the range 5-15km, and concave PR2/SR2 - I've looked at the RoC range 300m-4km).

  • This is where we order two new sets of mirrors, one for use as PR2/SR2, and the other for use as PR3/SR3.
  • RoC of flat PR3/SR3 in simulation explored in the range 5km-15km (concave)
  • RoC of concave PR2/SR2 in simulation explored in the range 300m-4km (concave)

Attachment #1: Mode matching between PRC cavities and arm cavities with some contour plots

Attachment #2: Mode matching between SRC cavities and arm cavities with some contour plots

Attachment #3: Gouy phase and TMS for the PRC. I've plotted two sets of curves, one for a PR3 with RoC 5km, and the other for a PR3 with RoC 15km

Attachment #4: Gouy phase and TMS for the SRC. Two sets of curves plotted, as above.

Hopefully EricG will have some information with regards to what is practical to spec at tomorrow's meeting.

EDIT: Added 9pm, 16 Aug 2016

A useful number to have is the designed one-way Gouy phase and TMS for the various cavities. To calculate these, I assume flat folding mirrors, and that the PRM has an RoC of 115.5m, SRM has an RoC of 148m (numbers taken from the wiki). The results may be summarized as:

Cavity One-way Gouy phase [rad]           TMS [MHz]           
PRX 0.244 1.730
PRY 0.243 1.716
SRX 0.197 1.743
SRY 0.194 1.717

So, there are regions in parameter space for both options (i.e. keep current G&H mirrors, or order two new sets of folding mirrors) that get us close to the design numbers...

Attachment 1: PRC_consolidated.pdf
Attachment 2: SRC_consolidated.pdf
Attachment 3: GouyPRC.pdf
Attachment 4: GouySRC.pdf
  12417   Wed Aug 17 14:37:36 2016 gautamUpdateCOCRC folding mirrors - Numerical review


Cavity One-way Gouy phase [rad]           TMS [MHz]           
PRX 0.244 1.730
PRY 0.243 1.716
SRX 0.197 1.743
SRY 0.194 1.717

So, there are regions in parameter space for both options (i.e. keep current G&H mirrors, or order two new sets of folding mirrors) that get us close to the design numbers...

Keeping these design numbers in mind, here are a few possible scenarios. The "designed" TMS numbers from my previous elog are above for quick reference.

Case 1: Keep existing G&H mirror, flip it back the right way, and order new PR3/SR3. 

  • Spec PR3 to be concave with RoC 600 +/- 50m
  • This means the TMS in the PRC is in the range 1.4 MHz - 1.6 MHz [see this plot]
  • The mode matching efficiency for the PRC is > 98.5% [see this plot]
  • The TMS in the SRC is in the range 1.6 MHz - 1.8 MHz [see this plot]
  • Mode matching efficiency for SRC is > 98.5% [see this plot]
  • PRG between 34-38, depending on uncertainty in measurement of RoC of existing G&H mirror [see Attachment #1, added Nov 11 2016]

Case 2: Order two new sets of folding mirrors

  • Spec PR3/SR3 to be flat - for purposes of simulation, let's make it concave with RoC 10 +/- 5 km
  • Spec PR2/SR2 to be concave with RoC 1500 +/- 500m
  • The TMS in the PRC is between 1.7 MHz and 1.85 MHz [see this plot]
  • Mode matching efficiency is >98.5% in the PRC [see this plot]
  • TMS in the SRC is between 1.7 MHz and 2 MHz [see this plot]
  • Mode matching efficiency >99.0% in the SRC [see this plot]

At first glance, it looks like the tolerances are much larger for Case 2, but we also have to keep in mind that for such large RoCs in the km range, it may be impractical to specify as tight tolerances as in the 100s of metres range. So these are a set of numbers to keep in mind, that we can re-iterate once we hear back from vendors as to what they can do.

For consolidation purposes, here are the aLIGO requirements for the coatings on the RC folding mirrors: PR2, PR3, SR2, SR3

Attachment 1: PRG.pdf
  12418   Wed Aug 17 16:28:46 2016 KojiUpdateCOCRC folding mirrors - Numerical review

For the given range of the PR3/SR3 RoCs for both cases, all the resulting numbers such as TMSs/mode matching ratios look reasonable to me.

  12847   Thu Feb 23 10:59:53 2017 gautamUpdateCOCRC folding mirrors - coating optimization

I've now made a DCC page for the mirror specifications, all revisions should be reflected there.

Over the last couple of days, I've been playing around with Rana's coating optimization code to come up with a coating design that will work for us. The basic idea is a to use MATLAB's particle swarm constrained optimization tool to minimize an error function that is a composite of four penalties:

  1. Thermal noise - we use the proxy function from E0900068-v3 to do this
  2. Deviation from target T @1064nm, p-pol
  3. Deviation from target T @532nm, p and s-pol
  4. HR Surface field

On the AR side, I only considered 2 and 3. The weighting of these four components were set somewhat arbitrarily, but I seem to be able to get reasonable results so I am going with this for now. 

From my first pass at it, the numbers I've been able to get, for 19 layer pairs, are (along with some plots):

HR Side:

  • T = 50ppm, 1064nm p-pol
  • T = 99%, 532nm s and p-pol

       (in this picture, the substrate is to the right of layer 38)

AR Side:

  • R ~50ppm for 532nm, s and p-pol

   (substrate to the right of layer 38)

These numbers are already matching the specs we have on the DCC page currently. I am not sure how much better we can get the specs on the HR side keeping with 19 layer pairs... 

All of this data, plus the code used to generate them, is on the gitlab coatings page...


Attachment 1: PR3_R_170222_2006.pdf
Attachment 2: PR3_123_TOnoise_170222_2203.pdf
Attachment 3: PR3_123_Layers_170222_2203.pdf
Attachment 4: PR3AR_R_170222_2258.pdf
Attachment 5: PR3AR_123_Layers_170222_2258.pdf
  12887   Tue Mar 14 10:56:33 2017 gautamUpdateCOCRC folding mirrors - coating optimization

Rana suggested including some additional terms to the cost function to penalize high sensitivity to deviations in the layer thickness (L). So the list of terms contributing to the cost function now reads:

  1. Thermal noise - we use the proxy function from E0900068-v3 to do this
  2. Deviation from target T @1064nm, p-pol
  3. Deviation from target T @532nm, p and s-pol
  4. HR Surface field
  5. The ratio \frac{d\mathcal{T}/\mathcal{T}}{dL/L} with dL/L = 1%, evaluated at 1064nm p-pol and 532nm p and s-pol (only the latter two for the AR side)

I did not include other sensitivity terms, like sensitivity to the refractive index values for the low and high index materials (which are just taken from GWINC).

There is still some arbitrariness in how I chose to weight the relative contributions to the cost function, but after some playing around, I think I have a solution that I think will work. Here are the spectral reflectivity and layer thickness plots for the HR and AR sides respectively. 

HR side: for a 1% increase in the thickness of all layers, the transmission changes by 5% @ 1064nm p-pol and 0.5% @ 532nm s and p-pol


AR sidefor a 1% change in the thickness of all layers, the transmission changes by <0.5% @ 532nm s and p-pol

  (substrate to the right of layer 38)

I've also checked that we need 19 layer pairs to meet the spec requirements, running the code with fewer layer pairs leads to (in particular) large deviations from the target value of 50ppm @ 1064nm p-pol.

Do these look reasonable? 


Attachment 1: PR3_R_170313_1701.pdf
Attachment 2: PR3AR_123_Layers_170313_1701.pdf
Attachment 3: PR3AR_R_170313_1752.pdf
Attachment 4: PR3AR_123_Layers_170313_1752.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
  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
Recycling_Mirrors_Specs_Nov2016.pdf Recycling_Mirrors_Specs_Nov2016.pdf Recycling_Mirrors_Specs_Nov2016.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
  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.


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

Attachment 1: circuit.pdf
  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
  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
  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

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

  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.

  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. 


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


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

  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.

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




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.

  4245   Thu Feb 3 16:08:06 2011 AidanUpdateComputer Scripts / ProgramsRCG VCO frequency error

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

 Here's the code I used:

dt = 1/16384;

diffList = [];
% set the frequencies

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

% plot the results

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

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

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

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

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

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

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

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

Things we tried, none of which worked:

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

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

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

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

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

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

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

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

The code now compiles and sees the digital output card.

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

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

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

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

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

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

There were a couple of gotchas:

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

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


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

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

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

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


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

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


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

I submitted a bug report for this:


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

We need to upgrade.

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

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

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

Peter and Koji,

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

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

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

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

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

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

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

Koji, Pete 

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

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

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

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

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

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

Koji, Peter


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


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

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

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

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

Pete, Koji


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

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

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

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

+ work some reflective memory magic and create the hybrid frontend


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

+ MEDM screen design

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

+ make game plan for the rest of the RCG frontend

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

Koji, Pete


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

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

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

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

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

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

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

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

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

Attachment 1: mdcmdpyaw.jpg
ELOG V3.1.3-