In order to do high quality huddle subtraction, we need to align the seismometer axes to high precision. We would need 1000x subtraction to see the instrument noise floor, but are likely to only get 100x. For that we need to align the axes to 0.5 deg (or do a Wiener coordinate transform with the data). To do this, we need to use a high quality bubble level and eventually iterate after trying out.

We should strain relieve the seismometer cables on the slab. It should be a tight clamp so that acoustic vibrations on the cables are terminated at the clamp and don't get to the seismometers. The clamp can be attached to the slab using some strong epoxy.

I have selected a set of 16 magnets which have a B field between 900 to 950 Gauss (5% variation) when measured in the following fashion.

I took a Petri-dish, of the type which we usually use for mixing the glue, and I placed a magnet on its end.  I then brought the tip of the Hall-probe into contact with the Petri-dish from the opposite side and adjusted the location (and orientation) of the probe to maximise the reading on the Gauss meter.

The distribution of magnets observed is listed below

The set of sixteen has been have been placed inside two test tubes and left on the optical bench (right-side)  in the clean room.

I am considering to have 3 to 6 motorized optical mounts at the PSL and end tables for remote beam steering.

Question 1:
Was there any issue on the PI 3-axis PZT on the PSL?
Why was it disabled (even before the PSL upgrade)?


Question 2:
Do we need two mount at a place? Or we do have one instead?

- Comparing the distance of the steering mirrors and that from the steering mirror to the cavity waist, induced shift
is mostly cancelled by angle adjustemnts of a either of the mounts.
i.e. Induced misalignments by the steering mirrors are nearly degenerated.

We need to move two steering mirrors only for the initial installation, but any drift felt by a cavity can be compensated by a single mirror.

Question 3:
Do we like PI-style 2 or 3 axis PZT mount with analog inputs on the HV amp?
Or do we like "Newport Agilis" style controller with USB connection?

Any opinion?

I discovered that I was not getting enough SNR on all the refl RFPDs when I actuated using the Sensing Matrix script.  The problem was that the ITMs have actuation constants that are a factor of 5 lower than the PRM.  So, I need to push on the ITMs (for MICH) about 5 times as hard as I push on the PRM (for PRCL).  I have modified the sensing matrix scripts to allow different actuation amplitudes for each degree of freedom.  If I watch the REFL PD spectra while the script is running, I see that I now have some actual SNR (as in, more than 1, which is what the SNR was for some diodes previously). 

A consequence of this is that the script to analyze past data will no longer work on sensing matrix data taken before this afternoon.  On the other hand, that data isn't very useful, since there was no SNR.

I have made some plots of the sensing matrix (PRCL / MICH amplitude ratio, and relative angle) versus Schnupp asymmetry for all the configurations that involve the power recycling cavity.  I am still meditating on what they mean for us, in terms of whether or not we should be changing our Schnupp asymmetry.

The Schnupp asymmetry scan starts at 1mm, rather than 0.  Also, recall that our current Schnupp asymmetry is 3.9cm.

PRMI:

DRMI:

PRFPMI:

DRFPMI:

The plots, with a log y axis

PRMI:

DRMI:

PRFPMI:

DRFPMI:

Interesting.
What's the reason why the PRMI/MICH ratio gets worse (larger) for 55MHz and 165MHz for the DRMI compared to the PRMI case?

I have modeled the PRMI sensing matrix as I bring the Xarm into resonance.  In optickle, I have the PRMI on sideband resonance, the ETMY is artificially set to have a transmission of 1, and the ETMX has it's nominal transmission of 15ppm.  I start with the ETMX's microscopic position set to lambda/4 (antiresonant for IR in the arm), and take several steps until the ETMX's microscopic position is 0 (resonant for IR in the arm).

Xarm antiresonant:

Modeled sensing matrix, units = W/m, Offset = 2.66e-07, phase in degrees
 
            MICH Mag   MICH Phase    PRCL Mag   PRCL Phase  
AS55         3.348E+04   142.248      5.111E+03    70.571    
POX11        3.968E+01   -66.492      1.215E+04    54.312    
REFL11       3.231E+05    24.309      9.829E+07   144.311    
REFL165      9.946E+03  -159.540      4.540E+05   -64.710    
REFL33       1.963E+04  -168.530      1.573E+06    -2.744    
REFL55       1.160E+06    -6.755      5.429E+07    86.895 

Xarm resonant:

Modeled sensing matrix, units = W/m, Offset = 0, phase in degrees
 
            MICH Mag   MICH Phase    PRCL Mag   PRCL Phase  
