I have implemented automatic triggered switching of the analog whitening (and digital dewhitening). 

The trigger is the same as the degree of freedom trigger.  On the LSC RFPD screen there is a space to enter the amount of time (in seconds) you would like to wait between receiving a trigger and actually having the whitening filter switch. 

The trigger logic is as follows: 

* For each column of the LSC input matrix (e.g. AS11 I), check if there is a non-zero element.  If there is a non-zero element (indicating that we are using that PD as the error signal for a degree of freedom), check if the corresponding DoF has been triggered.  Repeat for all columns of the matrix. 

* If either the I or the Q signal from a single PD is being used, send a trigger in the direction of the PD signal conditioning / phase rotation blocks.  (Since the whitening happens before the phase rotation, we want to have the whitening state be the same for both the I and Q signals coming from the demod boards.

* Before actually changing the whitening state, wait for the amount of time indicated on the RFPD overview screen.

* Switch the digital dewhitening.  If the digital dewhitening is on, send a bit over to the binary I/O to switch the analog whitening on.

This required changing the LSC RF_PD library part so that you can send the trigger to the filter bank from outside that part..  This part is in use by all LSC models, so I'll make sure the LLO people are aware of this change before I commit it to the svn.

While I was working on the LSC model, I also put in a wait between the time that the filter module trigger is received, and when it actually switches the filter modules.  So far, this time is defined for a whole filter bank (so all filters for a given DoF still switch at the same time).  If I need to go back and make the timing individual for each filter module, I can do that.  This new EPICS variable (the WAIT) defaults to zero seconds, so the functionality will not change for anyone who uses this part.

These changes also require 2 pieces of c-code:  {userapps}/cds/common/src/wait.c and {userapps}/isc/c1/src/inmtrxparse.c

After Den's work with the ASS model this week, all of the channel names were changed (this wasn't pointed out in his elog....grrr), so none of the A2L scripts worked. 

They are now back, however there is still some problem with the plotting that I'm not sure I understand yet.  So, the measurement works, but I don't think we're saving the results and we certainly aren't plotting them yet. 

I wanted to check where the spots are on the mirrors, to make sure Den's stuff is doing what we think it's doing.  All of the numbers were within ~1.5mm of center, although Rossa keeps crashing (twice this afternoon?!?), so I can't copy and paste the numbers into the elog.

A near-term goal is to copy over Den's work on the Yarm to the Xarm, so that both arms will auto-align.  Also, I need to put the set of alignment scripts in a wrapper, and have that wrapper call-able from the IFO Configure screen.

Also, while thinking about the IFO Configure screen, the "save" scripts weren't working (on Rossa) today, even though I just made them work a week or so ago. Rossa, at least, was unhappy running csh, so I changed the "save" script over to bash.

Are 4 of these spring loaded pins enough?  I'm not sure how one pin can hold 2 lids at each point.  It seems like we need 8 pins.

 Steve has explained to me that the pins will go in between the 2 lids, with a big washer, so that one pin holds both lids at the same time.  4 is the right number.

Koji is working on PRMI locking, and while he was doing that I glanced at the oplevs' spectra for the ITMs and PRM.

I found that when the PRMI was locked (for only 1 second or so max lock time) on the 55MHz sideband, and the error signals show a big peak around 400Hz (definitely audible in the control room), the only OpLev that I see a similar peak in is ITMX pitch. 

In the plot below, I have grabbed a time when the PRMI was flashing as the black reference traces, and then a time when the PRMI was locked as the active traces.  You can see that there is a similar peak in both REFL55I and ITMX_OL_PIT when the cavity is locked. 

I think you have the splitter that splits the RF signal from the network analyzer in the wrong place. 

Usually you split the signal immediately after the RF Out, so that half of the signal goes to the A-input of the Analyzer, and the other half goes to your controller (here, the laser diode controller).  Then you would take the output of your controller and go straight to the actual laser diode, with no splitting in this path.

Den made a nice elog about the PRMI RIN that we see a few weeks ago:  8464.  The RIN that we're seeing is typically about ~30%.  The question at hand is: what is causing this power fluctuation, and more specifically, is it the angular motion of the mirrors?

I find that no, the angular motion that we see does not explain the RIN that we see.

