Summary of this week's work Wednesday - Aligned the mode cleaner with Koji, and then measured the beam characteristics at MC2 end. Koji then taught me how to read the WFS signals Thursday - wrote a script to measure the signals and calculated the coefficients relating mirror movement and DC signals of WFS. To know the possibility of the control, found SVD of the coeff matrix, and condition number. Friday - Set up the measurement of QPD linear response using a laser outside the cavity. Took data. Monday - did the calculations and plotting for the above experiment. Then played around with the MEDM screens , and also tried to see what happens to the Power Spectrum of WFS signals by changing the coefficients in teh matrix. (failed) Tuesday - played around with WFS, tried seeing what it does when switched on at different points, and also what it does when I disturb the system while WFS has kept it locked.

This week I was mainly interested in investigating the noise source at the phase camera. So having this issue in mind, my activities are the following:

1. I worked on producing multiple beat signal (1Hz and 5Hz). Elog entry.

2. I altered the setup so that instead of triggering the camera from the signal generator, we are now triggering it from the beat signal from the reference beam and sideband.

3. I made the nice little aluminium table for all the amplifiers, mixer and splitters to sit at one place instead of floating around.

4. I talked with Aidan and Joe and verified my calculation and extended it to further investigation of the noise source in the setup.

Plan for the upcoming week:

1. Measure and calibrate the camera w.r.t the power incident on it.

2. Investigate the noise source.

This is regards to zero signal being reported by the channels C1:PEM-SEIS_GUR1_X, C1:PEM-SEIS_GUR1_Y, and C1:PEM-SEIS_GUR1_Z.

I briefly swapped Guralp 1 EW and Guralp 2 EW to confirm to myself that it was not on the gurlap end (although the fact that its digital zero is highly indicative a digital realm problem).  I then unplugged the 17-32, and then 1-16 channel connections to the 110B.  I saw floating noise on the GUR2 channels, but still digital zero on the GUR1 channels, which means its not the BNC break out box.

There was a spare 110B, unconnected in the crate, so to do a quick test of the 110B, I turned off the crate and swapped the 110Bs, after copying the switch configuration of the first 110B to the second one.  The original 110B was labeled ADC 1, while the second 110B was labeled ADC 0.  The switches were identical except for the ones closest to the Dsub connectors on the front.  All those switches in that set were to the right, when looking down at the switches and the Dsub connectors pointing towards yourself.

Unfortunately, the c0duc1 never seemed to come up with the new 110B (ADC 0).  So we put the original 110B back.  And turned the crate back on. 

The fb then didn't seem to come back quite right.  We tried rebooting fb40m it, but its still red with status 1.  c0daqctrl is green, but c0dcu1 is red, although I'm not positive if thats due to fb40m being in a strange state.  Jenne tried a telnet in to port 8087 and shutdown, but that didn't seem to help.  At this point, we're going to contact Alex when he gets in around 12:30.

 Before I left, I disconnected the PD55, so the 33 MHz channel wasn't physically connected to anything!!! Only one end of the wire was connected to the rack while the other was free...

So it wasn't the PD connection that is responsible for MC tripping at the later time...

Weekly update:

We correctly connected our circuit to power source to verify that it was functional and that our LED in the shadow sensor turned on.  It did, but we also noticed a funky signal from the LED driver.  We continued to attempt 1x1 levitation, but determined that the temporary flag we were using out of convenience (a long, thin cylindrical magnet) was weakly attracted to residually magnetized OSEM components.  We then switched to an aluminum screw as our flag.

We resoldered and applied heat shrink to the wires connecting our coil to the BNC terminal, since they were falling apart.

We sat down with Rana and removed circuit components in the LED drive part by part to determine what was tripping up the circuit.  We determined a rogue capacitor to be at fault and removed it from the circuit.

We used a spectrum analyzer to measure the frequency response of our circuit (see details in last elog).  We are currently making a Simulink block diagram so we can check the stability of our setup, but are temporarily set back because our plotted calculation of the transfer function clearly doesn't match the measured one.

Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera.  This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).

Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc).  This equipment output a DC voltage proportional to the amplitude of the RF signals.  The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc.  These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system).  The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.

We simply chose one, the 33 MHz channel in this case, and connected.  At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping.  The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection.  We were able to restore the watchdog and confirm that the optic started to settle down again.  Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.

Yesterday we hooked up the Quadrant Maglev control to the power supply to test the components in the Input/Output part of the circuit.

The output from the buffer was an unexpected high noise signal which was caused by some circuit components.

Consequently these were replaced/removed after confirming the source of noise.

The following is a story of how it was done.

To test the components of input/output, we measured the output across TP_PD3(Test Point -Photo Diode 3).
We got a high noise signal with a frequency of several kHz.

We tested the values of various electronic components. The resistances R5 and R6 did not measure as mentioned(each had a value of 50 K in the schematic). The value of R6 was 10 K and we replaced R5 with a 10 K resistor. We still got the noise signal at 5.760 kHz with a Pk-Pk voltage of 2.6 V. The resistors in R-LED measured 1.5 K instead of the marked 2.2 K.