AS55         1.647E+06    57.353      3.676E+06   -81.916    
POX11        3.927E+02  -118.791      2.578E+04  -102.158    
REFL11       7.035E+05    61.203      1.039E+08   167.149    
REFL165      1.602E+04  -144.586      5.971E+05   -49.802    
REFL33       2.157E+04   171.658      1.940E+06    -9.133    
REFL55       1.822E+06     7.762      6.900E+07   101.906 

For REFL55, the MICH magnitude increases by a factor of 1.6, while the PRCL  magnitude increases by 1.3 .  The MICH phase changes by 15 degrees, while the PRCL phase also changes by 15 degrees.  Just eye-balling (rather than calculating), the other REFL PDs look to have similar-ish magnitude and phase changes.  Certainly none of them are different by orders of magnitude.

Movies forthcoming.

Here is the Sensing Matrix movie (sorry for the iffy quality - my movies usually come out better than this):

This is the sensing matrix for the sideband locked on PRMI, bringing the Xarm into resonance from anti-resonance, in 20 equally-spaced steps.  You can see the microscopic ETMX offset (units of meters) in the title of the figures.

I was surprised to see some of the 'jumps' in the sensing matrix that happen near the end, when the arm is almost in resonance.  I'm in the process of making movies of the error signals as the Xarm is brought into resonance.  I'll have to post those in the morning, since they're taking a long time to produce and save, however when I looked at a few, there is some weird stuff going on as we get close to resonance, even with the 3f signals. 

The modeling phone call is in the morning, but if anyone who is not regularly on the call has thoughts, I'm all ears.

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:

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.

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 

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  

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)

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 

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!

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

To my dismay, I found today that somebody had changed the oscillator frequencies for the sensing matrix infrastructure we have. The change happened 2 days and 2 hours ago (I write this at ~1230 on Saturday, 3/6), i.e. ~1030am on Thursday. According to the elog, this is when Anchal and Paco were working on the interferometer, but I can find no mention of these settings being changed. Not cool guys 😒 .

This was relatively easy to track down but I don't know what else may have been messed with. I don't understand how anything that was documented in the elog can lead to this weird doubling of the frequencies.

I have now restored the correct settings. The "sensing matrix" I posted last night is obviously useless.

