40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 163 of 335  Not logged in ELOG logo
ID Date Author Type Category Subject
  8654   Thu May 30 10:40:59 2013 JamieConfigurationCDSAttempt to cleanup c1ioo ADC connections

I have attempted to reconcile all of the ADC connections to c1ioo.  Upon close inspection, it appears that there was a lot of legacy stuff hanging around.  Either that or things have not been properly connected.

The c1ioo front end machine has two ADC cards, ADC0 and ADC1, which are used by two models, c1ioo and c1als.  The CURRENT ADC connections are listed in the table below.  The yellow cells indicate connections that were moved.  The red cells indicate connections that were removed/unplugged:

  channel block connection channel usage  model
ADC0 8-15 MC WFS1 interface   MC WFS1 c1ioo
16-23 MC WFS2 interface   MC WFS2 c1ioo
0-7

generic interface card (2 pin lemo)

0    
1    
2    
3 ALS TRX c1als
4 ALS TRY c1als
5    
6 MCL c1ioo
7 MCF c1ioo

 

  channel block connection channel usage model
ADC1 0-31 1U interface board 0/1 (J1A) PSL FSS MIXER/NPRO c1ioo
2/3 (J2) ALS BEAT X/Y DC c1als
4/5 (J3) PSL eurocrate DAQ interface J4  
6/7 PSL eurocrate DAQ interface J5  
8/9 PSL eurocrate DAQ interface J6  
10/11 MC eurocrate DAQ interface J1  
12/13 MC servo board DAQ  
14/15 (J8)    
16/17 (J9A) UNLABELLED ("DAQ ISS1"???)  
18/19 (J10) "DAQ ISS2"  
20/21 "DAQ ISS3"  
22/23 ALS BEAT X I/Q c1als
24/25 ALS BEAT Y I/Q c1als
26/27    
28/29    
30/31 (J16)    

The following changes were made:

  • "MC L" had been connected to ADC_0_0, moved to ADC_0_6
  • "MC F" had been connected to ADC_0_6, moved to ADC_0_7

The c1ioo model was rebuilt/restarted to reflect this change.

The PSL-FSS_MIXER and PSL-FSS_NPRO connections were broken in the c1ioo so I fixed them when I moved the MC channels.

All the removed connections from ADC1 were not used by any of the front end models, which is why I unplugged them.  Except for the MC DAQ interface J1 and MC servo DAQ connections, I left all other cables plugged in to wherever they were coming from.  The MC cables I did fully remove.

I don't know what these connections were meant for.  Presumably they expose they expose some useful DAQ channels that we're now getting elsewhere, but I'm not sure.  We don't currently have an ISS, which is presumably why the cables labelled "ISS" are not going anywhere.

TODO

I would like to see some more 4-pin lemo --> double BNC cables made.  That would allow us to more easily use the ADC1 generic interface board:

  • Moved ALS TRX/Y to ADC1, so that we can keep all the ALS connections together in ADC1.
  • POP QPD X/Y/SUM

We should also figure out if we're sub-optimally using the various "DAQ" connections to the DAQ cable connectiosn to the eurocrate DAQ interface cards and servo boards.

  8653   Thu May 30 01:02:41 2013 ManasaUpdateGreen LockingFound it!

X green beat note found!

Key points
1. Near-field and far-field alignment on the PSL table. The near-field alignment checked by looking at the camera and the far-field alignment checked by allowing the beams to propagate by removing the DC PD.
2. Check laser temperature and get a sense of how the offset translates to the actual laser temperature.
3. Get an idea of the expected temperature of laser using the plot in elog.

Data
PSL laser temperature = 31.45 deg C

X end laser temperature = 39.24 deg C
C1-ALS-X_SLOW_SEERVO2_OFFSET = 4810
Amplitude of beat note = -40dBm

I do not understand why
1. The amplitude of beatnote falls linearly with frequency (peak traced using 'hold' option of the spectrum analyzer).
2. I found the beat note at the RF output of the PD. Earlier, while I was trying to search for the beatnote from the RFmon output of the betabox, there was a strong peak at 29.6MHz that existed even when the green shutters were closed. It's source has to be traced.

Next
Solve beatbox puzzle and lock arm using ALS.

IMG_0598.JPGIMG_0599.JPG

  8652   Tue May 28 22:11:23 2013 AnnalisaUpdate40m upgradingETMY - Yarm shutter cable

 

 For some strange reason the Yarm shutter cable runs up to the POY table, where it is connected to another cable going to the rack. It has to be put off from the table, at least. It would be better to have only one cable going directly to the rack.

I roughly aligned the green into the Yarm and I've seen the green beam flashing on the PSL table, but the mode matching is not so good and I get an higher order mode, so I'm going to fix the mode matching tomorrow.

  8651   Tue May 28 19:35:17 2013 ManasaUpdateGreen LockingStill searching for the X green beat note

Procedure

1. Aligned X-arm to IR.
2. Aligned green to the X-arm.
3. PSL green and X-green aligned to the X-green beat PD.
4. Scanned X-green laser temperature (sweep X slow servo offset through the whole range)

I did not succeed in finding the beat note; but noticed something I cannot explain.
With green very stably aligned to the X-arm, GTRX reads 3000 counts. But when the laser temperature is changed and the green unlocks and locks to the X-arm, it locks with GTRX counts over 5000. GTRX stays at 5000 counts as long as the temperature is changing but settles down to 3000 (over a time lapse of tens of seconds) when let to stay at any specific temperature.

  8650   Tue May 28 17:06:04 2013 KojiUpdateLSCPRMI sensing matrix: Got it!

- We want to add POX11/POY11 in the collection. They may indicates some abnormal asymmetry between two arms (for PRMI).

- We also want to PRCL/MICH after the input matrix. This will be useful when we want to adjust the input matrix to give the optimul
demod phase for the two signals from a single port.

  8649   Tue May 28 17:00:50 2013 JenneUpdateASCProposed POP path, to be installed this evening