We had three suspects in hand:

• BUF634P : A buffer from the Sallen-Key filter to the LED.
• C24 : A capacitor which is a part of the Sallen-Key filter.
• C23 : A capacitor in the feedback circuit of the Sallen-Key filter.

BUF634P : The data sheet for the BUF634P instructed a short across the 1-4 terminals in the presence of capacitive load.  We followed this to overcome the effect(if any) of the extra-long BNC cables which we were using. The oscilloscope still waved 'Hi!' at a few kHz. We removed the buffer and also the feedback resistor R42 from the circuit, what we were testing boiled down to measuring the output of the Sallen-Key filter. The output still contained the funny yet properly periodic signal at a few kHz.      

.    

C24: Removing C24 did not do any good.

C23: As a final step C23 was removed. And ... We got a stable DC at 9.86 V(almost stable DC with a low noise at a few MHz). C24 and the buffer were replaced and output seemed fine. The output was a high frequency sine wave which was riding on a DC of 9.96 V.

We rechecked if the LED was on and the infrared viewer gave a positive signal.

We went ahead obtaining the transfer function of the feedback control for which we used a spectrum analyzer.

The input for feedback system is a photo current whereas the spectrum analyzer tests the circuit with a voltage impulse.  Hence the voltage input from the spectrum analyzer needs to be converted into current of suitable amplitude(few microamps) for testing the spectrum analyzer.  Similarly the output which is a coil current needs to be changed to a voltage output through a load for feeding into the channel of the spectrum analyzer. We used a suitable resistance box with BNC receiving ends to do this. We obtained a plot for the transfer function which is shown below.

Future plans:

- Check the calculated transfer functions with the plot of the spectrum analyzer

- Model the entire(OSEM, magnet, actuators etc.) system in Simulink and calculate the overall transfer function

- Stable levitation of the 1X1 system

 I just rebooted c0dcu1, which didn't help anything.  Joe said he'd try to give me a hand tomorrow.

 I measured FSS's open loop transfer function.

For FSS servo schematic, see D040105-B.  

4395A's source out is connected to Test point 2 on the patch panel.

Test Point 2 is enabled by FSS medm screen.

"A" channel is connected to In1, on the patch panel.

"R" channel is connected to In2, on the patch panel.

the plot shows signal from A/R.

Note that the magnitude has not been corrected for the impedance match yet.

So the real UGF will be different from the plot.

-------------------------

4395A setup

-------------------------

network analyzer mode

frequency span 1k - 10MHz

Intermediate frequency bandwidth 100Hz

Attenuator: 0 for both channels

Source out power: -30 dBm

sweep log frequency

------------------------------

medm screen setup

-----------------------------

TP2: enabled

Common gain -4.8 dB

Fast Gain 16 dB

After whatever Joe/Alberto did this afternoon, the MC was not locking. Koji and I removed several of the cables in the side of the rack where they

were apparently working (I say apparently because there's no elog).

MC is now locking but the autolocker did not work at first - op340m was unable to access any channels from c1iool0. After several minutes, it mysteriously

started working - the startup.cmd yields errors seen on the terminal. I attach the screen dump/.

For yesterday - July 12th.

Yesterday, I tried understanding the MEDM and the Dataviewer screens for the WFS.

I then also decided to play around with the sensing matrix put into the WFS control system and see what happens.

I changed the sensing matrix to completely random values, and for some of the very bad values, it even lost lock :P (i wanted that to happen)

Then I put in some values near to what it already had, and saw things again.

I also put in the matrix values that I had obtained from my DC calculations, which after Rana's explanation, I understand was silly.

Later I put back the original values, but the MC lock didnot come back to what it was earlier. Probably my changing the values took it out of the linear region. THE MATRIX NOW HAS ITS OLD VALUES.

I was observing the POwer Spectrum of teh WFS signals after changing the matrix values, but it turned out to  be a flop, because  I had not removed the mean while measuring them.  I will do that again today, if we obtain the lock again (we suddenly lost MC lock badly some 20 minutes ago).

Via reconfiguration of Viton parameters (previously posted), I managed to debug the COMSOL run time errors and null pointer exceptions. Listed are the resultant eigenfrequencies obtained through structural analysis testing. For all tests, the bottom of the Viton springs are constrained from motion, and all other parts are free to oscillate. Notice that color variations signify displacement from the equilibrium position. Also note that different initial conditions produce different eigenmodes:

No initial displacement:

0.01 m x-displacement:

0.01 m y-displacement:

 0.01 m z-displacement:

Clearly, the plate has its first harmonic between 210-215 Hz, which is much greater than seismic noises (which never exceed the 10-Hz range). This suggests a highly attenuating transfer function. Since the remaining three plates have been designed to resonate similarly, it is likely that the entire stack system will also function very well.

Next steps:

1) Extend the eigenfrequency analysis to obtain a transfer function for the single-plate system

2) Expand the CAD model to include all four stack layers, and perhaps a base

Viton flouroelastomers have somewhat variable material properties. The following parameters are being used for eigenfrequency analysis.

