40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  SUS Lab eLog, Page 22 of 37  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1918   Tue Aug 10 09:51:44 2021 PacoDailyProgress1418 nm AUX ECDL1419 nm ECDL AOM diffraction at 95 MHz

[radhika, paco]

We changed the setup to use a low power amplifier rather than the 5W amp from last time. The updated schematic is in Attachment 2. This is in part because 5W is an overkill to drive a fiber AOM which is known to saturate at 0.6 mW of RF input, but also because working with lower power active elements is easier and considerably safer. We dropped the 5W amp. in Rana's office last Friday, and got a ZHL-3A-sma. This little guy gives a max power output of 29.5 dBm (~890 mW) which should be more than enough while using the Marconi as our source (max output +13 dBm).

We hooked the amplifier to the load (AOM) without any couplers or attenuators in between, powered it with +24 VDC and quickly repeated a scan of the source power level while to see any sign of diffraction in the PDs. The result is in Attachment 2. We were a little bit disappointed that there appeared to be no diffraction, so next we tried scanning the RF frequency (it was nominally at 80 MHz) around and we finally succeeded in seeing some diffraction at 95 MHz! Paco thinks the internal fiber coupling made for the design wavelength (2004 nm) is suboptimal at 80 MHz and ~1.4 um wavelength. Therefore, to couple the 1st order back into the fiber, we need to shift the RF frequency to restore the diffraction angle at the cost of potentially not driving the optimal efficiency. An interesting observation made at the same time we saw 1st order light was that the power seemed to drift very slowly (-1%/min), which may have to do with some thermal drift inside the crystal... Our plan is to make a complete characterization of the diffraction efficiency at 1.4 um, and also investigate the slow intensity drifts as a function of RF input. The goal is not so much to understand and fix this last one, but to be able to operate the setup at a point where things are stable for a low frequency, frequency noise measurement.

Attachment 1: rf_setup.jpg
rf_setup.jpg
  1919   Tue Aug 10 11:00:43 2021 PacoDailyProgressDOPODOPO v2

[paco, nina]

We started rebuilding the DOPO in the lab even though the new optical table hasn't arrived. For this reason, we are using a 1 ft x 3 ft x 0.5 in anodized aluminum breadboard which we can then attach handles to move the setup. This also makes the prototype's footprint smaller. The first thing we did as usual was settle on a beam height. The beam height used before was ~ 3in (~ 75mm), and since the EOM, Faraday Isolator, and RFPD are nominally at that height from the breadboard, the only thing we had to fix was the pump laser head. The bare height is 55 mm, so we stacked two 9 mm thorlabs bases together, bolted them down to the breadboard and then mounted the NPRO laser head on the top. Finally, using a level we secured it to the breadboard using the three points and long 1/4-20 screws while being careful as we didn't want to flex the head too much.

Next up is aligning the laser to the EOM and Faraday Isolator. For this, we will use the beam profiles measured late last year. Another task ahead is to implement the new mount for the cavity.

  1924   Thu Sep 16 15:21:21 2021 PacoDailyProgress1418 nm AUX ECDLFree space AOM

[Paco,  Radhika]

Uninstalled the fiber AOM and temporarily removed the third fiber 2x2 port beamsplitter. We are now using this free-space AOM. Then, I managed to launch one of the outputs of the second fiber beamsplitter into free space using a F220APC-1550 fixed collimator. The beam clears the  AOM aperture nicely and lands on the other side.

This AOM operates at a RF frequency of 35 MHz, so we set up a sweep on the Marconi to cover a window of 35 MHz +- 15 MHz. Using an IR detector card, we looked for evidence of 1st-order diffraction (from the setup geometry, the 1st order beam should have been visibly discernable). We first scanned the AOM across yaw but did not notice diffraction. Then, Paco lowered the height of the fixed collimator and we repeated scanning across yaw. We eventually saw the beam "jump" - diffraction! We adjusted yaw until we recovered both 0th and 1st order beams, at 50/50 intensity.

In summary, the free-space AOM works and we have managed to see 1st order diffraction. Next steps will be to quantitatively measure this diffraction while sweeping across RF frequency and power.

  1928   Tue Mar 8 09:32:56 2022 PacoDailyProgress1418 nm AUX ECDL1418nm ECDL Frequency noise

[Paco, Radhika]

Beatnote recovery

Restarted ECDL characterization last Friday. After some lab cleanup, and beatnote amplitude optimization we borrowed Moku Lab from Cryo lab to fast-track phase noise measurements. Attachment #1 shows a sketch of our delayed self-heterodyne interferometer. The Marconi 2023A feeds +7 dBm to a  ZHA-3A amplfier which shifts the frequency of the laser in one of the arms using a free space AOM. The first order is coupled back into a fiber beamsplitter to interfere with a 10 m delay line beam.

Improved beatnote detection

The 38.5 MHz beatnote was barely detectable before when using PDA20CS2 because at unity (lowest) gain stage, the bandwidth was only 11 MHz... We instead switched to an FPD310-FC-NIR type which has a more adequate high-frequency response. Attachment #2 shows the beatnote power spectrum taken with Moku Lab spectrum analyzer. The two vertical lines indicate (1) the heterodyne beatnote frequency and (2) the "free spectral range" indicating the actual delay in the MZ arms, which is calibrated to c\tau/n = 9.73 m (using 1.46 for n, the fused silica fiber index).

Phase meter and freq noise calibration