I have mounted 2 2" G&H high reflective mirrors, to be used in the new POP path.  Manasa and Annalisa are doing green things on their respective arms, so I will hopefully be able to install the new POP path after dinner tonight.

Here are photos of the current POP path, and my proposed POP layout.  In the proposed layout, the optical components whose labels are shaded are the ones which will change.

CurrentPOPpath.pdf

ProposedPOPpath.pdf

  8648   Tue May 28 14:52:56 2013 JenneUpdateLSCPRMI sensing matrix: Got it!

Just so we have it, here is the re-analysis with the correct plot and phases for the May 21st data, taken near the violin mode:

Sensing Matrix, units = counts/meter, phase in degrees
 
            PRCL Mag   PRCL Phase    MICH Mag   MICH Phase  
AS55         9.048E+11   -22.880      2.927E+12   107.071    
REFL11       2.954E+16   -21.628      3.670E+14   123.857    
REFL33       2.757E+14  -192.608      9.186E+12    -4.037    
REFL55       2.868E+14   -82.690      1.186E+13   170.097 

SensMat_21May2013_withIQ_andCorrectPhases.png

Even though this data was taken near the violin mode (oops!), it is fairly consistent with the stuff taken a few days later at 580Hz (elog 8644). 

Neither of these is at all similar to what Kiwamu had measured a year ago (elog 6283), but we have changed many, many things since then.  He also includes an Optickle simulation, which is fairly similar to the Koji simulation in the wiki, but neither his measurements nor mine are particularly close to the simulated version.  I should think about why this is.

Also, I have fixed up the measurement scripts so that they record all of the relevant current settings / information:  Current actuator calibration, current PD demod phases, drive amplitude and drive frequency.  The "Analyze Saved Data" script has been updated to read all of this info from the files.  If you want to plot / look at any old data, open up SensMatAnalyzeSavedData in /scripts/LSC/SensingMatrix/ and put in the relevant filename that you want (which should be saved in /scripts/LSC/SensingMatrix/SensMatData/)

  8647   Tue May 28 11:11:37 2013 ManasaUpdateIOOMC aligned

[Jenne, Manasa]

Fixed crappy alignment of MC by moving MC mirrors. MC REFL PD measured 0.5 after alignment. Spot positions were measured using msassMCdecenter. Plot for the same is attached.

Attachment 1: MC_0528.png
MC_0528.png
  8646   Mon May 27 21:38:53 2013 AnnalisaUpdate40m upgradingETMY - Beam Dumps

 

I put many razor dumps along the IR/green path. The rejected beam from the IR Faraday needs to be dumped (about 1.5 mW). I used all the new razor blade I had, so I need one more for that beam.

The IR reflection of the Harmonic separator right after the doubler needs to be dumped in a better way. At the moment there is a black screen, but we need something suitable to dump more than 300 mW.

After the second steering mirror along the green beam path there is a very small transmission (about 6 uW), which is difficult to dump because there is no space enough. Can it be dumped with a black screen?

 

The Oplev has a lot of reflection hitting the central BS (The BS for the transmitted beam). It is very difficult to dump them without intercepting the main beam path. Maybe we have to slightly change the Oplev beam angle to avoid so many reflections.

 

  8645   Sat May 25 02:03:48 2013 AnnalisaUpdate40m upgradingETMY - Mode Matching for green - new calculation

 Mode matching calculation for green - Yarm

I did again the mode matching calculation. The previous one was using 1064nm as wavelength, so it was wrong.

The seed beam waist and its position are the same as in elog 8637. The new results are shown in the attached graphs.

I got the following values for focal lengths and positions of the two Mode Matching lenses:

 

                    Focal length (m)             Distance from the Faraday output (m)

lens1            0.125                                                  0.1829

lens2           -0.200                                                  0.4398

L                   1.000                                                  1.4986 (fixed)

The position of the lens L has changed because the path lengh has been slightly  reduced. 

The Coupling factor for he astigmatic beam is C = 0.959 (it is C = 0.9974 if we consider the beam as non astigmatic).

I put the lenses and aligned the beam up to the shutter, which has been moved from its initial position because the beam size on it was too large. 

TO DO

The green beam needs to be aligned and sent into the arm cavity. 

Polarization has to be checked.

Many beams still have to be dumped, both in IR and Green paths. 

 

 

 

 

Attachment 1: ModeMatchingGreenNEW.jpg
ModeMatchingGreenNEW.jpg
Attachment 2: ModeMatchingGreenZoomNEW.jpg
ModeMatchingGreenZoomNEW.jpg
Attachment 3: XYpathNEW.jpg
XYpathNEW.jpg
Attachment 4: photo1.JPG
photo1.JPG
Attachment 5: photo2.JPG
photo2.JPG
  8644   Fri May 24 22:18:33 2013 JenneUpdateLSCPRMI sensing matrix: Got it!

Okay, I think I am finished with the sensing matrix scripts!  

I had the syntax for atan2() wrong, so I was calculating the demod phase wrong.  Do not trust the phase in any previous elogs!!

Also, the theta=0 axis of the plots are for 0 degree demod phase, but our PDs are not at 0 deg.  The measured sensing matrix phase is relative to the current demod phase, not 0 (unless the demod phase for that PD is currently 0degrees).  So, now I take that into account.  I add the current PD demod phase to the measured sensing matrix phase, so that the plot is actually true.

For interested parties, I have made all of the sensing matrix scripts, and the data folder a subdirectory of the /scripts/LSC folder, since it was starting to get crowded in there.  I have moved the 2 data sets that have been collected (21May, 23May) into the new place.

Future thoughts: 

* Save the amplitude and modulation frequency and the current demod phases in the data file.  Right now the ampl and mod freqs are included in the title of the data file, but there is no record of what the demod phase was at the time.  I need to fix this.

 

So, really, really, the Sensing Matrix:

Sensing Matrix, units = counts/meter, phase in degrees
 
            PRCL Mag   PRCL Phase    MICH Mag   MICH Phase  