Young's Modulus: 72,500-87,000 psi (cite: http://www.row-inc.com/pfa.html) *Accurate for PFAs

Poisson's Ratio: 0.48-0.50 (cite: http://www.engineeringtoolbox.com/poissons-ratio-d_1224.html) *Accurate for rubber

Density: 1800 kg/m^3 (cite: http://physics.nist.gov/cgi-bin/Star/compos.pl?matno=275)

[Sanjit, Jenne]

Sanjit discovered that the Gur1 channels are all digital 0.  We determined that this began on July8, 04:00 UTC (~9pm on the 7th?).

It's digital zero, so we suspect a software thing.  Just to check, we put a sine wave in, and didn't see anything.  Gur2 seems totally fine, and the sine wave input showed up nicely on dataviewer.  What's going on? Sabotage to prevent this paper from getting done?  Dmass trying to get his paper done before me???

Investigations are ongoing.... Joe claims it's not his fault, since his shenanigans near the PEM rack were on days before, and days after this, but not on the 7th.  

 It seems like you might inherit an offset by using step (3) b/c of the temperature gradient between the crystal and the sensing point. Depending on how large this gradient is you could increase the linear coupling from temperature to intensity noise from zero to a significant number. Phase noise should not be effected.

SInce these things (ovens) are so low time constant, shouldn't we

1. Lock to a temperature
2. Let the oven equilibrate for however long - a few tau maybe - my oven has a time constant of 60 sec, don't know if this is fast or slow compared to that
3. Measure P_532/P_1064
4. Change the setpoint
5. Go back to step 1

The optimum temperature for the doubling crystal on the PSL table was found to be 36.8 deg.

I scanned the temperature of the crystal from 44 deg to 29 deg, in order to find the optimum temperature where the frequency doubled power is maximized. 

(method) 

The method I performed is essentially the same as that Koji did before (see this entry).

(1) First of all, I enabled the PID control on the temperature controller TC200 and set the temperature to 44 deg.

(2) After it got 44 deg, I disabled the PID control.

(3) Due to the passive cooling of the oven, the temperature gradually and slowly decreased. So it automatically scans the temperature down to the room temperature.

(4) I recorded the power readout of the power meter: New Port 840 together with the temperature readout of TC200. The power meter was surely configured for 532 nm.

(result)

The measured data are shown in the attachment. 

The peak was found at T=36.8 deg where the power readout of  532 nm was 605 uW.

Compared with Koji's past data (see this entry), there are no big side lobes in this data. I am not sure about the reason, but the side lobes are not critical for our operation of the green locking.

 (to be done)

 Adjustment of the PID parameters

I have just removed an other 400 cc of water from the chiller.  I have been doing this since the HTEMP started fluctuating.

The Neslab bath temp is 20.7C, control room temp 71F

Jenne and Koji

We tweaked the alignment of the TT mirror.

First we put a G&H mirror, but the mirror was misaligned and touching the ECD as the magnet was too heavy. We tried to move the wires towards the magnet by 1mm.
It was not enough but once we moved the clamps towards the magnet, we got the range to adjust the pitching back and forth.
We tried to align it by the feaher touch to the clamp, we could not get close to the precision of 10mrad as the final tightening of the clamp screws did change the alignment.

We will try to adjust the fine alignment tomorrow again.

The damping in pitch, yaw and longitudinal looks quite good. We will also try to characterize the damping of the suspension using a simple oplev setup.

The connection between our coil wires and BNC terminals was pretty awful (soldered wires broke off ) so we removed the old heat shrink and re-soldered the wires.  We then chose more appropriately sized heat shrinks (small one around each of the two soldered wires, a medium-sized shrink around the wires together, a large one covering the BNC terminal and the wire) and used the solder iron and heat gun to shrink them.

Eigenfrequency analysis has been successfully completed in COMSOL on both a tutorial camshaft, as well as a homemade metal bar.

Upon increasing in complexity to the busbar, I once again began getting into run time errors and increased lag. It seems that this is due to undefined eigenvalues when solving the linear matrices. I tried many boundary values as well as initial conditions in case this was the issue, but it was not. There seems to be some sort of an internal inconsistency. This is no longer a matter of tweaking parameters.

Next steps:

1) Try using the same techniques on the actual mirror stacks to see if we get lucky.

2) In the likely case that this doesn't happen, continue the debugging process. If necessary, a good deal of time may need to be spent learning the COMSOL lower-level jargon.

 The old plots looked horrible, and so here is a new plot

The slopes and other stats are

Pitch

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =        8550  (7684, 9417)
       p2 =       -2148  (-2390, -1906)

Goodness of fit:
  SSE: 9944
  R-square: 0.9923
  Adjusted R-square: 0.9907
  RMSE: 44.59

Yaw

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =       -8310  (-8958, -7662)
       p2 =        2084  (1916, 2252)

Goodness of fit:
  SSE: 6923
  R-square: 0.9954
  Adjusted R-square: 0.9945
  RMSE: 37.21

I and koji setup the measurement of the QPD response to the pitch and yaw displacements of the beam spot.

