40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m elog, Page 133 of 357  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  12497   Thu Sep 15 18:37:20 2016 LydiaUpdateSUSDiagonalization

[Teng, Lydia]

  • We fixed the 60Hz filter on ITMY. This improved the phase problems somewhat but one coil (UL) is still about 12 degrees out of phase compared to the others for all the dofs. Is there some other place where a filter coule be applied to just one coil sensor? I pressed the "Load coefficients" button for UL, so maybe that will have helped.
  • We want to interpret the coil signals to have an accurate measurement of each dof. This means what the input matrix should describe is the dependence of each dof on the OSEM signals, which is found by inverting the matrix which describes the sensitivity of each OSEM to changes in that degree of freedom.
    • We looked at the spectra of the individual coils for ITMY and ETMY (See attachment 1 & 2). The coupling between some coils and applicable resonance peaks is very weak (~0.1 times the sensitivity of the other coils).
    • However, when a certain degree of freedom, e.g. pitch, is deliberately driven using awggui, the response of the ITMY coils is clear on the StripTool and is about the same magnitude for all of the face OSEMS. So, it seems like the diagonalization script does not always succeed at measuring the relative sensitivity of the OSEMs to the degrees of freedom.
    • This may be because the fundamental swing modes experienced by the free swinging pendulum are not the same as what we measure as pitch, yaw, etc. This could be possible if the wire tension is not the same on both sides. For ITMY, the spectra imply that the funamdental frequencies are actually at some linear combinations of pitch and yaw, swinging about a diagonal axis that results in a much weaker response for some of the OSEMS. Calling these peaks pitch and yaw may be inaccurate. Certainly they do not indicate the true relative sensitivity of the coils.
    • We propose an alternate approach to measuring this sensitivity: drive one dof at a time with awggui, take a spectrum (less resolution is ok because we already know the drive frequency), and measure the sensing matrix values for that dof the same way as before, but using a spectral peak that decribes motion that we know is purely pitch. Repeat this for all 4 dofs that we can actuate on, then compile these results into a sensing matrix and take the inverse.
Attachment 1: ETMY_osemspec.png
ETMY_osemspec.png
Attachment 2: ITMY_osemspec.png
ITMY_osemspec.png
  12499   Fri Sep 16 19:14:27 2016 LydiaUpdateSUSDiagonalization

[Lydia, Teng]

We built matrices for ITMY and ETMY by driving one degree of freedom at a time with awggui, while the damping was on. These have been applied to the damping loops.

  • Each segment of data is 1000s long and each dof was driven at 0.25 Hz.
  • These matrices are much closer to the ideal matrix and have no wrong signs. We believe they represent the relative sensitivity of the OSEMs to the degrees of freedom much more accurately. This is because the free swinging modes are not actually pitch, yaw, etc, but some linear combination of these. However, the damping actuates on pitch, yaw, etc. So we should isolate the degrees of freedom by driving them one at a time instead of just looking at free swinging peaks.
    • Attachment 1: An example of the dof spectra, calculated using the default input matrix, when ETMY YAW was driven at 0.25 Hz.
    • Attachment 2: The same OSEM sensor data, with the dofs calculated using the matrix found from this data. There is still a significant peak in pitch, but the other dofs are significantly suppressed.
    • Attahcment 3: The same data again, but the dofs are measured with the input matrix calculated by the free swinging data. This achieves much less suppression than the new matrix. Obviously this is not exactly a fair comparison because the new matrix was generated with this data, but the method of measuring OSEM responses by driving peaks has a much close relationship between what it measured (the OSEM response), and how the matrix is used (by damping loops which drive the coils in much the same way as awggui).
  • The phase problems seem to be mostly solved. Both Y arm test masses have some phase warnings, but they mostly occur with side. This can happen because the ideal matrix elements are 0, so the real parts are small. If there is no strong coupling then there is no reason to expect the background spectrum to be in phase with the peak. Other phase differences are small; most less than 5 degrees, a couple between 5 and 10 degrees. This may still merit further investiagtion.
  • Comparing the damping results for ITMY with the old (based on free swinging data) and new (based on driven data), we see the 1Hz peak suppressed by ~35% and the noise above 1Hz generally suppressed by ~25-30% . There is, however, significantly more movement between 0.5 and 1 Hz, maybe because the fundamental physical modes are not being directly measured and suppressed. Overall this seems like an improvement.

GPS times:

ITMY

Pitch:1158085097 Yaw: 1158086537 Pos: 1158089237 Side: 1158087977

ETMY

Pitch: 1158095897 Yaw: 1158097577 Pos: 1158099377 Side: 1158100817

Attachment 1: ETMY_yawdrivedefault.png
ETMY_yawdrivedefault.png
Attachment 2: ETMY_yawdrivenew.png
ETMY_yawdrivenew.png
Attachment 3: ETMY_yawdriveold.png
ETMY_yawdriveold.png
Attachment 4: 57.png
57.png
  12500   Fri Sep 16 19:48:52 2016 LydiaUpdateGeneralAlignment status

Today the Y arm was locking fine. The alignment had drifted somewhat so I ran the dither and TRY returned to ~0.8. However, the mode cleaner has been somewhat unstable. It locked many times but usually for only a few minutes. Maybe the alignment or autolocker needs to be adjusted, but I didn't change anything other than playing with the gain sliders (which didn't seem to make it either better or worse).

ITMX is still stuck.

  12502   Sat Sep 17 16:51:01 2016 LydiaUpdateSUSAlignment status

Here's the timeseries plots. I've zoomed in to right after the problem- did you want before? We pretty much know what happened: c1susaux was restarted from the crate but the damping was on, so as soon as the machine came back online the damping loops sent a huge signal to the coils. (Also, it seems to be down again. Now we know what to do first before keying the crate.) It seems like both right side magnets are stuck, and this could probably be fixed by moving the yaw slider. Steve advised that we wait for an experienced hand to do so. 

Quote:

All is not lost. I've stuck and unstuck optics around a half dozen times. Can you please post the zoomed in time series (not trend) from around the time it got stuck? Sometimes the bias sliders have to be toggles to make the bias correct. From the OSEM trend it seems like it got a large Yaw bias. May also try to reseat the satellite box cables and the cable from the coil driver to the cable breakout board in the back of the rack.

 

Attachment 1: Screenshot_from_2016-09-17_16-45-00.png
Screenshot_from_2016-09-17_16-45-00.png
  12513   Thu Sep 22 20:01:47 2016 LydiaUpdateGeneralITMX freed, all optics kicked

Rana came by and freed ITMX again. I think it shouldn't be a problem for me to free it if it happens again. 

In hopes of getting better SNR on the free swing spectra, we kicked all optics at around 7pm. The damping should come back on a little after midnight. ITMX did not get stuck after this kick. 

  12514   Thu Sep 22 20:18:27 2016 LydiaUpdateGeneralAcromag Progress

We moved the Acromag and its power supply to the X end, where we connected it to the diagnostic output of the NPRO controller. We renamed the channels to be descriptive of the pin outputs as described in the laser manual. We were able to recover readouts similar to those we found with a multimeter. 

We should figure out how to set up the channels on the front end machines: right now they are accessed through a tmux session running on pianosa. Once we are confident in the operation, we will make a box to contain the Acromag and wire connections and move the setup to connect to the PSL controller. 

  12518   Mon Sep 26 19:48:09 2016 LydiaUpdateSUSITMX stuck again, ITMY whitening issue