AS55         5.485E+08   -43.424      2.679E+09    93.392    
REFL11       1.126E+13    -7.168      1.618E+11   135.296    
REFL33       2.658E+11   164.973      8.910E+09    -2.226    
REFL55       3.012E+11   -75.216      1.210E+10   172.764

SensMat_23May2013_withIQ_andCorrectPhases.png

  8643   Fri May 24 14:44:34 2013 JenneUpdateGeneralRossa freezes all the time

I am getting tired of having to restart Rossa all the time.  She freezes almost once per day now.  Jamie has looked at it with me in the past, and we (a) don't know why exactly it's happening and (b) have determined that we can't un-freeze it by ssh-ing from another machine.

I wonder if it's because I start to have too many different windows open?  Even if that's the cause, that's stupid, and we shouldn't have to deal with it.

\end{vent}

  8642   Fri May 24 14:40:22 2013 JenneUpdateLSCPRMI sensing matrix: now what?

Quote:

It's hard to believe but is AS55Q really almost insensitive to MICH?

Well, anyway, now it is the time to use the automatic demod phase (and input matrix) adjustment.

 I am also wondering if I understand / am using the demod phase from the screen correctly.  This plot is indicating that MICH is entirely in I, and not at all in Q.

Currently, I take the demod phase, and plot that as the "I" line, then plot the "Q" line 90 degrees away from the I line.  Maybe it should be the other way around?

Re: the auto-demod phase, I was starting to wonder about that.  For each sensor, can I declare what degree of freedom I want in which quadrature to take priority (ex. MICH goes to REFL55 Q), and set the demod phase to the value that makes that true?

  8641   Fri May 24 14:01:59 2013 KojiUpdateLSCPRMI sensing matrix measured at 580.1Hz

It's hard to believe but is AS55Q really almost insensitive to MICH?

Well, anyway, now it is the time to use the automatic demod phase (and input matrix) adjustment.

  8640   Fri May 24 13:41:19 2013 JenneUpdateLSCPRMI sensing matrix measured at 580.1Hz

"0 degrees" is 0 degrees of demod phase.  I have now added the PD demod phases to the plot:

SensMat_23May2013_withIQ.png

  8639   Fri May 24 12:50:25 2013 AnnalisaUpdate40m upgradingETMY - Mode Matching for green

Quote:

I got confused. Is the mode calculation in the cavity correct?
Are you sure the wavelength in the code is 532nm?

The first plot says "the waist radius at ITMY is 2.15mm". This number is already very close to
the waist size of the cavity mode (2.1mm@ITM, 3.7mm@ETM), but the spot radius at ETMY is 6mm.
They are inconsistent.

 

 Jenne and I just realized that a la mode has 1064e-9 m as default value. I'll change it and make the calculation again.

  8638   Fri May 24 11:38:00 2013 KojiUpdate40m upgradingETMY - Mode Matching for green

I got confused. Is the mode calculation in the cavity correct?
Are you sure the wavelength in the code is 532nm?

The first plot says "the waist radius at ITMY is 2.15mm". This number is already very close to
the waist size of the cavity mode (2.1mm@ITM, 3.7mm@ETM), but the spot radius at ETMY is 6mm.
They are inconsistent.

 

  8637   Fri May 24 02:12:50 2013 AnnalisaUpdate40m upgradingETMY - Mode Matching for green

 

 Mode Matching calculation for green beam - Yarm

After measuring the beam radius out from the Faraday for the green, I made the calculation to match the green beam mode with the IR mode inside the arm.

The beam waist after the Faraday is elliptical, and I found the following value for the waist:

w0x = 3.55e-5 m @ z0x = -0.042 m

w0y = 2.44e-5 m @ z0y = -0.036 m

(the origin of the z axis is the output of the Faraday, so the waist is inside the Faraday itself)

I did the calculation using a la mode, using as beam waist and its position the following values:

w0 = sqrt(w0x*w0y) = 2.943e-5 m @ z0 = (z0x+z0y)/2 = -0.039 m

The results are shown in the attached plots.

                      Focal length (m)             position (m)

lens1            0.125                                0.1416

lens2            0.100                                0.5225

L                    1.000                                1.5748 (fixed lens used to focus transmitted beam)

 

As the first plot shows, the green beam size on the ETMY is about 6mm. My concern is that it could be too big.

The third plot shows the X and Y section of the beam. It is strongly elliptical, but nevertheless the coupling factor calculated with Koji's formula  gives C=0.936 for the astigmatic beam, and C=0.985 for the non astigmatic beam, so it seems to be still ok.

 

 

Attachment 1: ModeMatchingGreen.jpg
ModeMatchingGreen.jpg
Attachment 2: ModeMatchingGreenZoom.jpg
ModeMatchingGreenZoom.jpg
Attachment 3: XYpath.jpg
XYpath.jpg
  8636   Thu May 23 22:13:12 2013 KojiUpdateLSCPRMI sensing matrix measured at 580.1Hz

Can you clarify the definition of the phase "0deg" of your plot?

Is "I" the definition of "0deg"? Or does the demod phase of "0deg" define "0deg"?

I want to know if the demod phase of REFL55 is correctly adjusted or not.

With the decent level of the separation, we should be able to keep the decent lock of PRMI with REFL55.

  8635   Thu May 23 21:45:51 2013 JenneUpdateLSCSensing matrix scripts now check for lockloss

A few more small mods to the sensing matrix script.  Now the script saves the data after each measurement, so that in case you lose lock and can't measure any more, you still have the data you already measured.  Also, the error bar measurements are last, so that the consequence of losing lock partway through the measurement is just that you get fewer error bar numbers.  Not a big deal, since the actual sensing matrix data is already saved.

Also, the old script had a lockloss checker that I had overridden since it wasn't where I wanted it.  I have now re-implemented it, so that the script will stop the oscillation and quit measuring if either the LSC enable switch is off, or the degrees of freedom you're trying to measure are not triggered.  All data saved before the lockloss is saved though (as mentioned above).

  8634   Thu May 23 20:58:49 2013 JenneUpdatePEMPRM, ITMX optics tripped, restored

M5.7 - 11km WNW of Greenville, California