We did this using a 100mW 1064nm laser. Its power was attenuated to ~ 1.9mW, and the spot size at the QPD position was 6000-7000 um .

The QPD was put on a translation stage, using which, the center of teh QPD wrt the beam spot could be moved in pitch and yaw.

Following are the measurements :

For yaw

:

The slope of teh linear region is -8356 /inch

 For pitch

The slope of the linear region in this is 9085/inch

[Jenne, Chip]

The alarm was still going, because the LOLO setting was higher than the LOW, which is a little bit silly.  So we changed the .LOLO setting to 0.80 (the LOW was set to 0.82)

We also changed psl.db to reflect these values, so that they'll be in there the next time c1psl gets rebooted.

The feedback signal going to the laser PZT at the X end station was measured in the daytime and the nighttime.

It's been measured while the laser frequency was locked to the arm cavity with the green light.

The red curve was measured at 3pm of 8/July Friday. And the blue curve was measured at 12am of 9/July Saturday. 

As we can see on the plot, the peak-peak values are followers

              daytime:  ~ 4Vpp

       nighttime:  ~1.8Vpp

It is obvious that the arm cavity is louder in the daytime by a factor of about 2.

Note: the feedback signal is sent to the PZT only above 1Hz because the low frequency part is stabilized mostly by the crystal temperature (see this entry)

 An entry on the 40m wiki page might serve you better, and be easier to sift through once all is said and done

For the sake of future users, I have decided to periodically add tips and tricks in using COMSOL that I have figured out, most probably after hours of circuitous efforts. They will always be listed under the new COMSOL Tips category.

Today's topic: Intrusions

COMSOL has a very user-friendly interface for taking objects from 2D to 3D using the "extrusion" feature. But suppose one wants to design an object which contains screw holes or some other indentation. I've found that creating "punctures" in COMSOL is either impossible or very complicated.

Instead, COMSOL encourages users to always "add" to the object. In other words, one must form the lowest level first, then build layers sequentially on top using new work plane and boolean difference operators. This will probably be a bit clearer with an example:

1) First, create the planar projection in a work plane:

2) Extrude the first layer only in the regular fashion:

 3) Add a new work plane which is offset in the z-direction to the deepest point of the intrusion.

 4) Now, create the shape of the intrusion in this new work plane.

5) Use the Boolean "Difference" to let COMSOL know that, on this plane, the object has a hole.

 6) Extrude once more from the second work plane to complete the intrusion.

The AC filters will be checked and/or replaced today. This means the AC will be off for sort periods of time. Temperature and particle count will be effected some what.

See 800 days plot

I have resurrected the MC WFS on Friday night.
I have uncommented the WFS part of the MC autolocker.
The WFS total gain was empirically set to 0.1 such that the loops have no instability.

The loops somewhat worked through the weekend although they seemed to have the drift of the operating points
in accordance with the WFS spot.

I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.

I did the same for the MOPA's AMPMON because its decayed state is now nominal.

Steve and I removed the thermal insulation from around the reference cavity vacuum chamber. It wasn't really any good anyways.

Here are the denuded photos:

Steve and I are now planning to replace the foam with some good foam, but before that we will wrap the RC chamber with copper sheets like you would wrap a filet mignon with applewood bacon.

This should reduce the thermal gradients across the can. We will then mount the sensors directly to the copper sheet using thermal epoxy. We will also use copper to cover most of this hugely

oversized window flange - we only need a ~1" hole to get the 0.3 mm beam out of there.

My hope is that all of this will improve the temperature stability of this cavity. Right now the daily frequency fluctuations of the NPRO (locked to the RC) are ~100 MHz. This implies

that the cavity dT = (100 MHz) / (299792458 / 1064e-9) / (5e-7) = 1 deg.    That's sad....

I also changed the RC_REFL cam to manual gain from AGC. I cranked it to max gain so that we can see the REFL image better.

In order to increase the green power on the PSL table, I moved the position of the Second Harmonic Generation (SHG) crystal by ~5cm.

