40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 140 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5423   Thu Sep 15 18:31:27 2011 PaulUpdateSUSITMY and SRM Oplev current status - comparison with ITMY

Quote:

Just to find out where we are currently, I plotted the ITMY and SRM oplev spectra along with the ETMY oplev spectra. ETMY seems to be very good, so comparing with this seemed useful, so we know how much we have to improve by. The SRM power spectrum appears to be around 2 orders of magnitude higher than ETMY over pretty much the whole measurement band. The ITMY power spectrum is not so bad as the SRM above about 60Hz. Next thing to do is to check the dark noise level for the ITMY and SRM QPDs.

 The title of this post should of course have been " ... - comparison with ETMY" not " ... - comparison with ITMY"

  5427   Thu Sep 15 22:26:32 2011 PaulUpdateSUSITMY Oplev QPD dark noise PSD

 I took a dark noise measurement for the ITMY QPD, for comparison with measurements of the oplev noise later on. Initially I was plotting the data from test points after multiplication by the oplev matrix (i.e. the OLPIT_IN1 / OLYAW_IN1), but found that the dark noise level seemed higher than the bright noise level (!?). Kiwamu realised that this is because at that test point the data is already divided by QPD SUM, thus making the dark noise level appear to be greater than the bright level, since QPD SUM is much smaller for the dark measurements. The way around this was to record the direct signals from each quadrant before the division. I took a power spectrum of the dark noise from each quadrant, then added them in quadrature, then divided by QPD SUM at the end to get an uncalibrated PSD. Next I will convert these into the equivalent for pitch and yaw noise spectra. To calibrate the plots in radians per root Hz requires some specific knowledge of the oplev path, so I won't do this until I have adjusted the path.

  5429   Fri Sep 16 00:08:30 2011 PaulUpdateSUSITMY Oplev QPD dark and bright noise spectra

 I tried again at plotting the ITMY_QPD noise spectra in for dark and bright operation. Before we had the strange situation where the dark noise seemed higher, but Kiwamu noticed this was caused by dividing by the SUM before the testpoint I was looking at. This time I tried just multiplying by the measured SUM for bright and dark to normalise the spectra against each other. The results looks more reasonable now, the dark noise is lower than the bright noise for a start! However, the dark noise spectrum now doesn't look the same as the one I showed in my previous post.

  5432   Fri Sep 16 14:03:53 2011 PaulUpdateSUSSRM oplev QPD noise measurement

 I checked the dark and bright noise of the SRM oplev QPD. The SRM QPD has a rather high dark level for SUM of 478 counts. The dark noise for the SRM QPD looked a little high in the plot against the bright noise (see first attachment), so I plotted the dark noise with the ITMY QPD dark noise (see second attachment). It seems that the SRM QPD has a much higher dark noise level than the ITMY! In case anyone is wondering, to make these traces I record the data from the pitch and yaw test points, then multiply by the SUM (to correct for the fact that the test point signal has already been divided by SUM). I will check the individual quadrants of the SRM QPD to see if one in particular is very noisy. If so, we/I should probably fix it.

  5436   Fri Sep 16 16:34:54 2011 PaulUpdateSUSITMY SRM oplev telescope plan

I've calculated a suitable collimating telescope for the ITMY/SRM oplev laser, based on the specs for the soon-to-arrive 2mW laser (model 1122/P) available here: http://www.jdsu.com/ProductLiterature/hnlh1100_ds_cl_ae.pdf

Based on the fact that the 'beam size' value and 'divergence angle' value quoted don't match up, I am assuming that the beam radius value of 315um is _not_ the waist size value, but rather the beam size at the output coupler. From the divergence angle I calculated a 155um waist, (zR = 12cm). This gives the quoted beam size of about 316um at a distance of 8.5" away from the waist. This makes me think that the output coupler is curved and the waist is at the back of the laser, or at least 8.5" from the output coupler.