Time
Location
40.190°N 121.064°W
Depth
0.0km
  8633   Thu May 23 20:39:50 2013 JenneUpdateLSCPRMI sensing matrix measured at 580.1Hz

I locked the PRMI and remeasured the sensing matrix, this time at 580Hz.  The excellent news here is that the matrix looks quite similar to the one measured the other day, recorded in elog 8632.  Yay!  I'm not sure why the REFL11 MICH error is so much larger this time around.

Raw data:  .../scripts/LSC/SensMatData/sensematPRM_2013-05-23.202312.dat

Sensing Matrix, units = cts/meter, phase in degrees
 
            PRCL Mag   PRCL Phase    MICH Mag   MICH Phase  
AS55        5.485E+08   162.424      2.679E+09    25.608     
REFL11      1.126E+13  -122.832      1.618E+11    85.296     
REFL33      2.658E+11   -87.973      8.910E+09    79.226     
REFL55      3.012E+11   -99.534      1.210E+10    12.486 

     SensMat_23May2013.png

  8632   Thu May 23 19:09:15 2013 JenneUpdateLSCSensing matrix scripts modified to include actuator calibration

After fixing up my calculations in my scripts, I have calculated the final PRMI sensing matrix (as measured very close to the violin frequency, so things may not be perfect). The data is from the file that Koji mentioned in his elog when he did the measurement:  elog 8611, sensematPRM_2013-05-22.12615.dat

Sensing Matrix, units = cts/meter, phase in degrees
 
            PRCL Mag   PRCL Phase    MICH Mag   MICH Phase  
AS55        1.064E+09   141.880      3.442E+09    11.929     
REFL11      3.474E+13  -108.372      4.316E+11   106.143     
REFL33      3.242E+11   -90.392      1.080E+10    81.037     
REFL55      3.373E+11   -92.060      1.394E+10    15.153 

SensMat_21May2013.png

In the plot, the little blobs on the ends of the 'sticks' are the error blobs.  Many of them are smaller than is really visible - this is good.  These errors come from measuring the lockin outputs several times while there is no drive to any optics, then the errors are propagated to each degree of freedom.  These errors do not incorporate any information about the precision of the actuator calibration, and they assume that the shape of all the sensor transfer functions are the same. 

If you look at the REFL11 and REFL33, it kind of seems like a miracle that we've ever been able to lock the full PRMI with the I&Q signals from either PD!

  8631   Thu May 23 17:51:39 2013 KojiSummaryLSCMy usual locking procedure

For purpose of the automation and my record, I summarized my locking procedure as a chart.

Attachment 1: PRMI_locking_procedure.pdf
PRMI_locking_procedure.pdf PRMI_locking_procedure.pdf
  8630   Thu May 23 14:45:08 2013 JenneUpdateLSCSensing matrix scripts calculations make more sense now

I think I have most of the magnitude issues figured out now. 

First of all, the lockin outputs are different from the actual responses in the PDs by a factor of 2. 