This afternoon around 2:45, ITMX started ringing up at ~.9Hz for about a minute and then got stuck again. When I noticed this evening, I tried to free it with the alignment sliders but was unable to see any signal on UL or UR. It also looks like the damping for ITMY was turned off at the same time ITMX got stuck (not at the start of its ring up). SRM also has a spike in its motion at this time, and another one minute later that ended up with the LR OSEM at a much higher level, though the mirror does not appear to be stuck. We didn't see any strange behavior from any of the other optics.

Teng and I were working on diagnosing a problem with the ITMY UL whitening, but by the time we disconnected any applicable cables, the damping for ITMY was already off. Later we unplugged the ITMX PD whitening cables after verifying that the ITMX damping was also already off. This problem may have occured earlier, while Teng, Eric, and I were examining and pushing in the cables at 1X5 without unplugging anything.

We found that the reason for the bad phase on the ITMY free swing data is because the whitening filter for UL is not being properly turned on. We are in the process of investigating the source of this problem. Right now all the cables to the PD whitening boxes in 1X5 are switched between ITMY and ITMX.
 

Attachment 1: 44.png
44.png
Attachment 2: 26.png
26.png
  12520   Tue Sep 27 18:04:50 2016 LydiaUpdateSUSITMX slow channels down, ITMY diagonalization update

[Teng, Lydia]

When we plugged in the back cables yesterday on the whitening boxes after switching them, two of the ITMX PDMon channels (UR and LR) got stuck at 0. This caused me to believe ITMX was still stuck even when it was freed. However, it was left in a stuck state overnight and freed again today after this issue was discovered. The alignment sliders have been set to 0 as a safety net to keep ITMX from getting stuck again if c1susaux is restarted again. We switched the cables back and the problem was still there.

The ITMY UL whitening filter problem, which the cables were originally switched to diagnose, was also still there. Ericq suggested we turn off all the whitening filters in order to get diagonalization data that would not show a phase difference between coils. We ran the diagonalization again with all the dewhitening filters off and got much cleaner results, with no visible cross-coupling peaks remaining between the degrees of freedom (see attachemnt 1). We did not apply this matrix to the damping, however, because there are elements which have the wrong sign compared to the ideal matrix. Significant adjustments to the output matrix will probably need to be made if this result is to be used. We also verified that the phase problem had been solved in DTT, where we saw the same sign discrepancies as in the matrix below. 

Damping can be turned back on, using the old, non-diagonalized matrix currently in effect. There is enough free swing data to diagonalize ITMY now, so feel free to mess with it. 

Matrix (wrong signs red, suspiciously small elements orange):

           pit     yaw     pos         side    butt
UL    1.633   0.138   1.224   0.136   0.984  
UR   -0.202  -1.768   1.179   0.132  -1.028  
LR   -2.000   0.094   0.776   0.107   1.001  
LL   -0.165   2.000   0.821   0.111  -0.987  
SD    0.900   1.131  -1.708   1.000  -0.107  

 

Attachment 1: ITMY_diagsuccess.pdf
ITMY_diagsuccess.pdf
  12523   Thu Sep 29 16:19:29 2016 LydiaUpdateSUSFree swing eigenmodes

[Lydia, Teng]

Motivated by the strange pitch/yaw coupling behavior we ran into while doing diagonalization, we looked at the oplev pitch and yaw free swing spectra for all 4 test masses (see attachment 1). We saw the same behavior there: At the peak frequencies for the angular degress of freedom, the oplevs saw significant contributions from both pitch and yaw. We also examined the phase between pitch and yaw at these peaks and found that consistently, pitch and yaw were in phase at one of the resonance frequencies and out of phase at the other (ignoring the pos and side peaks). 

This corresponds physically to angular motion about some axis that is diagonal, ie not perfectly vertical or horizontal. If we trust the oplev calibration, and Eric says that we do, then the angle of this axis of rotation with the horizontal (pitch axis) is

 \theta = \arctan \frac{Y\left ( f_{peak} \right )}{P\left ( f_{peak} \right )}  

Where Y and P are yaw and pitch ASD values. This will always give an angle between 0 and 90 degrees; which quadrant the axis of rotation occupies can be dermined by looking at the phase between pitch and yaw at the same frequencies. 0 phase means that the axis of rotation lies somewhere less than 90 degrees counterclockwise from the horizontal as viewed from the AR face of the optic, and a phase of 180 degrees means the axis is clockwise from horizontal (see attachment 2). Qualitatively, these features show up the same way for segments of data taken at different times. In order to get some quantitative sense of the error in these angles, we found them using spectrogram values with a bandwidth of 0.02 Hz averaged over 4000 seconds. 

Results (all numbers in degrees unless otherwise specified):

ITMY
peak 1 ( 0.692  Hz):
mean: 24.991
std: 1.23576
ptich/yaw phase: -179.181
peak 2 ( 0.736  Hz):
mean: 21.7593
std: 0.575193
pitch/yaw phase: 0.0123677

 

ITMX
peak 1 ( 0.502  Hz):
mean: 17.4542
std: 0.745867
ptich/yaw phase: -179.471
peak 2 ( 0.688  Hz):
mean: 74.822
std: 0.455678
pitch/yaw phase: -0.43991

 

ETMX
peak 1 ( 0.73  Hz):
mean: 43.1952
std: 1.54336
ptich/yaw phase: -0.227034
peak 2 ( 0.85  Hz):
mean: 60.7117
std: 0.29474
pitch/yaw phase: -179.856

ETMY
peak 1 ( 0.724  Hz):
mean: 78.2868
std: 2.18966
ptich/yaw phase: 6.03312
peak 2 ( 0.844  Hz):
mean: 26.0415
std: 2.10249
pitch/yaw phase: -176.838

ETMY and ITMX both show a more significant (~4x) contribution from pitch on one peak, and from yaw on the other. This is reflected in the fact that they each have one angle somewhat close to 0 (below 30 degrees) and one close to 90 (above 60 degrees). The other two test masses don't follow this rule, meaning that the 2 angular frequency peaks do not correspond to pitch and yaw straightforwardly. 

Also, besides ITMX, the axes of rotation are at least several degrees away from being perpendicular to each other. 

 

Attachment 1: 05.png
05.png
Attachment 2: SUS_eigenmodes.png
SUS_eigenmodes.png
  12536   Thu Oct 6 15:42:51 2016 LydiaUpdateSUSOutput matrix diagonalization

Summary: At the 40m meeting yesterday, Eric Q. gave the suggestion that we accept the input matrix weirdness and adjust the output matrix by driving each coil individually so that it refers to the same degrees of freedom. After testing this strategy, I don't think it will work. 

Yesterday evening I tested this idea by driving one ITMY coil at a time, and measuring the response of each of the free swing modes at the drive frequency. I followed more or less the same procedure as the standard diagonalization: responses to each of the possible stimuli are compared to build a matrix, which is inverted to describe the responses given the stimuli. For the input matrix, the sensor readings are the responses and the free swing peaks are the stimuli. For the output matrix, the sensors transformed by the diagonalized input matrix as the responses of the dofs which are compared, and the drive frequency peak associated with a coil output is the stimulus. However, the normalization still happens to each dof independently, not to each coil independently. 

The output matrix I got had good agreement with the ITMY input matrix in the previous elog: for each dof/osem the elements had the same sign in both input and output matrices, so there are no positive feedback loops. The relative magnitude of the elements also corresponded well within rows of the input matrix. So the input and output matrices, while radically different from the ideal, were consistent with each other and referred to the same dof basis. So, I applied these new matrices (both input and output) to the damping loops to test whether this approach would work. 