The collimating telescope gives a waist of size 1142um (zR=6.47m) at a distance of 1.427m away from the original laser waist, using the following lens combo:

 

L1 f=-0.15 @ 0.301m

L2 f=0.3 @ 0.409m

 

This should be fine to get a small enough spot size (1-2mm) on the QPDs.

 

  5437   Fri Sep 16 17:09:07 2011 PaulUpdateSUSITMX oplev plan

 I just drew a basic picture of how the ITMX oplev path could be reworked to minimise the number of optics in the path. Only possible problem with this might be the turning mirror onto the ITMX getting in the way of the collimating lenses. Should be easy to solve though. Does anyone know if there is a ITMX pick off beam I should be careful to avoid?

  5442   Fri Sep 16 22:11:21 2011 PaulUpdateSUSITMY transfer function

First of all I moved the lenses on the ITMY/SRM oplev path to get a smaller spot size on the QPDs. I couldn't get the beam analyzer to work though, so I don't know quite how successful this was. The software brought up the error "unable to connect to framegrabber" or something similar. I don't think the signal from the head was being read by the software. I will try to get the beam analyzer working soon so that we can characterize the other oplev lasers and get decent spot sizes on the QPDs. I searched the elog for posts about the analyzer, and found that it has been used recently, so maybe I'm just doing something wrong in using it. 

After this I measured the transfer function for the ITMY oplev yaw. I did a swept sine excitation of the ITMY in yaw with an amplitude of 500, and recorded the OSEM yaw values and the oplev yaw values. This should show a flat response, as both the QPD and the OSEMS should have flat frequency response in the measurement band. This measurement should therefore just yield a calibration from OSEM yaw to oplev yaw. If the OSEM yaw values were already calibrated for radians, we would then immediately have a calibration from oplev yaw values to radians. However, as far as I'm aware, there is not a calibration factor available from OSEM yaw values to radians. Anyway, the TF I measured did not appear to be very flat (see attached plot). Kiwamu suggested I should check the correlation between the OSEM measurements and the oplev QPD measurements - if the correlation is less than 1 the TF is not reliable. Indeed the coherence was poor for this measurement. This was probably because at frequencies above the pendulum frequency, the excitation amplitude of 500 was not enough to cause a measurable change in the optic angle. So, the plot attached is not very useful yet, but I learned something while making it.

 

  5443   Fri Sep 16 22:51:52 2011 PaulUpdateSUSCalibration plan for the oplevs

 In order to estimate the amount of noise that the oplevs are injecting into the GW channel, we first need to calibrate oplev signals in terms of angular change in the optic. I said in my previous post that there wasn't a calibration factor for OSEM values to radians, but I found that Kakeru had estimated this in 2009 - see entry 1413. However, Kakeru found that this was quite a rough estimate, and that it didn't agree with his calibrated oplev values well. He does quote the 2V/mm calibration factor for the OSEM readings though - does anyone know the provenance of this factor? I searched for OSEM calibration and found nothing.

 
Kiwamu and Suresh suggested a way to calibrate the oplevs without needing to calibrate the OSEMs in the way that Kakeru describes in entry 1413. This should give a calibration for the OSEMs _and_ the oplevs in fact. The method should be as follows:
 
1) Change the coil driver values in DC to give tip or tilt the optic. Measure the resulting change in spot position at a known distance from the optic, perhaps just using a ruler. Record the spot position and OSEM values for each coil driver value. This will definitely require a smaller spot size, so I'll implement the new telescopes first.
 
2) Knowing the length of the lever arm from the optic to the spot measurement position, we can calibrate the OSEM values to radians.
 
3) We can now put the beam onto the oplev QPD, and either change the coil driver values again in the same way (but over a smaller range), or excite the test mass in pitch or yaw, this time measuring both the OSEM values and the oplev QPD values. Since we can already convert from OSEM values to radians, we can now convert from oplev values to radians too.
 