If the optic is driven with amplitude D, it will have a response of Asin(wt) + Bcos(wt) + other frequency junk.  The lockin bandpasses the response to get rid of the 'other frequency junk'.  Then creates 2 new signals, one multiplied by cos(wt), the other multiplied by sin(wt).  So, now we have Asin^2(wt) + Bcos(wt)sin(wt) and Asin(wt)cos(wt) + Bcos^2(wt).   If I rewrite these, I have A/2*(1-cos(2wt))+B/2*(sin(2wt) and A/2*sin(2wt)+B/2*(1+cos(2wt)).  We lowpass to get rid of the 2w components, and are left with A/2 for the Q-phase, and B/2 for the I-phase of the lockin outputs.  Since the real amplitudes of the response were A for the Q-phase and B for the I-phase, we need to multiply the lockin outputs by 2.

The other problem was that in the 'uncalibrated' version of numbers that I was printing to compare with Koji's, I had not normalized by the drive amplitude yet.  That happens in the "calibration" part of my script.  So, if I go back to comparing the calibrated versions of our numbers, I get quite close to Koji's answers.

For the PRCL magnitudes, 3 of the 4 numbers match to ~5%.  However, the MICH magnitudes all seem to be off by a factor of 2.  I'm still stuck on this factor of 2, but I'm thinking about it. Also, the phases that Koji and I get are pretty different.

Koji's sensing matrix:

Sensing Matrix, units = cts/meter, phase in degrees
            PRCL Mag   PRCL Phase    MICH Mag   MICH Phase  
REFL33_I    3.100E+11  -109.727      4.900E+09    74.434     
REFL33_Q    3.300E+09  -141.730      7.900E+08    71.120     
REFL55_I    3.200E+11  -109.672      5.900E+08    77.313     
REFL55_Q    1.200E+10  -143.169      6.500E+09    91.559  

My sensing matrix:

Sensing Matrix, units = cts/meter, phase in degrees
            PRCL Mag   PRCL Phase    MICH Mag   MICH Phase  
REFL33_I    3.242E+11  -157.846      1.067E+10    19.010     
REFL33_Q    2.217E+09  -104.088      1.683E+09    28.731     
REFL55_I    3.371E+11  -157.915      3.645E+09    11.072     
REFL55_Q    1.213E+10  -118.348      1.346E+10     2.847

Here are the plotted versions of these matricies:

SensMat_KojiMeas_23May2013.png

SensMat_JenneMeas_23May2013.png

SOME EDITS:  Koji's measurement was 1Hz away from the violin mode, while mine (him running my script) was at the violin mode, so the sensor TFs were actually taken at slightly different frequencies. This helps explain the discrepancies.

Also, the phase in these plots isn't correct, so I need to figure that out. Corrected version of the 'koji' measurement put in place of the incorrect one.  I convert from radians to degrees for my script, but Koji had already reported his phases in degrees, so when I multiplied by 180/pi, it didn't make any sense. I now convert his numbers to radians before running them through my analysis script.

 

  8629   Thu May 23 13:14:34 2013 KojiSummaryLSCXarm beat note search continues

We should consider to hook up the temperature monitors of the NPROs to the ADCs.

  8628   Thu May 23 12:02:48 2013 SteveUpdateendtable upgradeETMY - oplev

 Temporary oplev in place. The spot on the qpd is still big. My two lens solution did not work.

I will finalize optical component position of the oplev after the the arm transmitted and green beam optics in place. They have priority.

 

Attachment 1: ETMYopl.jpg
ETMYopl.jpg
  8627   Thu May 23 10:48:42 2013 ManasaUpdateIOOMC autolocker and MCWFS enabled

Some strong seismic noise (not related to any earthquakes - watchdogs are all green) had got the MC unlocked this morning.

I found the MC autolocker and MCWFS disabled. Enabling them locked the MC right away. I don't see any updates in the elog  as to why these were left disabled and hence have left them ON now.

  8626   Thu May 23 10:24:23 2013 JamieSummaryCDSc1scy model continues to run at the hairy edge

c1scy, the controller model at the Y END, is still running very long, typically at 55/60 microseconds, or ~92% of it's cycle.  It's currently showing a recorded max cycle time (since last restart or reset) of 60, which means that it has actually hit it's limit sometime in the very recent past.  This is obviously not good, since it's going to inject big glitches into ETMY.

c1scy is actually running a lot less code than c1scx, but c1scx caps out it's load at about 46 us.  This indicates to me that it must be some hardware configuration setting in the c1iscey computer.

I'll try to look into this more as soon as I can.

  8625   Thu May 23 10:20:33 2013 JamieUpdateSUSTurn off zero padding in DAC outputs

Quote:

After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:

  • c1mcs
  • c1sus
  • c1scx
  • c1scy

The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads.  This should reduce the 32 kHz lines we were noticing in the analog DAC output.

I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample.  We will continue to investigate.

In any event, I have rebuilt and installed all models listed above.  I will restart as soon as opportunity allows.

I have restarted all the suspension models with the new no_zero_pad flag for the DAC upsampling.  Everything came up fine and all optics are damped as expected (except for concerns about c1scy which I'll note in a followup).

  8624   Thu May 23 01:27:11 2013 ManasaSummaryLSCXarm beat note search continues

Towards finding the x-arm beat note:

The green would not lock to a maximum GTRX this morning. In the course of aligning the green stably to the X arm, somewhere down the line, the input pointing got messed up (reasons unknown). To set this right, Koji tried to lock the Yarm with POY DC but it wouldn't work. The transmon for Y had to be set up temporarily and the Y arm was locked with TRY. This restored the input pointing and the arms locked with transmission TRX/TRY > 0.9 counts. The transmon path along the Y arm was then re-configured as mentioned in Annalisa's elog.

I still had trouble getting the X-green locked in TEM00 (similar situation mentioned by Jenne in elog). The arm cavity mirrors were tweaked to get the green to resonate in TEM00 but it wouldn't stay locked when the temperature of the x-end NPRO was changed. Koji helped recover missing links to filters for the ALS_X_SLOW servo from the archives. Enabling the filters helped keep the green locking stable for laser temperature changes (which corresponds to 'offset' change in ALS_X_SLOW servo screen).

PSL green alignment was checked once again and the X-end laser temperature was scanned trying to find the beatnote. RFMON from the beatbox was connected to the spectrum analyzer. I have scanned through the whole range of offset but have not been able to find the beat note yet.


The search will continue tomorrow

  8623   Thu May 23 00:49:13 2013 JenneUpdateLSCLSC filters loaded

Quote:

 To avoid exciting at the PRM violin mode frequency, I have changed all of the filters relevant to the sensing matrix measurement from 628Hz to 580.1Hz.  This includes notches in the LSC control loops, as well as the band pass filters in the lockins.  I have not yet loaded the new filters, since arm locking is in progress.

 I have loaded these new filters in.  Manasa is still using the IFO for green stuff, so I can try out the PRMI measurement in a day or so.  (Right now I have to make sure I understand my data, anyway.)

  8622   Thu May 23 00:16:32 2013 AnnalisaUpdate40m upgradingETMY - progress

 [Annalisa, Koji] 

 GREEN

I aligned back the beam (we lost part of the alignment after we put back the box and after the posts were installed). The green beam out from the crystal is still low, but anyway I get about 1.2 mW of green out from the Faraday. 

TO DO 

Mode Matching calculation (tomorrow)

Fix the dumping situation

Replace some of the mounts with more solid ones (in the future)

TRANSMON PATH

 QPD, PD and Camera have been rotated as Rana suggested last Wednesday. A 1m focal length lens is on the main beam transmitted path (before the harmonic separator), and the beam diameter on the QPD is about 5mm. We put another lens with a shorter focal length to put the PD very close to the beam waist and in way to have a reasonable beam size on the camera. Tomorrow I will write down all the correct sizes of the beams.

OPLEV 

(for Steve) I marked a possible beam path for the Oplev (the laser is not in the right place in the picture, but I left it in the correct place on the table). I also put the QPD for the IP-ANG, so we know in which part of the table the beam can be steered.

The space in the red rectangle (right corner) has to be left empty to put a PD for the rejected beam from the green Faraday.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Attachment 1: TransMonAndOplev.jpg
TransMonAndOplev.jpg
  8621   Wed May 22 20:50:26 2013 JenneUpdateLSCSensing matrix scripts don't calculate correctly

I am trying to re-analyze the data that Koji took last night.  

I think that my script is just pulling out the I and Q data for each port, and each degree of freedom, calculating the magnitude from sqrt( I**2 + Q**2 ) and the phase from atan2( I / Q ).  No calibration.

If I print out the results, I get:

Sensing Matrix, units = cts/ct, phase in degrees
 
            MICH Mag   MICH Phase    PRCL Mag   PRCL Phase  
AS55_I      1.627E-02   62.063        4.189E-03   68.344       
AS55_Q      2.073E-02  -105.353        1.983E-02   66.361       
REFL11_I    8.165E+02  -112.624        2.441E+00   77.911       
REFL11_Q    2.712E+02  -112.650        7.065E-01  -127.093       
REFL33_I    8.028E+00  -112.154        6.282E-02   70.990
       

REFL33_Q    5.490E-02  -165.912        9.908E-03   61.269       

REFL55_I    8.347E+00  -112.085        2.146E-02   78.928       
REFL55_Q    3.003E-01  -151.652        7.924E-02   87.153
 

If, however, I take the raw values that are stored in the data file, for one row (say, REFL33_Q) and calculate by hand (same formulas), I get different results:

            MICH Mag   MICH Phase    PRCL Mag   PRCL Phase  
REFL33_Q    9.9E-03    28.89         5.46E-02   -103.8

Contrast that with Koji's uncalibrated transfer function result from elog 8611:

            MICH Mag    MICH Phase    PRCL Mag     PRCL Phase  
REFL33Q     1.8665e-5   71.1204      
1.6310e-4    -141.73

 

I am currently confused, and need to re-look at my script, as well as make sure I am actually measuring the things I think I am.

EDIT:  This has been fixed, in that my 2 calculations agree with one another.  I have crossed out the incorrect numbers, and put correct numbers below.  I still don't agree with Koji, but at least I agree with myself. 

The phase issue:  I needed to calculate the phase with "ATAN2(I,Q)", which I did when I calculated by hand, but the script had "atan2(Q,I)".  This has been fixed. 

The magnitude issue:  They match, but my "pretty print" script labels MICH as PRCL, and vice versa.  Doh.

Corrected values:

Sensing Matrix, units = cts/ct, phase in degrees
 
            PRCL Mag   PRCL Phase    MICH Mag   MICH Phase  
AS55_I      1.627E-02    27.937      4.189E-03    21.656     
AS55_Q      2.073E-02  -164.647      1.983E-02    23.639     
REFL11_I    8.165E+02  -157.376      2.441E+00    12.089     
REFL11_Q    2.712E+02  -157.350      7.065E-01  -142.907     
REFL33_I    8.028E+00  -157.846      6.282E-02    19.010     
REFL33_Q    5.490E-02  -104.088      9.908E-03    28.731     
REFL55_I    8.347E+00  -157.915      2.146E-02    11.072     
REFL55_Q    3.003E-01  -118.348      7.924E-02     2.847 

  8620   Wed May 22 18:24:19 2013 JenneUpdateSUSViolin mode survey

Quote:

It was too embarassing to see that the actuation frequency was set at the violin mode frequency in order to avoid designing a new filter!?

 Ooops, definitely my bad.  I think I was the one who put in the PRM violin filter, so I should have recognized that frequency.  However, I couldn't think of a reason why violin mode filters should be in the LSC filter banks, since we usually put them in C1:SUS-optic_LSC filter banks. 

Anyhow, so that I don't make a mistake like that again, I was looking through all of the violin mode filters for all the optics, so I could write down the frequencies.  The result: confusion.

Violin filters in C1:SUS-optic_LSC filter banks:

The PRM's violin mode filter is set correctly to 627.75Hz:  elog 8533.

One of BS or SRM has probably been measured (presumably BS), since they have the same filters centered around 645Hz. 

Neither ITM has a violin filter.

The ETMs have violin filters in the 440's, which I assume was correct back in the MOS days, before 2010.

Vio2 filters in C1:SUS-optic_LSC filter banks:

PRM, SRM, BS, ITMX, ITMY:  Centered around 1285 Hz, which matches the violin notch frequencies in the BS and SRM.

ETMY:  Centered around 883.5Hz, which matches the old 440Hz frequency

ETMX:  Centered around 631Hz .  So, this could have been measured, but it was put into the wrong filter module.

 

Koji tells me that we don't really need to worry about all these violin filters unless they are required (as with the PRM and the obnoxious hum a few weeks ago), so I 'm not going to do any measuring / adjusting of these filters for now.

  8619   Wed May 22 18:07:36 2013 JenneUpdateLSCKiwamu's sensing matrix measurement script revived

 

 To avoid exciting at the PRM violin mode frequency, I have changed all of the filters relevant to the sensing matrix measurement from 628Hz to 580.1Hz.  This includes notches in the LSC control loops, as well as the band pass filters in the lockins.  I have not yet loaded the new filters, since arm locking is in progress.

 

  8618   Wed May 22 17:29:34 2013 JenneUpdateASCQPD for POP ASC tested

I fiddled around with the QPD that I'll use to replace Koji's temporary razor blade yaw sensor for detecting POP beam angular motion, and checked that it is working. 

Using the Jenne Laser, I put beam onto the 4 different quadrants of the QPD, and saw that the Sum channel remained constant. 

   * I had the room lights off, since the PD elements are silicon. 

   * Beam size on the QPD as seen on an IR card was ~1mm diameter.

   * With the beam on the QPD, I chose gain setting "G2" on the amplifier, since that was the only setting where neither the "current too high" nor the "current too low" LEDs were illuminated.  I didn't measure the power going to the PD, but the Jenne Laser puts out 1.2mW, and there's a 50/50 BS, so I was getting about 600uW. 

   * I turned off the "zero/cal" switch on the back of the box, since I don't know how to set the zero.  Since the X and Y channels are normalized by the Sum, you can't just block all light going to the PD and set the zero.  There isn't a big change in the output levels with the zero/cal switch off, so I think it should be fine.  (Previously, I set all 4 knobs - "zero" and "cal" for each X and Y - to approximately the center of their ranges.  Once you hit the end of the range, you can keep turning the knob, but something inside makes a clicking sound ~once per revolution, and the signal level stops changing (for the zero knobs). Much like centering a beam on a PD, I found each edge of the range for each knob, and set the knobs in the centers by counting the number of turns.  Anyhow, since I set the knobs to ~halfway, I think that explains why there isn't really a change whether the "zero/cal" switch is on or off.

   * Using the steering mirror sending the beam to the QPD, I moved the beam around, and watched where I was going with an IR viewer.  I see that as I move from quad-to-quad, the X and Y channels respond as I expect.  If I only move the beam in X, I only see X response on a 'scope, and vice versa.

I can't do a real calibration until I get the QPD installed in place, so I can use the actual beam, but for now it looks like the QPD is responding nicely.  Since Annalisa and Manasa are using the Arms for the evening, I'll work on putting the QPD on the POX table tomorrow.

  8617   Wed May 22 15:48:56 2013 JamieUpdateSUSTurn off zero padding in DAC outputs

After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:

  • c1mcs
  • c1sus
  • c1scx
  • c1scy

The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads.  This should reduce the 32 kHz lines we were noticing in the analog DAC output.

I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample.  We will continue to investigate.

In any event, I have rebuilt and installed all models listed above.  I will restart as soon as opportunity allows.

  8616   Wed May 22 15:08:37 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

It seems that the effect is from the (linear) residual fluctuation of the digital AI filter for the zero-padded signal.

Namely, if we give the larger constant number, we get more oscillation.

Attachment 1: Screenshot.png
Screenshot.png
  8615   Wed May 22 11:35:06 2013 JamieSummaryCDSWeird DAC bit flipping at half integer output values

Quote:

Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)

This is a good question.  We may be able to test if it's a linear effect if we have enough DAC range to get the oscillation to be more than a single sample.

Quote:

You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case?

 In the zero-pad case the oscillation just continues indefinitely at the half-count value, so it never dies out (at least as far as I can tell).

  8614   Wed May 22 11:21:28 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)