drive-generated output matrix: 

      UL      UR      LR       LL      SD
pit    1.701  -0.188  -2.000  -0.111   0.452  
yaw    0.219  -1.424   0.356   2.000   0.370  
pos    1.260   1.097   0.740   0.903  -0.763  
sid    0.348   0.511   0.416   0.252   1.000  
but    0.988  -1.052   0.978  -0.981   0.060

However, when Gautam attempted to lock the Y arm, we noticed that this change significantly impacted alignment. The alignment biases were adjusted accordingly and the arm was locking. But when the dither was run, the lock was consistently destroyed. This indicates that the dither alignment signals pass through the SUS screen output matrix. If the output matrix pitch and yaw columns refer instead to the free swing eigenmodes, anything that uses the output matrix and attempts to align pitch and yaw will fail. So, the ITMY matrices were restored to their previous values: a close to ideal input matrix and naive output matrix. We could try to change everything that is affected by the output matrices to be independent of a transformation to the free swing dof basis, and then implement this strategy. But to me, that seems like an unneccessary amount of changes with unpredictable consequences in order to fix something that isn't really broken. The damping works fine, maybe even better, when the input matrix is set by the output matrix: we define pitch, for example, to be "The mode of motion produced by a signal to the coils proportional to the pitch row of the naieve output matrix," and the same for the other dofs. Then you can drive one of these "idealized" dofs at a time and measure the sensor responses to find the input matrix. (That is how the input matrix currently in use for ITMY was found, and it seems to work well.) 

 

  12554   Wed Oct 12 18:09:25 2016 LydiaUpdateGeneralAcromag Progress

[Lydia, Johannes]

Johannes acquired a crate to contain the Acromag setup and wiring, and installed a rail along the bottom panel so that the ADC units will be oriented vertically with the ehternet ports facing up. We briefly talkes about what the layout should be, and are thinking of using 2 rails, one for ADCs and one for DACs. We want to design a generic front panel to accept 25 pin D-Sub inputs and maybe also BNCs, which we can use for all the Acromag crates. 

I got the epics session for the acromag to run on c1iscex and was able to access the channel values using caget on donatella. However, I get the following warning: 

cas warning: Using dynamically assigned TCP port 48154,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)

 

It seems like there might be a way to assign a port for each unit, if this is a problem. 

Also, c1iscex doens't have tmux; what's the best way to run the modbusApp and then detach? Right now I just left an epics session running in an open terminal. 

Plans:

  • Deisgn crate connections and interior layout. Set up front panel to accept desired connections. 
  • Set up the crate with the Acromag XT1221 reading the diagnostic info from the X end NPRO in the X end rack.
  • Figure out how many of each type we need to replace c1auxex functionality, and order them.
  • Generate appropriate EPICS db files for acromag based on slow machine channels.
  • Add necessary units to X end Acromag crate and read in the same inputs as c1auxex. 
  • Set up everything else to look for c1auxex channels from Acromag instead. (Not sure about nuances of this step: should we name the channels something different at first? How to find everything that relies on c1auxex? Must be careful with SUS channel connections.)
  •  Determine number of units needed to replace all slow machines, and order thm. Likewise assemble as many crates as necessary with the right connections. 
  • Once we are confident that the replacement is complete and fully functional, disconnect c1auxex and repeat process for other slow machines. 
  12598   Thu Nov 3 16:30:42 2016 LydiaConfigurationSUSETMX to coil matrix expanded

[ericq, lydia]

Background: 

We believe the optimal OSEM damping would use an input matrix diagonalized to the free swing modes of the optic, and an output matrix which drives the coils appropriately to damp these free swing modes. As was discovered, a free swinging optic does not necessarily have eigenmodes that match up perfectly with pitch and yaw, however in the current state the "TO_COIL"  output matrix that determines the drive signals in response to the diagonlized sensor output also controls the drive signals for the oplevs, LSC/ASC, and alignment biases. So attempts to diagonalize the output matrix to agree with the input matrix have resulted in problems elsewhere. (See previous elog). So, we want to expand the "TO_COIL" matrices to treat the OSEM sensor inputs separately from the others.

Today:

  • We modified the ETMX suspension model (c1scx) to use a modified copy of the sus_single_control block (sus_single_control_mod) that has 3 additional input columns. These are for the sensing modes determined by the input matrix, and are labeled "MODAL POS", "MODAL PIT", and "MODAL YAW." 
    • The regular POS, PIT, and YAW columns no longer include the diagonalized OSEM sensor signals for ETMX.
    • The suspension screen now out of date; it doesn't show the new columns under Output Filters and the summed values displayed for each damping loop do not incluse the OSEM damping.
  • The new matrix can be acessed at /opt/rtcds/caltech/c1/medm/c1scx/C1SUS_ETMX_TO_COIL.adl (see Attachment 1). For now, it has the naive values in the new columns so the damping behavior is the same. 
  • In trying to get a properly generated MEDM screen for the larger matrix, we discovered that the Simulink block for TO_COIL specifies in its description a custom template for the medm autogeneration. We made a new verion of that template with extra columns and new labels, which can be reused for the other suspensions. These templates are in /opt/rtcds/userapps/release/sus/c1/medm/templates, the new one is SUS_TO_COIL_MTRX_EXTRA.adl
  • I will be setting the new column values to ones that represent the diagonlized free swing modes given by the input matrix. Hopefully this will improve OSEM damping without getting in the way of anything else. If this works well, the other SUS models can be changed the same way. 
Attachment 1: 01.png
01.png
  12599   Fri Nov 4 18:31:05 2016 LydiaUpdateCDSc1auxex channels/pins for Acromag

Here are the channels we are planning to switch over from c1auxex to Acromag, and their current pin numbers on the existing VME boards. 

Analog inputs: 

C1:SUS-ETMX_UL_AIOut    #C0 S0
C1:SUS-ETMX_LL_AIOut    #C0 S1
C1:SUS-ETMX_UR_AIOut    #C0 S2
C1:SUS-ETMX_LR_AIOut    #C0 S3
C1:SUS-ETMX_Side_AIOut    #C0 S4
C1:SUS-ETMX_OL_SEG1    #C0 S5
C1:SUS-ETMX_OL_SEG2    #C0 S6
C1:SUS-ETMX_OL_SEG3    #C0 S7
C1:SUS-ETMX_OL_SEG4    #C0 S8
C1:SUS-ETMX_OL_X    #C0 S9
C1:SUS-ETMX_OL_Y    #C0 S10
C1:SUS-ETMX_OL_S    #C0 S11
C1:SUS-ETMX_ULPD    #C0 S12
C1:SUS-ETMX_LLPD    #C0 S13
C1:SUS-ETMX_URPD    #C0 S14
C1:SUS-ETMX_LRPD    #C0 S15
C1:SUS-ETMX_SPD    #C0 S16
C1:SUS-ETMX_ULV    #C0 S17
C1:SUS-ETMX_LLV    #C0 S18
C1:SUS-ETMX_URV    #C0 S19
C1:SUS-ETMX_LRV    #C0 S20
C1:SUS-ETMX_SideV    #C0 S21
C1:SUS-ETMX_ULPD_MEAN    #C0 S12
C1:SUS-ETMX_LLPD_MEAN    #C0 S13
C1:SUS-ETMX_SDPD_MEAN    #C0 S16