4) I should be careful to consider the input sensing matrix for both the OSEMs and the oplevs in these measurements. Should I divide those out of the calibration to avoid that if they change the calibration factor changes too?
  5457   Mon Sep 19 12:23:30 2011 PaulUpdateSUSITMY and SRM oplev beam size reduced + next steps

I replaced the lenses that were there with a -150mm lens followed by a +250mm lens. This gave a significantly reduced beam size at the QPDs. With the beam analyzer up and running it should be possible to optimize this later this afternoon. Next I will remove the SRM QPD from the path and make measurements of the beam spot position movement and corresponding OSEM values for different DC mirror offsets. I will then repeat the process for ITMY.

  5458   Mon Sep 19 13:13:10 2011 PaulUpdateSUSITMY oplev available for use: SRM not for the moment

 I've got the bench set up for the measurement of the beam spot change with DC SRM alignment offsets. The ITMY oplev is aligned and fine to use, but the SRM one isn't until further notice (probably a couple of hours).

  5460   Mon Sep 19 15:30:22 2011 PaulUpdateSUSSRM oplev OSEM yaw calibration curve

 I made the first measurements towards oplev calibration measurements: calibrating the oplevs in SRM YAW. The measurements seemed fine, I had a range of between -1.5 and 1.5 in SRM DC alignment before clipping on mirrors on the oplev bench became a problem. This seemed to be plenty to get a decent fit for the spot position against DC alignment value - see attached plot. The fitted gradient was -420um oplev yaw count. I calculated oplev yaw values as UL+LL-UR-LR. Pitch next.

  5465   Mon Sep 19 16:56:29 2011 PaulUpdateSUSSRM oplev pitch calibration

 Same measurements for SRM pitch (as previously done for yaw in entry 5460) are complete. The QPD is back in the path and aligned. I will be doing the same measurements for ITMY now though, so please ask before activating the SRM or ITMY oplev servos, as I may be blocking the beam.

  5468   Mon Sep 19 20:56:36 2011 PaulSummarySUSRemaining 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.

 

 

  5487   Tue Sep 20 18:03:45 2011 PaulUpdateSUSITMY 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 PaulUpdateSUSITMY 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!

  5496   Wed Sep 21 09:10:15 2011 PaulUpdateSUSITMY 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 PaulUpdateSUSITMY 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. 

 

  5501   Wed Sep 21 16:31:28 2011 PaulUpdateSUSITMY 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

  5507   Wed Sep 21 23:05:16 2011 PaulUpdateSUSITMY 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

  5509   Wed Sep 21 23:44:45 2011 PaulUpdateSUSRe: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 PaulUpdateSUSITMY 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
  5514   Thu Sep 22 10:43:50 2011 PaulUpdateSUSPower 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?

  5517   Thu Sep 22 13:45:17 2011 PaulUpdateSUSETMX 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
  5532   Fri Sep 23 17:57:34 2011 PaulUpdateSUSOplev 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

 

 

 

  5540   Sat Sep 24 17:45:56 2011 PaulUpdateSUSRe: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!

 

  5554   Tue Sep 27 08:51:29 2011 PaulUpdateSUSOplev 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.

  5419   Thu Sep 15 17:00:10 2011 Paul and SteveUpdateSUSNew ITMY and SRM oplev plan

 We have made a new plan for the ITMY and SRM oplev optical path which uses as few optics as possible. This should help to reduce coupling from vibrations of optics in the oplev path back into the GW channel. To get enough room for the turning mirror into the SRM it might be necessary to move the POY optics a bit nearer to the tank. 

  1950   Wed Aug 26 16:10:28 2009 Peter KingConfigurationPSLPSL reference cavity temperature box modifications

The 40m Lab reference cavity temperature box S/N BDL3002 was modified as per DCN D010238-00-C.