Anyway, it seems that we should use no-zero-padding.

You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case?

  8613   Wed May 22 11:09:33 2013 JamieSummaryCDSWeird DAC bit flipping at half integer output values

After querying CDS folks about this issue, I got some responses that indicated the problems was likely limit-cycle oscillations due to zero-padding of the data when upsampling.  Tobin ran some Matlab tests to confirm this issue.

Starting in RCG 2.5 there is a new "no_zero_pad=1" cdsParameters option turns zero padding OFF.  I tried enabling this option c1scy to see how the behavior changed.  Sure enough, the 32 kHz oscillations mostly went away.  There are no oscillations for outputs held at the half-count value, and the oscillations around the half-count transitions went away as well.

The only thing I could see is a bit of oscillation when converging on a constant half-count value that went away after a couple of milliseconds:

nopad.pdf

So we might consider adding the no_zero_pad=1 option to all of our coil driver outputs, which might eliminate the need to add notches at the Nyquist in the analog anti-image filters

  8612   Wed May 22 00:42:13 2013 KojiSummarySUSviolin Q

While looking at the decay of the violin mode of the PRM, I made a simple measurement of the decay rate.

Error signal: REFL33I

The peak @628Hz became 0.372 to 0.303 in 60 sec.

-> Half life of the amplitude T_{1/2} is 203sec.