I understand this mst be frustrating for you. But we did not change these settings, knowingly atleast. We have documented all the things we did there. The only thing I can think of which could possibly change any of those channels are the scripts that we ran that are mentioned and the burt restore that we did on all channels (which wasn't really necessary). We promise to be more vigilant of changes that occur when we are present in future.

I've been working on analyzing the data from the DRMI locks last week.

Here are the results of the sensing measurement.

Details:

1. The sensing measurement is done by using the existing sensing matrix infrastructure to drive the actuators for the various DoFs at specific frequencies (notches at these frequencies are turned on in the control loops during the measurement).
2. All the analysis is done offline - I just note down the times at which the sensing lines are turned on and then download the data later. The amplitudes of the oscillators are chosen by looking at the LSC PD error signal spectra "live" in DTT, and by increasing the amplitude until the peak height is ~10x above the nominal level around that frequency. This analysis was done on ~600seconds of data.
3. The actual sensing elements in the various PDs are calculated as follows:
   • Calculate the Fourier coefficients at the excitation frequency using the definition of the complex DFT in both the LSC PD signal and the actuator signal (both are in counts). Windowing is "Tukey", and FFT length used is 1 second.
   • Take their ratio
   • Convert to suitable units (in this case V/m) knowing (i) The actuator discriminant in cts/m and (ii) the cts/V ADC calibration factor. Any whitening gain on the PD is taken into account as well.
   • If required, we can convert this to W/m as well, knowing (i) the PD responsivity and (ii) the demodulation chain gain.
   • Most of this stuff has been scripted by EricQ and is maintained in the pynoisesub git repo.

The plotting utility is a work in progress - I've basically adapted EricQs scripts and added a few features like plotting the uncertainties in magnitude and phase of the calculated sensing elements. Possible further stuff to implement:

• Only plot those elements which have good coherence in the measurement data. At present, the scripts check the coherence and prompt the user if there is poor coherence in a particular channel, but no vetos are done.
• The uncertainty calculation is done rather naively now - it is just the standard deviation in the fourier coefficient determined from various bins. I am told that Bendat and Piersol has the required math. It would be good to also incorporate the uncertainties in the actuator calibration. These are calculated using the python uncertainties package for now.
• Print a summary of the parameters used in the calculation, as well as sensing elements + uncertainty in cts/m, V/m and W/m, on a separate page.
• Some aesthetics can be improved - I've had some trouble getting the tick intervals to cooperate so I left it as is for the moment.

Also, the value I've used for the BS actuator calibration is not a measured one - rather, I estimated what it will be by scaling the old value by the same ratio which the ITMs have changed by post de-whitening board mods. The ITM actuator coefficients were recently  measured here. I will re-do the BS calibrations over the weekend.

Noise budgeting to follow - it looks like I didn't set the AS55 demod phase to the previously determined optimal value of -82degrees, I had left it at -42 degrees. To be fixed for the next round of locking.

eSummary:

I don't think the proposed scheme for sensing and controlling the homodyne phase will work without some re-thinking of the scheme. I'll try and explain my thinking here and someone can correct me if I've made a fatal flaw in the reasoning somewhere.

Field spectrum cartoon:

Attachment #1 shows a cartoon of the various field components.

• The input field is assumed to be purely phase modulated (at 11 MHz and 55 MHz) creating pairs of sidebands that are in quadrature to the main carrier field.
• The sideband fields are drawn with positive and negative imaginary parts to indicate the relative negative sign between these terms in the Jacobi-Anger expansion.
• For our air BHD setup, the spectrum of the LO beam will also be the same.
• At the antisymmetric (= dark) port of the beamsplitter, the differential mode signal field will always be in the phase quadrature.
• I'm using the simple Michelson as the test setup:
  • The ITMs have real and (nearly) identical reflectivities for all frequency components incident on it.
  • The sideband fields are rotated by 90 degrees due to the i in the Michelson transmission equation.
  • The Schnupp asymmetry preferentially transmits the 55 MHz sideband to the AS port compared to the 11 MHz sideband - note that in the simple Michelson config, I calculate T(11 MHz) = 0.02%, T(55 MHz) = 0.6% (both numbers not accounting for the PRM attenuation).
• I think the cartoon Hang drew up is for the DRFPMI configuration, with the SRC operated in RSE.
  • The main difference relative to the simple Michelson is that the signal field picks up an additional 90 degrees of phase propagating through the SRC.
• For completeness, I also draw the case of the DRFPMI where the SRC is operated at nearly the orthogonal tuning.
  • I think the situation is similar to the simple Michelson

So is there a 90 degree relative shift between the signal quadrature in the simple Michelson vs the DRFPMI? But wait, there are more problems...

Closing a feedback loop using the 44 MHz signal:

We still need to sense the 44 MHz signal with a photodiode, acquire the signal into our CDS system, and close a feedback loop.

• The 44 MHz signal is itself supposed to be generated by the interference between the TEM00 55 MHz sideband from the IFO output with the TEM00 11 MHz sideband from the LO field (let's neglect any mode mismatch, HOMs etc for the moment).
• By splitting this beat signal photocurrent in two, mixing each part with an electrical 44 MHz signal, and digitizing the IF output of said mixers, we should in principle be able to reconstruct the magnitude and phase of the signal.
• The problem is that we know from other measurements that this signal is going to go through multiple fringes, and hence, we don't have a signal that is linear in the quantity we would like to control, namely the homodyne phase (either quadrature signal can be a candidate linear signal around a zero crossing, but when the signals are going through multiple fringes, neither signal stays linear).
• One possible way to get around this problem is to use a phase tracker servo - basically, close a purely digital feedback loop, using one of the demodulated quadratures as an error signal, and changing the demodulation phase digitally such that the signal stays entirely in the orthogonal quadrature. However, such a scheme relies on the signal magnitude remaining constant. If the "error signal" goes to zero for multiple reasons (rotation out of the quadrature being considered, or just that the signal itself goes to zero), then this technique won't work. Of course, the phase tracker doesn't know what the "phase" of the signal is, when it's magnitude is (nearly) zero.
• It is true that we always expect a "background" level of 44 MHz signal, from the 11 MHz and 55 MHz sidebands in the LO beam directly interfering, but this doesn't contain any useful information, and in fact, it'd only contaminate the phase tracker error signal I think.
• So we can't rely on the error staying in one quadrature (like we do for the regular IFO PDH signals, where there is no relative phase propagation between the LO and RF sideband optical fields and so once we set the demodulation phase, we can assume the signal will always stay in that quadrature, and hence we can close a feedback loop), and we can't track the quadrature. What to do? I tried to dynamically change the phase tracker servo gain based on the signal magnitude (calculated in the RTCDS code using sqrt(I**2 + Q^2), but this did not yield good results...

Next steps:

I don't have any bright ideas at the moment - anyone has any suggestions?🤔

Aside:

I wanted to check what kind of signal the photodiode sees when only the LO field is incident on the photodiode. So with the IFO field blocked, I connected the PDA10CF to the Agilent analyzer in "Spectrum" mode, through a DC block. The result is shown in Attachment #2. To calculate the PM/AM ratio, I assumed a modulation depth of 0.2. The RIN was calculated by dividing the spectrum by the DC value of the PDA10CF output, which was ~1V DC. The frequencies are a little bit off from the true modulation frequencies because (i) I didn't sync the AG4395 to a Rb 10 MHz signal, and (ii) the span/BW ratio was set rather coarsely at 3kHz.

I would expect only 44 MHz and 66 MHz peaks, from the interference between the 11 MHz and 55 MHz sideband fields, all other field products are supposed to cancel out (or are in orthogonal quadratures). This is most definitely not what I see - is this level of RIN normal and consistent with past characterization? I've got no history in this particular measurement. 

I got some feedback from Koji who pointed out that the phase tracker is not required here. This situation is similar to the phase locking of two lasers together, which we frequently do, except in that case, we usually we offset the absolute frequencies of the two lasers by some RF frequency, and we demodulate the resulting RF beatnote to use as an error signal. We can usually acquire the lock by simply engaging an integrator (ignoring the fact that if we actuate on the laser PZT, which is a frequency actuator, just a proportional feedback will be sufficient because of the phase->frequency conversion), the idea being that the error signal is frequently going through a zero-crossing (around which the sinusoidal error signal is approximately linear) and we can just "catch" one of these zero crossings, provided we don't run of actuation range.

So the question here becomes, is the RF44 signal a suitable error signal such that we can close a feedback loop in a similar way? To try and get more insight, I tried to work out the situation analytically. I've attached my thinking as a PDF note. I get some pretty messy complicated expressions for the RF44 signal contributions, so it's likely I've made a mistake (though Mathematica did most of the heavy lifting), it'll benefit from a second set of eyes. 

Anyways, I definitely think there is some additional complications than my simple field cartoon from the preceeding elog would imply - the relative phases of the sidebands seem to have an effect, and I still think the lack of the PRC/SRC make the situation different from what Hang/Teng et. al. outlined for the A+ homodyne phase control analysis. Before the HEPA failed, I had tried closing the feedback loop using one quadrature of the demodulated RF44 signal, but had no success with even a simple integrator as the loop (which the experience with the PLL locking says should be sufficient, and pretty easily closed once we see a sinusoidally oscillating demodulated error signal). But maybe I'm overlooking something basic conceptually?

The in-loop Y-Arm error signal looks equal to the beat note noise divided by the Y-Arm OL gain in the broadband-noise region (>20 Hz), which would be the case if the loop was dominated by sensor noise here.

I would re-check the Y-Arm dark noise, or at least check for coherence between the Y-Arm error signal and the beat signal above 20 Hz. The input-referred PDH box noise should not be flat there according to the LISO model, but that might be worth checking, too.

The Sensoray device is currently viewing Monitor 4 and plugged into Pianosa.  The user interface is run at /home/controls/Downloads/sdk_2253_1.2.2_linux/python demo.py. It can preview and capture the video stream, however the captured files are terrible. I believe it has something to do with the bitrate, since the captured video with lower bitrates are not as bad as the ones with higher bitrates, but  I am not certain.

 Turns out that the "MPEG-4 VES" video format is just bad for captured video.  Everything except "MP4" and "MPEG-TS" works for streaming, and "MP4" and "MPEG-TS" seem to be the only captured formats that can be viewed properly.

The highest resolution available is 720x480 pixels. Bit depth of captured images and video is most likely 16 bits per pixel. Video may be captured raw as well, which will be necessary for image subtraction/enhancement, however it cannot currently be played raw. A captured image is shown below, along with MP4 video.

Now that Mike has got the Sensoray working, Jenne/Suresh should grab some new images of the ETM cage as Keiko did so that we can analyze them for another mode matching diagnostic.

I've upgraded the Sensoray GUI so it can now switch the video channel it receives, thanks to the videoswitch script.

I have made little progress in getting the sensoray driver installed on Donatella. I have confirmed that it is indeed the reason why none of the hardware is working. I am now working through changes on a virtual machine that is running Scientific Linux to find something that may work. If no progress is made soon, I will ensure that software for a replacement video encoder is able to be installed before requesting we order one.

I have been looking at various replacements for the sensoray, and have found that the majority of new usb video encoders don't have drivers anymore and now just work through being embedded with video-capturing software. This means that the hardware must be used with a compatible video player such as VLC or OBS. VLC can natively be run with terminal commands, and because OBS is open source, there are packages that can be downloaded to use terminal commands to control the software as well. I am not sure to what extent the usb video encoder can then be controlled with these commands, but this seems to be the easiest method so far. I will finish picking which new unit we should purchase tomorrow, and order it through JC. 

To capture video with the Sensoray, open the GUI (python ./demo.py), simply press "Save," enter a filename, and hit "Stop" when you wish to stop recording. If you want to change the video format, there is a dropdown menu labelled "Format." I recommend MP4 for standard video, and nv12 for RAW video.

 I also installed mplayer on rossa, so we can play the videos there.

Even though Mike won't admit it, the video stuff is all in /users/sensoray/ .  I opened the demo.py from there, and it also works.

Video Capture with the Sensoray works again. Pianosa just needed mplayer installed for it to play properly.

I am currently working on getting the driver reinstalled on Donatella for the sensoray. An issue keeps arising that will not allow me to run "make" successfully in the unzipped driver folder. Will continue to remedy this.

This is why there is no light showing up on the device while plugged in. The computer does see the device, but does not show its model due to the inability for it to communicate without the driver.

-Alex

 Joe and Kiwamu

We discussed about our CDS plan for this September. The summary of the plan and "to do list" are now on the wiki page;

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/CDS/September_CDS_plan

  Basically there are three major missions that we will do in this month;

 We also try to keep updating the wiki page.

All the serial vacuum signals are now interfaced to the new digital controls system. A set of persistent Python scripts will query each device at regular intervals (up to ~10 Hz) and push the readings to soft channels hosted by the modbus IOC. Similar scripts will push on/off state commands to the serial turbo pumps.

IP Addresses/Comm Settings

Each serial device is assigned an IP address on the local subnet as follows. Its serial communication parameters as configured in the terminal server are also listed.

Hardware Modifications

• Each of the five vacuum gauge controllers has an RJ45 adapter installed directly on its DB9/DB25 output port. Because the RJ45 cable now plugs directly into the terminal server, instead of passing through some additional adapters as it formerly did, it was necessary to reverse the wiring of the controller TXD and RXD pins to Ethernet pins. The DB9/25-to-RJ45 adapters on the back of the controllers are now wired as follows.
  • For the MKS controllers: DB2 (RXD) --> Eth4;  DB3 (TXD) --> Eth5;  DB5 (RTN) --> Eth6
  • For the Granville-Phillips controllers: DB2 (TXD) --> Eth5;  DB3 (RXD) --> Eth4;  DB7 (RTN) --> Eth6
• I traced a communications error with the GP307 gauge controller all the way back to what I would have suspected least, the controller itself. The comm card inside each controller has a set of mechanical relay switches which set the communications parameters (baud rate, parity, etc.). Knowing that this controller was not part of the original installation, but was swapped in to replace the original in 2009, I pulled the controller from the rack and checked the internal switch settings. Sure enough, the switch settings (pictured below) were wrong. In the background of the photo is the unit removed in 2009, which has the correct settings. After setting the correct communications parameters, the controller immediately began communicating with the server. Did these readouts (PRP, PTP1) never work since 2009? I don't see how they could.

Summary 

I have been working on setting up a serial-link with the temperature controller of the PPKPT crystal doubling oven at the Y-end for some time now. The idea was to remotely tune the PID gains of the controller and get temperature data. The device used to serially interface with the temperature controller is a Raspberry Pi model B, which is connected to the temperature controller by means of a USB to serial adaptor with a PL2303 chip. I installed the interface this morning, and have managed get talking with the doubling oven. I am now able to collect time-series data by ssh-ing to the Raspberry Pi from the control room. I will use this data to manually tune the PID gains for now, though automatic tuning via some script is the long-term goal.

Details 

The temperature controller for the doubling oven is a Thorlabs TC200, and supports serial communication via the RS232 protocol by means of a female DB9 connector located on its rear panel. I have hooked up the Raspberry Pi to this port by means of a USB-Serial adaptor that was in one of the cabinets in the 40m control room. After checking the Martian Host Table, I assigned the Raspberry Pi the static IP 192.168.113.166 so that I could ssh into it from the control room and test the serial-link. This morning, I first hooked up the Raspberry pi to an ethernet cable running from rack 1Y4 to make sure I could ssh into it from the control room. Having established this, I moved the raspberry pi and its power supply to under the Y-endtable, where it currently resides on top of the temperature controller. I then took down the current settings on the temperature controller so that I have something to revert to if things go wrong: these are

Set-Point:                           35.7 Celcius

Actual Temperature:          35.8

P-gain:                                 250

I-gain:                                 60

D-gain:                                25

TUNE:                                  ON

I then connected the Pi to the temperature controller using the serial-USB cable, and plugged the ethernet cable in. Rebooted the Pi and ssh-ed into it from the control room. I first checked the functionality of the serial-link by using terminal's "screen" feature, but the output to my queries was getting clipped on the command line for some reason (i.e. the entire output string wasn't printed on the terminal window, only the last few characters were). Turns out this is some issue with screen, as when I tried writing the replies to my queries to a text file, things worked fine. 

At present, I have a python script which can read and set parameters (set-point temperature, actual temperature, PID gains)on the controller as well as log time-series data (temperature from the temperature sensor as a function of time )to a text file on the Pi. As of now, I have only checked the read functions and the time-series logger, and both are working (some minor changes required in the time-series function, I need to get rid of the characters the unit spits out, and only save the numbers in my text-file). 

For the time-being, I plan to apply a step to the controller and use the time-series data to manually tune the PID parameters using MATLAB. I am working on a bunch of shell scripts to automate the entire procedure.

There has been a series of earthquakes since the big 7.0 in Alaska this morning.

None of the watchdogs were tripped when I came in. But I could not retrieve any info about the suspensions from fast channels because c1sus was not talking to the fb and that required an mxstream restart to fix it.

MC is trying to lock itself, but the seismic doesn't seem to get quiet. So MC is not all that happy.

Bad CDS team. Bad.

The servo gain for MC1 in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/reliefWFS was flipped to account for COIL_GAIN flip done in 40m/16898.
The reliefWFS script now works fine.

ezcaservo -r 'C1:SUS-MC2_ASCPIT_OUT16' -g ${g} -t ${ts} C1:SUS-MC2_PIT_COMM & 
ezcaservo -r 'C1:SUS-MC2_ASCYAW_OUT16' -g ${g} -t ${ts} C1:SUS-MC2_YAW_COMM & 
ezcaservo -r 'C1:SUS-MC1_ASCPIT_OUT16' -g -${g} -t ${ts} C1:SUS-MC1_PIT_COMM &  
ezcaservo -r 'C1:SUS-MC1_ASCYAW_OUT16' -g -${g} -t ${ts} C1:SUS-MC1_YAW_COMM & 
ezcaservo -r 'C1:SUS-MC3_ASCPIT_OUT16' -g ${g} -t ${ts} C1:SUS-MC3_PIT_COMM & 
ezcaservo -r 'C1:SUS-MC3_ASCYAW_OUT16' -g ${g} -t ${ts} C1:SUS-MC3_YAW_COMM & 
 

To get ready for the PRFPMI CM trials tonight, I put AS55's cables back to their nominal state, and now have REFL11 I going to IN1 of the CM board.  The OUT1 of the CM board goes to the REFL11I whitening channel.

REFLDC was not disconnected in the last few days, so it is still set up for IN2 of the CM board, with an external offset adjust.

The Marconi frequency was tuned by looking at 

1. The ~3.68 MHz (= 3*f1 - fIMC) peak at the IMC servo error point, TP1A, and
2. The ~25.8 MHz (= 5*f1 - fIMC) peak at the MC REFL PD monitor port. The IMC error point is not a good place to look for this signal because of the post-demodulation low pass filter (indeed, I didn't see any peak above the analyzer noise floor).

The nominal frequency was 11.066209 MHz, and I found that both peaks were simultaneously minimized by adjusting it to 11.066195 MHz, see Attachment #1. This corresponds to a length change of ~20 microns, which I think is totally reasonable. I guess the peaks can't be nulled completely because of imbalance in the positive and negative sidebands. 

Then, I checked for possible offsets at the IMC error point, by injecting a singal to the AO input of the IMC servo board (using the Siglent func gen), at ~300 Hz. I then looked at the peak height at the modulation frequency, and the second harmonic. The former should be minimized when the cavity is exactly on resonance, while the latter is proportional to the modulation depth at the audio frequency. I found that I had to tweak the MC offset voltage slider from the nominal value of 0V to 0.12 V to null the former peak, see Attachment #2. After accounting for the internal voltage division factor of 40, and using my calibration of the IMC error point as 13 kHz/V, this corresponds to a 40 Hz (~50 microns) offset from the true resonant point. Considering the cavity linewidth of ~4 kHz, I think this is a small detuning, and probably changes from lock to lock, or with time of day, temperature etc.

Conclusion: I think neither of these tests suggest that the IMC is to blame for the weirdness in the PRMI sensing, so the mystery continues.

I ramped the PMC gain slider to find where it oscillates. It starts going bad at ~13 dB, so the new default gain is 7 dB to give us some margin for alignment improvements, etc.

I also fixed the TIME field in our MEDM screens by adding the following text to the C1IFO_STATE.db file which runs on c1iscaux:
grecord(stringin, "C0:TIM-PACIFIC_STRING")
{
    field(DESC, "Current time and date")
    field(DTYP, "EPICS IOC VAR")
    field(SCAN, "1 second")
    field(INP, "C1:FEC-34_TIME_STRING")
}

grecord(stringin, "C0:IFO-TIME_PACIFIC")
{
    field(DESC, "Current time and date")
    field(DTYP, "EPICS IOC VAR")
    field(SCAN, "1 second")
    field(INP, "C1:FEC-34_TIME_STRING")
}
This gets the time info from the c1ioo processor via channel access and gives it these mroe reasonable names. The first record is for backwards compatibility. The second record is a better name and we should use it in the future for all new screens. I had to reboot c1iscaux several times to figure out the right syntax, but its OK now. You have to reopen stale screens to get the field to refresh.

This avoids the previous idea of changing all of the MEDM screens.

Riju, Elli

Today tried to take our first cavity scan.  We unplugged the 55MHz sideband input from the RF combiner on the PSL table, and connected a network analyser instead.  Using the network analyzer we injected a 12dBm signal (swept from 32MHz to 45MHz) through the RF combiner into the EOM to create our swept sidebands.  We measured the  MC cavity response by looking at the signal comming out of the RF photodiode on the MC2 table.  I replaced the BNC cable connected to the RF PD with a longer BNC cable that could reach our network analyzer next to the PSL table.  Riju will post a diagram of our setup.

We didn't see the expected carrier resonances when we performed a cavity scan.  The light incident on the RF PD is around 0.7micro Watts and we are still thinking about whether this is strong enough to see our signal above the noise.  We also want to work out what the strength of our swept sidebands is.  We will attempt to do a 'real' cavity scan tomorrow.

I have done the following thus far since elog #14626:

Simulation:

1. Cleaned up Pooja's code for simulating the beam spot. Added extensive comments and made the code modular. Simulated the Gaussian beam spot to exhibit 
   1. Horizontal motion
   2. Vertical motion
   3. motion along both x and y directions:
2. The motion exhibited in any direction in the above videos is the combination of four sinusoids at the frequencies: 0.2, 0.4, 0.1, 0.3 Hz with amplitudes that can be found as defaults in the script ((0.1, 0.04, 0.05, 0.08)*64 for these simulations.). The variation looks as shown in Attachment 1. For the sake of convenience I have created the above video files with only a hundred frames (fps = 10, total time ~ 10s) and this took around 2.4s to write. Longer files need much longer. As I wish to simply perform image processing on these frames immediately, I don't see the need to obtain long video files right away.
3. I have yet to add noise at the image level and randomness to the motion itself.  I intend to do that right away. Currently video 3 will show you that even though the time variation of the coordinates of the center of the beam is sinusoidal, the motion of the beam spot itself is along a line as both x and y motions have the same phase. I intend to add the feature of phase between the motion of x and y coordinates of the center of the beam, but it doesn't seem all too important to me right now. The white margins in the videos generated are annoying and make tracking the beam spot itself slightly difficult as they introduce offset (see below). I shall fix them later if simple cropping doesn't do the trick.
4. I have yet to push the code to git. I will do that once I've incorporated the changes in (3).

Circle detection:

1. If the beam spot intensity variation is indeed Gaussian (as it definitely is in the simulation), then the contours are circular. Consequently, centroid detection of the beam spot reduces to detecting these contours and then finding their centroid (center). I tried this for a simulated video I found in elog post 14005. It was a quick implementation of the following sequence of operations: threshold (arbritrarily set to 127), contour detection (video dependent and needs to be done manually), centroid determination from the required contour.  Its evident that the beam spot is being tracked (green circle in the video). Check #Attachment 2 for the results. However, no other quantitative claims can be made in the absence of other data.
2. Following this, Gautam pointed me to a capture in elog post 13908. Again, the steps mentioned in (1) were followed and the results are presented below in Attachment #3. However, this time the contour is no longer circular but distorted. I didn't pursue this further. This test was just done to check that this approach does extend (even if not seamlessly) to real data. I'm really looking forward to trying this with this real data.
3. So far, the problem has been that there is no source data to compare the tracked centroid with. That ought to be resolved with the use of simulated data that I've generated above. As mentioned before, some matplotlib features such as saving with margins introduce offsets in the tracked beam position. However, I expect to still be able to see the same sinusoidal motion. As a quick test, I'll obtain the fft of the centroid position time series data and check if the expected frequencies are present.

I will wrap up the simulation code today and proceed to going through Gabriele's repo. I will also test if the contour detection method works with the simulated data. During our meeting, it was pointed out that when working with real data, care has to be taken to synchronize the data with the video obtained. However, I wish to put off working on that till later in the pipeline as I think it doesn't affect the algorithm being used. I hope that's alright (?).

[Ian,Tega]

Today we continued working on setting up the 6 degrees of freedom model for testing the suspension which we copied over from  "/cvs/cds/rtcds/userapps/release/sus/c1/models/c1sup.mdl" to c1sp2.mdl in the same folder. We then changed the host from c1lsc to c1sus2, changed cpu # from 7 to 3 bcos c1sus2 has 6 cores. Then ran the following commands to build and install the model on c1sus2:

$ ssh c1sus2

$ rtcds make c1sp2

$ rtcds install c1sp2

where we encountered the following installation error:

It seems that changing the model name and host did not change the node allocation, so will remove the previous entries in testpoint.par to see if that helps. After deleting the following lines

[C-node62]
hostname=c1lsc
system=c1sup

from the file "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par", the installation went fine and the above entries were replaced by 

[C-node62]
hostname=c1sus2
system=c1sp2

BTW, I now believe the reason we had the node conflict earlier was bcos both models still had the same value of  dcuid=62, so I think changing this value in our model file would be a better solution. Work is ongoing.

Please don't put it on c1sus2. Put it on the completely independent test stand as we discussed Wednesday. You must test the controller on the simplant and verify that they thing is stable and works, before putting it in the 40m network.

[Ian, Tega]

We combined a controler and a plant model into a single modle (See first attachment) called x1sus_cp.mdl in the userapps folder of the cymac in c1sim. This model combines 2 blocks: the controler block which is used to control the current optics and is found in cvs/cds/rtcds/userapps/release/sus/c1/models/c1sus.mdl further the control block we are using comes from the same path but from the c1sup.mdl model. This plant model is the bases for all of my custom plant models and thus is a good starting point for the testing. It is also ideal because I know it can beeasily altered into a my state-space plant model. However, we had to make a few adjustments to get the model up to date for the cds system. So it is now a unique block.

These two library blocks are set in the userapps/lib folder on the cymac. This is the lib file that the docker system looks to when it is compiling models. For a quick overview see this. All other models have been removed from the MatLab path so that when we open x1sus_cp.mdl in MatLab it is using the same models it will compile with.

We could not find the rtbitget library part, but chris pointed us to userapps, and we copied it over using: scp /opt/rtcds/userapps/trunk/cds/common/models/rtbitget.mdl controls@c1sim:/home/controls/simLink/lib.

NOTE TO FUTURE IAN: don't forget that unit delays exist.

Next step: now that we have a model that is compiling and familiar we need to make medm screens. We will use the auto mdl2adl for this so that it is quick. Then we can start adding our custom pieces one by one so that we know that they are working. We will also work with Raj to get an independent python model working. Which will allow us to compare the cds and python models.

[Cici, Deeksha]

On Friday Cici and I set up the Mokulab to take readings of our loop. The aim is to characterise the PZT, in a similar manner as before, by exciting the circuit using our input noise (a swept sine) and recording the corresponding changes in the output. We used the MokuLab to observe the beat note created by the signals of the AUX and PSL, as well as the ASD of the output signal. The MokuLab simplifies the entire process.

Pictured : The beat note as observed by Cici

The MC / WFS stability seemed off to me. Trending some channels at random, I saw that the MC3 PIT/YAW gains were restored mixed up (PIT was restored to YAW and vice versa) in the last day sometime - I wasn't sure what other settings are off so I did a global burtrestore from the last time I had the interferometer locked since those were settings that at least allow locking (I am not claiming they are optimal).

How are these settings being restored after the suspension optimization? If the burtrestore is randomly mixing up channels, seems like something we should be worried about and look into. I guess it'd also be helpful to make sure we are recording snapshots of all the channels we are changing - I'm not sure if the .req file gets updated automatically / if it really records every EPICS record. It'd be painful to lose some setting because it isn't recorded.

Unconnected to this work - the lights in the BS/PRM chamber were ON, so I turned them OFF. Also unconnected to this work, the summary pages job that updates the "live" plots every half hour seem to be dead again. There is a separate job whose real purpose is to wait for the data from EOD to be transferred to LDAS before filling in the last couple of hours of timeseries data, but seems to me like that is what is covering the entire day now.

The mix up was my fault I think. I restored the channels manually instead of using burt restore. Your message suggests that we can set burt to start noticing channel changes at home point and create a .req file that can be used to restore later. We'll try to learn how to do that. Right now, we only know how to burt restore using the existing snapshots from the autoburt directory, but they touch more things than we work on, I think. Or can we just always burt restore it to morning time? If yes, what snapshot files should we use?

Indeed, you can make your own snapshot by specifying the channels to snap in a .req file. But what I meant was, we should confirm that all the channels that we modify are already in the existing snapshot files in the autoburt dir. If it isn't, we should consider adding it. I think the whole burt system needs some cleaning up - a single day of burt snapshots occupies ~400MB (!) of disk space, but I think we're recording a ton of channels which don't exist anymore. One day...