These were:

    R1, R2, R5, R6 was 10k now are 25.5k metal film

    R11, R14 was 10k now are 24.9k metal film

    R10, R15 was 10k now are 127k thick film - no metal film resistors available

    R22 was 2.00k now is 2.21k

    R27 was 10k now is 33.2k

    U5, the LM-336/2.5 was removed

    An LT1021-7, 7 V voltage reference was added.  Pin 2 to +15V, pin 4 to ground, pin 6 to U6 pin 3.

    Added an 8.87k metal film resistor between U6 pin 1 and U4 pin 6.

    Added an 8.87k metal film resistor between U6 pin 1 and U4 pin 15.

    The 10k resistor between J8 pin 1 and ground was already added in a previous modification.

In addition R3, R4, R7, R8, R12 and R13 were swapped out for metal film resistors of the same value

(1.00k).

    The jumper connection to the VME setpoint was removed, as per Rana's verbal instructions.

This disables the ability to set the reference cavity vacuum chamber temperature by computer.

 DSC_0731.jpg

 

 

  9028   Mon Aug 19 10:16:15 2013 PicassoMetaphysicsTreasureoutsider art

 ranasglory.png

  227   Tue Jan 8 15:20:17 2008 PkpUpdateCamerasGigE update
[Tobin , Pinkesh]

Finally we got the camera doing something (other than giving out its attributes). The only thing that seems to work so far is a program called AAviewer, which converts the image into an ASCII format and displays it on the screen. If you want to play around with it, log into mafalda (131.215.113.23) via rana.ligo.caltech.edu. Access /cvs/cds/caltech/target/Prosilica/bin-pc/x86/ and there should be a few programs in there, one of which is AAviewer, which requires you to get an IP address (which is 131.215.113.103) for the camera right now. (You can also get the IP information via the ListCameras program). The camera is physically in the 40m near the network rack.

Other programs dont seem to be working and its probably due to the network/packetsize issues. Since linux2 can change its packetsize to a higher number, I will get it to compile on linux2 for now and then give it a shot.
  234   Thu Jan 10 13:45:52 2008 PkpUpdateCamerasGLIBC Error
So, I have tried to compile the camera files which are in /cvs/cds/caltech/target/Prosilica/examples for the past 2 days now and have been unable to get rid of the following error. (specifically ListCameras.cpp, as it doesnt have any other libraries required, which unnecessarily complicates things)