Q = 4.53 f0 T_{1/2} = 5.8 x10^5

  8611   Wed May 22 00:08:19 2013 KojiUpdateLSCSensing matrix scripts modified to include actuator calibration

It was too embarassing to see that the actuation frequency was set at the violin mode frequency in order to avoid designing a new filter!?

I ran Jenne's sensing matrix code and the immitated the same result by manual measurement with DTT.
I noticed that the PRM excitation was not transmitted to the mirror. I tracked down the cause and found that
Jenne is using 628Hz which is the notch frequency of the viloing filter.

There is no way we can measure the precise calibration of the error signal exactly at the violin mode frequency.

Nevertheless I waited for the ringdown of the violin mode to the floor level and ran the code again WITH the violin mode filter OFF
at PRM SUS.

The result was stored in the data file

sensematPRM_2013-05-22.12615.dat

The code spit the message at the end

Sensing Matrix, magnitude only, units = cts/meter
 
            MICH          PRCL         
AS55        5.304E+08     1.716E+09     
REFL11      1.732E+13     2.151E+11     
REFL33      1.616E+11     5.384E+09     
REFL55      1.681E+11     6.950E+09

Now I replicated the same measurement with DTT.

MICH or PRCL were excited with the lockin. In order to aviod the violin mode, I shifted the excitation freq by 1Hz. (i.e. 629.125Hz)

The peaks in REFL33I/Q and RFL55I/Q were observed with PSD and TF. The spectrum was measured with the FLATTOP window with the line resolution of 0.1Hz
DTT suggested that this corresponds to the BW of 0.471271Hz if I correctly understood what DTT plot said. We need this information to convert cnt/rtHz to cnt_pk
if we need. For the TF measurements, I needed to find the excitatin monitor but I could not. Therefore, I set the offset of LSC-LOCKIN1_SIG to be 1000,
so that C1:LSC-LOCKIN1_I_IN1 produce the same signal as the excitation.

Note that during the measurement, 628Hz nothces in the LSC servos were on. I confirmed that this provides the reduction of the feedback by a factor of 76.
As the original openloop gain at 629Hz is lower than the unity more than a factor of 2, this was sufficient attenuation to measure the optical gain with the systematic error of less than a %.

MICH excitation (ITMX -1, ITMY +1)
        PSD (cnt/rtHz)   TF Mag    Phase

REFL33I 0.098590         9.5691e-5 74.4344
REFL33Q 0.019294         1.8665e-5 71.1204
REFL55I 0.016123         1.3890e-5 77.3132
REFL55Q 0.157522         1.5285e-4 91.5594

PRCL excitation (PRM +1)
        PSD (cnt/rtHz)   TF Mag    Phase

REFL33I 15.7565          1.5298e-2 -109.727
REFL33Q  0.171648        1.6310e-4 -141.73
REFL55I 16.2834          1.5809e-2 -109.672
REFL55Q  0.634096        6.1012e-4 -143.169

These measurements are saved in the XML files (for DTT) in
/cvs/cds/caltech/users/koji/130521/
as
130521_MICH_EXC.xml and 130521_PRCL_EXC.xml

As the actuator of the PRM/ITMX/ITMY are {19.6, 4.70, 4.66}/f^2 nm/cnt, the optical gains were calculated from the TF measurements.