Analog Outputs:

C1:ASC-QPDX_S1WhiteGain    #C0 S0
C1:ASC-QPDX_S2WhiteGain    #C0 S1
C1:ASC-QPDX_S3WhiteGain    #C0 S2
C1:ASC-QPDX_S4WhiteGain    #C0 S3
C1:SUS-ETMX_ULBiasAdj    #C0 S4
C1:SUS-ETMX_LLBiasAdj    #C0 S5
C1:SUS-ETMX_URBiasAdj    #C0 S6
C1:SUS-ETMX_LRBiasAdj    #C0 S7
C1:LSC-EX_GREENLASER_TEMP    #C0 S0 This appears to have the same pin as another channel-- is it not being used? 

Binary Outputs:

C1:SUS-ETMX_UL_ENABLE    #C0 S0
C1:SUS-ETMX_LL_ENABLE    #C0 S1
C1:SUS-ETMX_UR_ENABLE    #C0 S2
C1:SUS-ETMX_LR_ENABLE    #C0 S3
C1:SUS-ETMX_SD_ENABLE    #C0 S4
C1:ASC-QPDX_GainSwitch1    #C0 S7
C1:ASC-QPDX_GainSwitch2    #C0 S8
C1:ASC-QPDX_GainSwitch3    #C0 S9
C1:ASC-QPDX_GainSwitch4    #C0 S10
C1:AUX-GREEN_X_Shutter2    #C0 S15

  12607   Tue Nov 8 17:51:09 2016 LydiaUpdateCDSacromag chassis hooked up to PSL

We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.

  12612   Sun Nov 13 23:42:43 2016 LydiaUpdateSUSETMX output matrix data

I took data of the ETMX SUSPOS, SUSPIT and SUSYAW channels while driving each of the 4 face coils. I manually turned off all the damping except the side. 

Excitation: I used white noise bandpassed from 0.4 to 5 Hz in order to examine the responses around the resonance frequencies. To avoid ringing things up too much, I started with a very weak drive signal and gradually increased it until it seemed to have an effect on the mirror motion by looking at the oplev signals/sensor RMS values on the SUS screen; it's possible I'll need to do it again with a stronger signal if there's not enough coherence in the data. 

Finding the matrix: The plan is to estimate the transfer function of the coil drive signal with the sensed degrees of freedom (specified by the already diagonalized input matrix). This transfer function can be averaged around the resonance peak for each dof to find the elements of the matrix that converts signals to dof responses, (the "response matrix", which is the inverse of the output matrix). Each column of the response matrix gets normalized so that the degrees of freedom influence the drive signals in the right ratio. 

Other notes: 

  • I had some trouble getting the awg python library to work: I had to manually edit a CDLL statement to use the absolute path of an .so file. I wasn't sure what environment variable to set to make it look in the right folder automatically.
  • The awg ArbitraryLoop object seems to be affected by cds getdata calls (The EXC signal stopes early and then stop() hangs) so I ended up doing the excitation and data reading in 2 separate scripts. 
  • Reminder that the watchdogs must be on "Normal" for the EXC signal to make it to the coils, so the damping must be turned off manually with the watchdogs still on if you want to drive without damping. 
  12649   Wed Nov 30 11:56:56 2016 LydiaUpdateCDSWiring for Acromag auxex replacement

I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

  • We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
  • The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
  • There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
  • All the other backplane cables go the the fast machines only. 

 

Attachment 1: auxex_acromag.pdf
auxex_acromag.pdf
  12677   Wed Dec 14 19:16:57 2016 LydiaUpdateCDSAcromag Binary I/O testing

I looked into converting the QPD whitening switches for the X end to Acromag.

  • To test this out and be able to freely toggle filters without messing anything up, I added a temporary dummy cdsFiltCtrl module (ACROMAG_BIO_TEST) to the c1scx model.
  • The filters can be toggled from the automatically generated medm screen medm/c1scx/C1SCX_ACROMAG_BIO_TEST.adl
  • The control output of the dummy filter bank is sent to a channel named C1:SCX-ACROMAG_SWCTRL.
  • I was able to read in the appropriate bits from there and send them to the appropriate acromag channel using a calcout channel.
    • I couldn't get individual bo channels to work. This Acromag module is configured to write to 4 channels at a time, so I set that up with an analog output channel. The calcout channel shifts each relevant bit from C1:SCX-ACROMAG_SWCTRL to the right place for writing to the Acromag. 
  • I connected the Acromag XT1111 Binary I/O unit to a temporary power supply and verified that toggling the filters on and off changed the output appropriately. This is a sinking output model so the output pin is connected to the return if the switch is on. 

The plan from here:

  • Determine how to configure these outputs to be compatible with the QPD whitening board.
  • Modify the SUS PD whitening board to always use the analog filter and remove digital option in models.
  • Test DACs 
  • Verify that the QPD whitening gain switches aren't doing anything
  • Assemble new Acromag box for X end and connect to QPD whitening, SUS PD whitening and SOS driver boards
  12755   Wed Jan 25 15:41:29 2017 LydiaUpdateIMC29.5 MHz modulation depth measurement plan

[Lydia, gautam]

To measure the modulation depth of the 29.5 MHz sideband, we plan to connect a bidirectional coupler between the EOM and the triple resonant circuit box. This will let us measure the power going into the EOM and the power in the reflection. According to the manual for the EOM (Newport 4064), the modulation depth is 13 mrad/V at a wavelength of 1000 nm. Before disconnecting these we will turn off the Marconi.

Hopefully we can be gentle enough that the EOM can be realigned without too much trouble. Before touching anything we'll measure the beam power before and after the EOM so we know what to match after.

If anyone has an objection to this plan, speak now or we will proceed tomorrow morning.

  12762   Fri Jan 27 17:07:52 2017 LydiaUpdateCDSslow machine bootfest

Rebooted c1iscaux, c1auxex and c1auxey which were all not reponding to telnet. The watchdogs for the ETMs were turned off and then I keyed all 3 crates. All slow machines are reponding to telnet now. Both green lasers locked to the arms so I didn't do any burt restore.

  12767   Fri Jan 27 21:25:11 2017 LydiaUpdateIMC29.5 MHz modulation depth

[gautam, Lydia]

We set out to measure the 29.5 MHz power going to the EOM today but decided to start by looking at the output of the RF AM stabilizer box first. We wanted to measure the AM noise with a mixer, so we needed to know the power it was giving. We looked at the ouput that goes to the power combiner on the PSL table and found it was putting out only -2.0 dBm (~0.5 Vpp)! This was measured by taking a spectrum with the AG4395 and confirmed by looking on a scope.

To find out if this could be adjusted, we found an old MEDM screen (/opt/rtcds/caltech/c1/medm/c1lsc/master/C1LSC_RFADJUST.adl) and moved the 29.5 MHz EOM Mod Index Adjust slider while measuring the voltage coming in to the MOD CONTOL connection on the front of the AM stabilizer box. Moving the slider from 0 to 10 changes the input voltage linearly from -10 V to 10 V measured with a DMM at the cross-connects as we couldn't find an appropriate adapter for the LEMO cable. The 29.5 MHz modulation only appeared for slider values between 0 and 5, after which it abruptly shuts off. However, changing the slider value between 0 and 5 (Voltage from -10 to 0) does not change the amplitude of the output.