../../bin-pc/x86/libPvAPI.so: undefined reference to `__stack_chk_fail@GLIBC_2.4'
collect2: ld returned 1 exit status
make: *** [sample] Error 1

I used to get this error on mafalda too, but I had fixed it by installing the latest version of the glibc libraries. Inspite of doing so on linux2, the error still persists. I suspect it had something to do with it being a FC3 machine. My own laptop, which also runs Ubuntu works fine too. The problem with these Ubuntu machines is that they dont let me set the packet sizes to 9 kb which is required by the camera. Linux2 does.

If anyone has any idea how to resolve this issue, please let me know.

Thanks
Pinkesh.
  13862   Fri May 18 09:13:41 2018 PoojaUpdateSUSColored GigE image

To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.

 

  13868   Fri May 18 20:03:14 2018 PoojaUpdateCamerasTelescopic lens solution for GigE

Aim: To find telescopic lens solution to image test mass onto the sensor of GigE camera.

I wrote a python code to find an appropriate combination of lenses to focus the optic onto the camera keeping in mind practical constraints like distance of GigE camera from the optic ~ 1m and distance between the lenses need to be in accordance with the Thorlab lens tubes available. We have to image both the enire optic of size 3" and beam spot of 1" using this combination of lens. The image size that efficiently utilizes the entire sensor array is 1/4". Therefore the magnification required for imaging the entire optic is 1/12 and that for the beam spot is 1/4.

I checked the website of Thorlabs to get the available focal lengths of 2" lenses (instead of 1" lenses to collect sufficient power). I have tried several combination of lenses and the ones I found close enough to what is required have been listed below along with thier colorbar plots.

a) 150mm-150mm (Attachment 2 & 3)

With this combination, object distance varies like 50cm for 1" beam spot to 105cm for 3" spot. Therefore, it posses a difficulty that there is a difference of ~48cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

b) 125mm-150mm (Attachment 4 & 5)

With this combination, object distance varies like 45cm for 1" beam spot to 95cm for 3" spot. There is a difference of ~43cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

c) 125mm-125mm (Attachment 6 & 7)

The object distance varies like 45cm for 1" beam spot to 90cm for 3" spot. There is a difference of ~39cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

Sensitivity check was also done for these combination of lenses. An error of 1cm in object distance and 5mm in the distance between the lenses gives an error in magnification <2%.

The schematic of the telescopic lens system has been given in Attachment 8.

 

  12220   Tue Jun 28 16:09:41 2016 PrafulUpdateGeneral40m Summary Pages

Set up gwsumm on optimus and generated summary pages from both L1 and C1 data. Still a few manual steps need to be taken during generation, not fully automated due to some network/username issues. nds2 now working from optimus after restarting nds2 server.

  12221   Tue Jun 28 16:10:49 2016 PrafulUpdateGeneralBluebird Microphones

Found 1 out of 2 bluebird microphones in the 40m.

  12222   Tue Jun 28 17:11:27 2016 PrafulUpdateGeneralEM172 Microphones

Found 60 EM172 microphones. Previous elog with details: 7777.

  12239   Fri Jul 1 17:51:28 2016 PrafulSummaryElectronicsReplacing DIMM on Optimus

There has been an ongoing memory error in optimus with the following messages:

controls@optimus|~ >
Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705127] [Hardware Error]: Corrected error, no action required.

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705174] [Hardware Error]: CPU:24 (10:4:2) MC4_STATUS[Over|CE|MiscV|-|AddrV|CECC]: 0xdc04410032080a13

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705237] [Hardware Error]: MC4_ADDR: 0x0000001ad2bd06d0

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705264] [Hardware Error]: MC4 Error (node 6): DRAM ECC error detected on the NB.

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705323] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)

Optimus is a Sun Fire X4600 M2 Split-Plane server. Based on this message, the issue seems to be in memory controller (MC) 6, chip set row (csrow) 7, channel 0. I got this same result again after installing edac-utils and running edac-util -v, which gave me:

mc6: csrow7: mc#6csrow#7channel#0: 287 Corrected Errors 

and said that all other DIMMs were working fine with 0 errors. Each MC has 4 csrows numbered 4-7. I shut off optimus and checked inside and found that it consists of 8 CPU slots lined up horizontally, each with 4 DIMMs stacked vertically and 4 empty DIMM slots beneath. I'm thinking that each of the 8 CPU slots has its own memory controller (0-7) and that the csrow corresponds to the position in the vertical stack, with csrow 7 being the topmost DIMM in the stack. This would mean that MC 6, csrow 7 would be the 7th memory controller, topmost DIMM. The channel would then correspond to which one of the DIMMs in the pair is faulty although if the DIMM was replaced, both channels 0 and 1 would be switched out. Here are some sources that I used:

http://docs.oracle.com/cd/E19121-01/sf.x4600/819-4342-18/html/z40007f01291423.html#i1287456

https://siliconmechanics.zendesk.com/hc/en-us/articles/208891966-Identify-Bad-DIMM-from-EDAC

http://martinstumpf.com/how-to-diagnose-memory-errors-on-amd-x86_64-using-edac/

I'll find the exact part needed to replace soon.

  12244   Tue Jul 5 18:44:39 2016 PrafulUpdateComputer Scripts / ProgramsWorking 40m Summary Pages

After hardware errors prevented me from using optimus, I switched my generation of summary pages back to the clusters. A day's worth of data is still too much to process using one computer, but I have successfully made summary pages for a timescales of a couple of hours on this site: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/

 

Currently, I'm working on learning the current plot-generation code so that it can eventually be modified to include an interactive component (e.g., hovering over a point on a timeseries would display the GPS time). Also, the 40m summary pages have been down for the past 3 weeks but should be up and working soon as the clusters are now alive.

  12252   Wed Jul 6 11:02:41 2016 PrafulUpdateComputer Scripts / ProgramsVMon Tab on Summary Pages

I've added a new tab for VMon under the SUS parent tab. I'm still working out the scale and units, but let me know if you think this is a useful addition. Here's a link to my summary page that has this tab: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1151193617-1151193917/sus/vmon/


I'll have another tab with VMon BLRMS up soon.

Also, the main summary pages should be back online soon after Max fixed a bug. I'll try to add the SUS/VMon tab to the main pages as well.

  12254   Wed Jul 6 17:17:22 2016 PrafulUpdateComputer Scripts / ProgramsNew Tabs and Working Summary Pages

The main C1 summary pages are back online now thanks to Max and Duncan, with a gap in pages from June 8th to July 4th. Also, I've added my new VMon and Sensors tabs to the SUS parent tab on the main pages. These new tabs are now up and running on the July 7th summary page.

Here's a link to the main nodus pages with the new tabs: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160707/sus/vmon/

And another to my ldas page with the tabs implemented: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1150848017-1150848317/sus/vmon/

Let me know if you have any suggestions or see anything wrong with these additions, I'm still working on getting the scales to be right for all graphs.

  12275   Fri Jul 8 15:44:07 2016 PrafulUpdateElectronicsReplacing DIMM on Optimus

Optimus' memory errors are back so I found the exact DIMM model needed to replace: http://www.ebay.com/itm/Lot-of-10-Samsung-4GB-2Rx4-PC2-5300P-555-12-L0-M393T5160QZA-CE6-ECC-Memory-/201604698112?hash=item2ef0939000:g:EgEAAOSwqBJXWFZh I'm not sure what website would be the best for buying new DIMMs but this is the part we need: Samsung 4GB 2Rx4 PC2-5300P-555-12-L0 M393T5160QZA-CE6.

  12277   Fri Jul 8 19:33:16 2016 PrafulUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

A new MEDM tab has been added to the summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160708/medm/), although some of the screens are not updated when /cvs/cds/projects/statScreen/cronjob.sh is run. In /cvs/cds/projects/statScreen/log.txt, the following error is given for those files: import: unable to read X window image `0x20011f': Resource temporarily unavailable @ error/xwindow.c/XImportImage/5027. If anyone has seen this error before or knows how to fix it, please let me know.