After this modification, the green power increased from 200 uW to 640 uW. This is sufficiently good.

     As I said in the past elog entry (# 3122), the power of the green beam generated at the PSL table should be about 650 uW.

I measured the green power by the Ophir power meter and found it was ~200 uW, which made me a little bit sad.

Then I performed the beam scan measurement to confirm if the crystal  was  located on the right place. And I found the postion was off from the optimum position by ~5cm.

So I slided the postion of the SHG oven to the right place and eventually the power got increased to 640 uW.

some notes: 

(power measurement)

        The outgoing beam from the SHG crystal is filtered by Y1-45S to eliminate 1064nm.

According to Mott's measurement Y1 mirrors are almost transparent for green beams (T~90%), but highly reflective for 1064nm (T~0.5%).

All the green power were measured after the Y1 mirror by the Ophir configured to 532nm, though, the measured power might be offseted by a leakage of 1064nm from the Y1 mirror.

I didn't take this effect into account.

(beam scanning and positioning of crystal)

          Here is the properties of the incident beam. These numbers are derived from the beam scan measurement.

w0h             = 52.6657      +/- 0.3445 um

w0v             = 52.4798      +/- 0.1289  um

z0h             = 0.574683         +/- 0.001937 m

z0v             = 0.574325         +/- 0.0007267 m

Where the suffixes "h" and "v" stand for "horizontal" and "vertical" respectively.

The distances are calibrated such that it starts from the lens postion.

Both waist size are already sufficiently good because the optimum conversion can be achieved when the waist size is about 50um ( see this entry)

The measured data and their fitting results are shown in attachement 1.

         According to my past calculation the center of the crystal should be apart from the beam waist by 6.8mm (see this entry). 

So at first I put the oven exactly on the waist postion, and then I slided it by 6.8mm.

(to be done)

        I need to find an optimum temperature for the crystal in order to maximize the green power.

Previously the optimum temperature for the crystal was 38.4 deg. But after moving the position I found the optimum temperature is shifted down to around 37deg.

Here are some more details about the current phasecam setup. We are using a He-Ne laser setup

A crude snap shot of the setup....

We sent light through SM2 (Steering Mirror 2)  to BS1(Beam-Splitter 1) where the laser light is split into two parts, one going to the AOM and the other to the EOM. The EOM adds 40 MHz sidebands to the incoming carrier light after SM3, and the AOM shifts the frequency of the incident light on it to 40.000 005 MHz. The purpose for doing this juggling is to intentionally create a beat signal off the reference beam from the AOM with the sidebands added at the EOM. Note that, we are driving the AOM at 7dBm and the EOM at 13 dBm with 0 (nil) modulation. The two lights are combined at the BS2 and sent off through SM5 to the camera. The CMOS of the camera contains silicon based Micro MT9V022 chip which has a quantum efficiency of 50% at 633 nm. Thus we expected a fairly good response to this He-Ne setup from the camera. 

Using a trigger circuit, we triggered the camera at 20 Hz by sending a 20Hz sinusoidal signal to it. The trigger circuit converts this to a positive square waves. Then I roughly figured out the optimum exposure time for the camera before the DC levels saturates it by writing a code for taking a series of 25 images at different exposure time. I found that 500µs seems to be a reasonable exposure time. So, using this data, I took 20 consecutive images and sent them through a short Fourier Transform segment using Matlab to see the beat signal. Note that the DC component from these processing of the images have some fringe pattern which is due to the ND 2.5 filter that we were using to reduce the light power incident on the camera. The FT method also gave us the presence of the beat signal at the corresponding bin of the FT (for example: for 5Hz beat signal, I got the DC at bin 1 of the FT and 5Hz component at bin 6 as expected). Then I changed the AOM driving frequency to 40.000 001 MHz in order to see a 1 Hz beat signal. The results for both is in my previous post. 

For the last week, I have been attempting to determine the mirror stack transfer function which relates mechanical mirror response to a given ground-motion drive. The idea is to model the stacks in COMSOL and ultimately apply mechanical tests for manual calculation.

Procuring the correct drawings to base my 3D models off of was no simple task. There are two binders full of a random assortment of drawings, and some of them are associated with the smaller chambers, while others are appropriate for the main chamber, which is what we're interested in right now. For future workers, I suggest checking that your drawings are appropriate for the task at hand with other people before wasting time beginning the painstaking process of CAD design in COMSOL.

The drawings that I ultimately decided to use are attached below. They detail four layers of stacks, each which arrange 15, 12, 8, and 5 (going from bottom to top) Viton damping springs in an orderly fashion. The numbers have been chosen to keep the load per spring as constant as possible, in order for all springs to oscillate with as close a resonant frequency to each other as possible.

After making some minor simplifications, I have finished modeling the top stack:

After triangular meshing, before my many failed attempts at mechanical testing:

Both the Viton and steel portions have been given their material properties, and so I should be (theoretically ) ready to perform some eigenfrequency calculations on this simplified system. If my predictions are correct, these eigenfrequencies shouldn’t be too far of the eigenfrequencies of the 4-layer stacked system, because of the layout of the springs. I’ve tried doing mechanical tests on the top stack alone, but there hasn’t been much progress yet on this end, mostly because of some boundary value exceptions that COMSOL keeps throwing at me.

In the next couple weeks or so, I plan to extend this model to combine all four layers into one completed stack, along with a simple steel base and mirror platform. I also plan to figure out how to make eigenfrequency and transfer function measurements.

Lastly, to anyone who is experienced with COMSOL, I am facing two major roadblocks and could really use your help:

1) How to import one model into another, merge models together, or copy and paste the same model over and over.

2) Understanding and debugging run-time errors during mechanical testing.

If you have any idea how to attack either of these issues, please talk to me! Thanks!

I turned off fb40m2 and fb40m temporarily while we added an extra power strip  to the (new) 1X6 rack at the bottom in the back.  This is to allow for the addition of the 4600 computer  given to us by Rolf (which needs a good name) into the rack above the fb machine.  The fb40m2 was unfortunately plugged into the main power connectors, so we unplugged two of its cables, and put them into the new strip. While trying to undo some of the rats nest of cables in the back I also powered down and unpluged briefly the c0dcu1, the pem crate, and the myrinet bypass box.