This seems like a problem; further investigation into the AM stabilizer box is neccessary. This DCC document outlines how to test the box, but we can't find a schematic. Since we don't have any mixers that can handle signals as small as -2 dBm, we gave up trying to measure the AM noise and will attempt to measure that and the reflection power from the EOM + resonant circuit once this problem has been diagnosed and fixed.

GV: After some digging, I found the schematic for the RF AM stabilization box (updated wiki and added it to the 40m document tree). According to it, there should be up to +22dBm of RF AM stabilized output to the EOM available, though we measured -2dBm yesterday, and could not vary this level by adjusting the EPICS voltage value. Neglecting losses in the cabling and the power combiner on the PSL, this translates to a paltry 0.178Vrms*0.6*8mard/Vrms ~ 0.85 mrad of modulation depth (gain at 29.5 MHz of the triple resonant circuit taken from this elog)... I think we need to pull this 1U chassis out and debug more thoroughly...

 

  12772   Tue Jan 31 01:07:20 2017 LydiaUpdateIMCRF AM stabilization box pulled out

[gautam, Lydia]

We looked at the RF AM stabilizer box to see if we could find out 1) Why the output power is so low, and 2) Why it can't be changed with the DC input "MOD CONT IN." Details to follow, attached is the annotated schematic from DCC document D000037

We are not returning the box tonight so the PSL shutter remains closed. 

Attachment 1: AM_stablilizer_annotation.pdf
AM_stablilizer_annotation.pdf
  12782   Tue Jan 31 22:28:39 2017 LydiaUpdateIMCRF AM stabilization box pulled out

[rana, gautam, lydia]

Today we looked at the schematics for the RF AM stabilizer box and decided that there were an unnecessary amount of attenuators and amplifiers cancelling each other out and adding noise. At the end of the path are 2 HELA-10D amplifiers which we guessed based on the plots for the B version would have an acceptable amount of compression if the output of the second one is ~27dBm. This means the input to the first one should be a few dBm. This should be achieved with as simple a path as possible.

This begged the question, do we need the amplitude to be stabilized at all? Maybe it's good enough already when it comes into this box from the RF distribution box. So I tried to measure the AM noise of the 29.5 MHz signal that usually goes into the AM stabilizer:

  • I first measured the power to be 12.8 dBm with the AG4395.
  • I sent the signal through a splitter, then sent one side attenuated by 3 dB to the LO side of a level 7 mixer, and the other side attenuated by 10 dB to the RF side of the mixer.
  • The output of the mixer went through a lowpass filter at 1.9 MHz (with a 50Ω inline terminator). Initially I connected this directly to a DAQ channel (C1:ALS-FC_X_F_IN), but the ADC noise was stronger than the AM signal.
  • To fix this I used the SR560, AC coupled with a gain of 10^4. Attachment 1 is a spectrum of the noise measured with everything connected as described, and also for separate portions of the signal chain:
    • I measured the ADC noise by connecting a terminator to the cable going to DAQ.
    • I measured the mixer noise by putting a terminator on the RF input (and the end of the cable that was connected to it), while still driving LO.
    • I measured the SR560 noise by putting a terminator on the input.

It seems like I'm getting mostly noise from the SR560. Maybe it would be better to use an SR785 to take data instead of DAQ, and then skip the SR560? At low frequencies it seems like the AM noise measurement may be actually meaningful. In any case, if the actual AM noise from the crystal is lower than any of these other noise sources, it means we probably don't need to stabilize the amplitude with a servo, which means we can simplify the AM stabilizer board considerably to just amplify what it gets to 27 dBm.

Attachment 1: AM_noise.pdf
AM_noise.pdf
  12784   Wed Feb 1 16:45:56 2017 LydiaUpdateIMCRF AM stabilizer box Modification Plan

Here's what I'm planning to do to the RF AM stabilizer box. I'm going to take out several of the components along the path to the EOM (comments in green), including the dead ERA-4 and ERA-5 amplifiers, the variable attenuator which is controlled by a switch that can't be accessed outside the box, and the feedback path from the daughter board servo. I'm arranging things so that the output of the HELA-10 does not exceed the maximum output power. 

I wasn't quite as sure what to do about the path to the ASC box (comments in blue). I talked with Gautam and he said this gets split equally between several singals, one of which goes to the LO of the demod board which expects -10 dBm and currently gets -12 dBm (can go up to -8 by turning switch). So maybe we don't actually want the signal to be anywhere near +27 dBm at the output. The plans for the box are here, it looks like +27 in will end up with +10 at each output, which is way more than what's currently coming out. But maybe this needs to be increased to match the other path? 

Also we haven't measured the actual response of the variable attenuator U4 for various switch positions; it's the same model as the one I'm removing from the EOM path and that one had slightly different behavior for different switch positions than what the spec sheet says. Same goes for the HELA-10 units along this path: what is their actual gain? So perhaps these should be measured and then a single attenuator should be chosen to get the right output signal level. Alternatively it could just be left alone, if it is at an OK level right now. Advice on what to do here would be appreciated.  

I'll work on the EOM path tonight and wait for feedback on the rest of it. 

EDIT: Gautam pointed out that there's some insertion loss from the components I'll be removing that hasn't been accounted for. Also the plans have been updated to reflect that I'm replacing AT5 with a 1dB attenuator (from 6 dB). 

Attachment 1: RF_AM_stabilizer_modification.pdf
RF_AM_stabilizer_modification.pdf
  12786   Wed Feb 1 23:13:30 2017 LydiaUpdateIMCRF AM stabilizer box Modification Plan

I made some of the changes. Gautam and I will finish tomorrow. 

While I was soldering the sharpest tip of the soldering iron (the one whose power supply shows the temperature) stopped working and I switched to a different one. Not sure how to fix this. 

Do we want to replace all of the removed ERA's with 50 Ohm resistors, or just the one along the spare output path? I shorted one of them with a piece of wire and left all the others open. 

I couldn't get one of the attenuators off (AT1, at beginning of ASC path). In trying I messed up the solder pad. Part of the connecting trace on the PCB board is exposed so we should be able to fix it. 

  12801   Sun Feb 5 21:56:50 2017 LydiaUpdateIMC29.5 MHz stabilizer box replacement

Since the "stablizer box" doesn't really need to stabilize, it just needs to amplify, I decided to replace it with an off the shelf amplifier we already had, ZHL-2. I worked on getting it set up today, but didn't connect anything so that people have a chance to give some feedback. 

  • The gain we expect is 18 dB, and the maximum output with 1dB of compression is 29 dBm. To avoid compression, I'm aiming for ~26 dBm output, so ~8 dBm input. We measured the output of the source to be 12.8 dBm before, so I attached a 5dB attenuator to the input side of the amplifier. 
  • Across the 24V power input and the ground pin, I soldered a 100 uF, 50V electrolytic capacitor and a .27 uF, 50V metal film capacitor. Note that unlike the other similar amplifiers we have, the ground and +24 pins are separated (see image on datasheet). I wasn't sure if that changed what to do so I just found comparable caps to the ones that were there on another model. 
  • I twisted and soldered wires to the +24 and ground, making sure they were long enough to reach the clips where the power from the Sorensens gets split up. I placed the amplifer in the rack on top of the RF distribution box and ziptied the power cable in place. 
  • I connected a splitter to the output of the amplifier. Should I use a 10dB coupler instead, to maximize the power to the EOM?

So, I think the remaining thing to do is to connect the splitter to ASC out and to the line to the EOM, the +24V supply to the amplifier, and the 29.5 MHz input to the attenuator. I wanted to wait on this to get confiration that the setup is OK. Eventually we can put all of this in a box. 

