ID |
Date |
Author |
Type |
Category |
Subject |
5468
|
Mon Sep 19 20:56:36 2011 |
Paul | Summary | SUS | Remaining SRM and ITMY OSEMs calibrations |
I've now taken data for the pitch and yaw calibrations for the OSEMs of SRM and ITMY. Until such time as I know what the calibrated oplev noise spectra are like, I'm leaving the servo gains at zero.
I estimate the length of the lever arm from SRM to measurement position to be 3.06m, and the length of the lever arm from the ITMY to the measurement position to be 3.13m.
From the fits shown on the attached plots, this gives the following calibration factors for the SRM and ITMY OSEMs pitch and yaw counts (i.e. counts from channels such as SUS-ITMY_ULSEN_SW2 multiplied by a matrix of 1s and -1s) to pitch and yaw angle:
SRM PITCH: 1 OSEMs pitch count = 11.74 microradians
SRM YAW: 1 OSEMs yaw count = 12.73 microradians
ITMY PITCH: 1 OSEMs pitch count = 13.18 microradians
ITMY YAW: 1 OSEMs yaw count = 13.52 microradians
Next step is to do some DC offsets with the oplev paths back in place to get the final calibration between OSEMs counts and oplev counts, thus finally getting a conversion factor from oplev counts to radians.
I noticed while taking these measurements that the DC offsets I put on ITMY caused around 5 times larger change in angle than those on the SRM. The different path length is not enough to account for this, so I propose that the actuation is working differently for the two. I guess this should be taken into account when designing the output matrices (unless the control is passed through a different output matrix than the DC offsets?). I'll quantify the difference shortly, and write a conversion factor between output alignment count (e.g. SUS-ITMY_PIT_COMM) and angle.
|
Attachment 1: SRM_PITCH_calib_curve.png
|
|
Attachment 2: SRM_YAW_calib_curve.png
|
|
Attachment 3: ITMY_PITCH_calib_curve.png
|
|
Attachment 4: ITMY_YAW_calib_curve.png
|
|
5471
|
Mon Sep 19 22:47:44 2011 |
Jenne | Update | SUS | SUS diag stuff... just so I remember what I'm doing |
The last person out tonight should run the following scripts:
In Matlab:
/opt/rtcds/caltech/c1/scripts/SUS/peakFit/writeMultiSUSinmat.m
In command line:
/opt/rtcds/caltech/c1/scripts/SUS/freeswing all
Then in the morning, someone should do a BURT restore to early today (to get the default matricies back), and also restore the watchdogs.
Thanks!
|
5475
|
Tue Sep 20 03:12:14 2011 |
Anamaria | Update | SUS | Jenne's Scripts started |
I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning. |
5476
|
Tue Sep 20 04:12:26 2011 |
Jenne | Update | SUS | Jenne's Scripts started |
Quote: |
I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.
|
Thanks! I'll give them a little more time, then restore things. |
5477
|
Tue Sep 20 09:44:44 2011 |
Jenne | Update | SUS | Jenne's Scripts started |
Quote: |
Quote: |
I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.
|
Thanks! I'll give them a little more time, then restore things.
|
I began restoring the optics at ~9:30am, so I have a full 6 hours of data, in case I need that much to separate the Pos/Side modes on some of the optics. They are all damping again with their original matricies. |
5479
|
Tue Sep 20 14:53:13 2011 |
Jenne | Update | SUS | Jenne's Scripts started |
Quote: |
Quote: |
Quote: |
I followed Jenne's instructions, ran the matrix filler script and then set the optics to freeswing. Someone has to burt resture and damp them in the morning.
|
Thanks! I'll give them a little more time, then restore things.
|
I began restoring the optics at ~9:30am, so I have a full 6 hours of data, in case I need that much to separate the Pos/Side modes on some of the optics. They are all damping again with their original matricies.
|
So, clearly this was a kind of dumb idea. There is nothing mechanical going on between our sensor inputs and our Pit/Pos/Yaw/Side DoF filter banks. It's just math. On the other hand, we now have a 3rd set of in-vac free swinging data, so I can (after all the suspensions are working) have a look at the drift in matrix elements over time.
In other news, after some meditation, and fitzing with DoF gain values, all of the IFO optics except for SRM now have their new input matricies, and are damping pretty nicely. I need to go through and do an "eyeball" check to make sure that everything has a Q of ~5ish. So far, I've kicked the optics, and watched that they damped fairly quickly, but I don't have a guesstimate of the Q's for each optic, for each DoF.
So, still to do:
Use another set of data and invert the SRM matrix DONE
Plug in the MC matricies, make sure they're okay. DONE
Check the Q's for all optics, all DoFs. |
5480
|
Tue Sep 20 15:23:16 2011 |
Jenne | Update | SUS | free swinging test in vacuum condition |
This is using data for the SRM from: 20 Sept 2011 03:20:00 PDT = 1000549215
You can see that there are still some funny peaks between Pit and Yaw, but I finnessed the peak-finding, and I was able to fit all of the correct peaks, and invert the matrix:
SRM now has its new matrix, and is damping happily.
Optic |
The Plot |
Matrix |
Badness |
SRM |
 |