I am in the process of bringing those machines back up and restoring the network.

Also this morning, Megatron was moved from the end station into the (new) 1X3 rack, along with its router.  This is to allow for the installation of the new end computer and IO chassis.

I just found the singular values and the condition number of the 4*4 matrix relating the WFS error signals and the MC1 and MC2 movements.

the condition number is ~12.5. I think its small enough to continue with the scheme. (if the measurements and all are reliable).

I and Koji were trying to lock the mode cleaner for measuring the beam power at MC2 end. That is when we obtained the trans and refl values.

The beam characteristics at the MC2 were measured so that we could now use a dummy beam of similar power to test and characterize the QPD we are about to install at the MC2 end. This QPD wil provide two more signals in pitch and yaw, and hence complete 6 signals for 6 rotatioanl dof of the cavity. (4 are coming from WFS).

Once the QPD is characterised, it can be used to see the spot position at MC2. This is related to the mirror angles.

The width measurements were done using a beam scan. the beam scan was properly adjusted so that the maxima of the intensity of the sopt was at its center.

We also fitted gaussian curve to the beam profile, and it was a substantially good fit.

The whole idea is that I am trying  to look how the Wavefront sensors respond to the perturbations in the mirror angles. Once this is known, we should be able to control the mirror-movements.

the starting point would be to do just the DC measurements (which I did today). For proper analysis, AC measurements are obviously required.(will be done later).

The matrices so calculated can be inverted, and if found enough singular, the method can be used to control.

The first shot is to see teh dependency of teh error signals only on MC1 and MC3, and see if that is kind of enough to control these two mirrors.

If this works, the QPD signals could be used to control MC2 movements.

The WFS error signals were recorded in the order

WFS1_PIT

WFS1_YAW

WFS2_PIT

WFS2_YAW

these measurements are made in the linear region, that is the MC is nearly perfectly aligned.

This is  the average and std. dev.of 5 measurements taken of the same signals over 10 secs each. The std. dev are under 10%. And hence, I will be using 10 secs for measurements for the WFS signals after perturbations to the mirrors.

avg =

829.4408
-517.1884
297.4168
-944.7892


std_dev =

9.0506
22.9317
15.4580
8.9827

I perturbed the Pitch and Yaw of the Three mirrors (in order MC1,2,3), using ezcastep and calculated the coefficients that relate these perturbations to the WFS error signals.

The perturbation made is of -0.01 in each dof , and after measuring the WFS error for it, the system is reverted back to the previous point before making the other perturbation.

I was able to calculate the coefficients since I have assumed a linear relationship..

Following are the coefficients calculated using 10 secs measurements

coef_mat =

   1.0e+05 *

                            MC1_P   MC1_Y  MC2_P   MC2_Y    MC3_P   MC3_Y  constant
WFS1_PIT        -0.1262    0.3677   -0.4539   -0.6297   -0.1889   -0.1356   0.013664
WFS1_YAW     -0.0112   -0.7415   -0.1844    2.4509   -0.0023   -0.3531  -0.016199
WFS2_PIT         0.1251    0.4824   -0.2028   -0.6188    0.0099   -0.1490   0.006890
WFS2_YAW      0.0120   -0.7957   -0.1793    0.9962   -0.0493    0.2672 -0.013695

Also, I measured the same thing for 100s, and to my surprize, even the signs of coeficients are different.

coef_mat =

   1.0e+05 *

                           MC1_P   MC1_Y  MC2_P   MC2_Y    MC3_P   MC3_Y   constant
WFS1_PIT       -0.1981    0.3065   -0.6084   -0.9349   -0.4002   -0.3538   0.009796
WFS1_YAW     0.0607   -0.6977    0.0592    2.8753    0.3507    0.0373   -0.008194
WFS2_PIT        0.0690    0.4769   -0.2859   -0.7821   -0.1115   -0.2953  0.004150
WFS2_YAW     0.0580   -0.8153   -0.0937    1.1424    0.0650    0.4203  -0.010629

The reason I can understand is that the measurements were not made at the same time, and hence conditions might have changed.

A thing to note in all these coefficients is that they relate the error signals to the 'perturbation' around a certain point (given below). That point is assumed to lie in the linear region.

MC1_PIT      2.6129
MC1_YAW   -5.1781
MC2_PIT       3.6383
MC2_YAW    -1.2872
MC3_PIT      -1.9393
MC3_YAW    -7.518

Last night, we successfully connected and powered our circuit, which allowed us to test whether our OSEMs were working.  Previously, we had been unable to accomplish this because (1) we weren't driving it sufficiently high voltage, and  (2) we didn't check that the colored leads on our circuit actually corresponded to the colored ports on the power supply (they were all switched, which we are in the process of rectifying), so our circuit was improperly connected to the supply .  Unfortunately, we didn't learn this until after nearly cooking our circuit, but luckily there appears to have been no permanent damage .