Also, I noticed that in the clear cabinet with the Sorensens next to this rack, the +24 V unit is not supplying any voltage and has a red light that says "OVP." 

  12807   Tue Feb 7 12:01:10 2017 LydiaUpdateIMC29.5 MHz stabilizer box replacement

I tested the amplifier with the Agilent network analyzer and measured 19.5 dB of gain between 29 and 30 mHz. The phase only changed by 1 degree over this same 1 MHz span. Since everything seems to be in order I'll hook it up this afternoon, unless there are any objections

Attachment 1: RF_amp.pdf
RF_amp.pdf
  12809   Tue Feb 7 17:00:55 2017 LydiaUpdateIMC29.5 MHz stabilizer box replacement

I set everything up and connected it as shown on the block diagram attached to the previous entry, with the exception of the DC power. This is becuase there is no place open to connect to on the DIN rail where the DC power is distributed, so the +24V power will have to be shut off to the other equipment in 1X1 before we can connect the amplifier. (The amplifier is in 1X2, but the DC power distribution was more accessible in 1X1.) I also added 3 new +24 V clips with fuses despite needing only one, so next time we need to connect something new it's not such a hassle. 

The RF distribution box where the 29.5 MHz signal originates should not be turned on until the amplifer has DC power. Since we may have a power interruption tomorrow, the plan is to wait until things are shut down in preparation, and then shut off anyhting else necessary before connecting the new clips on the rail to the existing ones. 

  12817   Fri Feb 10 11:41:43 2017 LydiaUpdateIMC29.5 MHz stabilizer box replacement

To install the replacement amplifier, I did the following:

  • Mounted the amplifier in a 2U chassis, with a metal plate between the amplifier and the bottom of the box. The plate is separated from the box and the amplifier with 2 sets of Nylon screws. I did it this way to make use of the holes that were already in the chassis bottom and just drill holes into a plate instead. 
  • Cannibalized mounting brackets and back panel from old ALS Beatbox. The back panel has an on/off switch and a 3W3 feedthrough for power. 
  • Made a power cable to reach from the 1X1 fuse blocks to the back panel of my box. Goes up through the top of the rack and then back down. 
  • Installed the chassis in the rack. The lid is currently off and there is no front panel yet. 
  • Changed the +5dB attenuator to +30 to be able to check things first before supplying a way stronger signal. 
  • Installed 4 new +24 V fuse blocks on the adjacent rack (1X1). 
    • Put the new fuses on the DIN rail and wired them together. Connected the new power cable to one of them. 
    • Blocked PMC transmission and made sure all RF sources in 1X1 and 1X2 were turned off
    • Turned off the + 24 V and -24 V Sorensens, trying to keep them fairly balanced as I turned them to 0. 
    • At this point Rana suggested I turn off the other DC power supplies in the rack, which I did.
    • Connected the new fuse blocks to the existing +24 V ones. Note that they are not contiguous but they follow the color code and will be labeled. 
    • I'm only using one of the new +24 outputs, but I made more for future use to minimize the number of times we have to turn the power off. 
  • Connected the output of the amplifier to the EOM, and the coupled signal to the distribution box (which splits it and sends it to the demod boards). 
  • Turned on the power switch and checked that the amplifier was in fact getting 24 V. 
  • Connected the input from the 29.5 MHz source and measured the power coming from the amplifier. I measured -12 dBm instead of the expected ~0 dBm, but Gautam was able to see the expected power later, so maybe something just wasn't connected right.
  • Double checked the power coming into the amplifier, which was consistent with earlier measurements at about 12.8 dBm. 

 

Still to be done:

  • Label/relabel several things (fuse blocks, back panel, etc) 
  • Current label on +24 Sorensen needs to be updated
  • Order front panel and install
  • Install power indicator lights on front and back 
  • Readjust gains (analog and digital) to use full signal output and measure (hopefully) improved WFS performance
  • Insert bi-directional coupler and measure modulation depth and reflections from EOM
  12827   Mon Feb 13 19:44:55 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box

I made a tentative front panel design for the newly installed amplifier box. I used this chassis diagram to place the holes for attaching it. I just made the dimensions match the front of the chassis rather than extending out to the sides since the front panel doesn't need to screw into the rack; the chassis is mounted already with separate brackets. For the connector holes I used a caliper to measure the feedthroughs I'm planning to use and added ~.2 mm to every dimension for clearance, because the front panel designer didn't have their dimensions built in. Please let me know if I should do something else. 

The input and coupled output will be SMA connectors since they are only going to the units directly above and below this one. The main output to the EOM is the larger connector with better shielded cables. I also included a hole for a power indicator LED. 

EDIT: I added countersinks for 4-40 screws on all the screw clearance holes. 

Johannes, if you're going to be putting a front panel order in soon, please include this one. 

Also, Steve, I found a caliper in the drawer with a dead battery and the screws to access it were in bad shape- can this be fixed? 

 

Attachment 1: rfAmp.pdf
rfAmp.pdf
  12832   Wed Feb 15 22:21:12 2017 LydiaUpdateDAQpanels and pcbs

This is already how it's hooked up. The hole on the from that says +24 V is for an indicator light.

Quote:

The amplifier unit should use the three pin dsub connectors (3w3?) that we use on many of the other units for DC power, and preferably go through the back panel. You can leave out the negative pin, since you just need +24 and ground.

 

  12861   Wed Mar 1 21:15:40 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box


I installed the front panel today. While I had the box out I also replaced the fast decoupling capacitor witha 0.1 uF ceramic one. I made SMA cables to connect to the feedthroughs and amplifier, trying to keep the total lengths as close as possible to the cables that were there before to avoid destroying the demod phases Gautam had found. I didn't put in indicator lights in the interest of getting the mode cleaner operational again ASAP. 

I turned the RF sources back on and opened the PSL shutter. MC REFL was dark on the camera; people were taking pictures of the PD face today so I assume it just needs to be realigned before the mode cleaner can be locked again. 

I've attached a schematic for what's in the box, and labeled the box with a reference to this elog. 

Attachment 1: RF_amp_(1).pdf
RF_amp_(1).pdf
  12865   Thu Mar 2 20:32:18 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box

[gautam, lydia]

I pulled out the box and found the problem: the +24 V input to the amplifier was soldered messily and shorted to ground. So I resoldered it and tested the box on the bench (drove with Marconi and checked that the gain was correct on scope). This also blew the fuse where the +24 power is distributed, so I replaced it. The box is reinstalled and the mode cleaner is locking again with the WFS turned on.

Since I tried to keep the cable lengths the same, the demod phases shouldn't have changed significantly since the amplifier was first installed. Gautam and I checked this on a scope and made sure the PDH signals were all in the I quadrature. In the I vs. Q plot, we did also see large loops presumably corresponding to higher order mode flashes.

Quote:

Walking over to the 1X1, I noticed that the +24V Sorensen that should be pushing 2.9A of current when our new 29.5MHz amplifier is running, was displaying 2.4A. This suggests the amplifier is not being powered. I toggled the power switch at the back and noticed no difference in either the MC locking behaviour or the current draw from the Sorensen.

 

 

  12713   Fri Jan 13 14:33:00 2017 MAX (not Rana)UpdateSummary PagesDecember outage

PEM config file was also lacking a section named "summary", which is necessary for all parent tabs; this has now been solved. I have deactivated the MEDM pages because Praful's screencap script seemed to be broken (I should have logged this, I apologize).