pit yaw pos side butt
UL 0.877 0.983 1.105 -0.288 1.092
UR 1.010 -1.017 1.123 -0.145 -1.055
LR -0.990 -1.002 0.895 -0.091 0.848
LL -1.123 0.998 0.877 -0.234 -1.006
SD 0.089 0.064 3.752 1.000 -0.009 |
4.4076 |
|
5481
|
Tue Sep 20 15:39:57 2011 |
Koji | Update | SUS | free swinging test in vacuum condition |
Can't we use Yuta's auto-Q adjust script?
http://nodus.ligo.caltech.edu:8080/40m/3723
Edit by KI :
Of course we can use it but first we have to fix some pynds sentences since his script was written for the OLD pynds. |
5485
|
Tue Sep 20 16:45:09 2011 |
Jenne | Update | SUS | SUS diag stuff... just so I remember what I'm doing |
Has the Q been checked? Still in progress...
Optic |
POS |
PIT |
YAW |
SIDE |
ITMX |
done |
done |
done |
done |
ITMY |
done |
done |
fine?? |
done |
ETMX |
done |
done |
done |
done |
ETMY |
done |
done |
done |
done |
BS |
done |
done |
done |
done |
PRM |
done |
done |
done |
done |
SRM |
done |
done |
done |
done |
MC1 |
|
|
|
|
MC2 |
|
|
|
|
MC3 |
|
|
|
|
So, update as of 6:17pm: I have tuned the damping gains for all IFO optics. Everything is good, except for ITMY Yaw. It's probably fine, the optic damps okay, but it doesn't look like a nice clean ringdown. I haven't taken the time to go back and look at it again.
I have to go to a dinner, but later (probably in the morning, so I don't disturb evening locking) I'll check the MC Qs. |
5487
|
Tue Sep 20 18:03:45 2011 |
Paul | Update | SUS | ITMY and SRM oplev calibrations - measured and estimated |
The measured calibration factors for the oplevs are as follows:
SRM pitch: 666urad per count on channel C1-SUS-SRM-OLPIT-INMON
SRM yaw: 557urad per count on channel C1-SUS-SRM-OLYAW-INMON
ITMY pitch: 470urad per count on channel C1-SUS-ITMY-OLPIT-INMON
ITMY yaw: 491urad per count on channel C1-SUS-ITMY-OLYAW-INMON
Since I'm going to calibrate all the other oplevs with the rougher technique of estimating the angle from the OSEM signals directly, I thought I would check the result of such an estimation for the oplevs I have calibrated already. My method was as follows:
dA = change in angle
dx = change in OSEM flag position
dV = change in OSEM PD voltage
dC = change in OSEM counts
D = optic diameter
L = distance between OSEMs = D/sqrt(2)-0.002m = 0.052m
dV/dx = OSEMs volts per meter flag position change = 1700 V/m
dC/dV = OSEM counts per volt = 2^16/40 = 65536/40 counts/V
counts per radian = dC/dA = dV/dx x dC/dV x 1/L = 1700*65536/40/0.052 = 5.3564x10^7 counts/rad
radians per count = dA/dC = 1.867x10^-8, or 0.019 urad/count
This is around a factor of 1000 smaller than what I measured earlier, reported in entry 5468. I guess this might be an issue with the whitening filter on the OSEMs, but my initial feeling was that this was only a factor of a few. If anyone can see a big obvious mistake in my above calculations please let me know!
|
5488
|
Tue Sep 20 19:00:49 2011 |
Paul | Update | SUS | ITMY and SRM oplev calibrations - measured and estimated |
Kiwamu noticed that the 1/L in the counts per radian should have just been L, which accounts for most of the discrepancy. We checked the input filters on the OSEMs, and they have 10dB of gain at DC. Accounting for this, estimates on the order of 20urad/count, which is much more reasonable! |
5493
|
Wed Sep 21 00:34:29 2011 |
rana | Update | SUS | SUS diag stuff... just so I remember what I'm doing |
ETMX was ringing up when it was mis-aligned for Y arm locking. I restored the input matrix to something more diagonal and its now damping again. Needs more work before we can use the calculated matrix. |
5494
|
Wed Sep 21 00:37:01 2011 |
rana | Update | SUS | ITMY and SRM oplev calibrations - measured and estimated |
I found that some of the Optical Lever Servos were ON today and injecting nonsense into the interferometer optics. I have set all of the gains = 0 to save us more headaches.
Please leave them OFF until we review the servo and noise characterization results in the elog. |
5496
|
Wed Sep 21 09:10:15 2011 |
Paul | Update | SUS | ITMY and SRM oplev calibrations - measured and estimated |
Quote: |
I found that some of the Optical Lever Servos were ON today and injecting nonsense into the interferometer optics. I have set all of the gains = 0 to save us more headaches.
Please leave them OFF until we review the servo and noise characterization results in the elog.
|
I had previously set the gains to zero, see the first line of my entry on Monday 5468. I should have the servo and noise characterisation done today for these oplevs today, so we can review it soon. |
5499
|
Wed Sep 21 14:44:25 2011 |
Paul | Update | SUS | ITMY and SRM open loop transfer functions |
Here are the open loop transfer functions for ITMY and SRM. The various settings for the OLTFs were as follows:
Oplev filter used for all OLTFs: 300^2:0
Gains for oplev servos (for each OLTF only the 1 servo for the measured TF was on. They are all set back to 0 now):
SRM yaw gain = 1
SRM pitch gain = -1
ITMY yaw gain = -1
ITMY pitch gain = 1
measurement band = 0.2Hz to 200Hz
points = 33
swept sine magnitude envelope: amp = 2 for f > 60Hz, amp = 0.1 for f < 60Hz
Measurement points were from e.g. C1-SUS-ITMY-OLPIT-IN2 to C1-SUS-ITMY-OLPIT-IN1 to give a TF of -(loop gain).
Next step is to divide this through by the sensor reponse (i.e. the calibration factor measured earlier) and the filter response to get just the actuator response.
|
Attachment 1: ITMY_SRM_oplev_OLTFs.png
|
|
5500
|
Wed Sep 21 16:22:14 2011 |
rana | Update | SUS | Summary screen |
The SUS SUMMARY screen is now fully activated. You should keep it open at all times as a diagnostic of the suspensions.
No matter how cool you think you are, you are probably doing something bad when trying to lock, measure any loop gains, set matrices, etc. Use the screen.
This is the link to the automatic snapshot of the SUS SUMMARY screen. You can use it to check the Suspensions status with your jPhone.
Auto SUS SUMMARY Snapshot
When the values go yellow its near the bad level. When its red, it means the optic is misaligned or not damped or has the wrong gain, etc.
So don't ignore it Steve! If you think the thresholds are set too low then change them to the appropriate level with the scripts is SUS/ |
5501
|
Wed Sep 21 16:31:28 2011 |
Paul | Update | SUS | ITMY and SRM actuator response functions |
I divided the open loop transfer functions by the filter response and the sensor responses (previously measured calibration factors) to leave just the actuator responses. I've attached the actuator responses plotted in radians/count and phase over frequency.
Next step: fit the actuator response with poles and zeros.
EDIT: I divided by the wrong filter function earlier - the plots there now are divided by the correct filter function |
Attachment 1: ITMY_PITCH_actuator_response.png
|
|
Attachment 2: ITMY_YAW_actuator_response.png
|
|
Attachment 3: SRM_PITCH_actuator_response.png
|
|
Attachment 4: SRM_YAW_actuator_response.png
|
|
5507
|
Wed Sep 21 23:05:16 2011 |
Paul | Update | SUS | ITMY and SRM actuator response functions - fitting results |
I used an fminsearch function to fit the SRM and ITMY actuator response magnitudes. The testfunction was just that for a single second order pole, but it gave what I consider to be good fits for the following reasons:
*for 3 of the 4 fits the residuals were less than 0.5% of the summed input data points. The worst one (ITMY pitch) was about 2.7%, which I think is due to the resonance happening to be right in the middle of two data points.
*the tolerance of 1 part in 10^9 was reached quickly from not very finely tuned starting points.
The test function was: G=abs(Gp./(1+1i.*f./fp./Qp-(f./fp).^2)), where G(f) is the actuator response magnitude, Gp is the pole gain, fp is the pole frequency, and Qp is the pole Q factor.
In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?
Anyway, here are the results of the fits, and I've attached plots of each too (each one in linear and log y axis because each on its own might be misleading for fits):
EDIT - I added more points to the otherwise sparse looking fitted curves
ITMY PITCH actuator response fit
-- Fit completed after 190 iterations--
Started with: Gain = 3e-06,
Q factor = 5,
Pole frequency = 1,
Fit results: Gain = 1.32047e-06,
Q factor = 4.34542,
Pole frequency = 0.676676
Residual (normalised against the sum of input datapoints) = 0.0268321
ITMY YAW actuator response fit
-- Fit completed after 156 iterations--
Started with: Gain = 3e-06,
Q factor = 5,
Pole frequency = 1,
Fit results: Gain = 1.14456e-06,
Q factor = 8.49875,
Pole frequency = 0.730028
Residual (normalised against the sum of input datapoints) = 0.00468077
SRM PITCH actuator response fit
-- Fit completed after 192 iterations--
Started with: Gain = 3e-06,
Q factor = 5,
Pole frequency = 1,
Fit results: Gain = 7.94675e-06,
Q factor = 7.16458,
Pole frequency = 0.57313
Residual (normalised against the sum of input datapoints) = 0.00301265
SRM YAW actuator response fit
-- Fit completed after 156 iterations--
Started with: Gain = 3e-06,
Q factor = 5,
Pole frequency = 1,
Fit results: Gain = 3.34179e-06,
Q factor = 9.57601,
Pole frequency = 0.855322
Residual (normalised against the sum of input datapoints) = 0.000840468 |
Attachment 1: ITMY_PITCH_actuator_response_FIT.png
|
|
Attachment 2: ITMY_YAW_actuator_response_FIT.png
|
|
Attachment 3: SRM_PITCH_actuator_response_FIT.png
|
|
Attachment 4: SRM_YAW_actuator_response_FIT.png
|
|
5508
|
Wed Sep 21 23:25:51 2011 |
kiwamu | Update | SUS | Re:ITMY and SRM actuator response functions - fitting results |
Did you take the 180 deg shift into your account ?
Since your measurement was done when the loop was closed, there must be an additional 180 deg phase shift (in other words, minus sign).
Quote from #5507 |
In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?
|
|
5509
|
Wed Sep 21 23:44:45 2011 |
Paul | Update | SUS | Re:ITMY and SRM actuator response functions - fitting results |
Quote: |
Did you take the 180 deg shift into your account ?
Since your measurement was done when the loop was closed, there must be an additional 180 deg phase shift (in other words, minus sign).
Quote from #5507 |
In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?
|
|
I thought I had, but apparently not, and I'd made another error or two in the complex version of my fitting routine. I've fixed them now, thanks! I'll put up the new fitting results tomorrow morning. |
5510
|
Thu Sep 22 00:00:10 2011 |
Paul | Update | SUS | ITMY and SRM actuator response functions - complex fitting results |
Here are the results of the complex fitting. The residuals are bigger this time, but still probably small enough to be ok(?), with the possible exception of ITMY PITCH (due again I think to the data points straddling the resonance).
ITMY YAW actuator response complex fit
-- Fit completed after 282 iterations--
Started with: Gain = 3e-05,
Q factor = 5,
Pole frequency = 0.6776,
Fit results: Gain = 1.14673e-06,
Q factor = 12.9471,
Pole frequency = 0.766531
Residual (normalised against the sum of input datapoints) = 0.0688174
ITMY PITCH actuator response complex fit
-- Fit completed after 191 iterations--
Started with: Gain = 3e-05,
Q factor = 5,
Pole frequency = 0.6776,
Fit results: Gain = 1.25105e-06,
Q factor = 3.88981,
Pole frequency = 0.706744
Residual (normalised against the sum of input datapoints) = 0.144165
SRM YAW actuator response complex fit
-- Fit completed after 246 iterations--
Started with: Gain = 3e-05,
Q factor = 5,
Pole frequency = 0.6776,
Fit results: Gain = 3.34137e-06,
Q factor = 9.6875,
Pole frequency = 0.854913
Residual (normalised against the sum of input datapoints) = 0.0153646
SRM PITCH actuator response complex fit
-- Fit completed after 266 iterations--
Started with: Gain = 3e-05,
Q factor = 5,
Pole frequency = 0.6776,
Fit results: Gain = 7.97529e-06,
Q factor = 7.63888,
Pole frequency = 0.568227
Residual (normalised against the sum of input datapoints) = 0.0319653 |
Attachment 1: ITMY_PITCH_actuator_response_complex_FIT.png
|
|
Attachment 2: ITMY_YAW_actuator_response_complex_FIT.png
|
|
Attachment 3: SRM_PITCH_actuator_response_complex_FIT.png
|
|
Attachment 4: SRM_YAW_actuator_response_complex_FIT.png
|
|
5514
|
Thu Sep 22 10:43:50 2011 |
Paul | Update | SUS | Power spectrum with different filter gains |
I thought it might be informative before trying to optimise the filter design to see how the current one performs with different gain settings. I've plotted the power spectra for ITMY yaw with filter gains of 0, 1, 2, 3 and 4.
All of the higher gains seem to perform better than the 0 gain, so can I deduce from this that so far the oplev control loop isn't adding excess noise at these frequencies? |
Attachment 1: ITMY_YAW_closed_vs_open_noise.pdf
|
|
5517
|
Thu Sep 22 13:45:17 2011 |
Paul | Update | SUS | ETMX actuator response fits |
Fitting results:
Pitch
-- Fit completed after 305 iterations--
Started with: Gain = 3e-05,
Q factor = 5,
Pole frequency = 0.6776,
Fit results: Gain = 1.85497e-06,
Q factor = 23.7233,
Pole frequency = 0.956686
Residual (normalised against the sum of input datapoints) = 0.0202483
Yaw
-- Fit completed after 334 iterations--
Started with: Gain = 3e-05,
Q factor = 5,
Pole frequency = 0.6776,
Fit results: Gain = 2.518e-06,
Q factor = 7.21618,
Pole frequency = 0.853559
Residual (normalised against the sum of input datapoints) = 0.0570132 |
Attachment 1: ETMX_PITCH_actuator_response_complex_fit.png
|
|
Attachment 2: ETMX_YAW_actuator_response_complex_fit.png
|
|
5521
|
Thu Sep 22 17:48:20 2011 |
kiwamu | Update | SUS | bad oplev on ETMY |
It turned out the oplev controls on ETMY were just bad.
It looks like the whitening filters have been OFF and because of that the resultant open-loop was not crossing the unity gain.
I will check the whitening filters.
(open-loop transfer function)
The blue dots are the measured data points and the green curve is the fit.
Apparently the open-loop doesn't go above the unity gain, so the oplev had been doing nothing.
If we try to increase the overall gain it will oscillate because of the phase delay of more than 180 deg around 3 Hz.
The red curve is the expected one with the whitening filters (WFs) properly engaged.
Note that WF are supposed to have two zeros at 1 Hz and two poles at 10 Hz.

Quote from #5518 |
(to do)
+ optimization of the ETMY oplevs and OSEM damping.
|
|
5523
|
Thu Sep 22 20:12:54 2011 |
kiwamu | Update | SUS | ETMY oplev whitening engaged |
The whitening filters for the ETMY oplevs are back. 
The whitening board had been in the rack but the ADC was connected directly to the oplev interface board without going through the whitening board.
In fact the interface board and the whitening board had been already connected. So the ADC was making a shortcut.
I disconnected the ADC from the interface board and plugged it to the output of the whitening board.
Here is an example of the new open-loop transfer function with the whitening filters.

Note :
before the measurement I increased the control gain by an arbitrary number to obtain gain of more than 1 around 1 Hz.
Quote from #5521 |
I will check the whitening filters.
|
|
5532
|
Fri Sep 23 17:57:34 2011 |
Paul | Update | SUS | Oplev filter optimization for 2 poles and 2 zeros |
I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.
I have a attached a plot showing the power spectrum and RMS curves for the optimization result for 2 zeros and 2 poles, optimized to give a minimal RMS below 20Hz.
I have also attached a plot showing the loop gain and the filter transfer function.
The noise spectrum shows that the optimised filter gives a better noise performance below 10Hz, but a servo oscillation at the UGF of 10 Hz means it injects a lot of motion around this frequency. Should I consider some more aggressive way to force the script to keep a decent phase margin?
The fminsearch results show that the 'optimized' solution is two resonant peaks:
-- Optimisation completed after 571 iterations--
Started with:
Pole 1 frequency = 1 Hz
Pole 2 frequency = 2 Hz
Zero 1 frequency = 0.1 Hz
Zero 2 frequency = 5 Hz
Overall gain = 1
Finished with:
Pole 1 frequency = 0.0497181 Hz
Pole 2 frequency = 2.01809 Hz
Zero 1 frequency = 0.0497181 Hz
Zero 2 frequency = 2.01809 Hz
Overall gain = 71970.1
Initial RMS below 10 Hz = 5.90134e-06
Remaining RMS below 10 Hz = 8.42898e-07
|
Attachment 1: optimised2p2z_v1.png
|
|
Attachment 2: optimised2p2z_v1_TFs.png
|
|
5534
|
Sat Sep 24 01:21:11 2011 |
kiwamu | Update | SUS | damping test |
As a suspension test I am leaving all of the suspensions restored and damped with OSEMS but without oplevs |
5536
|
Sat Sep 24 01:51:02 2011 |
rana | Update | SUS | Oplev filter optimization for 2 poles and 2 zeros |
Quote: |
I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.
|
I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.
Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:
1) Limit the gain peaking at the upper UGF to 6 dB.
2) Minimum phase margin of 45 deg.
3) Minimum gain margin of 10 dB.
4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.
5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.
6) Looser noise contraint above 50 Hz for the non TM loops. |
5537
|
Sat Sep 24 02:09:43 2011 |
kiwamu | Update | SUS | Re:Oplev filter optimization for 2 poles and 2 zeros |
Good work for the oplev noise simulations. Here are some comments/questions:
(A) The noise looks suppressed but the open-loop transfer function doesn't look so good, because it doesn't have sufficient phase margins at the UGFs (0.01 and 10 Hz).
I guess it is better to have a phase margin detector in your code so that the code automatically rejects a bad phase margin case.
Actually since the number of data points are finite, the rms detector in the simulation can not always find a sharp loop oscillation.
(B) The resultant poles and zeros seem canceling each other but the filter still has a structure. Is something wrong ?
Quote from #5332 |
Pole 1 frequency = 0.0497181 Hz
Pole 2 frequency = 2.01809 Hz
Zero 1 frequency = 0.0497181 Hz
Zero 2 frequency = 2.01809 Hz
|
|
5540
|
Sat Sep 24 17:45:56 2011 |
Paul | Update | SUS | Re:Oplev filter optimization for 2 poles and 2 zeros |
Quote: |
(B) The resultant poles and zeros seem canceling each other but the filter still has a structure. Is something wrong ?
Quote from #5332 |
Pole 1 frequency = 0.0497181 Hz
Pole 2 frequency = 2.01809 Hz
Zero 1 frequency = 0.0497181 Hz
Zero 2 frequency = 2.01809 Hz
|
|
Ah yes, well noticed. I think I have tracked this down to just a bug in printing of fitting results: It was just printing the pole results for the zeros too. The results for the same fit now read:
Finished with:
Pole 1 frequency = 0.0497181 Hz
Pole 2 frequency = 2.01809 Hz
Zero 1 frequency = 0.0972455 Hz
Zero 2 frequency = 6.50126 Hz
Overall gain = 71970.1
EDIT: sorry, I forgot that when you write a reply, the author is still by default the person you are replying to unless you change it!
|
5544
|
Mon Sep 26 14:21:07 2011 |
kiwamu | Update | SUS | ITMX ULSEN shows jumps |
Quote from #5534 |
As a suspension test I am leaving all of the suspensions restored and damped with OSEMS but without oplevs
|
According to the spectra, all of the suspensions had been damped with the OSEMs. The peaks around 1Hz are reasonably suppressed.
However the spectra from ITMX showed a noise floor at very high level. This is because of strange jumps in the signal of the UL shadow sensor.
I will check some analog circuits for the UL sensor.
(ITMX shadow sensors)
Here is the spectra of the ITMX shadow sensors taken during the damping test (#5534)- -
The UL sensor shows a unacceptable amount of noise.
Additionally I checked the time series of the ITMX shadow sensors and found ONLY the UL sensor frequently showed strange jumps in data.
Here is an example of the time series showing a jump ONLY in the UL sensor.

It is possible that the jumps are coming from some circuits, since the rest of the sensors (including the oplevs) don't detect the same jump. |
5546
|
Mon Sep 26 15:54:46 2011 |
kiwamu | Update | SUS | ITMX ULSEN shows jumps |
Currently the damping of the ITMX suspension is intentionally disabled for the noise investigation.
Quote from #5544 |
However the spectra from ITMX showed a noise floor at very high level. This is because of strange jumps in the signal of the UL shadow sensor.
I will check some analog circuits for the UL sensor.
|
|
5547
|
Mon Sep 26 16:42:08 2011 |
kiwamu | Update | SUS | ITMX ULSEN : fixed |
The issue on the ITMX UL sensor has been fixed. It was because of a loose connection in the sensor signal path. 
After the fix, the sensor responses completely changed and the suspension became unable to be damped with the new matrix.
At the moment the ITMX suspension is damped by the default input matrix.
we should do the free swinging test once again.
(details)
The loose connection was found on the rear side of the 1X5 rack.
There is an adapter card on the rear side, where the driver and sensor signals are combined into a single cable.
I pushed the sensor cable (bottom right in the picture) and the noise disappeared.

Note that I changed the labels on the adapter cards from the old X/Y convention to the new one.
After fixing the loose cable the ITMX suspension became unable to be damped.
So I put the input matrix back to the default and it immediately started damping happily. It means our new matrix is not valid any more.
Here is the latest noise spectra of the ITMX sensors damped with the default input matrix.
As usual all of them are limited by the ADC noise above 20 Hz. (ADC noise is plotted in purple curve)

During the work I also pushed not only ITMX ones but also the cable for the rest of the optics in the adapter cards.
Then PRM became unable to be damped, so it implies the PRM suspension also used to be the same situation.
The input matrix of PRM has been also back to the default.
Quote from #5546 |
Currently the damping of the ITMX suspension is intentionally disabled for the noise investigation.
|
|
5554
|
Tue Sep 27 08:51:29 2011 |
Paul | Update | SUS | Oplev filter optimization for 2 poles and 2 zeros |
Quote: |
Quote: |
I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.
|
I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.
Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:
1) Limit the gain peaking at the upper UGF to 6 dB.
2) Minimum phase margin of 45 deg.
3) Minimum gain margin of 10 dB.
4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.
5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.
6) Looser noise contraint above 50 Hz for the non TM loops.
|
I moved two matlab scripts into the folder /cvs/cds/rtcds/caltech/c1/scripts/SUS/Oplev_filter_optimization
These are the function 'filter_optimiser_zeros_and_poles.m', and the example script to run the function 'run_filter_optimiser.m'. Type 'help filter_optimiser_zeros_and_poles.m' to get details about the function.
I haven't implemented the new weights yet. I've pasted them into the the file header to remind me/us of the work to be done on the function. |
5559
|
Tue Sep 27 20:02:19 2011 |
Koji | Update | SUS | Watchdog rearmed |
I came to the control room and found the PMC and IMC were unlocked. ==> Relocked
I found the watch dogs of the vertex suspensions are tripped.
I checked the data for the past 6 hours and found they are independent events.
The unlock of the MCs occured 4 hours ago and the watchdogs tripped 2 hours ago.
The suspension damping was restored at around 7:50PM PDT. |
5560
|
Wed Sep 28 00:06:21 2011 |
Jenne | Update | SUS | Watchdog rearmed |
Quote: |
I came to the control room and found the PMC and IMC were unlocked. ==> Relocked
I found the watch dogs of the vertex suspensions are tripped.
I checked the data for the past 6 hours and found they are independent events.
The unlock of the MCs occured 4 hours ago and the watchdogs tripped 2 hours ago.
The suspension damping was restored at around 7:50PM PDT.
|
Oops, I should have noticed all of those things. Several hours of computer-battle exhausted me. Thanks Koji. |
5562
|
Wed Sep 28 07:36:41 2011 |
steve | Update | SUS | ITMY damping restored |
ITMY suspention damping restored |
5563
|
Wed Sep 28 07:46:42 2011 |
steve | Update | SUS | Dsub connections at the back of 1X5 are fixed |
I'm turning the sus damping off for Dsub connection fix at the back of 1X5 rack
The plan is to install 4-40 jack screws to lock connector positions.
All dewittening(or called coil driver) and wittening D sub connectors are locked with two 4-40 socket head screws |
5587
|
Fri Sep 30 17:01:29 2011 |
steve | Update | SUS | ETMX oplev intensity effect on noise |
Kiwamu and Steve,
This is one of the better oplev set up we have. Single bounce from TM, no mirror on stack. One lens and one mirror on ISCT. Old Uniphase 1103P laser on heafty 3" od mounts.
Somewhat big ~5-6 mm spot on qpd in 1,300 counts.
The intensity noise effect can be seen at 1 Hz and 3-20 Hz
Oplev servo was OFF |
Attachment 1: ETMXoplintens.jpg
|
|
Attachment 2: P1080267.JPG
|
|
5594
|
Sun Oct 2 02:21:27 2011 |
kiwamu | Update | SUS | free swinging test once more |
The following optics were kicked:
MC1 MC2 MC3 ETMX ETMY ITMX ITMY PRM SRM BS
Sun Oct 2 02:13:40 PDT 2011
1001582036
They will automatically get back after 5 hours. |
5597
|
Sun Oct 2 18:33:36 2011 |
kiwamu | Update | SUS | inversion of the input matrix on ETMX, ITMX and PRM |
The input matrices of ETMX, ITMX and PRM have been newly inverted.
Those were the ones having some troubles (see #5444, #5547).
After a coarse adjustment of the damping Q factors, they look damping happily.
optic |
spectra |
inverted matrix |
BADNESS |
ETMX |
 |
pit yaw pos side butt
UL 0.848 0.108 1.578 0.431 1.025
UR 0.182 -1.892 1.841 -0.128 -1.172
LR -1.818 -1.948 0.422 -0.122 0.939
LL -1.152 0.052 0.159 0.438 -0.864
SD 1.756 -3.794 -0.787 1.000 -0.132 |
5.37028 |
ITMX |
|
pit yaw pos side butt
UL 0.510 0.584 1.228 0.458 0.203
UR 0.783 -1.350 0.348 -0.050 0.555
LR -1.217 0.065 0.772 0.264 0.312
LL -1.490 2.000 1.652 0.772 -2.930
SD -0.635 0.853 -1.799 1.000 -1.597 |
7.5125 |
PRM |
 |
pit yaw pos side butt
UL 0.695 1.422 1.774 -0.333 0.954
UR 1.291 -0.578 0.674 -0.068 -0.939
LR -0.709 -1.022 0.226 0.014 0.867
LL -1.305 0.978 1.326 -0.251 -1.240
SD 0.392 -0.437 -0.500 1.000 0.420 |
5.09674 |
(some notes)
Before running the peakFit scripts, I woke up the nds2 sever process on Mafalda because it hasn't been recovered from the power outage.
To start the nds2 process I followed the instruction by Jamie (#5094).
Then I started requesting the data of the last night's free swinging test (#5594)
However the NDS2_GetData command failed everytime when data with long duration were requested.
It maybe because some of the data are missing in sometimes, but I haven't seriously checked the data stored in fb.
So for the reason, I had to use a short duration of 1200 sec (default is 3600 sec). That's why spectra look noisier than usual. |
5600
|
Mon Oct 3 13:04:12 2011 |
Jenne | Update | SUS | AUXEX, AUXEY rebooted |
Quote: |
+ I found that burtrestore for the ETMX DC coil forces were not functional.
=> currently ETMX's "restore" and "mislalign" buttons on the C1IFO_ALIGN screen are not working.
=> According to the error messages, something seemed wrong on c1auxex, which is a slow machine controlling the DC force.
|
[Suresh, Jenne]
Suresh pointed out the oddity that all of the EX, EY slow channels were showing white boxes on the medm screens on all of the workstations except Rosalba. I don't know why Rosalba seemed to be working, but whatever. I'm not 100% sure that Rosalba was even working properly....I shutdown ETMX and ETMY's watchdogs before we went to boot computers, but when I came back to the control room the 2 optics were rung up anyway. Turning back on the watchdogs, the optics immediately began to damp happily.
Since Kiwamu had trouble with the slow channels for EX, we decided to key some crates.
We keyed the c1auxey, and c1auxex crates, waited a few seconds, and then things looked okay in medm-land. I looked at the "View Backup" for ETMX, and there were no values for the DC sliders, so since the arms are both flashing right now, I did a "save", and then confirmed that I can misalign and restore the optic. However, since I didn't fully align/lock the cavity, the saved value for right now shouldn't be fully trusted. We might have to manually align the cavity using the BS. |
5601
|
Mon Oct 3 14:05:41 2011 |
Jenne | Update | SUS | Failing to set SUS summary screen values |
I assume it's because the burt restore didn't work for the SUS summary screen, but all of the values for the ifo suspensions (not the MCs...they're okay) are red.
I am trying to run Rana's setSensors.py script, but am failing. Any inspiration would be appreciated:
rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
File "./setSensors.py", line 81, in ?
mean = acquire(x)
File "./setSensors.py", line 73, in acquire
daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
daq.request_channel(daq, str)
did not match C++ signature:
request_channel(_daq_t {lvalue}, daq_channel_t*)
I'm not exactly sure what the problem is. Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error. So...something else is wrong. Ideas from someone who "speaks" python?? |
5604
|
Mon Oct 3 17:27:23 2011 |
Jenne | Update | SUS | Failing to set SUS summary screen values |
Quote: |
I am trying to run Rana's setSensors.py script, but am failing. Any inspiration would be appreciated:
rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
File "./setSensors.py", line 81, in ?
mean = acquire(x)
File "./setSensors.py", line 73, in acquire
daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
daq.request_channel(daq, str)
did not match C++ signature:
request_channel(_daq_t {lvalue}, daq_channel_t*)
I'm not exactly sure what the problem is. Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error. So...something else is wrong. Ideas from someone who "speaks" python??
|
My guess is that this has something to do with the NDS client version you're using. Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa. |
5618
|
Tue Oct 4 19:31:17 2011 |
kiwamu | Update | SUS | PRM and BS oplev laser died |
The He-Ne laser which has been used for the PRM and BS oplevs were found to be dead. 
According to the trend data shown below, it became dead during the dolphin issue.
(During the dolphin issue the output from the oplev QPDs are digitally zero)

|
5620
|
Wed Oct 5 11:33:25 2011 |
steve | Update | SUS | PRM and BS oplev laser replaced |
JDSU 1103P died after 4 years of service. It was replaced with new identical head of 2.9 mW output. The power supply was also changed.
The return spots of 0.04 mW 2.5 mm diameter on qpds are BS 3,700 counts and PRM 4,250 counts.
|
5622
|
Wed Oct 5 17:08:49 2011 |
steve | Update | SUS | BS oplev spectra |
Kiwamu and Steve,
The He/Ne oplev shows no coherece so relative intensity noise is not limiting factor for the oplev servo |
Attachment 1: BSoplservON2.png
|
|
5630
|
Fri Oct 7 14:04:48 2011 |
steve | Update | SUS | He/Ne intensity noise effect on oplevs |
The SRM bounce peak 18.33 Hz. Suresh helped me to retune filter through Foton, but we failed to remove it.
ITMX_OPLEV_PERROR shows high coherence with oplev laser. This is our lousiest set up. I will work on it next week.
Generally speaking we can say that JDSU-Uniphase 1103P and 1125P laser intensity noise do not limit oplev servo performance.
However, the overall well being of filters, gain settings, beam sizes on qpds are poor.
|
Attachment 1: PRMoplevINTn.png
|
|
Attachment 2: BSoplevINTn.png
|
|
Attachment 3: ITMXoplevINTn.png
|
|
Attachment 4: ITMYoplevINTn.png
|
|
Attachment 5: SRM_oplevINTn.png
|
|
Attachment 6: ETMYoplevINTn3.png
|
|
Attachment 7: ETMXoplevINTn.png
|
|
5633
|
Fri Oct 7 22:31:53 2011 |
kiwamu | Update | SUS | noisy ULSEN on ETMY |
Yesterday Koji was claiming that the rms monitor of ULSEN on ETMY didn't well go down.
Indeed something bad is happening on ULSEN of ETMY.
I guess it could be a loose connection.

(The unit of Y axis in the plot is not true. Don't believe it !) |
5636
|
Fri Oct 7 23:23:05 2011 |
kiwamu | Update | SUS | SRM oplev was oscillating |
The SRM oplevs were found to be oscillating because of a small phase margin.
I reduced the gains to the half of them. The peak which Steve found today maybe due to this oscillation.
Quote from #5630 |
The SRM bounce peak 18.33 Hz. Suresh helped me to retune filter through Foton, but we failed to remove it.
|
|