Our circuit specs suggested powering it with a voltage difference of 48V, so we needed to run our circuit at a difference of at least 36-40 V.  Since our power supply only supplied a difference of up to 30V in each terminal, we combined them in order to produce a voltage of up to double that.  We decided to power our circuit with a voltage difference of 40V (+/- 20V referenced to true ground).  The current at the terminals were 0.06 and 0.13 A. 

To test our circuit, we used a multimeter to check the supplied voltage at different test points, to confirm that an appropriate input bias was given to various circuit elements.  We identified the direction of LED bias on our OSEM, and connected it to our circuit. We were extremely gratified when we looked through the IR viewer and saw that, in fact, the LED in the OSEM was glowing happily .

We hooked up two oscilloscopes and measured the current through the coil, and also through the LED and photodiode in the OSEM.  We observed a change in the photodiode signal when we blocked the LED light, which was expected.  The signal at the PD and the LED were both sinusoidal waves around ~3 kHz.

We then went back to our levitation setup, and crudely tried to levitate a magnet with attached flag by using our hands and adjusting the gain (though we also could have been watching the PD current).  The first flag we tried was a soldering tip; we couldn't levitate this but achieved an interesting sort of baby-step "levitation" (levitation .15) which allowed us to balance the conical flag on its tip on top of the OSEM (stable to small disturbances).  After learning that conical flags are a poor idea, we switched our flag to a smaller-radius cylindrical magnet.  We were much closer to levitating this magnet, but were unable to conclusively levitate it .

 
Current plan:

Adjust the preset resistors to stabilize feedback

Check LED drive circuit.

Finish calculating the transfer function, and hook up the circuit to the spectrum analyzer to measure it as well.

Observe the signal from the photocurrent as disturbances block the LED light.

Play with the gain of the feedback to see how it affects levitation.

 

Single layer of stack successfully modeled in COMSOL. I'm working on trying to add Viton springs now and extend it to a full stack. Having some difficulty with finding consistent parameters to work with.

 Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then

verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.

The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always

specify a very precise test that must be used when we ask for help debugging some complicated software problem.

We gave the Zonet camera the IP 192.168.113.26 and the name Zonet1.

We did this by modifying the /var/named/chroot/var/named/113.168.192.in-addr.arpa.zone and martian.zone files on linux1 as root.

After talking with Rolf, and clarifying exactly which machine I wanted, he gave me an 4600 Sun machine (similar to our current megatron).  I'm currently trying to find a good final place for it, but its at least here at the 40m. 

I also acquired 3 boards to plug our current VMIPMC 5565 RFM cards into, so they can be installed in the IO chassis.  These require +/- 5V power be connected to the top of the RFM board, which would be not possible in the 1U computers, so they have to go in the chassis.  These style boards prevent the top of the chassis from being put on (not that Rolf or Jay have given me tops for the chassis).  I'm planning on using the RFM cards from the East End FE, the LSC FE, and the ASC FE. 

I talked to Jay, and offered to upgrade the old megatron IO chassis myself if that would speed things up.  They have most of the parts, the only question being if Rolf has an extra timing board to put in it.  Todd is putting together a set of instructions on how to put the IO chassis together and he said he'd give me a copy tomorrow or Monday.  I'm currently planning on assembling it on Monday.  At that point I only need 1 more IO chassis from Rolf.

NEW CDS SETUP CHANGE:

When I asked about the dolphin IO chassis, he said we're not planning on using dolphin connections between the chassis and computer anymore.  Apparently there was some long distance telecon with the dolphin people and they said the Dolphin IO chassis connection and RFM doesn't  well together (or something like that - it wasn't very clear from Rolf's description).  Anyways, the other style apparently is now made in a fiber connected version (they weren't a year ago apparently), so he's ordered one.  When I asked why only 1 and what about the IOO computer and chassis, he said that would either require moving the computer/chassis closer or getting another fiber connection (not cheap).

So the current thought I hashed out with Rolf briefly was:

We use one of the thin 1U computers and place that in the 1Y2 rack, to become the IOO machine.  This lets us avoid needing a fiber.  Megatron becomes the LSC/OAF machine, either staying in 1Y3 or possibly moving to 1Y4 depending on the maximum length of dolphin connection because LSC and the SUS machine are still supposed to be connected via the Dolphin switch, to test that topology.

I'm currently working on an update to my CDS diagram with these changes and will attach it to this post later today.

This has been fixed, thanks to some help from Alex. It doesn't correspond to new computers being put in, but rather corresponds to a dcu_id change I had made in the new LSC model.

The fundamental problem is way back when I built the new LSC model using "lsc" as the name instead of something like "tst", I forgot to go to the current frame builder master file (/cvs/cds/caltech/chans/daq/master) and comment out the C1LSC.ini line. Initially there was no conflict with c1susvme, because the initially was dcu_id 13. The dcu_id was eventually changed to 10 from 13 , and thats when it conflicted with the c1susvme2 dcu_id which was also 10. I checked it against wiki edits to my dcu_id list page and I apparently updated the list on May 20th when it changed from 13 to 10, so the time frame fits.  Apparently it was previously conflicting with C0GDS.ini or C1EXC.ini, which both seem to have dcu_id = 13 set, although the C1EXC file is all commented out. The C0GDS.ini file seems to be LSC and ASC test points only.

The solution was to comment out the C1LSC.ini file line in the /cvs/cds/caltech/chans/daq/master file and restart the framebuilder with the fixed file.

Hmm. I expect that you will put more details of the work tomorrow.
i.e. motivation, method, result (the previous entry is only this),
and some discussiona with how to do next.

Nancy and Koji:

This is what I and Koji measured after aligning the MC in the afternoon.

MC_Trans 4.595 (avg)

MC_Refl 0.203 (avg)

MC2_trans :

power = 1.34mW

13.5% width : x=6747.8 +- 20.7 um  , y = 6699.4+- 20.7 um

Rana found out that a connection was bad in the shown place, due to which the MEDM screen was showing bad offset for length control.

Basically, the offset slider value would not go into the system because of that bad connection, and was locking the mode cleaner at the wrong location.

[Rana, Jenne]

We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th.  This corresponds to the same day that some other upgrade computers were installed.  Coincidence?

We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number).  No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000.  Except sometimes it is 0x2000.  Anyhow, it's bad, and we can't make it good again. 