In the meantime, I'll be working on creating an archive of MEDM screens for every hour to be displayed on the summary pages.

  12280   Fri Jul 8 21:15:03 2016 PrafulUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

Thanks! Yes, only the screens that are not updated when the script is executed show this error. I'll try to keep debugging over the weekend.

Quote:

Very nice!

Some of the screens are up-to-date, and some are not. Are the errors associated with the screens that failed to get updated?

 

  12329   Mon Jul 25 10:54:55 2016 PrafulUpdateComputer Scripts / ProgramsFinished MEDM Tab on Summary Pages

The MEDM screen capture tab is now working and up on the summary pages: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160725/medm/

Please let me know if you have any suggestions or notice any issues.

  12344   Wed Jul 27 22:42:00 2016 PrafulUpdateElectronicsEM172 Amplifier

I recreated Den's microphone amplifier circuit on a solderless breadboard to test it and make sure it does what it's supposed to. So far it seems like everything is working- I'll do some testing tomorrow to see what the amplified output is like for some test noises. Here's the circuit diagram that Den made (his elog as well https://nodus.ligo.caltech.edu:8081/40m/6651):

I'm not sure why he set up the circuit the way he did- he has pin 7 grounded and pin 4 going to +12V while in the datasheet for the opamp (http://cds.linear.com/docs/en/datasheet/1677fa.pdf), pin 7 goes to positive voltage and pin 4 goes to negative voltage. There's some other strange things about the circuit that I don't really understand, such as the motivation for using no negative voltage source, but for now I'm going to stick with Den's design and then make some modifications after I have things working and a better understanding of the problem.



Here's my current plan:

-Make sure Den's amplifier works, test it out and make changes if necessary

-Make multiple amplifier circuits on soldering breadboard

-Either make a new amplifier box or reuse Den's old box depending on how many changes I make to the original circuit

-Solder EM172s to BNC connectors, set them up around the floor suspended

-Get the amplifier box hooked up, set up some data channels for the acoustic noise

-Add new acoustic noise tab to the summary pages

 

Den also mentioned that he wanted me to measure the coupling of acoustic noise to DARM.

  12356   Fri Jul 29 19:37:43 2016 PrafulUpdateElectronicsMic Amplifier

I set up a test inverting amplifier circuit using the LT1677 opamp:

The input signal was a sine wave from the function generator with peak to peak amplitude of 20 mV and a frequency of 500 Hz and I received an output with an amplitude of about 670 mV and the same 500 Hz frequency, agreeing with the expected gain of -332k/10k = -33.2:

So now I know that the LT1677 works as expected with a negative supply voltage. My issue with Den's original circuit is that I was getting some clipping on the input to pin 2, which didn't seem to be due to any of the capacitors- I switched them all out. I set up a modified version of Den's circuit using a negative voltage input to see if I could fix this clipping issue:

I might reduce the input voltages to +5V and -5V- I couldn't get my inverting amp circuit to work with +12V and -12V. I'll start testing this new circuit next week and start setting up some amplifier boxes.

  12369   Wed Aug 3 18:53:46 2016 PrafulUpdateElectronicsMic Amplifier

I could not get Den's circuit to work for some reason with microphone input, so I decided to try to use another circuit I found online. I made some modifications to this circuit and made a schematic:

Using this circuit, I have been able to amplify microphone input and adjust my passband. Currently, this circuit has a high-pass at about 7 Hz and a low-pass at about 23 kHz. I tested the microphone using Audacity, an audio testing program. I produced various sine waves at different frequencies using this program and confirmed that my passband was working as intended. I also used a function generator to ensure that the gain fell off at the cutoff frequencies. Finally, I measured the frequency response of my amplifier circuit:

ampTest_03-08-2016_180448.pdf

A text file with the parameters of my frequency response and the raw data is attached as well.

These results are encouraging but I wanted to get some feedback on this new circuit before continuing. This circuit seems to do everything that Den's circuit did but in this case I have a better understanding of the functions of the circuit elements and it is slightly simpler.

  12374   Thu Aug 4 17:29:17 2016 PrafulUpdateGeneralGuralp Cable

The Guralp cable has been pulled and put in the corner to the left of the water cooler:

 

Ben came by today before the cable had been pulled but he said he'll be back tomorrow.

  12380   Fri Aug 5 16:25:08 2016 PrafulUpdateElectronicsMic Amplifier

I took the spectrum of an EM172 connected to my amplifier inside and outside a large box filled with foam layers:

I also made a diagram with my plan for the microphone amplifier boxes. This is a bottom view:

The dimensions I got from this box: http://www.digikey.com/product-detail/en/bud-industries/CU-4472/377-1476-ND/696705

This seemed like the size I was looking for and it has a mounting flange that could make suspending it easier. Let me know if you have any suggestions.

I'll be doing a Huddle test next week to get a better idea of the noise floor and well as starting construction of the circuits to go inside the boxes and the boxes themselves.
 

  12387   Tue Aug 9 15:50:30 2016 PrafulUpdateGeneralGuralp Cable

The Guralp cable has been reconnected and powered after having the connector changed out.
 

ELOG V3.1.3-