We then tried using the phase meter application on the Moku. The internal PLL automatically detected the 38.499 MHz center frequency and produced an unwrapped RF phase timeseries (e.g. shown in Attachment #3). The MZ interferometer gives an AC signal

I_{\rm AC} = I_0 \cos(\Omega_0t + \phi(t + \tau) - \phi(t))

oscillating at \Omega_0 , i.e. the angular beatnote frequency. The delay (calibrated above) characterizes the response of the MZ relating the RF phase noise spectrum to the optical phase noise spectrum. The RF phase obtained through the phase meter has a fourier transform

\tilde{\phi}_{\rm RF}(\omega) = \tilde{\phi}(\omega) e^{-i \omega \tau} - \tilde{\phi}(\omega)

So the optical phase spectral density is related to the rf phase spectral density by a transfer function H(\omega) = e^{-i \omega \tau} - 1  Then, the RF & optical phase power spectral densities are related by S_{\phi_{\rm RF}}(\omega) = |1 - e^{-i \omega \tau}|^2 S_{\phi}(\omega)  or

S_{\phi}(\omega) = \frac{S_{\phi_{\rm RF}}(\omega) }{ 4 \sin^2(\omega \tau /2) }

Then, because the instantaneous laser frequency is 2 \pi \nu = \dot{\phi},  in fourier domain \tilde{\nu} = \frac{i\omega}{2 \pi} \tilde{\phi} the frequency and phase PSDs are related by the magnitude square of this transfer function like

S_{\nu}(\omega) = f^2 S_{\phi}(\omega)

Following this prescription, we compute an estimate for the frequency noise ASD (square root of the PSD) shown in Attachment #4. The frequency noise estimated by this method has several contributions and *does not* necessarily represent the free-running ECDL frequency noise.


Next steps

  • Noise budgeting (experiment)
  • Control loop (open/closed) models
Attachment 1: schematic.png
schematic.png
Attachment 2: raw_bn_spectrum.png
raw_bn_spectrum.png
Attachment 3: phase_timeseries.png
phase_timeseries.png
Attachment 4: ecdl_freqnoise.png
ecdl_freqnoise.png
  1929   Thu Jun 23 16:34:46 2022 PacoLab InfrastructureDOPORelocated DOPO setup

Following Koji's request, I took some time to clear the area surrounding the crackle chamber so it can be migrated to the former TCS lab.

I moved the DOPO setup which was sitting on a breadboard for easy transportation (Attachment #1) and placed into the other table in the lab. Attachments #2-3 shows the cleared area. Several instruments from the DOPO experiment still remain around the other side of the crackle chamber, if they need to be relocated I can move them as well.

Attachment 1: PXL_20220623_222426584.jpg
PXL_20220623_222426584.jpg
Attachment 2: PXL_20220623_223623414.jpg
PXL_20220623_223623414.jpg
Attachment 3: PXL_20220623_224259785.jpg
PXL_20220623_224259785.jpg
  1889   Thu Jan 7 17:09:16 2021 Paco & AnchalDailyProgressOpticsMode matching OPO

Fresh attempt at mode matching. For this,

  1. Installed the oven, plugged it to the controller and went to the nominal temperature setpoint (40 C) to match the expected path length inside the NL crystal
  2. Placed the output coupler (roc = 15 mm) and roughly align so that the retroreflection is overlapped with the input beam.
  3. Set up a PD (Newfocus 2001) and scope, operating the laser at relatively low power (current ~ 840 mA), and optimize the FI rejected power.
  4. The output coupler is mounted on a three axis mirror mount (Polaris, hoping to get low drift) such that we have some knobs to tune the mode matching initially.

After a couple of iterations moving the mirror X,Y and then scanning all knobs (X,Y, and XY) to effectively translate along Z, the optimized FI rejection is ~(2.15 mW /2.95 mW) 75% of the input beam power. Looking closely at the backreflection from the output coupler, I can clearly see multiple scattered spots, which could definitely account for the defficiency. The most likely culprit is the crystal itself, which is mounted between brass and glass surfaces with no respect for anti-reflection measures. The waist is small enough that no clipping should be happening, so it looks like the NL crystal placement may have to be revisited. Other than that, this procedure should be fine.

  508   Wed May 2 14:01:46 2012 QDailyProgressCoating QRingdown Measurements and Fits

Nice work James!

Screen_Shot_2012-05-02_at_2.00.33_PM.png

Quote:

[Eric, Giordon]

 We were able to get more beats of the ringdown by moving the drive frequency away from the resonance - I don't understand totally why this makes it work... but it does. And the ringdowns are real.

 

 

  1917   Wed Aug 4 11:36:30 2021 RadhikaDailyProgress1418 nm AUX ECDL1419 nm ECDL with 2um AOM tests

[Radhika, Paco]

In order to transition the ECDL laser noise characterization to a heterodyne setup, we needed to test the AOM (acousto-optic modulator). We wanted to drive the AOM at 80MHz using the Marconi signal generator. Since the AOM has a max driving power of 600 mW, we determined that if we run the Marconi at max output power (13dBm), we saturate the AOM through a variable attenuator and a 5W amplifier. The detailed setup is in Attachment 1.

As we scanned the AOM RF input power, we monitored the mean of the 0th and 1st order power outputs using 2 amplified photodiodes on the scope. Attachment 2 plots the results of the scan; although we noticed the 0th order dropping, we did not see evidence of diffraction in the 1st order. Our suspected theory is that the lost power from the 0th order is due to thermally-driven attenuation inside the AOM (we do not know what is inside the AOM, so this is purely speculative). The next thing we want to try is to add a DC power level to the AOM RF input, but we will double check with Aidan.

Attachment 1: rf_setup.jpg
rf_setup.jpg
Attachment 2: diffraction_levels.png
diffraction_levels.png
  1920   Thu Aug 12 11:49:59 2021 RadhikaDailyProgress1418 nm AUX ECDL1419 nm ECDL AOM diffraction at 95 MHz

[Paco, Radhika]

When previously trying to characterize the AOM, we had noticed no 1st order diffraction when operating at 80 MHz, but significant diffraction at 95 MHz. This motivated us to take measurements while sweeping across both RF drive frequency and Marconi drive power. For frequency, we swept from 80-120 MHz in steps of 1 MHz. For power, we swept across [3, 0, -3] dBm (3 dBm is max power before saturating AOM). We took our measurements of 0th and 1st order signal using an oscilloscope.

Contour plots of the 0th and 1st order signals can be seen in Attachments 1 and 2, respectively. Peak 1st order diffraction seems to occur at ~106 MHz. Using this AOM for a beat note measurement, the frequency difference would be greater than intended, which could lead to a weaker beat note signal. 

*Bonus: Today we moved the ECDL setup off the cryostat table and onto the other table. These measurements were taken after the move. 

Attachment 1: zeroth_order_contour.pdf
zeroth_order_contour.pdf
Attachment 2: first_order_contour.pdf
first_order_contour.pdf
  1922   Wed Sep 1 13:12:02 2021 RadhikaDailyProgress1418 nm AUX ECDL1419 nm ECDL AOM diffraction at 95 MHz

[Paco, Radhika]

Today we tried to pick up from [1920] by repeating the sweep measurements across RF frequency, at 3 dBm (max power). We noticed that the 0th order signal would dip around the expected value, consistent with the plot in [1920]. However, there was no signal from the 1st order. Clearly diffraction was occurring as seen by the dip in 0th order, but nothing was coming out of the 1st order port. We spent some time debugging by swapping the photodetector inputs / playing with the PD gains / performing power cycles, but got no insight into the issue. 

We suspected the 1st order fiber coming out of the AOM might be damaged, since it loops around fairly tightly. After giving it more slack, we still saw no signal. We wanted to test the fiber, so we took an unused output of the 50-50 beamsplitter and fed it into the 1st order port, effectively running the AOM in reverse. We hooked up the input and 0th order ports to the photodiodes and did not observe any signal. From here we were more convinced that the 1st order fiber may have seen some damage. 

For next steps, we can still use the existing fiber setup to take measurements of relative intensity noise (RIN), using the 0th order output of the AOM. I plan to do this in the next few days. Meanwhile, Paco is looking into ordering parts for a free space setup. We found a free-space AOM at 1064nm that seems promising, and we will work to transition the setup accordingly. 

  1923   Thu Sep 2 17:31:38 2021 RadhikaDailyProgress1418 nm AUX ECDL1418 nm ECDL Relative Intensity Noise

I took a relative intensity noise (RIN) measurement of the ECDL, by feeding the 0th order output of the AOM to the SR785. The RF power driving the AOM was set to 0 dBm. The RIN at 1 Hz is about 3x10-5, which is consistent with informal measurements we took on 08/13. From my understanding this noise looks pretty low, which is good. I will consult with Paco and add more discussion or conclusions, if any.

Attachment 1: ECDL_RIN_02-09-2021_165151_alone.pdf
ECDL_RIN_02-09-2021_165151_alone.pdf
  1925   Wed Sep 22 16:44:34 2021 RadhikaDailyProgress1418 nm AUX ECDLFree space AOM

[Paco, Radhika]

We had previously noticed that the ECDL laser power seemed weaker compared to when we originally set it up and tested it. Today Paco opened it up and tweaked the grating inside to obtain a max power of 3 mW. This way, we could better resolve the 0th and 1st order beams coming out of the AOM.

Since we don't yet have a lens to send the collimated 1st-order beam to fiber, we connected a power meter to detect the beam and hooked it up to the oscilloscope. We noted peak diffraction at around 38.5 MHz (rough estimate). Using the inverse relationship between laser wavelength and the RF frequency f \lambda = constant, and the fact that the AOM is designed to operate at 1550 nm at 35 MHz, we calculated that the ECDL wavelength should be ~1409 nm. Of course this is a rough estimation, but it is a quick validation that we are indeed operating near 1418 nm. 

  1926   Mon Oct 4 17:44:34 2021 RadhikaDailyProgress1418 nm AUX ECDLFree space AOM

[Paco, Radhika]

Last Friday we received a new lens to direct the AOM 1st-order beam from free space into a fiber cable. We mounted the lens and connected a fiber cable into the photodiode, and tried to align the lens and see a jump in the oscilloscope. We were not able to do so and wrapped up for the day.

Today we continued aligning the lens with the fine adjustment on the mount, and eventually saw signal on the scope! Hooray, done with free space. We then prepared for eventually taking a heterodyne beat note measurement and hooked up the appropriate inputs/outputs to the beamsplitters. We added in the 50-50 beamsplitter that takes in the 1st order diffracted beam along with the beam from the delay line as inputs. We passed one of the outputs to the photodiode and had to retweak the freespace-to-fiber lens until we recovered signal on the scope, and we saw the beatnote signal.

Next, while Paco is out of town I will continue to work towards making a frequency noise measurement. We made a roadmap today:

I will demodulate the beat note using a mixer and a 35 MHz LO sourced from the Marconi. The result will be a 2f cosine term, along with a much lower frequency term which encloses the frequency noise information. This will be passed through a low-pass filter to get rid of the first high-frequency term. The remaining time-domain signal will be passed to the SR785 to obtain a spectra of the frequency noise. Calibration will need to be performed to obtain the right units for the spectra, Hz2/Hz (or Hz/rtHz). 

  1927   Tue Oct 19 13:52:03 2021 RadhikaDailyProgress1418 nm AUX ECDL1418nm ECDL Frequency noise

Attachment 1 is a diagram of the current setup for measuring ECDL frequency noise. Since the last update, I have fed the beat note signal to a mixer, using a 35 MHz LO sourced from the Marconi. The resulting demodulated signal is passed to a low-pass filter, removing the 2f sinusoidal term (any trace of the frequency difference) and leaving behind a low-frequency term containing frequency noise information of the original beam (accumulated over the length of delay line).

I took spectra of the resulting signal using the SR785 (Attachment 2). Note that these units are still in V/rtHz, since the signal has not been calibrated to the appropriate units for frequency noise, Hz/rtHz. Finding the calibration term will involve study of delay line frequency discrimination. 

Attachment 1: ECDL_diagram.pdf
ECDL_diagram.pdf
Attachment 2: ECDL_FNM_13-10-2021_151524.pdf
ECDL_FNM_13-10-2021_151524.pdf
  449   Tue Apr 10 21:16:29 2012 RanaSummaryCoating QDisk was stuck: started new sweep

 

 The sweeps looked strange to me, as if there was something broken. Zach assured me that the solder/paste is sound. He tested the voltage continuity of the ESD just before pumping down.

I used the HV knob to change the ESD's DC voltage from -2 kV to +2 kV to look for arcing, etc. There is indeed some arcing (the next version should have less pointy edges).

However, the big discovery for me is that any voltage beyond +/- 500 V is enough to stick the optic to the ESD by the electrostatic force. All of our runs for the past few days have been at +1-2 kVdc, so the optic was stuck the whole time.

 

I have now set the DC voltage to +200 V and confirmed by eye that the optic is swinging (its obvious with a flashlight): the red laser beam swings around in the chamber with a several second period.

I have set up a sweep with a 0.1 Vpp with a 200 Hz span around 5030 Hz and with a 5 sec settling time and a 55 s integration time per point. Also the 'auto resolution' feature of the sweep is on. Let's see what happens.

 

Next time around, we should set up active damping or make the yaw frequency higher by a factor of 5-10.

  571   Wed Sep 12 17:15:21 2012 RanaDailyProgressCryo SUSSilicon Suspension talk from Alan Cumming

 https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?docid=96085

Useful data on Silicon strength tests...

  1574   Fri Jul 15 01:46:32 2016 RiccardoDailyProgressCrackleRescaling the Code to 1.0 Yielding Point

Since I have found a the bug in the code (threshold value probability distribution was not centered in 1.0 and was not Gaussian, as we thought, but flat),I am trying to rescale down the code to 1.0 yieldin point.

First tests failed. I attached the resoults: Fig.1 - Flat Distribution - Mean V. 1.0 - Range [0.75,1.25] - Cconst = 400 / 1.25. The micro - plasticity regime starting point remained unchanged. Furthermore, the avarage modulus amplidude, for all frequencies, is too high and data shape is not good.

In subsequent trial the starting point seem to be not sensite to variation of the width of the distribution and its shape. I attached a figure where are compared different distribution, centered in 1.0, with different width. Fig.2

Tomorrow I am going to check the physical units of the elastic coupling coefficent in the objective of defining better a range of analysis for my rescaling work.

 
Attachment 1: Fig.1.png
Fig.1.png
Attachment 2: Fig.2.png
Fig.2.png
  1577   Sun Jul 17 23:59:13 2016 RiccardoDailyProgressCrackleMicro Plasticity Starting Point Shifted in 0.75

I have changed the definition for the threshold probability distribution in the code. It is a flat ditribution centered in 1.0 (the nominal yielding point) with range of values included between [0.875,1.125]. I didn't use the python default flat distribution from numpy library, numpy.random.uniform()),  but numpy.random.random().

The Yielding point is now in 0.75. Data Shape for amplitude seems to be good. For what concerns the Phases i need some more trial.

I attached an image about my resoults.  

Attachment 1: Amplitude-Phase.png
Amplitude-Phase.png
  977   Thu May 21 18:48:12 2015 SaikanthSummaryCrackleSensing breadboard motion | Analytical model - Transformation relations

I have tried to build an analytical model to translate the shadow sensor readings to motion of the breadboard in 6 d.o.f. I started off with the basic relation that is true for a rigid body - the velocity at any point P on a rigid body is given by: v_p = v_{cm} + w$x$r , where v_p is the velocity at P, v_{cm} is the velocity of the centre of mass in the absolute frame, w is the angular velocity of rotation and r is the position vector of the point P.

In an infinitesimal time interval, the above relation is equivalent to: s_p = s_{cm} + d\theta$x$r, where s_p is now infinitesimal displacement vector of the point P, and s_{cm} is the infinitesimal displacement vector of the center of mass of the suspended breadboard. This can be written in the matrix form as:

\begin{pmatrix} s_{p,x}\\ s_{p,y}\\ s_{p,z}\\ \end{pmatrix} = \begin{pmatrix} 1 & 0 & 0 & 0 & -r_z & r_y\\ 0 & 1 & 0 & r_z & 0 & -r_x\\ 0 & 0 & 1 & -r_y & r_x & 0\\ \end{pmatrix} \begin{pmatrix} s_{cm,x}\\ s_{cm,y}\\ s_{cm,z}\\ d\theta_x\\ d\theta_y\\ d\theta_z\\ \end{pmatrix}

where s_{p,x} corresponds to displacement of the point in the x direction.

 

In the case of interest here, each of the 6 sensors has one such matrix equation (that is 3 linear equations). However, since OSEMs can measure movement only along the direction of axis, by construction, the matrix equation for each then boils down to one linear equation corresponding to the direction of orientation of the OSEM axis.

Consider the OSEM scheme shown in attachement 1. (Axis convention: shown in the fig.) For the sensor A, for instance, the equation corresponding to s_{p,x}  would be the only relevant one, because its axis is along the x-axis. Hence, the linear equation corresponding to s_{a,x} can be written down from the above matrix equation by plugging in the values for r_{a,z} and r_{a,y}. The same can be carried out for the rest of the sensors before plugging in the necessary values, and one can arrive at the final transformation equation:

\begin{pmatrix} s_a\\ s_b\\ s_c\\ s_d\\ s_e\\ s_f\\ \end{pmatrix} = \begin{pmatrix} 1 & 0 & 0 & 0 & 162.5 & 0\\ 0 & -1 & 0 & 162.5 & 0 & -176\\ 0 & -1 & 0 & 162.5 & 0 & 176\\ 0 & 0 & 1 & -25 & 116 & 0\\ 0 & 0 & 1 & -25 & -116 & 0\\ 0 & -1 & 0 & -172 & 0 & -176\\ \end{pmatrix} \begin{pmatrix} s_{cm,x}\\ s_{cm,y}\\ s_{cm,z}\\ d\theta_x\\ d\theta_y\\ d\theta_z\\ \end{pmatrix}

Note:

  • Sign convention for sensor data: Magnet moving out is positive.
  • All distaces are in mm, angles in radians.
  • Even though we said that the OSEM can measure displacement only along its axis, notice the coupling in the linear equation for s_d: rotation about both x and y axes give non-zero readings. However, this is acceptable because the element due to coupling (the one with the value -25) has a lesser value compared to the other.

The next thing to do, then, would be to learn to interface with the setup and acquire data from the sensors, after which the transformation can be implemented and motion in 6 d.o.f can be analyzed.

Attachment 1: osem_scheme.png
osem_scheme.png
  978   Mon May 25 12:15:53 2015 SaikanthSummaryCrackleSensing breadboard motion | Analytical model - Transformation relations | Corrections, final matrix

Writing this update to close the topic of constructing transformation relations. The last time, I had made some assumptions that I later, upon discussion, realized are not reasonable. This update summarizes the changes and gives the final transformation relation.

 

Finding the CM of the suspended setup:

I have considered the following while calculating the CM of the system. The axis convention is shown in Attachment 1. I have skipped the y-coordinate, since we know from the position of the suspension wires that the absolute y-coordinate of CM is -27. All coordinates in mm.

Item Mass Absolute coordinates (in the xz plane) Comments
Optical posts and components 12 x 0.4 = 4.8kg (217.83, 177.75)

0.2kg is the weight of each post, according to what I found on Thorlabs website for 1" length posts. I have added 0.2kg to all posts to account for the components: photo detector, lens mount, beam splitter etc.

Look at Attachment 1 for the positions of these posts/components. The coordinates indicated in the previous column correspond to the CM of the system of posts and components.

Suspended block#1 2.2kg (356, 210)  
Suspended block#2 2.2kg (44, 210)  
Fixed block 1.45kg (200, 400) This is the block to which the steel blades are clamped.
Breadboard 5.9kg (200, 225) I didn't find the exact model on the Thorlabs website, so I picked up the weight of the model which had same dimensions.
Reinforcement#1 1.97kg (380, 225) Mass calculated from material and dimensions.
Reinforcement#2 1.97kg (20, 225) Mass calculated from material and dimensions.

The center of mass, then, comes out to be: 20.49kg at (204.18, 223.09) (in the x-z system). Complete absolute coordinates are: (204.18, -27, 223.09).

This table enlists the coordinates for the suspension sensors in both absolute and CM frame. 'X' means that we don't care about that particular coordinate since it is along the axis of the sensor.

Sensor Absolute coordinate Coordinate in CM frame
A (X, 0, 62.5) (X, 27, -160.6)
B (24, X, 62.5) (-180.18, X, -160.6)
C (376, X, 59.5) (171.82, X, -163.6)
D (316, 25.7, X) (111.82, 52.7, X)
E (84, 25.7, X) (-120.18, 52.7, X)
F (24, X, 397) (-180.18, X, 173.91)

 

The transformation matrix, then, becomes:

\begin{pmatrix} s_a\\ s_b\\ s_c\\ s_d\\ s_e\\ s_f\\ \end{pmatrix} = \begin{pmatrix} 1 & 0 & 0 & 0 & 160.6 & 27\\ 0 & -1 & 0 & 160.6 & 0 & -180.18\\ 0 & -1 & 0 & 163.6 & 0 & 171.82\\ 0 & 0 & 1 & -52.7 & 111.82 & 0\\ 0 & 0 & 1 & -52.7 & -120.18 & 0\\ 0 & -1 & 0 & -173.91 & 0 & -180.18\\ \end{pmatrix} \begin{pmatrix} s_{cm,x}\\ s_{cm,y}\\ s_{cm,z}\\ d\theta_x\\ d\theta_y\\ d\theta_z\\ \end{pmatrix}

The inverse of this matrix is as follows:

\begin{pmatrix} 1 & 0.0774 & -0.0767 & -0.6922 & 0.6922 & -6.88e-04\\ 0 & -0.0034 & -0.5119 & 0 & 0 & -0.4847\\ 0 & 0.1575 & 0 & 0.5180 & 0.4820 & -0.1575\\ 0 & 2.989e-06 & 0 & 0 & 0 & -2.989e-06\\ 0 & 0 & 0 & 4.31e-06 & -4.31e-06 & 0\\ 0 & -2.87e-06 & 2.84e-06 & 0 & 0 & 2.5478e-08 \end{pmatrix}

Attachment 1: osem_scheme.png
osem_scheme.png
  979   Mon May 25 15:30:46 2015 SaikanthDailyProgressCrackleSensing breadboard motion | Reconstructing in 6D

This afternoon, I used the sensor data Xiaoyue provided. I made use of the transformation matrix I came up with earlier to reconstruct motion in 6 d.o.f. The approach I used was the following.

Approach:

  • Loaded data from struct files, converted to a double array.
  • Not all sensor data was centered around the origin, so I found out the mean and subtracted from each sensor data array. This is because we are looking at infinitesimal displacements around the equilibrium point.
  • I made use of the inverted transformation matrix to obtain motion (about the equilibrium point) in 6 d.o.f of the breadboard.
  • The data array from the initial struct file gave distance in micron. Multiplied by 0.001 to convert into mm, which is what I used while constructing the matrix.
  • Plotted.

See Attachment 1 for the plots I obtained for the given data. Following are some subtleties we need to look at once again:

  1. The units on the y-axis of the translational motion plots are mm. The motion seems to be of the order of 0.1 - 1 micron then, along all 3 axes.
  2. The net displacement (when I calculated the sum of all infinitesimal displacements) comes out to be incredibly small: of the order of 10^-11mm! This might be because I subtracted from the data its mean, in the beginning, since I said I want to observe only the fluctuations.

Edit (19 June'15): The attachment below is only for representational purposes. As we recently figured out, magnets might have been touching the sensors. The data hence better not be used for any analysis.

Attachment 1: transform_1_1.jpg
transform_1_1.jpg
  980   Mon Jun 1 18:19:30 2015 SaikanthSummaryCrackleSensing motion of breadboard | Spectra of motion in physical d.o.f

The last update shows the motion of the breadboard in physical degrees of freedom. (This was when the linear damping was on, though.) One of the interesting things that one can observe from the transformed sensor data that has been collected is the modes of the system; and one can do so by doing a spectral analysis.

I have arrived at the spectral density of the physical d.o.f motion data by using the pwelch function. (In this case, the linear damping was turned off in order to better observe the modes.) The following are some quick summary points about the same.

  • [Pxx,f] = pwelch(data, hamming(nfft), nfft/2, nfft, fs) gives the power spectral density Pxx and the corresponding frequency array f.
  • In the above, nfft was chosen to be 1/6th of the total number of data points.
  • fs is the sampling frequency, known to be 2048Hz.
  • Pxx represents the power spectral desnsity, and I have used the square-root of that quantity in my plots.

I have attached spectral plots corresponding to motion along all six degrees of freedom. The last plot is that of absolute motion along all d.o.f. A couple of quick inferences that can be drawn are:

  1. The breadboard is suspended and the OSEMs are fixed relative to the ground. Most of what is seen in the spectrum is due to motion of the ground, and this seems to be concentrated in the <10Hz region. This would form the region of interest for us: the aim would be to damp motion at the resonant frequencies of the suspension.
  2. All the plots show a peak at a common frequency, just below 1Hz - one of the modes of the system. A few more peaks (modes), too, can be seen for a few frequencies between 1Hz through 10Hz.

This sets a target for the rest of the work relating to suspension damping. We will come back and plot the same kind of data gain - this time with damping turned on - to see the difference.

 

PS: These plots correspond to data from 1 June'15 1:00AM - 1:30AM.

Edit (19 June'15): The attachment below is only for representational purposes. As we recently figured out, magnets might have been touching the sensors. The data hence better not be used for any analysis.

Attachment 1: spectrum_x.jpg
spectrum_x.jpg
Attachment 2: spectrum_y.jpg
spectrum_y.jpg
Attachment 3: spectrum_z.jpg
spectrum_z.jpg
Attachment 4: spectrum_roll.jpg
spectrum_roll.jpg
Attachment 5: spectrum_pitch.jpg
spectrum_pitch.jpg
Attachment 6: spectrum_yaw.jpg
spectrum_yaw.jpg
Attachment 7: motion.jpg
motion.jpg
  984   Mon Jun 8 15:40:08 2015 SaikanthSummaryCrackleCharacterization of mechanical response of breadboard suspension

This elog summary is about my work on characterization of mechanical response of the suspended breadboard system.

In order to effectively damp breadboard motion at resonance frequencies, it is necessary to have an idea of how the system responds to forces at different frequencies applied at various points on the rigid body. The way to do this is to construct the frequency response functions (transfer functions).

As we know, the Optical Shadow Sensor ElectroMagnetic Actuator (OSEM) has two parts:

  1. Shadow sensor: can sense displacement, and
  2. Electromagnetic actuator: can induce displacement.

Clearly, we have means to not only measure displacement and at specific points on the rigid body and reconstruct 6D motion in physical d.o.f., we also have means to drive the system by applying force using OSEMs at these positions. (OSEM scheme shown in attachment 1).

Also, the part of the breadboard whose displacement is to be measured must be made up a magnetic material if it has to be driven by the EM force, obviously.

 

Transfer function measurement, then, becomes a matter of exciting coils, measuring sensor displacements and transforming to the absolute (ground) coordinates. This is conveniently done by the LIGO Diagnostic Test Tools (DTT). Before I talk about results, here are some important points to be kept in mind about the excitation configuration on LIGO DTT.

  • Sweep-sine excitation; frequency range used was 0.5Hz - 15Hz.
  • As can be seen in the transfer function bode plots in the attachments, the coherence was not the best (>0.9) at all frequencies. While plotting the transfer functions, I have made use of only those values that are above a certain threshold (0.7). This is to ensure that there are only reliable readings and no spurious ones.
  • Since whitening and dewhitening filters are on, the number of output counts to the coil being excited varies with frequency of excitation. The force, however, remains the same at all frequencies, thanks to the compensating analog filter. In order to achieve better coherence, the amplitude can thus be increased at lower freuencies -- while not exceeding the maximum limit on the number of output counts. This is summarized in the table below and shown in attachment 14.
Frequency (Hz) Amplitude (uN) No. of counts
15 400 10000
10 600 10000
5 1200 10000
2 2800 10000
1 4700 10000
0.5 6300 10000

Transfer function measurements:

I have initially measured transfer functions for coil excitation to sensor displacement. These were later on transformed to coil excitation to physical d.o.f. transfer functions using the same transformation that displacement signals are related by. Attachments 2 through 12 show transfer functions of translation or rotation in coil excitation to physical d.o.f. -- A to F, in that order. Notice that there are hardly any points for frequencies above 6 Hz. This is simply because of low coherence. The threshold set here was 0.7.

Here too, one can see common peaks at a particular frequency below 1Hz -- one of the resontant frequencies.

What's next?

I have successfully characterized the mechanical response and measured 6x6 tranfer functions. In order to make use of these for control, one must input these transfer functions to the control system in terms of poles and zeros. I have used the MATLAB function vectfit3 to fit a vector of 6 transfer functions with common poles. This can be extended to all 36 transfer functions as well. However, whether we want to fit all of them with the same set of poles or not, or whether we want to fit 6 groups of 6 transfer functions each individually, is something that will become more clear after modeling the system analytically and staring at the transfer function simulations. My next step, hence, would be to work on the analytical model.

Attachment 1: osem_scheme.png
osem_scheme.png
Attachment 2: Translations_A-exc.pdf
Translations_A-exc.pdf
Attachment 3: Rotations_A-exc.pdf
Rotations_A-exc.pdf
Attachment 4: Translations_B-exc.pdf
Translations_B-exc.pdf
Attachment 5: Rotations_B-exc.pdf
Rotations_B-exc.pdf
Attachment 6: Translations_C-exc.pdf
Translations_C-exc.pdf
Attachment 7: Rotations_C-exc.pdf
Rotations_C-exc.pdf
Attachment 8: Translations_D-exc.pdf
Translations_D-exc.pdf
Attachment 9: Rotations_D-exc.pdf
Rotations_D-exc.pdf
Attachment 10: Translations_E-exc.pdf
Translations_E-exc.pdf
Attachment 11: Rotations_E-exc.pdf
Rotations_E-exc.pdf
Attachment 12: Translations_F-exc.pdf
Translations_F-exc.pdf
Attachment 13: Rotations_F-exc.pdf
Rotations_F-exc.pdf
Attachment 14: excitation_profile.pdf
excitation_profile.pdf
  985   Tue Jun 9 18:01:52 2015 SaikanthDailyProgressCrackleFitting multiple transfer functions with common set of poles

Now that we have transfer functions to for all possible combinations of coil-sensor, one of the things we might want to do is to fit all of them with a common set of poles. Or, fit some of them with a common set of poles.

vectfit3:

I have used the vectfit3 function of MATLAB to try and vector fit multiple transfer functions with a common set of poles. The function works for both - a vector of transfer functions or a single transfer function.

However, in current case of interest, it is not straightforward. The problem is subtle, and is as follows: For the function to work, data for each transfer function in the transfer function array must have the same length. Here, I have measured 36 transfer functions as groups of 6 each, 1 group for each coil excitation. Each of these groups have a set of finite points for which the coherence of all the 6 measurements in the group is above a set threshold (say 0.7), and the points of which all coherences are above the threshold are different for each group. Put in simple terms, the frequency axes were different for each group. Clearly, simply inputing this to the vectfit3 function won't work.

How I solved this was to identify points on the frequency axis, for each group, where all coherences were above the set threshold; and then find the intersection of such collected points for all groups. This set the common frequency axis for the measurements. I extracted transfer function values corresponding to these and then made use of the vectfit3 function.

 

Wrapper function - fitmulti_zpk:

Given a transfer function vector and (common) frequency axis, the vectfit3 function does not output in zpk format. The fit_zpk wrapper that's already existing in the LIGOShare folder doesn't work for a vector of transfer functions. So, I have written code for a wrapper that will take a vector of transfer functions and output an array of zpk's. It can be found here. (Users are advised to go through the comments in the beginning to see details of the input format.)

Some results:

I have tried this out on some data - for 12 transfer functions, for coil A and coil B excitation. Attached images 1 and 2 show the fit results. (This is only for representational purpose. Notice that I have also not given any legend for the transfer functions or tried to show what I am plotting. The point is just to show that vector fitting is working for multiple transfer functions.)

Attachment 1: multi_1_mag.jpg
multi_1_mag.jpg
Attachment 2: multi_1_phase.jpg
multi_1_phase.jpg
  990   Fri Jun 12 12:38:48 2015 SaikanthDailyProgressCrackleComparison of motion spectra - with longer legs vs with shorter and floating legs

After having floated the new table legs, re-centered all sensors and reinstalled the mechanical part of the setup completely, it is now possible to collect sensor data again. It would be interesting to see how the change in table legs affected the motion of the breadboard.

I have extracted data from last night (12 June'15 1:00AM-1:30AM) using ligoDV. These timings were selected to coincide with those corresponding to the data we had collected and analyzed earlier (on 1 June'15). I've used the same method as earlier for computing spectra, and I've plotted spectra of data from both the dates to observe the difference. Refer to attachments.

 

Some inferences from the plots:

  1. One common feature in all plots is the reduction in noise in the >10Hz region. This holds till about 100Hz; the acoustic noise in this region has hence been mitigated.
  2. Of particular interest is Z-translation. Though the resonance peaks seem to have shifted to the left (notice the <1Hz region), I see some new peaks in the 1-10Hz region.
  3. In case of some others, the first peak seemed to have shifted to the right... Though there are no new peaks, the amplitude is now higher.

One important difference to be kept in mind is that for the 1 June'15 data, block damping was ON, and for the 12 June'15 data, it was OFF. This could be the reason for what has been observed. An examination of the data with block damping ON will give us a better idea.

 

Edit (19 June'15): As we recently figured out, magnets might have been touching the sensors. That was the reason.

Attachment 1: comparison_x.jpg
comparison_x.jpg
Attachment 2: comparison_y.jpg
comparison_y.jpg
Attachment 3: comparison_z.jpg
comparison_z.jpg
Attachment 4: comparison_pitch.jpg
comparison_pitch.jpg
Attachment 5: comparison_roll.jpg
comparison_roll.jpg
Attachment 6: comparison_yaw.jpg
comparison_yaw.jpg
  1000   Thu Jun 18 10:16:12 2015 SaikanthHowToCrackleAlignment of the suspension system in the new shorter-leg setup

After moving to the shorter legs, we had to go through a lot of iterations to get the setup to working stage; As far as the suspension system goes, there were problems with the alignment: positioning and centering of the suspension and block OSEM. We kept knocking off magnets once in a while, and some times the intermediate mass stage itself was not leveled. The following steps, in the same order, were and should be followed in future for hassle-free alignment and recentering.

  1. First, move all OSEMs off the mounts so that there's no knocking off while the breadboard moves. That is, no magnet should be inside of the OSEM.
  2. Start with filling pressure in all the table legs to 6bar. Note that this only keeps the table parallel to the floor, but NOT perpendicular to gravity. But we will work with this.
  3. Obviously, the intermediate mass stage is NOT going to be leveled (i.e. perpendicular to gravity). This can be easily verified using a spirit (bubble) level. The task then is to adjust the tilts of the suspension blades such that the bubble is centered in two mutually perpendicular directions. This ensures that the whole of the setup is nearly perpendicular to gravity even though the table is not.
  4. One can now move on to recentering all OSEMs. In the latest round of recentering, we had knocked off magnets while trying to recenter. The process would become simple if one did the following:
    • Align and recenter suspension OSEM first, with the blocks free. It is easier to move the OSEM mount itself than to remove and reposition the magnet!
    • In case of any magnet falling off, use superfast glue - one that dries up quickly. Also, wherever possible, a smart method described here can be put to use to recenter it perfectly.
    • While aligning the block OSEMs, extra care must be taken not to shake the breadboard too much because that would knock off the suspension magnets. 
    • As usual, all shadow sensor output counts must be around 8000.
  1003   Thu Jun 18 13:40:16 2015 SaikanthSummaryCrackleForce and torque transformation equations - Driving Matrix

Earlier, I had constructed the transformation matrix that gave motion in physical d.o.f from the OSEM signals. That matrix was the 'Sensing Matrix'. Just like sensing, driving is possible only through the 6 OSEM. It is through these driving forces that any force of a certain desired magnitude and direction can be achieved. Since we want to build the suspension damping control system based on the physical d.o.f motion, it is essential to have a way to translate OSEM driving forces to forces along physical d.o.f. This is simple - write down Newton's 2nd law along all 'directions'.

The above image shows the scheme of OSEM, and direction of their driving force. This convention has been chosen such that for positive force, the magnet moves OUT of the OSEM. The current wiring (as of 18-06-2015) is NOT in the right sense, and this has to be corrected.

One can write down the following equations easily:

F_x = F_A

F_y = -F_B-F_C-F_F

F_z = F_D+F_E

One must be a little more careful while writing down the torque relations. The net torque can be written as:

\tau_{net} = \sum_{i=A}^{F} \vec{r_i} \times \vec{F_i}

where the \vec{r_i} and \vec{F_i} are position and force vectors of OSEM 'i'.

This can be expanded to:

\small \tau_{net} = \vec{r_A} \times (F_A\hat{e_x}) + \vec{r_B} \times(F_B(-\hat{e_y}))+ \vec{r_C} \times(F_C(-\hat{e_y}))+ \vec{r_D} \times(F_D\hat{e_z})+ \vec{r_E} \times(F_E\hat{e_z}) + \vec{r_F} \times(F_F(-\hat{e_y}))

\small F_i corresponds to the force by each OSEM, the negative sign in some of the terms is because of the orientation of the sensors. (For example, positive force -- which we defined as when the magnet moves out -- along B would mean a displacement in negative y direction.)

The x, y, z components can be separated, and a matrix transformation equation can be written from all the above equations as below.

\small \begin{pmatrix} F_x\\ F_y\\ F_z\\ \tau_x\\ \tau_y\\ \tau_z\\ \end{pmatrix} = \begin{pmatrix} 1 & 0 & 0 & 0 & 0 & 0\\ 0 & -1 & -1 & 0 & 0 & -1\\ 0 & 0 & 0 & 1 & 1 & 0\\ 0 & z_{cm,B} & z_{cm,C} & y_{cm,D} & y_{cm,E} & z_{cm,F}\\ z_{cm,A} & 0 & 0 & -x_{cm,D} & -x_{cm,E} & 0\\ -y_{cm,A} & -x_{cm,B} & -x_{cm,C} & 0 & 0 & -x_{cm,F} \end{pmatrix} \begin{pmatrix} F_A\\ F_B\\ F_C\\ F_D\\ F_E\\ F_F\\ \end{pmatrix}

Note\small x_{cm,A}, for instance, is the x-coordinate of OSEM A in the CM frame.

On substituting the necessary values of the coordinates (which can be found here), the final driving matrix equation can be written as:

\small \begin{pmatrix} F_x\\ F_y\\ F_z\\ \tau_x\\ \tau_y\\ \tau_z\\ \end{pmatrix} = \begin{pmatrix} 1 & 0 & 0 & 0 & 0 & 0\\ 0 & -1 & -1 & 0 & 0 & -1\\ 0 & 0 & 0 & 1 & 1 & 0\\ 0 & -160600 & -163600 & 52700 & 52700 & 173910\\ -160600 & 0 & 0 & -111820 & 120180 & 0\\ -27000 & 180180 & -171820 & 0 & 0 & 180180\\ \end{pmatrix} \begin{pmatrix} F_A\\ F_B\\ F_C\\ F_D\\ F_E\\ F_F\\ \end{pmatrix}

On converting length units to meter and taking the inverse, we get the driving matrix equation:

\begin{pmatrix} F_A\\ F_B\\ F_C\\ F_D\\ F_E\\ F_F\\ \end{pmatrix} = \begin{pmatrix} 1 & 0 & 0 & 0 & 0 & 0\\ 0.0774 & -0.0034 & 0.1575 & -2.9894 & 0 & 2.8664\\ -0.0767 & -0.5119 & 0 & 0 & 0 & -2.8409\\ -0.6922 & 0 & 0.5180 & 0 & -4.3103 & 0\\ 0.6922 & 0 & 0.4820 & 0 & 4.3103 & 0\\ -0.00068 & -0.4847 & -0.1575 & 2.9894 & 0 & -0.0255\\ \end{pmatrix} \begin{pmatrix} F_x\\ F_y\\ F_z\\ \tau_x\\ \tau_y\\ \tau_z\\ \end{pmatrix}

Note:

In the last equation, forces are in uN and torques in uNm.

Attachment 1: osem_scheme.png
osem_scheme.png
  1004   Thu Jun 18 13:53:28 2015 SaikanthDailyProgressCrackleTransfer function measurements - with shorter legs

After a number of iterations of recentering and alignment, we finally have a stable setup with no magnets touching the OSEM - blocks or suspension. I ran a measurement the other day, for coil A excitation. Results in the attachments. Some key points:

  1. I have used the same configuration for excitation as described here.
  2. Notice that there are now 2 resonance peaks in SENS_A/COIL_A: which is what one would expect for a double pendulum-like suspension.
  3. The coherence for other sensors is still low. This is not suprising because there is less coupling between orthogonal directions, as one would expect, but it is can pose some problems while fitting poles and zeros.
  4. I haven't used any coherence cut-off in these plots.

I've attached .fig files too, along with .pdf.

Attachment 1: translations_A-exc_new.pdf
translations_A-exc_new.pdf
Attachment 2: rotations_A-exc_new.pdf
rotations_A-exc_new.pdf
Attachment 3: translations_A-exc.fig
Attachment 4: rotations_A-exc.fig
  1013   Wed Jun 24 23:08:08 2015 SaikanthSummaryCrackleUnsuccessful attempts to automate parallel TF measurements

Over the last week, I have been trying to find out ways to make parallel measurements of transfer functions (TF's) for different coil excitations. The way I've been doing it so far, it takes about 6-8hrs per measurement, and 6 such measurements - which is a week's time! Things would be much more efficient if I could take all measurements in, say, a night.

Fortunately, that's possible with our system - simply because it is a linear system. Why is it a linear system? Because Newton's laws - which govern the behaviour of our system - are linear!

 

As long as the system is not excited by the same frequency through different coils, because of linearity, the measurements should be as good as they were taken independently. The difficult part, however, is to find out how to do it.

I have been suggested a couple of methods to make parallel DTT measurements.

  1. Commands on a control room workstation - which is not possible (or easy?), because ours is not a control room.
  2. Use Python-MATLAB to run DTT measurements. People at LLO, LHO etc. have done this before, and I've tried working on their codes. However, there seem to be issues with the Python-MATLAB interface. We couldn't get Python XML parsing working the way it should be. Until we happen to find a solution for this, it wouldn't be possible to automate parallel DTT measurements.

As a result, I've had to come down to the manual mode of operation. Some details mentioned here.

  1014   Wed Jun 24 23:45:21 2015 SaikanthDailyProgressCrackleParallel DTT TF measurements - parameters

As mentioned in the previous update, I have been unsuccessful so far in automating parallel DTT measurements. However, it is essential to have measurements running parallel to some extent to save time. One way, obviously, is to do setup and run measurements manually.

The parallel measurements that I had started left last night had taken a lot of time and didn't finish even after 12 hrs. Meanwhile, independent of this, it has also been noticed that there is a lot of unnecessary data that we are collecting: the data above 5Hz where the coherence is almost always bad. Also, the number of averages, number of measurement cycles etc. were never taken into consideration while running measurements - since we were never worried about time. But then, time is now of interest. Therefore, it would be good to see if any of these parameters can be played around with and if the measurement time can be reduced without affecting the measurements itself.

 

For this, I have repeated measurements of the same type - with just about 10 points each time (for the sake of making a quick comparison) - by varying the number of cycles and averages. Attached are some results. Notice the coherence plot (on top).

Note: 1) The figure names tell about parameters in each case. 2) Not all plots start at the same frequency. I ran measurements from high to low frequency, and I've aborted some measurements which were taking a while because they were taking too much time at low frequencies, and the area of concern really was not the lowest frequencies.

 

Clearly, the coherence is exceptionally bad only for the case with 5 averages and 5 cycles - especially in the 0.3-0.8 Hz region - while it's above 0.7 in the rest of the cases. To decide among which combination to go with among the rest of them, I have looked at the product of averages and cycles, since it determines how long the measurement would go for. The current decision is to go ahead with 8 cycles and 5 averages.

 

Example: For a case with 200 log-spaced points between 0.1Hz to 5hz, I have estimated the time to be about 5.6hrs, which is reasonable enough compared to the earlier time durations. The bigger question, though, is to ask if it remains the same for parallel tests. The measurements will testify this.

Attachment 1: 5av_5cyc.png
5av_5cyc.png
Attachment 2: 5av_8cyc.png
5av_8cyc.png
Attachment 3: 5av_10cyc.png
5av_10cyc.png
Attachment 4: 7av_8cyc.png
7av_8cyc.png
  1018   Mon Jun 29 20:29:19 2015 SaikanthSummaryCrackleParallel TF measurements (automation) now possible

Pending post: one that I was supposed to write last week.

Earlier, I had tried running parallel TF measurements through Python-MATLAB. However, I was unsuccessful and I couldn't make much sense of the problem I was facing. I then tried the other method that was suggested - using the Diagnostic Tools "diag". The process can be summarized as follows.

First, a DTT template is prepared and saved as an XML file. The desired parameters are set; 'start time' is to be chosen as 'Now'.

Next, a short 'diag' script to be run from the workstation is prepared. The code itself is simple; here's how it goes

open

restore PATH-TO-DIRECTORY/IN_FILE_NAME.xml

run -w

save PATH-TO-DIRECTORY/OUT_FILE_NAME.xml

exit

Path to directory and file names are to be set appropriately. The above commands are for the Diagnostic Tools "diag". However, since we want to automate this, six such scripts must be run in parallel automatically; this was done through Python using the subprocess module.

 

I have, for the purpose of illustration, attached the diag script, Python script and the input DTT template that I used. Remember, to reproduce what I have talked about in this elog post:

  1. Input template is a set of files such as 'a-exc.xml'
  2. For 6 such files, 6 diag scripts must be appropriately created and saved in the same directory.
  3. The python code, also in the same directory and with appropriate files names, can be executed to begin measurements.
Attachment 1: a-exc
open
restore /home/controls/Saikanth/simultaneous_measurements/a-exc.xml
run -w
save /home/controls/Saikanth/simultaneous_measurements/a-done.xml
exit
Attachment 2: run_multi_tf.py
import subprocess

subprocess.Popen(['gnome-terminal', '-e', "diag -f /home/controls/Saikanth/simultaneous_measurements/a-exc"])
subprocess.Popen(['gnome-terminal', '-e', "diag -f /home/controls/Saikanth/simultaneous_measurements/b-exc"])
subprocess.Popen(['gnome-terminal', '-e', "diag -f /home/controls/Saikanth/simultaneous_measurements/c-exc"])
subprocess.Popen(['gnome-terminal', '-e', "diag -f /home/controls/Saikanth/simultaneous_measurements/d-exc"])
subprocess.Popen(['gnome-terminal', '-e', "diag -f /home/controls/Saikanth/simultaneous_measurements/e-exc"])
subprocess.Popen(['gnome-terminal', '-e', "diag -f /home/controls/Saikanth/simultaneous_measurements/f-exc"])
  1020   Mon Jun 29 21:59:16 2015 SaikanthDailyProgressCrackleMore realignment and some more knocking off

[Gabriele, Xiaoyue, Saikanth]

Today, we set out with the task of recentering block OSEMs, after what happened last week. While recentering block OSEMs, we realized that some suspension OSEMs were touching, and we tried to realign. The height for X2 had to be changed as well, and all of this gave the breadboard some good shaking. As a result, magnet C got knocked off. We tried to reglue it, but  Magnet C was not glued properly because there was a lot of residual glue on the breadboard reinforcement. After you left, while trying to remove the residual glue, we knocked off magnets B and F. Worse: the reason why C was not coming off easily was that the coil windings were off and they were getting stuck with the front part of the mount. (Or maybe, they came off because we tried too hard to push it in?) So, we had to change the OSEM. Right now, we have re-glued the 3 magnets again. (And oh, while re-gluing F, some wires broke.) Plan for tomorrow morning is to connect wires to OSEM C and resolder OSEM F wires, and do recentering for all (except D, E, Z1, Z2) again.

  1022   Tue Jun 30 11:44:37 2015 SaikanthDailyProgressCrackleMore realignment and some more knocking off

We had to change the sign of coils B and F to have stable damping loops. It's not clear if this is something related to wrong numbers loaded after the cymac restart.

Quote:

[Gabriele, Xiaoyue, Saikanth]

Today, we set out with the task of recentering block OSEMs, after what happened last week. While recentering block OSEMs, we realized that some suspension OSEMs were touching, and we tried to realign. The height for X2 had to be changed as well, and all of this gave the breadboard some good shaking. As a result, magnet C got knocked off. We tried to reglue it, but  Magnet C was not glued properly because there was a lot of residual glue on the breadboard reinforcement. After you left, while trying to remove the residual glue, we knocked off magnets B and F. Worse: the reason why C was not coming off easily was that the coil windings were off and they were getting stuck with the front part of the mount. (Or maybe, they came off because we tried too hard to push it in?) So, we had to change the OSEM. Right now, we have re-glued the 3 magnets again. (And oh, while re-gluing F, some wires broke.) Plan for tomorrow morning is to connect wires to OSEM C and resolder OSEM F wires, and do recentering for all (except D, E, Z1, Z2) again.

 

  1023   Tue Jun 30 15:36:23 2015 SaikanthSummaryCrackleCharacterization of mechanical response of suspension system: Analytical modeling - Model#1

Post pending from last week.

In order to better make sense of the results we have been obtaining in transfer function measurements, it is suggested to have an analytical model of the system under inspection -- in this case, a model of the suspension system based on the governing laws: Newton's laws.

I have made attempts, over the last couple of weeks, in reproducing transfer functions that we have obtained experimentally. In this elog post, I talk about particular model that I have worked with: one that was built about an year ago (and can be found on LIGOShare Dropbox at LIGOShare/Crackle2Design/SuspensionModel. (Link: https://www.dropbox.com/home/LIGOshare/Crackle2Design/SuspensionModel) I will not go into further details of the model; I will only talk about the results that I have achieved.

The 'suspension_4_2' file is the latest version of the analytical model of Crackle2, and that is the one I worked with. On running the script 'ToMatlab.m', the output is a file that contains, in a format MATLAB can understand, state-space matrices A, B and F. (A represents the dynamics of the system, B is the input coupling matrix and F represents external disturbances.)

 

In the current case of interest, the state equation can be written as:

\ddot{x} =A\vec{x} + F\vec{x_0} + B\vec{\tau}

In Laplace domain:

s^2I\vec{x}(s) = A\vec{x}(s) + F\vec{x_0}(s) + B\vec{\tau}(s)

Which gives:

\vec{x}(s)/\tau(s) = (s^2I-A)^{-1}B

This is a 12x12 matrix of transfer functions. (12x12 because the whole system has 12 degrees of freedom in all: 6 of intermediate mass and 6 of lower mass (breadboard setup).) Of interest to me is the last 6, and I have made use of the 6x6 submatrix to compare with experimental data. I have plugged in the required parameters after measuring them. I have attached an excel spreadsheet with the parameters I have used. I have also attached the results I have obtained from this simulation: a comparison of SENS_X/COIL_A transfer functions. Clearly, though the shape is a little similar, the positions of poles and zeros is definitely not matching. I have played around with the parameters as long as they were still sensible values, to try and match with measurements. I was unsuccessful in matching the positions of poles and zeros, and this called for building a better model altogether. I am currently working on building a model of Crackle2 on a simulation platform (also based on Mathematica) built by personnel who have worked at Advanced LIGO and KAGRA. I will talk about that in another elog post.

 

Attachment 1: CoilA_to_SensA_analytical_fit.pdf
CoilA_to_SensA_analytical_fit.pdf
Attachment 2: Model_parameters.xlsx
  1030   Mon Jul 6 18:40:03 2015 SaikanthDailyProgressCrackleMeasurement trials over the weekend

Over the long weekend, I have tried to run a few measurements. I've used the same set of parameters (number of cycles, averages etc.) as described here. The motivation was to get a set of measurements with the bell jar on. However, as in the past, there were problems.

  1. I did successfully run measurements, but after the measurements were done and I took a look at the results, I realized that:
    • The coherence was poor again - for all measurements. For B-sens/B-exc, I could not even see the double peak.
    • A, B and C were no longer centered. B and C went up to about 13000 and A down to about 4000-5000. Linearity in sensor readings was lost.
  2. I happened to try giving an offset to coil C to observe if a step was observed in sensor C or not, and that didn't happen: coil C stopped working again.

 

We figured out the reasons too:

  1. For 1 above, the reason was simple: the weight of the bell jar deflated the legs rather quickly, and this, obviously, spoilt the alignment of the setup. Now, this is a problem that's going to persist unless we think of ways to better maintain pressure. In order to avoid the effects, we have decided to work with deflated legs when the bell jar is put on.
  2. For 2 above, the reason turned out to be poor connections, and also probably the screw we used to pin down the OSEM: the metallic screw was shorting the coil in an unwanted way, and as a result coil C was not able to drive. Xiaoyue fixed the bad connection, and we have removed the top screw as well.

Tonight, I will try running measurements again. This time, I am going to try with higher number of averages and cycles (10 each). Earlier measurements, with 5 and 8 respectively, gave poor coherence and didn't take too long (~3-5hrs). For this one time, I am going to try with higher numbers and hope for better measurements.

Also for tonight, the bell jar has been taken off, and the legs are still inflated. Based on tonight's results, the plan for tomorrow is to deflate the legs and recenter OSEMs; these OSEM positions will serve as reference for future alignment. After that, we would like to compare OSEM spectra of inflated vs deflated cases, to observe what changes. We will then put on the bell jar and do another round of measurements tomorrow night.

  1036   Wed Jul 8 17:42:45 2015 SaikanthDailyProgressCrackleAll set for measurements

This morning, Gabriele recentered all OSEMs and re-inflated all legs to 6 bar. (See this.) The setup is now back in working condition.

After observing overnight drifts due to the legs deflating, we have decided to bring down the measurement time again; so I have now reduced the number of cycles for each frequency (from 10 to 7) and number of averages (from 10 to 6). The estimated time duration is now ~5.8hrs.

We also realized that I was driving too much on the coils, causing the sensor to go out of linear range near resonances. In order to avoid this, I have reduced the amplitude around resonant frequencies. The amplitude profile I was using earlier is shown here. What I'm using now, as an illustration, for coil A excitation is attached.

Tonight, I will run measurements after pumping legs back to 6bar again. These will, hopefully, form the set of measurements without the belljar. If this works out and if all else goes well, tomorrow, I will repeat with the bell jar put on. 

Attachment 1: coilA_exc_profile.pdf
coilA_exc_profile.pdf
  1047   Fri Jul 10 22:46:43 2015 SaikanthDailyProgressCrackleTF measurements with driving matrix implemented

Now that we have decent measurements without driving matrix implemented, we have decided to go ahead and apply the driving matrix too and get transfer functions in physical d.o.f. This evening, I got all the necessities for the same ready.

  • I had to build amplitude profiles for these new excitations based on coil excitation profiles and the driving matrix. I didn't directly use the driving matrix to transform the amplitudes directly, but I built the profile by seeing how much each coil contributes to each physical d.o.f. and a lot of experimentation. Put simply: I had to almost re-do the whole process that I went through for finding coil excitation amplitude profiles.
  • The excitation channel is now, of course, different. I now use CTRL_X_EXC and similar.
  • I turned OFF damping and ELP50 filters in CTRL_X, CTRL_Y (etc.) medm screens, turned OFF input signals too to keep the loop open.
  • Signs for all torques (i.e. CTRL_ROLL etc.) were different: a positive offset gave a negative shift in the sensor readings. So I flipped the signs. Although, this is a little surprising because with these signs, all OSEM linear dampings were working fine.
  • The sensing and driving matrices that are on suspension sensing and driving screens were "wrong" in the sense that the rows/columns for YAW and ROLL were interchanged. In my convention, the order is Pitch, Roll and Yaw (rotations about x, y and z axes). However, the order on the medm screens is different: Pitch, Yaw and Roll. I never noticed it till now... I have made the necessary changes in the .txt files of the sensing and driving matrices in ~/scripts.
  • The above realization doesn't necessarily mean that the measurements I have taken earlier are wrong. It's just those two rows/columns, and I can simply interchange them during analysis. It would be good, though, to change it on medm itself.
  • I pumped all legs and tried to carefully adjust pressures till all shadow sensor readings were close to 8000, and then initiated the measurements. Measurements began around 10:21PM LT.

The whole process of shifting from without-driving matrix measurements to with-driving matrix ones was a bit painful. A HowTo post on the same here.

  1048   Fri Jul 10 23:07:53 2015 SaikanthHowToCrackleHow to initiate TF measurements with driving matrix implemented

Currently, we have a working "local" damping feedback. This works, and we know it. And so, this forms our "backup plan" while we transition towards a new and better damping system. Especially while attempting to take TF measurements with driving matrix implemented, one must ensure that all necessary changes/modifications to the interface are done before initiating measurements. This post talks about the things to be done in order to start such TF measurements, and things to be done after such measurements are done. It assumes that the user starts with "local" damping turned on and working.

  1. Starting from when "local" damping is turned ON, the first step is to turn OFF "local" damping - both suspension and block damping. This can be done by opening the SUSP_CTRL_X (etc.) medm screens and turning OFF outputs.
  2. After outputs are turned OFF, inputs and all filters are to be turned OFF. The gain in each case is to be set to 1.
  3. For some d.o.f., it might happen that a positive offset might give a negative shift in the sensed displacement/rotation. In such a case, the sign of the gain must be flipped.
  4. Next, driving (and sensing) matrices are to be changed from identity to the desired ones.
  5. While using DTT/AWG to measure/excite, care must be taken to use SUSP_CTRL_X_EXC (and so on) for excitation, SUSP_CTRL_X_IN1 (and so on) for sensing.
  6. Care must be taken while choosing amplitudes of excitation: these are no longer coil amplitudes. One might want to look up the driving matrix, till one gets used to numbers in this domain.
  7. Start measurements.

Once measurements are done:

  1. First, before modifying anything else, outputs in SUSP_CTRL_X (and so on) screens are to be turned OFF.
  2. Then, gains can be brought back to earlier set values, and input and filters can be turned ON.
  3. Driving (and sensing too, if needed) matrix should be set to identity.
  4. Only after that can "local" damping be turned ON again.

 

If I find time before I leave, I will write a script to change all of this by one click. That can save some time, but more importantly: it is safer. Often, it can happen that one turns ON "local" damping without changing all settings back properly. For instance, one might turn ON "local" damping without changing the driving matrix back to identity; this makes the breadboard shake like crazy, and potentially knock off magets! The motivation, hence, is to make it easier and safer.

  1066   Thu Jul 16 23:31:20 2015 SaikanthMiscCrackleWhat happens when a magnet is loose?

Update for what followed:

In process of finding out what the problem with B was, we removed OSEMs one by one to see if the peak around 55Hz persisted. This is because we suspected some magnet was touching the inside of an OSEM. However, we did realize that magnet B was loose, and we fixed it.

In our process of recentering, coil F got broken, and we had to replace OSEM F with a new one. After recentering all 6 OSEM, we tried to turn on damping again, but this time, the sign of B seemed to be wrong, and the loop became unstable. This was unexpected and strage, because we hadn't messed with B like we did with F, and the sign could not have changed all of a sudden. (It is possible, though, that it was because we plugged the terminals in the reverse way when we checked the coil driver circuit...)

Quote:

[Saikanth, Gabriele]

Today we had problem in damping the suspension. We saw that both B and D loop were oscillating at high frequency. After a lot of investigations, we measured the plant transfer function of the B actuation, and found a very surprising response like a simple resonance at 55 Hz. Since we couldn't figure out the origin of this, we lifted the bell jar out and checked that nothing was touching. As a last resort, we checked the B magnet and found it very loose: just touching it was enough to detach it.

So, that's what happens when a magnet is loose.
 

 

  1067   Fri Jul 17 22:44:07 2015 SaikanthDailyProgressCrackleFinal suspension TF measurements

Late update: Pending from 15 July'15.

On the night of 15 July'15, I ran another round of measurements. The idea was to have more than just one set of measurements, before proceeding further to designing and implementing damping filters. Attached are the results, in .pdf and .fig formats. Updates about TF fits, comparison with analytical model predictions, damping filter design and implementation coming up soon. (A little caught up right now with wrapping up other things.)

Attachment 1: tf_x-exc_trans.pdf
tf_x-exc_trans.pdf
Attachment 2: tf_x-exc_rot.pdf
tf_x-exc_rot.pdf
Attachment 3: tf_y-exc_trans.pdf
tf_y-exc_trans.pdf
Attachment 4: tf_y-exc_rot.pdf
tf_y-exc_rot.pdf
Attachment 5: tf_z-exc_trans.pdf
tf_z-exc_trans.pdf
Attachment 6: tf_z-exc_rot.pdf
tf_z-exc_rot.pdf
Attachment 7: tf_pit-exc_trans.pdf
tf_pit-exc_trans.pdf
Attachment 8: tf_pit-exc_rot.pdf
tf_pit-exc_rot.pdf
Attachment 9: tf_yaw-exc_trans.pdf
tf_yaw-exc_trans.pdf
Attachment 10: tf_yaw-exc_rot.pdf
tf_yaw-exc_rot.pdf
Attachment 11: tf_x-exc_trans.fig
Attachment 12: tf_x-exc_rot.fig
Attachment 13: tf_y-exc_trans.fig
Attachment 14: tf_y-exc_rot.fig
Attachment 15: tf_z-exc_trans.fig
Attachment 16: tf_z-exc_rot.fig
Attachment 17: tf_pit-exc_trans.fig
Attachment 18: tf_pit-exc_rot.fig
Attachment 19: tf_roll-exc_trans.fig
Attachment 20: tf_roll-exc_rot.fig
Attachment 21: tf_yaw-exc_trans.fig
Attachment 22: tf_yaw-exc_rot.fig
  1137   Fri Aug 7 12:39:05 2015 SaikanthMiscCrackleSURF'15 Documentation | Scripts/Templates to be moved to workstation

Added Suspension TF measurement templates and script here. Gabriele told me he will take care of moving it to the appropriate folder on the workstation/cymac2. These are the most important templates that I leave behind.

I was looking for MATLAB scripts on my PC to be put in documentation, but I realized that MOST (apart from what I've already added to LIGOShare) of those are too specific to the trials I was doing, the formats I was using, etc. I felt that they won't be any useful to anybody else; but there's one script that could be useful, and it is generic enough to be modified for multiple purposes. Uploaded it here; these don't have to be moved anywhere else since these are just MATLAB scripts. Most of the other functions/wrapper I had built earlier are already on Dropbox in the MATLAB library here.

  1146   Mon Aug 17 04:24:24 2015 SaikanthSummaryCracklePending update: Analytical modeling of Crackle2 suspension

Pending update from a couple of weeks ago.

As I mentioned in the first update on Analytical Modeling of Crackle2, I had worked on the Mathematica model built by Gabriele to generate analytical results for the suspension transfer functions. The model could not reproduce the experimentally observed results, and so I had to shift to a different model. I had started using the Mathematica-based SUspension Model CONstructor (SUMCON) built by folks at KAGRA. What one can do with the interface, in brief, is as follows:

  • Define bodies/stages and associate one of them as attached to ground: In our case, the cage is attached to ground, and there's an intermediate suspension stage and the payload (optics breadboard).
  • Give shape information, mass, moment of inertia, initial position values for each of the bodies.
  • Setup wires for suspending one stage from another, and also input properties such as thickness, length, material.
  • Define springs (in our case blade springs) and their properties (Q, spring constant, etc.)
  • Setup other things, which are not relevant to our setup, such as inverted pendulum, heat links, dampers etc.

It is pretty intuitive to use; it can be found here.

Results for Crackle2:

The attachments below show the transfer function predictions for our suspension setup. Unfortunately, even after spending a lot of time, I couldn't recover data points of these plots to plot them on the same axis as experimentally obtained ones. There are a couple of channels available for one to extract data points, but somehow none of them seem to be working for me... Still, one can easily compare the frequency positions of each of these peaks with experimental results and observe the close matching.

 

Attachment 1: x_tf_1.pdf
x_tf_1.pdf
Attachment 2: y_tf_1.pdf
y_tf_1.pdf
Attachment 3: z_tf_1.pdf
z_tf_1.pdf
Attachment 4: p_tf_1.pdf
p_tf_1.pdf
Attachment 5: r_tf_1.pdf
r_tf_1.pdf
Attachment 6: w_tf_1.pdf
w_tf_1.pdf
  221   Tue Jun 21 14:53:29 2011 Vanessa AconDailyProgressCrackleMatlab simulation of Chopping

Our project is to set up a basic Michelson interferometer to measure and characterize the crackling in blade springs.  That crackling signal will likely be buried under other sources of noise and other parts of the signal, so we will use a chopping technique to extract the crackling signal.  We first set up a Matlab simulation of the chopping technique using a constructed "crackle" signal.  The code and explanation of that simulation are attached.

ETA: changed such that crackle = delta x(t), not delta x(t) - x(t).

Attachment 1: acon1.m
%crackling
fs = 500;
ts = 1/fs;
tt = (0:ts:100); %time vector
k0 = 2; %ideal spring constant
fdrive = 0.1; %driving frequency
Amp = 1; %max amplitude
dist = Amp*sin(2*pi*fdrive*tt); %spring position
vel = 2*pi*fdrive*Amp*cos(2*pi*fdrive*tt); %spring velocity
noise_t = rand(1,50001)*2-1; %noise function
... 34 more lines ...
Attachment 2: matlab_explanation.pdf
matlab_explanation.pdf matlab_explanation.pdf
  224   Thu Jun 23 12:18:15 2011 Vanessa AconDailyProgressCrackleMeasuring resonant frequency and Q factor of the blade springs

 Measurements taken on June 21.

Attachment 1: Q_and_res_freq.pdf
Q_and_res_freq.pdf Q_and_res_freq.pdf Q_and_res_freq.pdf
  225   Thu Jun 23 12:26:09 2011 Vanessa AconDailyProgressCrackleInitial Set-up: Noise Budget

Data taken June 22

We measured our initial set-up (with mirrors on PZTs, not masses on springs) noise and found a conversion factor from volts on the spectrum analyzer to meters (distance moved by the mirror).

Notes: I'm assuming that peak in the dark noise is from the lights, even though we have a plastic bin around the set-up.  Also, I used the most common wavelength value for HeNe lasers (from wikipedia).  I will confirm this value later.

ETA: Noise curves have been added for the PZT set-up.  Different curves are at different AC amplitudes and AC frequencies.  The curves do not change much in the 10-100Hz range, with varying low AC frequencies).

Attachment 1: 22_06_noise.pdf
22_06_noise.pdf
Attachment 2: 2406_noise_budgets.png
2406_noise_budgets.png
  237   Tue Jul 12 06:16:22 2011 Vanessa AconDailyProgressCrackleNoise Budget Update

 Using the approximate noise for vibration in the mirrors from Alastair's post, I have attached an updated noise plot with m/sqrt(Hz) on a log scale vs. Hz on a linear scale.

Attachment 1: totalnoiseplot01.png
totalnoiseplot01.png
Attachment 2: gyro_mirror_noise.m
load gyro_mirror_noise.mat
f_mech_noise = gyro_single_arm_noise_calibrated(:,1); % frequency vector for plotting mechanical noise
SA_x_noise = gyro_single_arm_noise_calibrated(:,2); % gyro single-arm noise calibrated to meters
SA_x_noise2 = (SA_x_noise)*2*sqrt(2); %double mirror displacement to get noise in laser path length
DA_x_noise = sqrt((SA_x_noise2).^2+(SA_x_noise2).^2+(SA_x_noise2).^2); %add noise from two mirrors in quadrature and beam splitter to get total incoherent noise in laser path system
semilogy(f_mech_noise,DA_x_noise); %plot seismic noise in mirrors on table in m/rHz vs Hz
%if we include beam splitter vibration
Attachment 3: mirror_vibration_noise.pdf
mirror_vibration_noise.pdf mirror_vibration_noise.pdf mirror_vibration_noise.pdf
  239   Wed Jul 13 12:57:13 2011 Vanessa AconDailyProgressCrackleNoise Budget Update

Quote:

 Using the approximate noise for vibration in the mirrors from Alastair's post, I have attached an updated noise plot with m/sqrt(Hz) on a log scale vs. Hz on a linear scale.

 Update: I've replotted the noise spectra, now with frequency on a log scale as well.

Attachment 1: totalnoiseplot02.png
totalnoiseplot02.png
  240   Wed Jul 13 13:05:30 2011 Vanessa AconDailyProgressCracklemagnetic actuator notes

 A quick calculation of the force from a solenoid on a small magnet (which we approximate as a dipole), from which we can find the dimensions and the number of coils for the solenoid we need (not sure if it is correct; will think more on it later).

Attachment 1: magnet_calculations.pdf
magnet_calculations.pdf
  241   Wed Jul 13 18:51:45 2011 Vanessa AconDailyProgressCrackleNoise Budget

I added the noise spectra for thermal noise in the blade springs, shot noise, and seismic noise from the table affecting the blade spring (seismic noise is from Tara's data).  My code and plot are attached.

I will upload them to SVN once I figure out how to do so.

 

Tara: The seismic data was measured on the optical table in PSL lab.

The seismic noise is calculated from a simple model of a mass-spring system using f0 (resonant frequency) and Q from previous measurement.

You have to add seismic from both blades which have different f0 and Q.

DO NOT forget to mention that the noise measured in the plot are from different setup ( metal shim instead of steel blade).

Attachment 1: totalnoiseplot.m
%%Total Crackling Noise Budget

%%mirror vibration noise==========================
load gyro_mirror_noise.mat
f_mech_noise = gyro_single_arm_noise_calibrated(:,1); % frequency vector for plotting mechanical noise
SA_x_noise = gyro_single_arm_noise_calibrated(:,2); % gyro single-arm noise calibrated to meters

SA_x_noise2 = (SA_x_noise)*2*sqrt(2); %double mirror displacement to get noise in laser path length
DA_x_noise = sqrt((SA_x_noise2).^2+(SA_x_noise2).^2+(SA_x_noise2).^2); %add noise from two mirrors in quadrature and beam splitter to get total incoherent noise in laser path system

... 96 more lines ...
Attachment 2: totalnoiseplot03.png
totalnoiseplot03.png
  242   Thu Jul 14 11:24:49 2011 Vanessa AconDailyProgressCrackleNoise Budget

 I've updated the thermal and seismic noise to reflect both blade springs, changed the thermal noise such that it uses the full fluctuation-dissipation theorem, and added some notes about where each piece of data came from.   

 The plot below is zoomed in from the previous one to 10Hz-100Hz.

 

 

Things we should think about:

Where our noise / sensistivity requirement is

How chopping / averaging will affect our sensitivity (it should improve it)

Recalculate / check our Q and w_0 values (these ones I found were approximate and from a different mass at a different distance along the blade spring, and Q differs very much from Tara's earlier measurements)

 

 

 

 

 

 

Attachment 1: totalnoiseplot04.png
totalnoiseplot04.png
Attachment 2: totalnoiseplot.m
%%Total Crackling Noise Budget

%%mirror vibration noise==========================
load gyro_mirror_noise.mat %note mirror (table) vibration noise is from gyro lab data (Alastair)
f_mech_noise = gyro_single_arm_noise_calibrated(:,1); % frequency vector for plotting mechanical noise
SA_x_noise = gyro_single_arm_noise_calibrated(:,2); % gyro single-arm noise calibrated to meters

SA_x_noise2 = (SA_x_noise)*2*sqrt(2); %double mirror displacement to get noise in laser path length
DA_x_noise = sqrt((SA_x_noise2).^2+(SA_x_noise2).^2+(SA_x_noise2).^2); %add noise from two mirrors in quadrature and beam splitter to get total incoherent noise in laser path system

... 108 more lines ...
ELOG V3.1.3-