Quote:

Pages still not working: PEM and MEDM blank.

  • Committed existing MEDM grabbing scripts to SVN. Ran the cron job on megatron by hand. It grabs PNG files, but somehow its not getting into the summary pages.
  • Changed the MEDM grabbing scripts to use '/usr/bin/env'.
  • GW summary log files were numbering in the many thousands, so I moved everything over 320 days old into the OLD/ sub-directory using 'find . -type f -mtime +320 -exec mv {} OLD/ \;' (the semi-colon is needed)
  • Did apt-get upgrade on Megatron.
  • pinged Max
  • Stared at GWsumm docs to see if there's a clue about what (if anything) is wrong with the .ini file.

 

  5760   Fri Oct 28 20:39:19 2011 MIrkoUpdateLSCRFAM monitor in place. ( Uncalibrated ) EPICS troubles

{Suresh, Jamie, Mirko]

We adapted the Stochmon box to include LP filters at 1.8Hz behind the RMS parts.
Then measured the RMS signals for different RF signal levels at 11.0.65, 29.5, 55.325MHz provided by a RF freq. generator.
As you can see in the data below the suppression of the BP filters of neighboring frequencies is only 35-35dB in power (see also manufacturer specs).

We therefor want to substract crosstalk, by calculating it out. We decided to use C-code in CDS. No computer crashing this time :)

We however ran into the problem that the RMS signal channels are acquired by the slow (EPICS) maschine c1iool0. Channels are (C1:IOO-RFAMPD_33MHZ , -"-133MHZ, -"-166MHZ) and we could not access those in the CDS c1ioo model. Using the EpicsIn block we got an CA.Exception stating that the variable was hosted on multiple servers. We then tried to use the EzcaRead to access the variables. Got an compile error, about the compiler not beeing able to connect all parts. It seems that the EzcaRead left behind a "ghost" part in the model (something with M1:SYS-FOO_BAR which is the default naming of the EzcaRead block) even after we deleted that block. We toyed around with the /opt/rtcds/caltech/c1/chans/daq/C1EDU_IOO.ini  and  /cvs/cds/caltech/target/c1iool0/ioo.db  files. We tried to uncomment the "old" (33,133,166) channels there to get rid of the conflict, but that didn't work.

We want to write the outputs to C1:IOO-RFAMPD_11MHZ , -"-29MHZ, -"-55MHZ EPICS channels.

We had to get the model back from the svn to get it running again.

Attachment 1: MC_DC11MHz.m
Pwr=[-60,-55,-50,-45,-40,-35,-30,-25,-20,-10,-5,0,5,10]';
Voltage11=[2.12,2.10,2.03,1.93,1.83,1.71,1.59,1.47,1.35,1.10,0.97,0.85,0.71,0.61]';

Voltage11=spline(Pwr,Voltage11,linspace(-60,10,15));
PwrSmooth=linspace(-60,10,15);

Voltage29=[2.14,2.14,2.14,2.14,2.14,2.14,2.13,2.12,2.09,1.94,1.84,1.73,1.61,1.49];
Voltage29=spline(Pwr,Voltage29,linspace(-60,10,15));

Voltage55=[2.16,2.16,2.16,2.16,2.16,2.16,2.16,2.15,2.14,2.13,2.10,2.04,1.94,1.83];
... 5 more lines ...
Attachment 2: MC_DC29MHz.m
Pwr=[-60,-55,-50,-45,-40,-35,-30,-25,-20,-15,-10,-5,0,5,10]';
Voltage11=[2.16,2.16,2.16,2.16,2.15,2.16,2.15,2.13,2.10,2.03,1.93,1.81,1.70,1.58,1.46]';

Voltage29=[2.12,2.10,2.03,1.93,1.83,1.70,1.59,1.47,1.34,1.22,1.09,0.97,0.84,0.71,0.61]';

Voltage55=[2.16,2.15,2.16,2.16,2.15,2.15,2.14,2.10,2.0,1.97,1.97,1.77,1.65,1.50,1.37]';

%%  Example 55MHz inj.

Voltage11=[2.00];
... 21 more lines ...
Attachment 3: MC_DC55MHz.m
Pwr=[-60,-55,-50,-45,-40,-35,-30,-25,-20,-15,-10,-5,0,5,10]';
Voltage11=[2.16,2.16,2.16,2.16,2.16,2.15,2.15,2.15,2.15,2.15,2.12,2.09,2.00,1.89,1.78]';

Voltage29=[2.14,2.14,2.14,2.13,2.14,2.13,2.11,2.06,1.98,1.88,1.76,1.64,1.52,1.40,1.27]';

Voltage55=[2.14,2.11,2.05,1.96,1.85,1.73,1.61,1.48,1.36,1.23,1.10,0.98,0.84,0.71,0.61]';

plot(Pwr,Voltage55)

%%
... 17 more lines ...
Attachment 4: RFAMPD.c
double x;
double y;
double z;

double temp1;
double temp2;

double Corrx;
double Corry;
double Corrz;
... 49 more lines ...
  5810   Fri Nov 4 14:18:24 2011 MIrkoUpdateAdaptive FilteringCoherence between seismometers and MC length

Looking into the coherence between the seismometers and IMC length (MC_F):

FIrst with the seismometers only AC filtered at around 0.003 Hz and AA30Hz:
Coherence_without_compensation.pngWith_Pend_compensation.mat

Ignore the increase in coherence at very low frequencies. That is an artefact.

Then with an additional filter single complex pole @1Hz Q=1000 (giving 20dB per decade in attenuation above 1Hz) , only for GUR1X:
Coherence_with_compensation.png

  5928   Thu Nov 17 17:03:28 2011 MIrkoUpdateIOOMC noise projection

Another go at the noise projection from MC1-3 pit/yaw to MC length. This time injecting into the MC autoalignment FB (e.g. C1:IOO-WFS1_PIT_EXC ).

LTPDA is working now, but still the NDS server is not so cooperative.

Summary: Alignment fluctuations of the MC mirrors don't significantly contribute to MC length changes up to at least 3.5Hz. Especially they can't explain the lack of coherence between seismometers and MC length below 1Hz that we worry about for the OAF.

At high frequencies >= 10Hz you can see angle to length coupling as is evident in Sureshes spot position measurements.

Whiteish noise injection:

Injection from 0.1-20Hz.Filtered by the servo filters and zp:[1],[1] , Gain = 1 @ 2Hz

 MCLengthToAngleCouplingNoiseProjection.png

Look at the coherence plots for the quality of the measurement:

Coherence_WFS1pit.png

Coherence_WFS2pit.png

 

Coherence_WFS1yaw.png

 Coherence_WFS2yaw.png

Injection details:

DOF      Amplitude[counts]        UTC Time (duration always 4mins)
WFS1p  70                               22:28
WFS1y  55                               22:03
WFS2p  70                               22:13
WFS2y  70                               22:18
None      -                                 22:23

Fixed sine injections:

To get some better SNR at low frequencies I did a fixed sine noise injection at 0.3Hz. See attached files.

DOF      Amplitude[counts]        UTC Time (duration always 4mins)    Lower limit of SNR MC length via mirror misalignment
WFS1p  4                                  00:05                                                29.3
WFS1y  4                                  00:14                                                22.0
WFS2p  4                                  00:19                                                18.5
WFS2y  4                                  00:25                                                18.0