In the attached Mathematica notebook, I calculate the power lost due to angular misalignments of one or more mirrors.  (Math comes from Appendix A of Keita's thesis.)

From calibrated oplev spectra, our mirrors are moving about 1 microradian (RMS, which is dominated by low frequencies).  From a super sophisticated "draw on the TV, then measure" method (details below), I have estimated that the maximum static misalignment that we're seeing is about 2 microradians.

With all of this, I find that for a g-parameter of 0.94, the power lost due to misalignments should, at maximum, be 0.6%.  I need a g-parameter of 0.995 to get a power loss of 23%.  Alternatively, if I take the derivative of the power coupling function, to find the static misalignment at the steepest slope of the curve (and thus, the place where any AC misalignment would have the most effect), for 1urad of AC misalignment, I get 40% power loss. 

So, in order for the AC angular motion that we see to explain the RIN that we see, either our mirrors are very, very misaligned (so much so that we couldn't really be locking), or our cavity is much closer to unstable than expected from Jamie's calculations.  Since both of these cases (static misalignment or incorrect g-parameter calculation) have to be taken to extremes before they approximate the RIN that we see, I do not think that this power loss is due to angular fluctuations.

This means that we have to think of another potential cause for this RIN that we're seeing.

Details on the "draw on TV and measure" technique for determining static cavity misalignments:  Looking at the POP camera view, with the PRM significantly misaligned, I traced the straight-through beam spot.  I then restored the PRM, and during several momentary locks, I traced the beam spot, which I took to be the saturated area of the camera.  The idea here is that the straight-through beam represents the incident beam axis, while the locked beam represents the cavity axis.  I'm assuming that the camera image plane is at the face of PR2. I approximately found the center of each of my tracings, and found them to be ~1/4 inch apart.  I also measured the "spot size" of the sideband-locked PRMI, and found it to be ~3.5 inches.  So, very roughly, the ratio of (distance between spots)/(size of beam) is ~0.07. This corresponds to a static misalignment of either the ITM or the PRM of ~2urad, rounding up. (I use the Jamie's calculated g-parameters from elog 8316, the case of flipped PR2, tangential = 0.94 to calculate the effective RoC of the PRM). 

Koji is elogging separately of his exploration of different configurations.  The lock stretch that I'm looking at here uses the same parameters as Koji had for PRMI sb lock, using AS55Q for MICH and REFL33I for PRCL, with MICH gain of -0.8 and PRCL gain of 0.05 .

All of these plots are the same few second lock stretch, with different zooming.  Jamie's super-sweet getdata python script only accepts integers for the start time and duration parameters, so lots of this zooming happened by hand, but I tried to always keep the time axis aligned within each screenshot.  Sometimes the plot axis labels say differently, but they're lying to you.

Plot 1:  gps start time is 1050915916, duration = 6 seconds.  Overall view of the lock stretch.

Plot 2:  gps start time is 1050915921, duration = 1 second.  We're looking at the lockloss that happens at the left side of the plots.

Plot 3:  zoomed in (along the time-axis) version of plot 2, so much shorter time duration.  Some zooming on y-axes.

Plot 4:  zoomed in (along y-axes) version of plot 2.

It seems to me from these plots that maybe MICH CTRL is drifting away?  It seems like we lose the MICH lock, and that destroys the whole thing. 

Koji made some comments to me earlier, regarding his work this evening, that the MICH signal quality is poor in general, and that we should calculate/think about changing our schnupp asymmetry. 

[Jenne, Annalisa, with guidance from Koji]

We took data to remeasure the Schnupp asymmetry, using the Valera method that Jamie described in elog 4821. 

1  First, we locked the arms each with their PO(X,Y) signals, to get the alignment of each arm. 

2.  Then, we locked the Xarm with AS55I (Yarm optics, and PRM very misaligned, more than the misalign script).  Since AS55 was saturating, I changed the analog gain from 24dB to 21dB. (After work was completed, the analog gain was put back to the nominal 24dB for both I&Q.)

3.  We set up the Lockin similar to Jamie's description, with a few differences.  We used the same f = 103.1313, but used ampl=10cts.  Sin and cos gain were each 100.  We changed the lowpass filter from 0.1Hz to 0.05Hz (so each measurement had a settling time of at least 20sec).  We were using LSC-Lockin4, so the Lockin matrix was set so Lockin4 was reading from AS55Q, and the LSC output matrix was such that we were actuating on the ETM (X, then Y when we switched arms later).

4.  By hand, we roughly found the zero crossing of the lockin-q output (which corresponded also to zero of the lockin-I, since this is the place where all of the PDH signal was in AS55I, and the lockin was reading AS55Q). 

5.  We took points separated by 0.2 degrees, plus and minus 1 degree from the zero-crossing phase we had found (i.e., for the Xarm, we roughly found the zero crossing at -14.39 deg, so took data from -15.39 to -13.39degrees).  For each phase, we took 5 measurements (using ezcaread), at least 20 seconds apart.  After moving the phase, we waited at least ~40 seconds (watching the lockin outputs on striptool, they had completely settled after 30 or 40 seconds).

6.  We then repeated steps 2, 4 and 5 for the Y arm.  The lockin setup didn't change, except that now we actuate on ETMY.

We did a quick estimate calculation, from our rough zero-crossings to get a rough measurement of the Schnupp asymmetry.  DeltaPhi = (-14.39 -   -19.79) = 5.40 . This gives us (using F_sideband = 5*11066134, the current 11MHz marconi freq) a rough Schnupp asymmetry of 4 cm. 

Analysis to follow.

EDIT, JCD:  The Xarm gain at this time was -0.160, and the Yarm gain was -0.170

I was sad to see that there wasn't a photo of the POX situation after the fiber work was done on Thursday.

Also, I was out looking at something else, and noticed that the fibers aren't in a very good/safe place from the POX table over to your splitter.  Getting to the POX table is certainly more tricky than the AP table, since the fiber splitter is right next to the AP table, but we should go back and try to make sure the fibers to the more distant tables are laid in a nice, safe way.

Is there a reason that we're not using the clear plastic tubing that Eric bought to put the fibers into?  It seems like that would help a lot in keeping the fibers safe.

I took a few photos of the things that I'm sad about:

1. We should not be keeping fibers on the floor in an area where they can be stepped on.  This will be fixed (I hope) as part of putting the extra coiled length over by the splitter.

2. Again, in an area where we semi-regularly walk, the fibers should not be a tripping hazard.  Behind the table legs (rather than under the middle of the table) is safer, and will help tuck them out of the way.

3.  It's not obvious when we're pumped down, but we remove the access connector (top right side of this photo), and need to walk in this area.  I can pretty much guarantee that within 1 day of the next time we vent, these fibers will be stepped on, tripped over, and broken if they are not moved to a different location.  I'm not yet sure what the best way to route these fibers is, but this is not it. 

Riju, since Eric will be away next week, please let one of us "40m Regulars" know when you plan to come over (at least a few hours ahead of time), and we can give you a hand in protecting these fibers a little bit better.  Thanks!

While helping Riju out this afternoon, I noticed that the timing fiber that goes to the OMC rack (near the AP table) was bent, and is now possibly kinked, after the installation of the fiber splitter box. 

The fiber was hanging from the back of the rack, and had been strain relieved.  However, the path that the fiber was taking is now occupied by the fiber splitter for the RF PD diagnostic stuff.  So, the installation of the fiber splitter box put the old timing fiber under tension, causing the fiber to be bent at a little over 90 degrees, since it was pulled tightly against the corner of the splitter's front panel. 

I adjusted the strain relief so that the fiber is loose again, although there is still a bit of a kink that you can feel.  Things (for now) seem to be working, since the 1pps light on the front of the box at the top of the OMC rack is still blinking happily, indicating that the 1pps is still getting there. 

We are not using most of the stuff in that rack right now, but if we have problems in the future, we should check out the fiber to make sure it is still good.

I'm not sure why or when it was tripped, but I have restored the ETMX watchdog.

Nice work.  That was a lot of effort, but having done it so nicely will definitely pay off, since it is now much harder to break the fibers.

2 small issues:  In your attachment 3, I see a coil of fiber just outside the POX table.  I thought Koji had asked that all spare coiled-up length of fiber always be at the splitter side.  Also, in securing the plastic tubing as it comes down near the PSL table, you have zip-tied the tubing to the PSL table.  Since that is a space that we need to access to align the Xgreen beatnote stuff, please disconnect that zip tie, and secure the tubing on the north side somewhere, underneath the AP table, rather than the PSL table (when you look closer, you may notice that no cables in that bundle are attached to the PSL side at the bottom, for this same reason). 

Back when Gabriele was here, he and I implemented online calibration of the oplevs, into microradians.  A consequence of this is that all of the XY-plots on the medm screens were too small. 

I have gone through all the screens that I could think of (SUS_SINGLE, SUS_SINGLE_OPTLEV_SERVO, OPLEV_MASTER, OPLEV_SUMMARY, OPLEV_SUMMARY_SMALL_SCALE, IFO_OVERVIEW) and made the range of the XY-plots +/- 100, rather than the old scale of +/-1. 

I have also added red boxes behind the numbers on many (but not yet all) of these screens, so that you can see when (a) the oplev sum is too low, or (b) either the pit or yaw value is over 50 microradians. 

While I was putzing around on the IFO overview screen, I also made the oplev sum numbers clickable, with the related display being that optic's oplev servo screen.

I have found in the depths of the elog the (original?) list of fibers and lengths that were decided upon:  elog 6535.

In Suresh's elog, we were assuming that POP22 & POP110 would be served by a single PD.  This is still the nominal plan, although we (Rana is maybe still thinking about this in the back of his head?) think that it might not be feasible.  Riju and I were hoping to put a 4th fiber in the tubing so that we wouldn't have to add it later if POP22 & POP110 are eventually 2 separate PDs.  Anyhow, for now, all we have available are 3 fibers for the POX table, so that is what was installed this afternoon.

Koji is working on PRMI locking with different photodiodes, and rather than typing different numbers into the input matrix, it is more convenient to just be able to click on/off buttons for different filter banks.  So, the CARM filter bank in the LSC model is currently being borrowed as a secondary PRCL filter bank.  I have copied all of the current PRCL filters over to the CARM filter bank. 

Just for reference, although we have not yet used CARM for CARM, the previous filters were the "default" set, +6dB, 0:1, 1:5, 1:50, 1000:10, RG3.2, RG16.5, RG24, empty, empty.  These are currently the same in the DARM and MC filter banks, so we can copy them back over in the future.

 Koji set the IFO in a PRM-ITMY configuration for me, while I went to put a lens on the POP path.  Before putting the lens, the maximum average output that I saw from the diode (on a 'scope) was 4.40mV.  After putting in the lens and realigning the beam onto the diode, the new max DCvalue that I saw was 21.6mV.  This is a factor of 4.9. 

EDIT:  The dark value was -3.20mV, so actually the ratio is ~3.25 .

I have not yet done anything to fix the situation of the large angle of incidence on the first out-of-vac steering mirror.

I have looked at / analyzed the Schnupp data that Annalisa and I took last week, as well as some more Yarm data that I took this week.

I only have one set of Xarm data, but 3 sets of Yarm data.  I had intended to do careful error analysis of the data, but from the 3 sets of Yarm data, the variance in the answer I get using any one of the Yarm sets is much larger than the error in a single measurement.

Using the central Yarm zero crossing, I get a Schnupp asymmetry of 3.9cm.  The other 2 Yarm data points give Schnupp asymmetries of 3.7cm and 4.1cm, so I'm claiming a value of 3.9 +\- 0.2cm . This is within error of Jamie's measurement of 3.64 ± 0.32 cm (elog 4821).

Koji spent some time earlier this evening exploring where the excess RIN that we see in the PRC is coming from. 

He did this by locking the PRMI (MICH on AS55Q, PRCL on REFL33I, Pnorm for MICH = sqrt(POP110) with 0.1, Pnorm for PRCL = sqrt(POP110) with 10, MICH gain = -30, PRCL gain = 8), and then exciting each relevant optic, one at a time, in yaw.  The excitation was always using the ASCYAW excitation point on each of the optics (BS, PRM, ITMX, ITMY), with a frequency of 4.56 Hz, and an amplitude of 30 counts.

He also took reference traces with no optics excited.

Here, I plot (for each excited optic separately) the reference traces and traces during excitation for POP110_I_ERR, POPDC, and the OPLEV_YERROR for the optic that is being excited.

What we are looking for (only in yaw, since we see on the cameras that the dominant motion is in yaw) is an increase in POPDC and POP110 at the same frequency as an optic's excitation. 

We see that neither ITM is contributing a noticeable amount to either POPDC or POP110.  BS is contributing a little bit, but PRM is clearly contributing.  No this entry should be read. (KA)

A week or two ago, I calculated in elog 8489 that the angular motion that we see does not explain the RIN that we're seeing, unless our cavity is much more unstable than Jamie calculated in elog 8316. 

I think that I need to install one of the T240's on the new granite slab, and see what kind of coherence we have between seismic and PRM yaw motion, and if FF can get rid of it.

While looking over Koji's shoulder earlier, I noticed the big peak in the PRM yaw spectrum (and I was starting to get annoyed by the hum....the fibox is so useful in motivating tasks that otherwise get looked over!) 

I used DTT's peak find feature (cursor tab, enable both cursors, select Peak X/Y as your 'statistic', set the 2 cursors to be on either side of the desired peak) to find the frequency of the PRM's violin mode.  It is 627.75 Hz. I adjusted FM5 of the C1:SUS-PRM_LSC filter bank (the "violin" filter) to be centered around this frequency, with the start and stop freqs +\- 4Hz.  I plotted the filter linearly in frequency to ensure that my target freq was not too close to either side of the bandstop.  After loading and engaging the new filter, the hum slowly started to go away. 

Note, for posterity:  The bandstop used to be centered around ~645 Hz or so.  I assume this is a copy-and-paste situation, where we hadn't gone through to check the exact frequency for each optic.

I'm not sure why, but starting ~3.5 hours ago, the WFS seem to not be holding the MC in optimal alignment. 

The WFS are definitely engaged and the loops are closed, but every time the MC locks, the WFS pitch and yaw values start drifting off.  In particular, the WFS loop actuation pushing on MC2 is in the many hundreds of counts after ~90 minutes of drift time.  I tried offloading those values by moving the MC2 slider, but then I unlocked the MC to check what that did to the alignment, and it was decidedly bad.  So, I'm not sure what's up with the WFS, but I need to look at it tomorrow.

I asked Gabriele why it looked like for the PRCL sweep REFL 55 I&Q were zero at zero, but for the MICH sweep only REFL55 I was zero.  He took a look at his code, and found that he was not at the correct locking point.  Here is his email back to me:

I found the reason for the not zero value. Indeed, if you could zoom into the PRCL sweep, you would see that the error signals does not cross zero exactly at PRCL=0, but instead some 50 pm away from zero. This is enough to change a lot the PRCL signal when sweeping MICH. If I put PRCL to the correct zero point, and I sweep MICH, I now get everything at zero. I'm sending again the plots.

The fact that such a small detuning is enough to change PRCL signal when sweeping MICH is due, I believe, to the fact that MICH optical gain is much smaller than PRCL one.

Here are the redone plots:

Phase not tuned:

Phase tuned:

POP22 resonance for MICH and PRCL:

POP110 resonance for MICH and PRCL:

Koji asked me to look at what the ideal RF modulation frequency is, for just the PRMI case (no arms).  If we had a perfect interferometer, with the sidebands exactly antiresonant in the arms when the arms resonate with the carrier, this wouldn't be an issue.  However, due to vacuum envelope constraints, we do not have perfect antiresonance of the sidebands in the arm cavities.  Rather, the sideband frequencies (and arm lengths) were chosen such that they pick up a minimum amount of extra phase on reflection from the arms.  But, when the arms are off resonance (ex, the ETMs are misaligned), the sideband frequencies see a different amount of phase.   

We want to know what a rough guess (since we don't have a precise number for the length of the PRC since our last vent) is for the ideal RF modulation frequency in just the PRMI. 

If I take (from Manasa's kind measurements from the CAD drawing yesterday) the relevant distances to be:

L_P[meters] = 1.9045 + 2.1155 + 0.4067

L_X[meters] = 2.3070 + 0.0254*n

L_Y[meters] = 2.2372 + 0.0359*n + 0.0254*n

L_PRCL = L_P + (L_X + L_Y)/2 = 6.7616 meters.

The *n factors (n=1.44963) are due to travel through glass of the BS, and the substrate of the ITMs. 

I find the FSR of the PRC to be 22.1686 MHz. For the sidebands to be antiresonant, we want them to be 11.0843 MHz. This would correspond to a mode cleaner length of 27.0466 meters.  Our current modulation frequency of 11.066134 MHz corresponds to a MC length of 27.091 meters.  So, if we want to use this 'ideal' modulation frequency for the PRC, we need to shorten the mode cleaner by 4.4cm!  That's kind of a lot.

Koji had the good idea of trying to measure the motion of the POP beam, and feeding that signal to PRM yaw to stabilize the motion.  To facilitate this, I have installed a 50% beam splitter before the POP 110/22 PD (so also before the camera). 

Before touching anything, I locked the PRM-ITMY half-cavity so that I had a constant beam at POP.  I measured the POP DC OUT to be 58.16 counts.  I then installed a 1" 50% BS, making sure (using the 'move card in front of optic while watching camera' technique) that I was not close to clipping on the new BS.  I then remeasured POP DC OUT, and found it to be 30.63.  I closed the PSL shutter to get the dark value, which was -0.30 .  This means that I now have a factor of 0.53 less light on the POP110/22 PD.  To compensate for this, I changed the values of the power normalization matrix from 0.01 (MICH) to 0.0189, and 100 (PRCL) to 189.

After doing this, I restored the ITMX and am able to get several tens of seconds of PRMI lock (using AS55Q and REFL33I). 

I found several QPDs in the PD cabinet down the Y arm, but no readout electronics.  The QPD I found is D990272.  I don't really want to spend any significant amount of time hacking something for this together, if Valera can provide a QPD with BNC outputs. For now, I have not installed any DC PD or razor blade (which can be a temporary proxy for a QPD, enough to get us yaw information).

Something that I want to look at is the coherence between seismic motion and PRM motion.  Since Den has been working on the fancy new seismometer installations, I got caught up for the day with getting the new corner seismometer station set up with a T240.  Later, Rana pointed out that we already have a Guralp sitting underneath the POX table, and that will give us a good first look at the coherence.  However, I'm still going to write down all the cable thoughts that I had today:

The cables that came with the electronics that we have (from Vladimir and tilt meter -land) are not long enough to go from the seismometer to 1X7, which is where I'd like to put the readout box (since the acquisition electronics are in that rack). I want to make a long cable that is 19pin MilSpec on one end, and 25pin Dsub on the other.  This will eliminate the creative connector type changes that happen in the existing setup.  However, before making the cable, I had to figure out what pins go to what.  So.

25pin Dsub          19pin MilSpec

1                   P

2                   N

3                   E

4                   No conn

5                   D

6                   R and V

7                   H

8                   J

9                   No connection

10                  T

11                  F

12                  L

13                  No conn

14                  B

15                  A

16                  R and V

17                  No conn

18                  C

19                  G

20                  G

21                  K

22                  U

23                  No conn

24                  S

25                  M 

I am not sure why R and V are shorted to each other, but this connection is happening on the little PCB MilSpec->ribbon changer, right at the MilSpec side.  I need to glance at the manual to see if these are both ground (or something similar), or if these pins should be separate. Also, I'm not sure why 19 and 20 are shorted together.  I can't find (yet) where the short is happening. This is also something that I want to check before making the cable.

Den had one Female 19 pin MilSpec connector, meant for connecting to a T240, but the cable strain relief pieces of the connector have 'walked off'.  I can't find them, and after a solid search of the control room, the electronics bench, and the place inside where all of Den's connectors were stored, I gave up and ordered 2 more.  If we do find the missing bits for this connector, we can use it for the 2nd T240 setup, since we'll need 2 of these per seismometer. If anyone sees mysterious camo-green metal pieces that could go with a MilSpec connector, please let me know.

Since I keep asking Manasa to "measure" distances off of the CAD drawing for me, I thought I might just write them all down, and quit asking.

So, these are only valid until our next vent, but they're what we have right now.  All distances are in meters, angles in degrees.

I have done a quicky offline Wiener filter to check how much PRM yaw motion we can subtract using a seismometer in the corner station.  This work may be redundant since Koji got the POP beam shadow sensor feedback loop working on Friday night.

Anyhow, for now, I used the GUR2 channels, since GUR2 was underneath the ITMX chamber (at the north edge of the POX table).  Note that Zach is currently borrowing this seismometer for the week.

I used GUR2_X, GUR2_Y and GUR2_Z to subtract from the PRM_SUSYAW_IN1 channel (the filename of the figure says "GUR1", but that's not true - GUR1 is at the Yend).  All 4 of these channels had been saved at 2kHz, but I downsampled to 256 (I probably should downsample to something lower, like 64, but haven't yet).  There is no pre-filtering or pre-weighting of the data, and no lowpass filters applied at the end, so I haven't done anything to remove the injected noise at higher freqs, which we obviously need to do if we are going to implement this online.

If I compare this to Koji's work (elog 8562), at 3.2Hz, he gets a reduction of 2.5x, while this gets 10x.  At all other frequencies, Koji's work beats this, and Koji's method gets reduction from ~0.03Hz - 10Hz, while this is only getting reduction between 0.4Hz and 5Hz.  Also, this does not include actuator noise, so the actual online subtraction may not be quite as perfect as this figure.

I want to redo this estimate of where RIN comes from, since Den did this measurement before I put the lens in front of the POP PD. 

While thinking about his method of estimating the PR3 effect, I realized that we have measured numbers for the pendulum frequencies of the recycling cavity tip tilt suspensions. 

I have been secreting this data away for years.  My bad.  The relevant numbers for Tip Tilts #2 and #3 were posted in elog 3425, and for #4 in elog 3303.  However, the data for #s 1 and 5 were apparently never posted.  In elog 3447, I didn't put in numbers, but rather said that the data was taken.

Anyhow, attached is the data that was taken back in 2010.  Look to elog 7601 for which TT is installed where. 

Conclusion for the estimate of TT motion to RIN - the POS pendulum frequency is ~1.75Hz for the tip tilts, with a Q of ~2.

[Evan, Jenne]

Evan brought the Guralp handheld readout paddle and cables back from the ATF (Zach is using GUR2 and one of the T240s for gyro stuff this week), and we recentered the GUR1 masses.  N/S and Vert were okay (within 0.1 V), but E/W was at -0.5 V, so we set it at zero.  We then plugged the Guralp back in, and turned on the readout box.

There isn't much of a change on the BLRMS on the wall, so it's possible that we weren't actually having any trouble anyway. 

Koji noticed that earlier this afternoon the Yarm ASS was working, but then after dinner it was no longer working.  I saw that the ETMY trans camera beam was clipped.  These things precipitated a visit to the Yend station. 

I saw that the beam on the optic that steers the camera beam to the camera was very, very low, almost falling off the optic.  The only mirror which steers to this optic is the harmonic separator which reflects the IR, and transmits the green.  I turned the pitch knobs on the harmonic separator until the beam was roughly centered on all 3 optics between the separator and the camera (BS to QPD, BS to TRYDC and Y1 for camera).  The yaw was fine, so I didn't touch it.

I then adjusted the steering mirror to the camera, and the BS pointing to the DC PD.  I have not touched the BS pointing to the QPD.  Once the beam was on the TRY PD, Koji ran the ASS script, and I recentered the beam on the DC PD.  During this time, Koji had the Yarm triggering using -1 in the POYDC element of the matrix.

The harmonic separator is not mounted in a nice way (I'm assuming that Annalisa is in the middle of things, and she'll get back to it after the green work), so the TRY PD and camera will need to be aligned again, so I didn't do any ASS-recentering-ASS iteration tonight.

The Yarm ASS works nicely again, getting TRY to ~0.89 . 

I locked the Xarm on green.  At the PSL table, I adjusted the steering mirror to get the beam centered on the GTRX DC PD.  We need a lens for this, and presumably for the GTRY as well. 

I then went down to the Xend, and adjusted the steering mirrors to maximize the transmitted green power.  I got as high as 2150 counts.

Either the alignment is particularly delicate, or something isn't quite right, but when I put the lid back on the optical table's box, the arm will no longer lock on the 00 mode.  It's pretty typical that the cavity will unlock while you put on the lid, but usually if you bang on the underside of the table, or toggle the green shutter, you'll get back to the 00 mode.  Tonight however, I can't get the 00 mode if the lid is on.  If I slide the lid off just enough to get my hand inside, then block the green beam with my hand, I immediately lock on the 00 mode.  Even if I gently slide the lid back on, I unlock the cavity, and with the lid on can't get better than a 01 mode in yaw.  I repeated this a few times, with the same result. 

A goal for the next few days:  Re-find the Xgreen beatnote.  Once we have the PRMI locking stably and reliably, we want to move on to PRFPMI.   

 I changed the value of the nominal FSS common gain in the PSL Settings screen (It's called the 'FSS global gain' there).  To get to this screen:  sitemap -> PSL_main -> PSL_settings.  The MC autolocker reads these settings from the screen and uses those values.  Now the FSS returns to this value of 13 that Jamie has chosen.  For the past few days, it's been going back to the old value of 10.1 .  The FAST gain was already set to this 23.5 value.

Kiwamu had an old set of scripts for measuring the sensing matrices, but they were hidden away in ..../scripts/general/kiwamuscripts/pyplant . I have moved them to a more useful place, and updated them.

The useful scripts (the main one is SensResp.py, and the PRMI-specific one, runPRMI_SENS.py, which calls SensResp.py) have been moved to .../scripts/LSC .  I have also created a folder within the LSC scripts folder called SensMatData for the data.

The 2 big changes to Kiwamu's scripts:  The ezca library that he was calling wasn't working.  I switched it over to using the one that Yuta wrote, in ..../scripts/pylibs.  Also, Kiwamu's script was written back during a time where we must have only had one total lockin for the whole LSC model.  Now we have one per PD in the input matrix.  This meant that several of his channel names were wrong.  I have fixed this, and also made it measure all the sensors at once using tdsread of the _OUT16 channels (the OUT16's have some AA action, other EPICS channels don't).

So, now (after you're locked), it shakes one "mirror" (the ITMs are shaken differentially at the same time, as one "mirror"), and reads out all of the RF PD lockin values.  Then it moves to the next mirror.  (For the PRMI case, there are only 2 "mirrors":  The ITM set and the PRM.)  All of the information is stored in a dictionary, which is written to a text file. 

The format of the dictionary is:

{ OPTIC_1: [Photodiode_1, Lockin_I, Lockin_Q], [Photodiode_2, Lockin_I, Lockin_Q], OPTIC_2: [Photodiode_1, Lockin_I, Lockin_Q], [Photodiode_2, Lockin_I, Lockin_Q] }

At this point, I am too tired to actually do a measurement, although next time the PRMI is locked, we should just have to run the runPRMI_SENS.py, and look at the data.  I'm also not quite sure how to extract the information from a dictionary after it has been written to a text file.  This may not be a good way to store data, and I'll ask Jamie about it tomorrow.

OTHER NOTES:

* I need to set up another iteration of the sensing matrix measurement with no drive, measuring several times, to get an estimate of the error in a single measurement.

* I had the PRMI locked on AS55Q/REFL33I for more than half an hour.  Then the MC started unlocking semi-regularly.  Seismic was good except for one EQ ~2 hours ago.  After the earthquake (unlocked MC, but no tripped optics), the MC has remained locked.

* The LSC Lockin Overview screen does not click-through to the _SIG individual screens.  We need to fix the path to these screens.

* All of the _SIG filters are band passes around 285 Hz, but the names of the filters all say 238Hz.  I need to fix all 27 of these.

* We can perhaps change the LSCoffsets script someday to use tdsread a few times, and average the results (since the PDs don't have lowpass filters, and we're measuring the offset of the IN1 location, not the OUT).  This way we can hopefully measure all the PDs at once and speed up the script, without having failed tdsavg runs.

Koji locked the PRMI for me, and I took some data.  I haven't finished figuring out what to do with it / writing a processing script.

Here is the data, in a python dictionary (not for you to read, but so that it's here and you can use it later if you want).

{'AS55_Q': [['ErrorBarData0', '-1.60826e-05', '0.000154774'], ['ErrorBarData1', '-1.61949e-05', '-9.69142e-05'], ['ITMs', '-0.134432', '0.00240338'], ['PRM', '0.0525864', '0.145516']], 'REFL55_Q': [['ErrorBarData0', '-0.00088166', '-0.00294315'], ['ErrorBarData1', '0.00298076', '-0.000466507'], ['ITMs', '-0.573825', '-0.0865747'], ['PRM', '1.94537', '0.534968']], 'REFL33_Q': [['ErrorBarData0', '0.000868208', '0.000785702'], ['ErrorBarData1', '-0.00136268', '-0.000288528'], ['ITMs', '-0.0653009', '-0.0112035'], ['PRM', '0.875275', '0.419765']], 'REFL11_I': [['ErrorBarData0', '-0.147347', '0.136075'], ['ErrorBarData1', '0.351823', '0.160556'], ['ITMs', '-12.0739', '-80.1513'], ['PRM', '6991.11', '7073.74']], 'REFL33_I': [['ErrorBarData0', '-0.00100624', '0.00134366'], ['ErrorBarData1', '0.00373581', '0.000783243'], ['ITMs', '-0.399404', '-0.774793'], ['PRM', '67.4138', '68.8886']], 'REFL11_Q': [['ErrorBarData0', '-0.0173368', '0.0141987'], ['ErrorBarData1', '0.100048', '0.0882165'], ['ITMs', '6.46585', '-26.2841'], ['PRM', '1653.42', '1663.96']], 'AS55_I': [['ErrorBarData0', '-1.87626e-05', '2.24596e-05'], ['ErrorBarData1', '-5.46466e-05', '-2.96552e-07'], ['ITMs', '-0.00531763', '0.00130579'], ['PRM', '-0.100501', '-0.0706334']], 'REFL55_I': [['ErrorBarData0', '-0.000774208', '-5.32631e-05'], ['ErrorBarData1', '0.00347621', '0.0025103'], ['ITMs', '-0.115633', '-0.83847'], ['PRM', '72.8058', '74.2347']]}

The structure is that each sensor has some "error bar" measurements, when there was no drive to any optics (I, then Q of the lockin), and then response to different optics' drives (waiting 20sec after turning on the oscillator before making a measurement, since the lockin has 0.1Hz lowpasses.  ).

The amplitude that Kiwamu had of 4000 cts in the LSC lockin was fine for MICH, but made PRCL unlock, so this data was taken with an amplitude of 1000 counts, at a frequency 283.1030 Hz. 

Since this is only barely above the UGF for both MICH and PRCL loops, I also have OLTF information at 283Hz from DTT:  PRCL mag = -1.05264 dB, phase = 24.6933 deg, MICH mag = -8.50951 dB, phase = 31.3948 deg.

I have started writing a script SensMatAnalysis.py in the scripts/LSC directory to do the analysis, but after having talked to Koji, I need to do more thinking to make sure I know what I'm doing.  Stay tuned for actual analysis later.

Just so we have some numbers, I did a by-hand analysis of the PRMI sensing matrix numbers I posted here in the elog the other day.  This analysis is ignoring the error bar data.

For each sensor (PD_I or PD_Q), I do loop compensation, since these measurements were taken fairly close to the UGFs of the loops, and notches were not in use at the drive frequency.  To do the loop compensation, I multiply the complex value (lockin_I + i*lockin_Q) by (1-G), where G is the (complex) open loop gain of the degree of freedom I'm shaking.

 When I'm shaking a single degree of freedom (ex. shaking the PRM to get PRCL information), for each PD_I or PD_Q, we get 2 numbers, the lockin_I and lockin_Q values.    I check the phase between the lockin_I and lockin_Q values, since that phase (after loop compensation) should be either 0 or 180, and if it is not, something is wrong. 

Of the 16 sensors I measure (where PD_I and PD_Q count as 2 sensors), 11 sensors had phases more than 20 degrees away from either 0 or 180.  This is not good, and indicates that something is wrong with my measurement.  I suspect that I may not be driving hard enough -  I was using an amplitude 4x smaller than the previous value.  Next time the PRMI is locked, I will turn on the drive oscillation, and ensure that I can see the line in all of the PD signals.

The results of my quickie analysis script:

Bad REFL11_I_MICH phase!  Phase is -82.0185 degrees!
Bad REFL11_Q_MICH phase!  Phase is -35.9697 degrees!
Bad REFL33_I_MICH phase!  Phase is -134.952 degrees!
Bad REFL55_I_MICH phase!  Phase is -79.7997 degrees!
Bad AS55_I_PRCL phase!  Phase is -142.6016 degrees!
Bad AS55_Q_PRCL phase!  Phase is 90.6194 degrees!
Bad REFL11_I_PRCL phase!  Phase is 52.471 degrees!
Bad REFL11_Q_PRCL phase!  Phase is 52.2324 degrees!
Bad REFL33_I_PRCL phase!  Phase is 52.909 degrees!
Bad REFL33_Q_PRCL phase!  Phase is 25.14 degrees!
Bad REFL55_I_PRCL phase!  Phase is 52.8113 degrees!

Sensing Matrix, calculated even though most of the measurement data isn't any good:
AS55: MICH = 0.13502, -1.6122deg.  PRCL = 0.14993, -2.245deg
REFL11: MICH = 29.6373, -2.6365deg.  PRCL = 7376.3206, -2.9098deg
REFL33: MICH = 0.35649, -2.9633deg.  PRCL = 69.5133, -3.1302deg
REFL55: MICH = 0.62084, -2.0261deg.  PRCL = 75.0214, 3.1176deg

So that I don't have to do loop compensation every time I measure a sensing matrix, I have put (back) in notches into FM10 of all the LSC filter banks, except MC2.  

MICH already had this notch, PRCL and CARM both had it, although it was mislabeled in the filter title as "Notch410" rather than the truth, which is "Notch628". 

The XARM and YARM filter banks were full, since we have not (in those filter banks) combined all of the resonant gains - 3.2Hz, 16Hz, 24Hz - into one module.  I took out a CLP3000 (  cheby1('LowPass",2,3,3000)gain(1.41254)  ) in each of those filter banks, and put in the notch.

I also have changed the band pass filters in the LSC-Lockin#_SIG filter banks to match this new drive frequency.

The PRMI sensing matrix, as measured last Thursday, in a more readable format:

EDIT: DON'T Look at this yet!  I forgot to calibrate it!  Please hold.....

            PRCL          MICH        
AS55_I      1.228E-01     5.476E-03    
AS55_Q      1.547E-01     1.345E-01    
REFL11_I    9.946E+03     8.106E+01    
REFL11_Q    2.346E+03     2.707E+01    
REFL33_I    9.639E+01     8.717E-01    
REFL33_Q    9.707E-01     6.626E-02    
REFL55_I    1.040E+02     8.464E-01    
REFL55_Q    2.018E+00     5.803E-01

Okay, Calibrated, but forgot to include loop compensation (since notches didn't exist yet):

Sensing Matrix, units = cts/meter
 
            MICH          PRCL        
AS55_I      5.024E+08     9.418E+07    
AS55_Q      6.328E+08     2.313E+09    
REFL11_I    4.068E+13     1.394E+12    
REFL11_Q    9.594E+12     4.656E+11    
REFL33_I    3.942E+11     1.499E+10    
REFL33_Q    3.970E+09     1.140E+09    
REFL55_I    4.253E+11     1.456E+10    
REFL55_Q    8.252E+09     9.981E+09

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  

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.

 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.

 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.

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 

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

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.

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!

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 

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

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

 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?