MICH excitation (ITMX -1, ITMY +1)
        OPTICAL GAIN
(cnt/m)
REFL33I 4.0e9
REFL33Q 7.9e8
REFL55I 5.9e8
REFL55Q 6.5e9

PRCL excitation (PRM +1)
        OPTICAL GAIN

REFL33I 3.1e11
REFL33Q 3.3e9
REFL55I 3.2e11
REFL55Q 1.2e10

These should be compared with the measurement by the script and we get more information from the script (like AS55, REFL11)

  8610   Tue May 21 23:29:57 2013 ManasaUpdateGreen LockingXend Green aligned

X-green and PSL green have been aligned so that they interfere at the beat PD for X.

I haven't scanned the X-end NPRO temperature to find the beat note. I found the earlier elog when this was done (elog 6851) and will use those temperatures to start with.

  8609   Tue May 21 18:22:18 2013 JenneUpdateLSCSensing matrix scripts modified to include actuator calibration

The PRMI sensing matrix scripts have been modified to output a sensing matrix which is calibrated into units of counts/meter.

To run, you should just need to run .../scripts/LSC/runPRMI_SENS.py . 

If it looks like the drive amplitude is not large enough (no nice peak in the photodiode signals), you can increase the drive amplitude, which is line 21 in runPRMI_SENS.py  

  8608   Tue May 21 18:18:28 2013 JamieUpdateComputer Scripts / ProgramsnetGPIB stuff update/modernized/cleanedup/improved

I did a bunch of cleanup work on the netGPIB stuff:

  • Removed extensions from all executable scripts (executables should not have language extensions)
  • fixed execution permissions on executables and modules
  • committed HP8590.py and HP3563A.py instrument modules, which were there but not included in the svn
  • committed NWAG4395A (was AG4395A_Run.py) to svn, and removed old "custom" copies (bad people!)
  • cleaned up, modernized, and fixed the netgpibdata program
  • removed plotting from netgpibdata, since it was only available for one instrument, there's already a separate program to handle it, and it's just plotting the saved data anyway
  • added a netgpibcmd program for sending basic commands to instruments.
  • added a README

Probably the most noticeable change is removing the extensions from the executables.   There seems to be this bad habit around here of adding extensions to executables.  It doesn't matter to the person running the program what language it was written in, so don't add extensions.  It only matters for libraries.

  8607   Tue May 21 18:18:23 2013 ManasaUpdateGreen LockingXend Green aligned

X arm aligned to green.

Aligned the X arm to IR.
Used steering mirrors to align the X end green to the X arm while remaining locked for IR. X arm locks to green stably with GTRX at the PSL table measuring 235uW and corresponds to 2560counts in C!:ALS-TRX_OUT.

Next
1. PSL green alignment.
2. Search for beat note.
3. Resurrect ALS for X arm.

  8606   Tue May 21 17:03:45 2013 SteveUpdateendtable upgradeenclosure tops are sealed

Quote:

 

 I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.

We'll install spring loaded lathes, hooks and quick release pins.

The bridge will be reinforced with steel plate to support release pins on posts.

There will be an other cut out for cable feedtrough as it is shown on elog #8472

Let me know if this timing does not fit your work.

 The bridge support posts were shimmed today. Surgical tubing 402R - o - rings were glued togeather with " instant krazy glue "

Atm2  Carey CH-3540 latches are compressed ~2.5 mm in the clamped position.

Atm3 is showing the captured quick release pin in the steel reinforced bridge that is supported by the post. It works great. The post screw is sealed by o-ring. The quick-pin is sealed by an epoxy attached copper cap.

Atm4 Enclosure is on it's back. Bottom o-ring can be seen. The hole reinforced bridge structure is visible.

Now I'm working on the window connection to the chamber. I'm very close leak checking this box.

In case of leaking around the top tubing seals we have two options:

a, cut down on the cover rim by 0.040"  or b, increase tubing diameter

Attachment 1: ETMYoptable.jpg
ETMYoptable.jpg
Attachment 2: surgtubclamps.jpg
surgtubclamps.jpg
Attachment 3: quickrelease.jpg
quickrelease.jpg
Attachment 4: reinforcbridge.jpg
reinforcbridge.jpg
  8605   Tue May 21 16:23:06 2013 ManasaUpdateGeneral40MARS wireless network problem RETURNS

Quote:

Here's an example of the total horribleness of what's happening right now:

controls@rossa:~ 0$ ping 192.168.113.222
PING 192.168.113.222 (192.168.113.222) 56(84) bytes of data.
From 192.168.113.215 icmp_seq=2 Destination Host Unreachable
From 192.168.113.215 icmp_seq=3 Destination Host Unreachable
From 192.168.113.215 icmp_seq=4 Destination Host Unreachable
From 192.168.113.215 icmp_seq=5 Destination Host Unreachable
From 192.168.113.215 icmp_seq=6 Destination Host Unreachable
From 192.168.113.215 icmp_seq=7 Destination Host Unreachable
From 192.168.113.215 icmp_seq=9 Destination Host Unreachable
From 192.168.113.215 icmp_seq=10 Destination Host Unreachable
From 192.168.113.215 icmp_seq=11 Destination Host Unreachable
64 bytes from 192.168.113.222: icmp_seq=12 ttl=64 time=10341 ms
64 bytes from 192.168.113.222: icmp_seq=13 ttl=64 time=10335 ms
^C
--- 192.168.113.222 ping statistics ---
35 packets transmitted, 2 received, +9 errors, 94% packet loss, time 34021ms
rtt min/avg/max/mdev = 10335.309/10338.322/10341.336/4.406 ms, pipe 11
controls@rossa:~ 0$ 

Note that 10 SECOND round trip time and 94% packet loss.  That's just beyond stupid.  I have no idea what's going on.

This has not been fixed!

Temporary solution: I ssh'd to nodus from the 40m wifi network and was able to connect to the FE machines.This works but the bandwidth is limited this way as expected.

40m MARS network needs to be fixed.

ELOG V3.1.3-