I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)

[Jenne, Kyung Ha]

We made some good progress on suspending the Tip Tilt ECDs today.  We finished one whole set, plus another half.  The half is because one of the screw holes on the lower right ECD somehow got cross threaded.  The ECD and screws in question were separately wrapped in foil to mark them as iffy.  We'll redo that second half tomorrow.  This makes a total of 2.5 (including yesterday's work) ECD backplanes suspended.  The only thing left for these ones is to trim up the excess wire.

We also (with Koji) took a look at the jig used for suspending the mirror holder.  It looks like it was designed for so many Tip Tilt generations ago as to be basically useless for the 40m TTs.  The only really useful thing we'll get out of it is the distance between the suspension block and the mirror holder clamps.  Other than that we'll have to make do by holding the mirror and block at the correct distance apart, utilizing a ruler, calipers, or similar.  Rana pointed out that we should slightly bend the blade springs up a bit, so that when they are holding the load of the mirror holder, they sit flat. 

Attached below are 2 different pictures of one of the ECD backplane sets that has been suspended.  One with black background to illustrate the general structure, and one with foil background to emphasize the wires.

I also removed two of the AM stabilizers from the 1Y2 rack. The other one, which is currently running th MC modulations, is still in the rack, and there it is going to remain together with its distribution box.

I stored both AM stabilizers and the Stochmon box inside the RF cabinet down the East arm.

The 1 Ton yellow crane support beam jammed up at Friday morning, June 25.

The 40m vertex crane has a folding I-beam support to reach targeted areas. The rotating I-beam is 8 ft long. The folding extension arm gives you another 4 ft.

The 12 ft full reach can be achieved by a straightening of the 4 ft piece. There is a spring loaded latch on the top of the I-beam that locks down when the two I-beams align.

This lock joins the two beams into one rigid support beam for the jib trolley to travel.  The position of this latch is visible when standing below, albeit not very well.

To be safe it is essential that this latch is locked down fully before a load is put on the crane.

We were preparing to pump down the 40m vacuum system on Friday morning. The straight alignment of the 8 and 4 ft piece made us believe that

the support beams were locked. In reality, the latch was not locked down. The jib trolley was driven to the end of the 12 ft I-beam. The 200 lbs ITM-east door was lifted

when the 4 ft section folded 50 degrees around the pivot point. This load of door + jib-trolley + 4 ft I-beam made the support beam sag about 6 inches

The door was removed from the jib hoist with the blue Genie-lift. The sagging was reduced to ~3".

The Genie-lift platform was raised to support the sagging crane jib-trolley. The lab was closed off to ensure safety and experts were called in for consultation. It was decided to bring in professional riggers.

Halbert Brothers, Inc. rigging contractor came to the lab Tuesday morning to fix the crane. The job was to unload the I-beam with safety support below. They did a very good job.

The static deformation of I-beams sprung back to normal position. There are some deformation of the I-beam ~2 mm where the beams were jammed under load.

It is not clear if this is a new deformation or if the crane sections have always been mis-aligned by a couple of mm.

The crane was tested with 450 lbs load at 12 ft horizontal travel position. The folding of I-beams were repeatedly tested for safe operation. Its a 1 ton crane, but we tested it with 450 lbs because that's what we had on hand.

We're working on the safety upgrade of this lift to prevent similar accident from happening.

Pictures below:

Atm 1)   load testing 2007

Atm 2)   jammed-sagging under ~400 lbs, horizontal          

Atm.3)   jammed-folded 50 degrees, vertical     

Atm.4)   static deformation of I-beams

Atm.5)   unloading in progress with the help of two A-frames          

Atm.6)   it is unloaded

Atm.7-8) load testing        

Atm.9)   latch locked down for safe operation            

Atm.9)   zoom in of the crane sections misalignment