[Radhika, Paco]

We tweaked the flexure alignment until we had a nominally collimated beam (~2 mW @ 250 mA of diode current) through the output aperture in the ECDL housing. We noted that the collimated beam is off-centered on that circular aperture along the horizontal (yaw) angle. After this, Radhika installed the ECDL grating and we hooked up the fiber output onto a InGaAs PD to monitor the power output. We tweaked the alignment of the grating (mostly yaw) to try and see a change in the power output to indicate optical gain in the diode, but saw no changes. We observed a change in the PD photocurrent as a function of the diode current in the absence of the grating (no optical feedback) which is indicative of ASE. We measured this level to be ~ 140 mV at 200 mA of current; with no observed threshold. In conclusion, we still need to refine our grating alignment to provide gain on the diode and observe lasing at the nominal 1450 nm wavelength.

[Paco]

Worked for a few hours to get the aspheric properly aligned. The procedure is quite finnicky, as the four 2-56 flexure screws have too much game and the fine thread setscrew that adds tension is too constrained. Anyways, it generally goes like this:

1. With the grating out of the way, and the 2-56 screws slightly loose, move the aspheric flexure until a collimated beam (as round as possible) exits the centered round aperture in front of the SAF chip.
2. Very carefully tighten the fine threaded setscrew in place to register the aspheric alignment.
3. Check that the desired beam hasn't changed
4. Insert grating careful not to touch the aspheric flexure (again, the mechanical registration is not great!)
5. Manually rotate the grating while monitoring the power at the fiber output until non-ASE light appears. This is quite sensitive to alignment/angle and the better the mode is matched back into the fiber, the easier it is to find the right position.
6. Fix the grating flexure.
7. Slightly tweak the grating mirror knobs by hand to maximize said power (careful to avoid saturating PD)

After this, I installed a second amplified InGaAs detector, hooked up the unbalanced MZ beamsplitter output into the two PDs, adjusted the gains to equalize the output voltages and then hooked the two signals to the A and B inputs of an SR560 in "A-B" mode. The output (gain 1) was good enough to feed back in the HV PZT amplifier input modulation which allowed the MZ to lock mid-fringe. The lock is rough, as the balanced homodyne signal retains a tiny offset due to imperfect balancing... Attachment 1 shows the setup, including a typical scope trace after coarse current tuning (Ch1 and Ch2 in yellow and blue represent the photocurrents in the two MZ ports in the absence of feedback).

Indeed, scanning the nominal PZT voltage broke the lock, potentially after crossing a mode hopping region.

Tasks to be done:

• Power characterization, including RIN, emission vs current.
• Emission spectrum characterization; using the homemade spectrograph (grating + lens + camera) as the PZT is scanned
• MZ feedback loop characterization, including optimizing the balancing stage
• Self-homodyne phase noise spectrum

Next, as was suggested during yesterday's group meeting, we will transition into a self-heterodyne setup (with an AOM which I have yet to check out in the QIL).

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

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

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

[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  = 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

oscillating at , 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

So the optical phase spectral density is related to the rf phase spectral density by a transfer function   Then, the RF & optical phase power spectral densities are related by   or

Then, because the instantaneous laser frequency is ,  in fourier domain  the frequency and phase PSDs are related by the magnitude square of this transfer function like

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

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.

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.

Nice work James!

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

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

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

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.

[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 , 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. 

[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, Hz²/Hz (or Hz/rtHz). 

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. 

 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.

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

Useful data on Silicon strength tests...

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.

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.  

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:  , where  is the velocity at P,  is the velocity of the centre of mass in the absolute frame,  is the angular velocity of rotation and  is the position vector of the point P.

In an infinitesimal time interval, the above relation is equivalent to: , where  is now infinitesimal displacement vector of the point P, and  is the infinitesimal displacement vector of the center of mass of the suspended breadboard. This can be written in the matrix form as:

where  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   would be the only relevant one, because its axis is along the x-axis. Hence, the linear equation corresponding to  can be written down from the above matrix equation by plugging in the values for  and . 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:

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

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.

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.

The transformation matrix, then, becomes:

The inverse of this matrix is as follows:

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.

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.

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.

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.

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

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.

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.

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:

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

where the  and  are position and force vectors of OSEM 'i'.

This can be expanded to:

 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.

Note: , 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:

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

Note:

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

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.

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.

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.

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.

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

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.

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:

In Laplace domain:

Which gives:

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.

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.

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. 

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.

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.

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

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

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.

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.

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

 Measurements taken on June 21.

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

 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.

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