Attachment 2: WFS1pit.png
WFS1pit.png
Attachment 3: WFS1yaw.png
WFS1yaw.png
Attachment 4: WFS2pit.png
WFS2pit.png
Attachment 5: WFS2yaw.png
WFS2yaw.png
Attachment 7: Coherence_WFS2pit.png
Coherence_WFS2pit.png
Attachment 11: NpWfs.pdf
NpWfs.pdf NpWfs.pdf NpWfs.pdf NpWfs.pdf NpWfs.pdf
  7090   Mon Aug 6 11:07:06 2012 ManasaUpdate40m UpgradingOptical layout updated

ACAD files of the 40m optical layout have been updated as per the vent in Aug 2011.

Files are available at the 40m svn docs-->Upgrade12-->Opt_Layout2011.

 

  7122   Wed Aug 8 19:54:06 2012 ManasaConfigurationIOOMC trans optics configured

Jan and I wanted to measure the ringdown at the IMC. Since the QPD at the MC trans is not fast enough for ringdown measurements, we decided to install a pickoff to include a faster PD while not disturbing much of the current MC trans configuration. The initial configuration had very little space to accommodate the pickoff. So the collimating lens along with the QPD were moved 2 inches closer to the incoming beam. A 50-50 BS was put in front of the QPD and the steering mirror was moved behind to reflect MC trans output to the new PD. The current configuration is shown below with the MC autolocker threshold mentioned in Jenne's elog

Pic1.png

The hunt for a faster PD wasn't satisfactory and we found a couple of PDs that were good for measurements actually didn't work after installing them. The one currently installed is also not satisfactorily fast enough for ringdown measurements. We'll hunt for faster PDs at Bridge tomorrow and replace PDA400. Also the IMC unlocked from time to time....may be we were noisy and didn't master the 'interferometer walk' very well.

 

 

  7125   Wed Aug 8 20:51:56 2012 ManasaUpdate40m UpgradingOptical layout updated

Quote:

ACAD files of the 40m optical layout have been updated as per the vent in Aug 2011.

Files are available at the 40m svn docs-->Upgrade12-->Opt_Layout2011.

 

 To ease the pain of hunting files, optical layout ACAD files have been moved to a new directory 40M_Optical Layout in the repository. Relevant files from directories Upgrade12 and upgrade 08 will be moved to "40M_Optical Layout" very soon and eventually these old directories will be removed. 

  7127   Wed Aug 8 22:17:43 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

  7140   Fri Aug 10 09:54:51 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

  7144   Fri Aug 10 15:05:52 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

Quote:

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

Can you explain more what "broken/bad" means?  Is there no signal?  Is it noisy?  Glitch?  etc.

 The PD saturates the oscilloscope just by switching on the power; with no real signal at all. But Steve helped locating a PD that is not being used at the AP table. So I will check it and replace the current one if it works!

  7159   Mon Aug 13 12:17:41 2012 ManasaConfigurationIOOPD from AP table removed

The PD (pda255) at the AP table, close to the MC refl , which Steve mentioned to be not in use, has been removed from the table for testing.

  7164   Mon Aug 13 19:29:10 2012 ManasaSummary Ringdown measurements

I tried to make ringdown measurements at the IMC using the DC falling edge as the trigger. Input to the MC was switched off by changing the polarity of the MC servo. But it does not seem to give the needed data as there seem to be several DC falling edges as soon as the polarity is switched. We should think about a better trigger or try to setup data recording from the oscilloscope seamlessly.

Also an ethernet cable has been connected to the router from the oscilloscope at the MC trans, but has not been set up to record data yet.

  7200   Wed Aug 15 20:53:48 2012 ManasaUpdateIOORingdown measurements

Quote:

Quote:

While I thought that the bumps observed at the end of the ringdown might be because of the cavity trying to lock itself, Jan commented that they have always existed in these measurements and their source is not known yet.

What I meant to say was that in all ringdown measurements that we observed today, the bumps were consistently part the ringdown, and that I have no explanation for the bumps. It should also be mentioned that fitting the bumpy part of the ringdown instead (we used the clean first 10us), the ringdown time is about twice as high. In either case, the ringdown time is significantly smaller than we have seen in documents about previous measurements.

We (basically I) also made one error when producing the plots. The yaxis label of the semi-logarithmic plot should be log(...), not log10(...).

 I thought about  why we do not find any bumps beyond the exponential fall. Could it be because we neglected fluctuations of voltage in the negative direction and plotted the absolute values?

  7205   Thu Aug 16 16:44:55 2012 ManasaConfigurationIOOPD from AP table removed

Quote:

The PD (pda255) at the AP table, close to the MC refl , which Steve mentioned to be not in use, has been removed from the table for testing.

 The PD installed at MC trans to make ringdown measurements has been replaced with the above PDA255. 

  7206   Thu Aug 16 17:28:51 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

Quote:

Quote:

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

Can you explain more what "broken/bad" means?  Is there no signal?  Is it noisy?  Glitch?  etc.

 The PD saturates the oscilloscope just by switching on the power; with no real signal at all. But Steve helped locating a PD that is not being used at the AP table. So I will check it and replace the current one if it works!

Koji opened up the PD and found that the screw connecting the PD to the pole was doing an additional job as well; connecting the power cable to the PD output in the inside. The PD is now fixed! Yippie...we have two PDA255 s at 40m now!!

  7222   Fri Aug 17 18:49:55 2012 ManasaUpdate40m UpgradingOptical layout updated

Quote:

Quote:

ACAD files of the 40m optical layout have been updated as per the vent in Aug 2011.

Files are available at the 40m svn docs-->Upgrade12-->Opt_Layout2011.

 

 To ease the pain of hunting files, optical layout ACAD files have been moved to a new directory 40M_Optical Layout in the repository. Relevant files from directories Upgrade12 and upgrade 08 will be moved to "40M_Optical Layout" very soon and eventually these old directories will be removed. 

Changes mentioned by Koji and Steve have been updated to the files (except for the cable connector which have been added but whose part number has to be found to match accurately with the current layout). The file in the directory should now match the current setup after the last vent Aug 2011.

Let me know if you find any mismatch between the current setup and the layout.

Plans about new installations/reconfiguration during the new vent will be carried out in a separate file.

  7245   Tue Aug 21 18:23:58 2012 ManasaUpdate40m UpgradingETMX table layout

Optical layout of the current endtable at ETMX has been updated in the svn repository (directory: 40M_Optical Layout). This layout will help in redesigning the table for the proposed replacement.

Some part numbers of mounts/optics are missing and will be updated once I find them. If you find anything wrong with the layout, do let me know.

 

  7256   Thu Aug 23 12:17:39 2012 ManasaUpdate IMC Ringdown

The ringdown measurements are in progress. But it seems that the MC mirrors are getting kicked everytime the cavity is unlocked by either changing the frequency at the MC servo or by shutting down the input to the MC. This means what we've been observing is not the ringdown of the IMC alone. Attached are MC sus sensor data and the observed ringdown on the oscilloscope.  I think we need to find a way to unlock the cavity without the mirrors getting kicked....in which case we should think about including an AOM or using a fast shutter before the IMC.

P.S. The origin of the ripples at the end of the ringdown still are of unknown origin. As of now, I don't think it is because of the mirrors moving but something else that should figured out.

Attachment 1: mozilla.pdf
mozilla.pdf
Attachment 2: MC_sus.pdf
MC_sus.pdf
ELOG V3.1.3-