ID |
Date |
Author |
Type |
Category |
Subject |
8600
|
Mon May 20 17:49:36 2013 |
Jenne | Update | LSC | PRMI sensing matrix - not high quality data |
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 |
Attachment 1: PRMIsensMatQuickAnalysis.m.gz
|
8601
|
Mon May 20 18:47:47 2013 |
Koji | Update | LSC | PRMI sensing matrix - not high quality data |
For now forget about the demodulation phase and assume all of the ports are independent.
I want to know the numbers in the following format.
PRCL MICH (unit: cnt/m)
REFL11I: x.xxxEx x.xxxEx
REFL11Q: x.xxxEx x.xxxEx
REFL33I: x.xxxEx x.xxxEx
REFL33Q: x.xxxEx x.xxxEx
REFL55I: x.xxxEx x.xxxEx
REFL55Q: x.xxxEx x.xxxEx
REFL165I: N/A N/A
REFL165Q: N/A N/A
AS55I: x.xxxEx x.xxxEx
AS55Q: x.xxxEx x.xxxEx
If you really want to resolve the TF phase difference between the I and Q demod-signals,
you need to look at the transfer functions between the excitation and these ports.
We can't understand what is happening only from the single point measurement. |
8602
|
Mon May 20 18:50:22 2013 |
Jenne | Update | LSC | Kiwamu's sensing matrix measurement script revived |
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. |
8603
|
Tue May 21 14:48:08 2013 |
Jenne | Update | LSC | PRMI sensing matrix - not high quality data |
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
|
8604
|
Tue May 21 14:50:52 2013 |
Max Horton | Update | | Importing New Code |
There was an issue with running the new summary pages, because laldetchar was not included (the website I used for instructions doesn't mention that it is needed for the summary pages). I figured out how to include it with help from Duncan. There appear to be other needed dependencies, though. I have emailed Duncan to ask how these are imported into the code base. I am making a list of all the packages / dependencies that I needed that weren't included on the website, so this will be easier if/when it has to be done again. |
8605
|
Tue May 21 16:23:06 2013 |
Manasa | Update | General | 40MARS wireless network problem RETURNS |
Quote: |
Here's an example of the total horribleness of what's happening right now:
controls@rossa:~ 0$ ping 192.168.113.222
PING 192.168.113.222 (192.168.113.222) 56(84) bytes of data.
From 192.168.113.215 icmp_seq=2 Destination Host Unreachable
From 192.168.113.215 icmp_seq=3 Destination Host Unreachable
From 192.168.113.215 icmp_seq=4 Destination Host Unreachable
From 192.168.113.215 icmp_seq=5 Destination Host Unreachable
From 192.168.113.215 icmp_seq=6 Destination Host Unreachable
From 192.168.113.215 icmp_seq=7 Destination Host Unreachable
From 192.168.113.215 icmp_seq=9 Destination Host Unreachable
From 192.168.113.215 icmp_seq=10 Destination Host Unreachable
From 192.168.113.215 icmp_seq=11 Destination Host Unreachable
64 bytes from 192.168.113.222: icmp_seq=12 ttl=64 time=10341 ms
64 bytes from 192.168.113.222: icmp_seq=13 ttl=64 time=10335 ms
^C
--- 192.168.113.222 ping statistics ---
35 packets transmitted, 2 received, +9 errors, 94% packet loss, time 34021ms
rtt min/avg/max/mdev = 10335.309/10338.322/10341.336/4.406 ms, pipe 11
controls@rossa:~ 0$
Note that 10 SECOND round trip time and 94% packet loss. That's just beyond stupid. I have no idea what's going on.
|
This has not been fixed!
Temporary solution: I ssh'd to nodus from the 40m wifi network and was able to connect to the FE machines.This works but the bandwidth is limited this way as expected.
40m MARS network needs to be fixed. |
8606
|
Tue May 21 17:03:45 2013 |
Steve | Update | endtable upgrade | enclosure tops are sealed |
Quote: |
I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.
We'll install spring loaded lathes, hooks and quick release pins.
The bridge will be reinforced with steel plate to support release pins on posts.
There will be an other cut out for cable feedtrough as it is shown on elog #8472
Let me know if this timing does not fit your work.
|
The bridge support posts were shimmed today. Surgical tubing 402R - o - rings were glued togeather with " instant krazy glue "
Atm2 Carey CH-3540 latches are compressed ~2.5 mm in the clamped position.
Atm3 is showing the captured quick release pin in the steel reinforced bridge that is supported by the post. It works great. The post screw is sealed by o-ring. The quick-pin is sealed by an epoxy attached copper cap.
Atm4 Enclosure is on it's back. Bottom o-ring can be seen. The hole reinforced bridge structure is visible.
Now I'm working on the window connection to the chamber. I'm very close leak checking this box.
In case of leaking around the top tubing seals we have two options:
a, cut down on the cover rim by 0.040" or b, increase tubing diameter |
Attachment 1: ETMYoptable.jpg
|
|
Attachment 2: surgtubclamps.jpg
|
|
Attachment 3: quickrelease.jpg
|
|
Attachment 4: reinforcbridge.jpg
|
|
8607
|
Tue May 21 18:18:23 2013 |
Manasa | Update | Green Locking | Xend Green aligned |
X arm aligned to green.
Aligned the X arm to IR.
Used steering mirrors to align the X end green to the X arm while remaining locked for IR. X arm locks to green stably with GTRX at the PSL table measuring 235uW and corresponds to 2560counts in C!:ALS-TRX_OUT.
Next
1. PSL green alignment.
2. Search for beat note.
3. Resurrect ALS for X arm. |
8608
|
Tue May 21 18:18:28 2013 |
Jamie | Update | Computer Scripts / Programs | netGPIB stuff update/modernized/cleanedup/improved |
I did a bunch of cleanup work on the netGPIB stuff:
- Removed extensions from all executable scripts (executables should not have language extensions)
- fixed execution permissions on executables and modules
- committed HP8590.py and HP3563A.py instrument modules, which were there but not included in the svn
- committed NWAG4395A (was AG4395A_Run.py) to svn, and removed old "custom" copies (bad people!)
- cleaned up, modernized, and fixed the
netgpibdata program
- removed plotting from
netgpibdata , since it was only available for one instrument, there's already a separate program to handle it, and it's just plotting the saved data anyway
- added a
netgpibcmd program for sending basic commands to instruments.
- added a README
Probably the most noticeable change is removing the extensions from the executables. There seems to be this bad habit around here of adding extensions to executables. It doesn't matter to the person running the program what language it was written in, so don't add extensions. It only matters for libraries. |
8609
|
Tue May 21 18:22:18 2013 |
Jenne | Update | LSC | Sensing matrix scripts modified to include actuator calibration |
The PRMI sensing matrix scripts have been modified to output a sensing matrix which is calibrated into units of counts/meter.
To run, you should just need to run .../scripts/LSC/runPRMI_SENS.py .
If it looks like the drive amplitude is not large enough (no nice peak in the photodiode signals), you can increase the drive amplitude, which is line 21 in runPRMI_SENS.py |
8610
|
Tue May 21 23:29:57 2013 |
Manasa | Update | Green Locking | Xend Green aligned |
X-green and PSL green have been aligned so that they interfere at the beat PD for X.
I haven't scanned the X-end NPRO temperature to find the beat note. I found the earlier elog when this was done (elog 6851) and will use those temperatures to start with. |
8611
|
Wed May 22 00:08:19 2013 |
Koji | Update | LSC | Sensing matrix scripts modified to include actuator calibration |
It was too embarassing to see that the actuation frequency was set at the violin mode frequency in order to avoid designing a new filter!?
I ran Jenne's sensing matrix code and the immitated the same result by manual measurement with DTT.
I noticed that the PRM excitation was not transmitted to the mirror. I tracked down the cause and found that
Jenne is using 628Hz which is the notch frequency of the viloing filter.
There is no way we can measure the precise calibration of the error signal exactly at the violin mode frequency.
Nevertheless I waited for the ringdown of the violin mode to the floor level and ran the code again WITH the violin mode filter OFF
at PRM SUS.
The result was stored in the data file
sensematPRM_2013-05-22.12615.dat
The code spit the message at the end
Sensing Matrix, magnitude only, units = cts/meter
MICH PRCL
AS55 5.304E+08 1.716E+09
REFL11 1.732E+13 2.151E+11
REFL33 1.616E+11 5.384E+09
REFL55 1.681E+11 6.950E+09
Now I replicated the same measurement with DTT.
MICH or PRCL were excited with the lockin. In order to aviod the violin mode, I shifted the excitation freq by 1Hz. (i.e. 629.125Hz)
The peaks in REFL33I/Q and RFL55I/Q were observed with PSD and TF. The spectrum was measured with the FLATTOP window with the line resolution of 0.1Hz
DTT suggested that this corresponds to the BW of 0.471271Hz if I correctly understood what DTT plot said. We need this information to convert cnt/rtHz to cnt_pk
if we need. For the TF measurements, I needed to find the excitatin monitor but I could not. Therefore, I set the offset of LSC-LOCKIN1_SIG to be 1000,
so that C1:LSC-LOCKIN1_I_IN1 produce the same signal as the excitation.
Note that during the measurement, 628Hz nothces in the LSC servos were on. I confirmed that this provides the reduction of the feedback by a factor of 76.
As the original openloop gain at 629Hz is lower than the unity more than a factor of 2, this was sufficient attenuation to measure the optical gain with the systematic error of less than a %.
MICH excitation (ITMX -1, ITMY +1)
PSD (cnt/rtHz) TF Mag Phase
REFL33I 0.098590 9.5691e-5 74.4344
REFL33Q 0.019294 1.8665e-5 71.1204
REFL55I 0.016123 1.3890e-5 77.3132
REFL55Q 0.157522 1.5285e-4 91.5594
PRCL excitation (PRM +1)
PSD (cnt/rtHz) TF Mag Phase
REFL33I 15.7565 1.5298e-2 -109.727
REFL33Q 0.171648 1.6310e-4 -141.73
REFL55I 16.2834 1.5809e-2 -109.672
REFL55Q 0.634096 6.1012e-4 -143.169
These measurements are saved in the XML files (for DTT) in
/cvs/cds/caltech/users/koji/130521/
as
130521_MICH_EXC.xml and 130521_PRCL_EXC.xml
As the actuator of the PRM/ITMX/ITMY are {19.6, 4.70, 4.66}/f^2 nm/cnt, the optical gains were calculated from the TF measurements.
MICH excitation (ITMX -1, ITMY +1)
OPTICAL GAIN (cnt/m)
REFL33I 4.0e9
REFL33Q 7.9e8
REFL55I 5.9e8
REFL55Q 6.5e9
PRCL excitation (PRM +1)
OPTICAL GAIN
REFL33I 3.1e11
REFL33Q 3.3e9
REFL55I 3.2e11
REFL55Q 1.2e10
These should be compared with the measurement by the script and we get more information from the script (like AS55, REFL11) |
8612
|
Wed May 22 00:42:13 2013 |
Koji | Summary | SUS | violin Q |
While looking at the decay of the violin mode of the PRM, I made a simple measurement of the decay rate.
Error signal: REFL33I
The peak @628Hz became 0.372 to 0.303 in 60 sec.
-> Half life of the amplitude T_{1/2} is 203sec.
Q = 4.53 f0 T_{1/2} = 5.8 x10^5 |
8613
|
Wed May 22 11:09:33 2013 |
Jamie | Summary | CDS | Weird DAC bit flipping at half integer output values |
After querying CDS folks about this issue, I got some responses that indicated the problems was likely limit-cycle oscillations due to zero-padding of the data when upsampling. Tobin ran some Matlab tests to confirm this issue.
Starting in RCG 2.5 there is a new "no_zero_pad=1" cdsParameters option turns zero padding OFF. I tried enabling this option c1scy to see how the behavior changed. Sure enough, the 32 kHz oscillations mostly went away. There are no oscillations for outputs held at the half-count value, and the oscillations around the half-count transitions went away as well.
The only thing I could see is a bit of oscillation when converging on a constant half-count value that went away after a couple of milliseconds:

So we might consider adding the no_zero_pad=1 option to all of our coil driver outputs, which might eliminate the need to add notches at the Nyquist in the analog anti-image filters |
8614
|
Wed May 22 11:21:28 2013 |
Koji | Summary | CDS | Weird DAC bit flipping at half integer output values |
Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)
Anyway, it seems that we should use no-zero-padding.
You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case? |
8615
|
Wed May 22 11:35:06 2013 |
Jamie | Summary | CDS | Weird DAC bit flipping at half integer output values |
Quote: |
Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)
|
This is a good question. We may be able to test if it's a linear effect if we have enough DAC range to get the oscillation to be more than a single sample.
Quote: |
You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case?
|
In the zero-pad case the oscillation just continues indefinitely at the half-count value, so it never dies out (at least as far as I can tell). |
8616
|
Wed May 22 15:08:37 2013 |
Koji | Summary | CDS | Weird DAC bit flipping at half integer output values |
It seems that the effect is from the (linear) residual fluctuation of the digital AI filter for the zero-padded signal.
Namely, if we give the larger constant number, we get more oscillation. |
Attachment 1: Screenshot.png
|
|
8617
|
Wed May 22 15:48:56 2013 |
Jamie | Update | SUS | Turn off zero padding in DAC outputs |
After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:
The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads. This should reduce the 32 kHz lines we were noticing in the analog DAC output.
I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample. We will continue to investigate.
In any event, I have rebuilt and installed all models listed above. I will restart as soon as opportunity allows. |
8618
|
Wed May 22 17:29:34 2013 |
Jenne | Update | ASC | QPD for POP ASC tested |
I fiddled around with the QPD that I'll use to replace Koji's temporary razor blade yaw sensor for detecting POP beam angular motion, and checked that it is working.
Using the Jenne Laser, I put beam onto the 4 different quadrants of the QPD, and saw that the Sum channel remained constant.
* I had the room lights off, since the PD elements are silicon.
* Beam size on the QPD as seen on an IR card was ~1mm diameter.
* With the beam on the QPD, I chose gain setting "G2" on the amplifier, since that was the only setting where neither the "current too high" nor the "current too low" LEDs were illuminated. I didn't measure the power going to the PD, but the Jenne Laser puts out 1.2mW, and there's a 50/50 BS, so I was getting about 600uW.
* I turned off the "zero/cal" switch on the back of the box, since I don't know how to set the zero. Since the X and Y channels are normalized by the Sum, you can't just block all light going to the PD and set the zero. There isn't a big change in the output levels with the zero/cal switch off, so I think it should be fine. (Previously, I set all 4 knobs - "zero" and "cal" for each X and Y - to approximately the center of their ranges. Once you hit the end of the range, you can keep turning the knob, but something inside makes a clicking sound ~once per revolution, and the signal level stops changing (for the zero knobs). Much like centering a beam on a PD, I found each edge of the range for each knob, and set the knobs in the centers by counting the number of turns. Anyhow, since I set the knobs to ~halfway, I think that explains why there isn't really a change whether the "zero/cal" switch is on or off.
* Using the steering mirror sending the beam to the QPD, I moved the beam around, and watched where I was going with an IR viewer. I see that as I move from quad-to-quad, the X and Y channels respond as I expect. If I only move the beam in X, I only see X response on a 'scope, and vice versa.
I can't do a real calibration until I get the QPD installed in place, so I can use the actual beam, but for now it looks like the QPD is responding nicely. Since Annalisa and Manasa are using the Arms for the evening, I'll work on putting the QPD on the POX table tomorrow. |
8619
|
Wed May 22 18:07:36 2013 |
Jenne | Update | LSC | Kiwamu's sensing matrix measurement script revived |
To avoid exciting at the PRM violin mode frequency, I have changed all of the filters relevant to the sensing matrix measurement from 628Hz to 580.1Hz. This includes notches in the LSC control loops, as well as the band pass filters in the lockins. I have not yet loaded the new filters, since arm locking is in progress.
|
8620
|
Wed May 22 18:24:19 2013 |
Jenne | Update | SUS | Violin mode survey |
Quote: |
It was too embarassing to see that the actuation frequency was set at the violin mode frequency in order to avoid designing a new filter!?
|
Ooops, definitely my bad. I think I was the one who put in the PRM violin filter, so I should have recognized that frequency. However, I couldn't think of a reason why violin mode filters should be in the LSC filter banks, since we usually put them in C1:SUS-optic_LSC filter banks.
Anyhow, so that I don't make a mistake like that again, I was looking through all of the violin mode filters for all the optics, so I could write down the frequencies. The result: confusion.
Violin filters in C1:SUS-optic_LSC filter banks:
The PRM's violin mode filter is set correctly to 627.75Hz: elog 8533.
One of BS or SRM has probably been measured (presumably BS), since they have the same filters centered around 645Hz.
Neither ITM has a violin filter.
The ETMs have violin filters in the 440's, which I assume was correct back in the MOS days, before 2010.
Vio2 filters in C1:SUS-optic_LSC filter banks:
PRM, SRM, BS, ITMX, ITMY: Centered around 1285 Hz, which matches the violin notch frequencies in the BS and SRM.
ETMY: Centered around 883.5Hz, which matches the old 440Hz frequency
ETMX: Centered around 631Hz . So, this could have been measured, but it was put into the wrong filter module.
Koji tells me that we don't really need to worry about all these violin filters unless they are required (as with the PRM and the obnoxious hum a few weeks ago), so I 'm not going to do any measuring / adjusting of these filters for now. |
8621
|
Wed May 22 20:50:26 2013 |
Jenne | Update | LSC | Sensing matrix scripts don't calculate correctly |
I am trying to re-analyze the data that Koji took last night.
I think that my script is just pulling out the I and Q data for each port, and each degree of freedom, calculating the magnitude from sqrt( I**2 + Q**2 ) and the phase from atan2( I / Q ). No calibration.
If I print out the results, I get:
Sensing Matrix, units = cts/ct, phase in degrees
MICH Mag MICH Phase PRCL Mag PRCL Phase
AS55_I 1.627E-02 62.063 4.189E-03 68.344
AS55_Q 2.073E-02 -105.353 1.983E-02 66.361
REFL11_I 8.165E+02 -112.624 2.441E+00 77.911
REFL11_Q 2.712E+02 -112.650 7.065E-01 -127.093
REFL33_I 8.028E+00 -112.154 6.282E-02 70.990
REFL33_Q 5.490E-02 -165.912 9.908E-03 61.269
REFL55_I 8.347E+00 -112.085 2.146E-02 78.928
REFL55_Q 3.003E-01 -151.652 7.924E-02 87.153
If, however, I take the raw values that are stored in the data file, for one row (say, REFL33_Q) and calculate by hand (same formulas), I get different results:
MICH Mag MICH Phase PRCL Mag PRCL Phase
REFL33_Q 9.9E-03 28.89 5.46E-02 -103.8
Contrast that with Koji's uncalibrated transfer function result from elog 8611:
MICH Mag MICH Phase PRCL Mag PRCL Phase
REFL33Q 1.8665e-5 71.1204
1.6310e-4 -141.73
I am currently confused, and need to re-look at my script, as well as make sure I am actually measuring the things I think I am.
EDIT: This has been fixed, in that my 2 calculations agree with one another. I have crossed out the incorrect numbers, and put correct numbers below. I still don't agree with Koji, but at least I agree with myself.
The phase issue: I needed to calculate the phase with "ATAN2(I,Q)", which I did when I calculated by hand, but the script had "atan2(Q,I)". This has been fixed.
The magnitude issue: They match, but my "pretty print" script labels MICH as PRCL, and vice versa. Doh.
Corrected values:
Sensing Matrix, units = cts/ct, phase in degrees
PRCL Mag PRCL Phase MICH Mag MICH Phase
AS55_I 1.627E-02 27.937 4.189E-03 21.656
AS55_Q 2.073E-02 -164.647 1.983E-02 23.639
REFL11_I 8.165E+02 -157.376 2.441E+00 12.089
REFL11_Q 2.712E+02 -157.350 7.065E-01 -142.907
REFL33_I 8.028E+00 -157.846 6.282E-02 19.010
REFL33_Q 5.490E-02 -104.088 9.908E-03 28.731
REFL55_I 8.347E+00 -157.915 2.146E-02 11.072
REFL55_Q 3.003E-01 -118.348 7.924E-02 2.847
|
8622
|
Thu May 23 00:16:32 2013 |
Annalisa | Update | 40m upgrading | ETMY - progress |
[Annalisa, Koji]
GREEN
I aligned back the beam (we lost part of the alignment after we put back the box and after the posts were installed). The green beam out from the crystal is still low, but anyway I get about 1.2 mW of green out from the Faraday.
TO DO
Mode Matching calculation (tomorrow)
Fix the dumping situation
Replace some of the mounts with more solid ones (in the future)
TRANSMON PATH
QPD, PD and Camera have been rotated as Rana suggested last Wednesday. A 1m focal length lens is on the main beam transmitted path (before the harmonic separator), and the beam diameter on the QPD is about 5mm. We put another lens with a shorter focal length to put the PD very close to the beam waist and in way to have a reasonable beam size on the camera. Tomorrow I will write down all the correct sizes of the beams.
OPLEV
(for Steve) I marked a possible beam path for the Oplev (the laser is not in the right place in the picture, but I left it in the correct place on the table). I also put the QPD for the IP-ANG, so we know in which part of the table the beam can be steered.
The space in the red rectangle (right corner) has to be left empty to put a PD for the rejected beam from the green Faraday.
|
Attachment 1: TransMonAndOplev.jpg
|
|
8623
|
Thu May 23 00:49:13 2013 |
Jenne | Update | LSC | LSC filters loaded |
Quote: |
To avoid exciting at the PRM violin mode frequency, I have changed all of the filters relevant to the sensing matrix measurement from 628Hz to 580.1Hz. This includes notches in the LSC control loops, as well as the band pass filters in the lockins. I have not yet loaded the new filters, since arm locking is in progress.
|
I have loaded these new filters in. Manasa is still using the IFO for green stuff, so I can try out the PRMI measurement in a day or so. (Right now I have to make sure I understand my data, anyway.) |
8624
|
Thu May 23 01:27:11 2013 |
Manasa | Summary | LSC | Xarm beat note search continues |
Towards finding the x-arm beat note:
The green would not lock to a maximum GTRX this morning. In the course of aligning the green stably to the X arm, somewhere down the line, the input pointing got messed up (reasons unknown). To set this right, Koji tried to lock the Yarm with POY DC but it wouldn't work. The transmon for Y had to be set up temporarily and the Y arm was locked with TRY. This restored the input pointing and the arms locked with transmission TRX/TRY > 0.9 counts. The transmon path along the Y arm was then re-configured as mentioned in Annalisa's elog.
I still had trouble getting the X-green locked in TEM00 (similar situation mentioned by Jenne in elog). The arm cavity mirrors were tweaked to get the green to resonate in TEM00 but it wouldn't stay locked when the temperature of the x-end NPRO was changed. Koji helped recover missing links to filters for the ALS_X_SLOW servo from the archives. Enabling the filters helped keep the green locking stable for laser temperature changes (which corresponds to 'offset' change in ALS_X_SLOW servo screen).
PSL green alignment was checked once again and the X-end laser temperature was scanned trying to find the beatnote. RFMON from the beatbox was connected to the spectrum analyzer. I have scanned through the whole range of offset but have not been able to find the beat note yet.
The search will continue tomorrow 
|
8625
|
Thu May 23 10:20:33 2013 |
Jamie | Update | SUS | Turn off zero padding in DAC outputs |
Quote: |
After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:
The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads. This should reduce the 32 kHz lines we were noticing in the analog DAC output.
I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample. We will continue to investigate.
In any event, I have rebuilt and installed all models listed above. I will restart as soon as opportunity allows.
|
I have restarted all the suspension models with the new no_zero_pad flag for the DAC upsampling. Everything came up fine and all optics are damped as expected (except for concerns about c1scy which I'll note in a followup). |
8626
|
Thu May 23 10:24:23 2013 |
Jamie | Summary | CDS | c1scy model continues to run at the hairy edge |
c1scy, the controller model at the Y END, is still running very long, typically at 55/60 microseconds, or ~92% of it's cycle. It's currently showing a recorded max cycle time (since last restart or reset) of 60, which means that it has actually hit it's limit sometime in the very recent past. This is obviously not good, since it's going to inject big glitches into ETMY.
c1scy is actually running a lot less code than c1scx, but c1scx caps out it's load at about 46 us. This indicates to me that it must be some hardware configuration setting in the c1iscey computer.
I'll try to look into this more as soon as I can. |
8627
|
Thu May 23 10:48:42 2013 |
Manasa | Update | IOO | MC autolocker and MCWFS enabled |
Some strong seismic noise (not related to any earthquakes - watchdogs are all green) had got the MC unlocked this morning.
I found the MC autolocker and MCWFS disabled. Enabling them locked the MC right away. I don't see any updates in the elog as to why these were left disabled and hence have left them ON now. |
8628
|
Thu May 23 12:02:48 2013 |
Steve | Update | endtable upgrade | ETMY - oplev |
Temporary oplev in place. The spot on the qpd is still big. My two lens solution did not work.
I will finalize optical component position of the oplev after the the arm transmitted and green beam optics in place. They have priority.
|
Attachment 1: ETMYopl.jpg
|
|
8629
|
Thu May 23 13:14:34 2013 |
Koji | Summary | LSC | Xarm beat note search continues |
We should consider to hook up the temperature monitors of the NPROs to the ADCs. |
8630
|
Thu May 23 14:45:08 2013 |
Jenne | Update | LSC | Sensing matrix scripts calculations make more sense now |
I think I have most of the magnitude issues figured out now.
First of all, the lockin outputs are different from the actual responses in the PDs by a factor of 2.
If the optic is driven with amplitude D, it will have a response of Asin(wt) + Bcos(wt) + other frequency junk . The lockin bandpasses the response to get rid of the 'other frequency junk'. Then creates 2 new signals, one multiplied by cos(wt), the other multiplied by sin(wt). So, now we have Asin^2(wt) + Bcos(wt)sin(wt) and Asin(wt)cos(wt) + Bcos^2(wt) . If I rewrite these, I have A/2*(1-cos(2wt))+B/2*(sin(2wt) and A/2*sin(2wt)+B/2*(1+cos(2wt)) . We lowpass to get rid of the 2w components, and are left with A/2 for the Q-phase, and B/2 for the I-phase of the lockin outputs. Since the real amplitudes of the response were A for the Q-phase and B for the I-phase, we need to multiply the lockin outputs by 2.
The other problem was that in the 'uncalibrated' version of numbers that I was printing to compare with Koji's, I had not normalized by the drive amplitude yet. That happens in the "calibration" part of my script. So, if I go back to comparing the calibrated versions of our numbers, I get quite close to Koji's answers.
For the PRCL magnitudes, 3 of the 4 numbers match to ~5%. However, the MICH magnitudes all seem to be off by a factor of 2. I'm still stuck on this factor of 2, but I'm thinking about it. Also, the phases that Koji and I get are pretty different.
Koji's sensing matrix:
Sensing Matrix, units = cts/meter, phase in degrees
PRCL Mag PRCL Phase MICH Mag MICH Phase
REFL33_I 3.100E+11 -109.727 4.900E+09 74.434
REFL33_Q 3.300E+09 -141.730 7.900E+08 71.120
REFL55_I 3.200E+11 -109.672 5.900E+08 77.313
REFL55_Q 1.200E+10 -143.169 6.500E+09 91.559
My sensing matrix:
Sensing Matrix, units = cts/meter, phase in degrees
PRCL Mag PRCL Phase MICH Mag MICH Phase
REFL33_I 3.242E+11 -157.846 1.067E+10 19.010
REFL33_Q 2.217E+09 -104.088 1.683E+09 28.731
REFL55_I 3.371E+11 -157.915 3.645E+09 11.072
REFL55_Q 1.213E+10 -118.348 1.346E+10 2.847
Here are the plotted versions of these matricies:


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.
|
8631
|
Thu May 23 17:51:39 2013 |
Koji | Summary | LSC | My usual locking procedure |
For purpose of the automation and my record, I summarized my locking procedure as a chart. |
Attachment 1: PRMI_locking_procedure.pdf
|
|
8632
|
Thu May 23 19:09:15 2013 |
Jenne | Update | LSC | Sensing matrix scripts modified to include actuator calibration |
After fixing up my calculations in my scripts, I have calculated the final PRMI sensing matrix (as measured very close to the violin frequency, so things may not be perfect). The data is from the file that Koji mentioned in his elog when he did the measurement: elog 8611, sensematPRM_2013-05-22.12615.dat
Sensing Matrix, units = cts/meter, phase in degrees
PRCL Mag PRCL Phase MICH Mag MICH Phase
AS55 1.064E+09 141.880 3.442E+09 11.929
REFL11 3.474E+13 -108.372 4.316E+11 106.143
REFL33 3.242E+11 -90.392 1.080E+10 81.037
REFL55 3.373E+11 -92.060 1.394E+10 15.153

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! |
8633
|
Thu May 23 20:39:50 2013 |
Jenne | Update | LSC | PRMI sensing matrix measured at 580.1Hz |
I locked the PRMI and remeasured the sensing matrix, this time at 580Hz. The excellent news here is that the matrix looks quite similar to the one measured the other day, recorded in elog 8632. Yay! I'm not sure why the REFL11 MICH error is so much larger this time around.
Raw data: .../scripts/LSC/SensMatData/sensematPRM_2013-05-23.202312.dat
Sensing Matrix, units = cts/meter, phase in degrees
PRCL Mag PRCL Phase MICH Mag MICH Phase
AS55 5.485E+08 162.424 2.679E+09 25.608
REFL11 1.126E+13 -122.832 1.618E+11 85.296
REFL33 2.658E+11 -87.973 8.910E+09 79.226
REFL55 3.012E+11 -99.534 1.210E+10 12.486

|
8634
|
Thu May 23 20:58:49 2013 |
Jenne | Update | PEM | PRM, ITMX optics tripped, restored |
- Time
- Location
- 40.190°N 121.064°W
- Depth
- 0.0km
|
8635
|
Thu May 23 21:45:51 2013 |
Jenne | Update | LSC | Sensing matrix scripts now check for lockloss |
A few more small mods to the sensing matrix script. Now the script saves the data after each measurement, so that in case you lose lock and can't measure any more, you still have the data you already measured. Also, the error bar measurements are last, so that the consequence of losing lock partway through the measurement is just that you get fewer error bar numbers. Not a big deal, since the actual sensing matrix data is already saved.
Also, the old script had a lockloss checker that I had overridden since it wasn't where I wanted it. I have now re-implemented it, so that the script will stop the oscillation and quit measuring if either the LSC enable switch is off, or the degrees of freedom you're trying to measure are not triggered. All data saved before the lockloss is saved though (as mentioned above). |
8636
|
Thu May 23 22:13:12 2013 |
Koji | Update | LSC | PRMI sensing matrix measured at 580.1Hz |
Can you clarify the definition of the phase "0deg" of your plot?
Is "I" the definition of "0deg"? Or does the demod phase of "0deg" define "0deg"?
I want to know if the demod phase of REFL55 is correctly adjusted or not.
With the decent level of the separation, we should be able to keep the decent lock of PRMI with REFL55. |
8637
|
Fri May 24 02:12:50 2013 |
Annalisa | Update | 40m upgrading | ETMY - Mode Matching for green |
Mode Matching calculation for green beam - Yarm
After measuring the beam radius out from the Faraday for the green, I made the calculation to match the green beam mode with the IR mode inside the arm.
The beam waist after the Faraday is elliptical, and I found the following value for the waist:
w0x = 3.55e-5 m @ z0x = -0.042 m
w0y = 2.44e-5 m @ z0y = -0.036 m
(the origin of the z axis is the output of the Faraday, so the waist is inside the Faraday itself)
I did the calculation using a la mode, using as beam waist and its position the following values:
w0 = sqrt(w0x*w0y) = 2.943e-5 m @ z0 = (z0x+z0y)/2 = -0.039 m
The results are shown in the attached plots.
Focal length (m) position (m)
lens1 0.125 0.1416
lens2 0.100 0.5225
L 1.000 1.5748 (fixed lens used to focus transmitted beam)
As the first plot shows, the green beam size on the ETMY is about 6mm. My concern is that it could be too big.
The third plot shows the X and Y section of the beam. It is strongly elliptical, but nevertheless the coupling factor calculated with Koji's formula gives C=0.936 for the astigmatic beam, and C=0.985 for the non astigmatic beam, so it seems to be still ok.
|
Attachment 1: ModeMatchingGreen.jpg
|
|
Attachment 2: ModeMatchingGreenZoom.jpg
|
|
Attachment 3: XYpath.jpg
|
|
8638
|
Fri May 24 11:38:00 2013 |
Koji | Update | 40m upgrading | ETMY - Mode Matching for green |
I got confused. Is the mode calculation in the cavity correct?
Are you sure the wavelength in the code is 532nm?
The first plot says "the waist radius at ITMY is 2.15mm". This number is already very close to
the waist size of the cavity mode (2.1mm@ITM, 3.7mm@ETM), but the spot radius at ETMY is 6mm.
They are inconsistent.
|
8639
|
Fri May 24 12:50:25 2013 |
Annalisa | Update | 40m upgrading | ETMY - Mode Matching for green |
Quote: |
I got confused. Is the mode calculation in the cavity correct?
Are you sure the wavelength in the code is 532nm?
The first plot says "the waist radius at ITMY is 2.15mm". This number is already very close to
the waist size of the cavity mode (2.1mm@ITM, 3.7mm@ETM), but the spot radius at ETMY is 6mm.
They are inconsistent.
|
Jenne and I just realized that a la mode has 1064e-9 m as default value. I'll change it and make the calculation again. |
8640
|
Fri May 24 13:41:19 2013 |
Jenne | Update | LSC | PRMI sensing matrix measured at 580.1Hz |
"0 degrees" is 0 degrees of demod phase. I have now added the PD demod phases to the plot:

|
8641
|
Fri May 24 14:01:59 2013 |
Koji | Update | LSC | PRMI sensing matrix measured at 580.1Hz |
It's hard to believe but is AS55Q really almost insensitive to MICH?
Well, anyway, now it is the time to use the automatic demod phase (and input matrix) adjustment. |
8642
|
Fri May 24 14:40:22 2013 |
Jenne | Update | LSC | PRMI sensing matrix: now what? |
Quote: |
It's hard to believe but is AS55Q really almost insensitive to MICH?
Well, anyway, now it is the time to use the automatic demod phase (and input matrix) adjustment.
|
I am also wondering if I understand / am using the demod phase from the screen correctly. This plot is indicating that MICH is entirely in I, and not at all in Q.
Currently, I take the demod phase, and plot that as the "I" line, then plot the "Q" line 90 degrees away from the I line. Maybe it should be the other way around?
Re: the auto-demod phase, I was starting to wonder about that. For each sensor, can I declare what degree of freedom I want in which quadrature to take priority (ex. MICH goes to REFL55 Q), and set the demod phase to the value that makes that true? |
8643
|
Fri May 24 14:44:34 2013 |
Jenne | Update | General | Rossa freezes all the time |
I am getting tired of having to restart Rossa all the time. She freezes almost once per day now. Jamie has looked at it with me in the past, and we (a) don't know why exactly it's happening and (b) have determined that we can't un-freeze it by ssh-ing from another machine.
I wonder if it's because I start to have too many different windows open? Even if that's the cause, that's stupid, and we shouldn't have to deal with it.
\end{vent} |
8644
|
Fri May 24 22:18:33 2013 |
Jenne | Update | LSC | PRMI sensing matrix: Got it! |
Okay, I think I am finished with the sensing matrix scripts!
I had the syntax for atan2() wrong, so I was calculating the demod phase wrong. Do not trust the phase in any previous elogs!!
Also, the theta=0 axis of the plots are for 0 degree demod phase, but our PDs are not at 0 deg. The measured sensing matrix phase is relative to the current demod phase, not 0 (unless the demod phase for that PD is currently 0degrees). So, now I take that into account. I add the current PD demod phase to the measured sensing matrix phase, so that the plot is actually true.
For interested parties, I have made all of the sensing matrix scripts, and the data folder a subdirectory of the /scripts/LSC folder, since it was starting to get crowded in there. I have moved the 2 data sets that have been collected (21May, 23May) into the new place.
Future thoughts:
* Save the amplitude and modulation frequency and the current demod phases in the data file. Right now the ampl and mod freqs are included in the title of the data file, but there is no record of what the demod phase was at the time. I need to fix this.
So, really, really, the Sensing Matrix:
Sensing Matrix, units = counts/meter, phase in degrees
PRCL Mag PRCL Phase MICH Mag MICH Phase
AS55 5.485E+08 -43.424 2.679E+09 93.392
REFL11 1.126E+13 -7.168 1.618E+11 135.296
REFL33 2.658E+11 164.973 8.910E+09 -2.226
REFL55 3.012E+11 -75.216 1.210E+10 172.764

|
8645
|
Sat May 25 02:03:48 2013 |
Annalisa | Update | 40m upgrading | ETMY - Mode Matching for green - new calculation |
Mode matching calculation for green - Yarm
I did again the mode matching calculation. The previous one was using 1064nm as wavelength, so it was wrong.
The seed beam waist and its position are the same as in elog 8637. The new results are shown in the attached graphs.
I got the following values for focal lengths and positions of the two Mode Matching lenses:
Focal length (m) Distance from the Faraday output (m)
lens1 0.125 0.1829
lens2 -0.200 0.4398
L 1.000 1.4986 (fixed)
The position of the lens L has changed because the path lengh has been slightly reduced.
The Coupling factor for he astigmatic beam is C = 0.959 (it is C = 0.9974 if we consider the beam as non astigmatic).
I put the lenses and aligned the beam up to the shutter, which has been moved from its initial position because the beam size on it was too large.
TO DO
The green beam needs to be aligned and sent into the arm cavity.
Polarization has to be checked.
Many beams still have to be dumped, both in IR and Green paths.
|
Attachment 1: ModeMatchingGreenNEW.jpg
|
|
Attachment 2: ModeMatchingGreenZoomNEW.jpg
|
|
Attachment 3: XYpathNEW.jpg
|
|
Attachment 4: photo1.JPG
|
|
Attachment 5: photo2.JPG
|
|
8646
|
Mon May 27 21:38:53 2013 |
Annalisa | Update | 40m upgrading | ETMY - Beam Dumps |
I put many razor dumps along the IR/green path. The rejected beam from the IR Faraday needs to be dumped (about 1.5 mW). I used all the new razor blade I had, so I need one more for that beam.
The IR reflection of the Harmonic separator right after the doubler needs to be dumped in a better way. At the moment there is a black screen, but we need something suitable to dump more than 300 mW.
After the second steering mirror along the green beam path there is a very small transmission (about 6 uW), which is difficult to dump because there is no space enough. Can it be dumped with a black screen?
The Oplev has a lot of reflection hitting the central BS (The BS for the transmitted beam). It is very difficult to dump them without intercepting the main beam path. Maybe we have to slightly change the Oplev beam angle to avoid so many reflections.
|
8647
|
Tue May 28 11:11:37 2013 |
Manasa | Update | IOO | MC aligned |
[Jenne, Manasa]
Fixed crappy alignment of MC by moving MC mirrors. MC REFL PD measured 0.5 after alignment. Spot positions were measured using msassMCdecenter. Plot for the same is attached. |
Attachment 1: MC_0528.png
|
|
8648
|
Tue May 28 14:52:56 2013 |
Jenne | Update | LSC | PRMI sensing matrix: Got it! |
Just so we have it, here is the re-analysis with the correct plot and phases for the May 21st data, taken near the violin mode:
Sensing Matrix, units = counts/meter, phase in degrees
PRCL Mag PRCL Phase MICH Mag MICH Phase
AS55 9.048E+11 -22.880 2.927E+12 107.071
REFL11 2.954E+16 -21.628 3.670E+14 123.857
REFL33 2.757E+14 -192.608 9.186E+12 -4.037
REFL55 2.868E+14 -82.690 1.186E+13 170.097

Even though this data was taken near the violin mode (oops!), it is fairly consistent with the stuff taken a few days later at 580Hz (elog 8644).
Neither of these is at all similar to what Kiwamu had measured a year ago (elog 6283), but we have changed many, many things since then. He also includes an Optickle simulation, which is fairly similar to the Koji simulation in the wiki, but neither his measurements nor mine are particularly close to the simulated version. I should think about why this is.
Also, I have fixed up the measurement scripts so that they record all of the relevant current settings / information: Current actuator calibration, current PD demod phases, drive amplitude and drive frequency. The "Analyze Saved Data" script has been updated to read all of this info from the files. If you want to plot / look at any old data, open up SensMatAnalyzeSavedData in /scripts/LSC/SensingMatrix/ and put in the relevant filename that you want (which should be saved in /scripts/LSC/SensingMatrix/SensMatData/) |
8649
|
Tue May 28 17:00:50 2013 |
Jenne | Update | ASC | Proposed POP path, to be installed this evening |
I have mounted 2 2" G&H high reflective mirrors, to be used in the new POP path. Manasa and Annalisa are doing green things on their respective arms, so I will hopefully be able to install the new POP path after dinner tonight.
Here are photos of the current POP path, and my proposed POP layout. In the proposed layout, the optical components whose labels are shaded are the ones which will change.


|