40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 281 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  6844   Thu Jun 21 09:01:18 2012 steveUpdateSTACISthe resurrection of STACIS -surf

There is a small wood cabinet under the south end flow bench, labeled STACIS.

Unit is complete with extension cards and cables.

Attachment 1: IMG_1364.JPG
  6882   Wed Jun 27 14:18:30 2012 Yaakov SummarySTACISFirst week summary

The beginning of my first week was spent at various orientations and safety meetings, some for general SURF and some more specific to LIGO and the lab. In between these I started  work.

Jenne and I took out the spare STACIS and took it apart, taking out the circuit boards. I've spent some time looking through the boards and sketching various parts of the board in trying to understand the exact function without any useful technical diagrams (STACIS supplied us only with a picture of the board without components, not all that helpful). I think I now at least understand the basic block diagram of the circuitry: the STACIS geophone signal goes through a preamplifier and filters (the semi-circular board), and converts it into a signal for the PZT stacks. This signal then goes through a high voltage amplifer, and then goes to the five PZTs (3 in the z, one each in the x and y direction). The unit I am looking at has an extension board, which allows us to tap into the signal going into the preamp and the one leaving it. This should allow us to input our own signal instead of the geophone signal, and thereby drive the PZTs ourselves.

My next step, once I get a resistor to replace a burnt one on the high voltage amplifier, is to take a transfer function of the STACIS and see if it is possible to drive the PZT stacks with the cables from the extension board. If that does not work, I'll have to keep tracing the circuit to determine where to input our own signal.

  6905   Mon Jul 2 23:08:38 2012 YaakovUpdateSTACISTurning on STACIS

This past Friday I swapped out a burnt resistor on the spare STACIS unit I'm working with and powered it up. Here's the setup:


And here's what happened:

X an Y directions: When I switched from open to closed loop (making the internal geophones provide feedback), the STACIS started making a loud noise- it seemed like it was oscillating uncontrollably.

Z direction: The same thing happened in z until I added some weight to the top of the STACIS- then it quieted down, and seemed to work okay. The geophone signal dropped considerably compared to the open loop signal, which is expected if the feedback is working.

Then I tried driving the PZTs with a signal from the SR785 network analyzer. With an amplitude of tens of mV and frequencies from around .1 to 200 Hz, I could see the accelerometers I mounted on top of the STACIS definitely register motion, which means I was successfully driving the PZTs.


Below are transfer functions of the STACIS as I drove the PZTs from .1 to 100 Hz at 10 mV. The top graph is open loop, the second is closed loop. These were measured with the internal geophones.

In the bottom graph, "A" is closed loop and "B" is open loop, where the transfer functions were taken with the accelerometers instead of the geophones.





Attachment 2: geo_closed.GIF
  6908   Tue Jul 3 18:58:14 2012 YaakovUpdateSTACISMore transfer functions and netGPIB status

I'm still having issues with the STACIS oscillating uncontrollably with the slightest extra vibration, but with some more added weight both x and z direction are stable if you don't disturb the setup.

I took more transfer functions of the STACIS. In the last data I took Jenne pointed out that the geophone signals were not correlated well with the driving signal, so I increased the amplitude of the driving signal and am looking in x and y too instead of just z. 

Details of the driving signal: 25 mV, swept sine from 0.1 to 100 Hz from the SR785. 

NOTE: The data below was all transferred from the SR785 using netGPIB, which works fine, if anyone was interested in using it.

Open loop in the y direction, taken with the y geophone (magnitude on top, phase on bottom):


Open loop in the x direction, taken with the x geophone (with some extra weight to try to make the closed loop more stable):


Open loop in the x direction, taken with accelerometer instead of geophone:


  6963   Wed Jul 11 14:27:29 2012 YaakovSummarySTACISCurrent STACIS Status

The X and Y directions in the STACIS still both oscillate uncontrollably in closed loop, so I'll be doing my testing in Z for now. If I need to use the other axes I'll lower their gain with the pots and add weight to the STACIS platform to try to make it more stable.

Measurements I've taken for Z:

--Open loop gain, taken by driving the PZTs with a swept sine signal and measuring with both internal geophones and external accelerometers. These measurements look a lot like the plots supplied by the STACIS manufacturer, with a resonance at 15-16 Hz (X and Y also look good). Figure below was taken with geophones:


--Open loop gain, where the input is ambient seismic noise measured by one set of accelerometers on the floor and one set on top of the STACIS:


--Closed loop gain, where the input is ambient seismic noise, and feedback is supplied by the geophones (like normal STACIS operation). There's a definite drop in the transfer function, as expected:


--Open and closed loop transfer functions superimposed (the higher one is open):


I am currently working on using the less-noisy accelerometers to provide feedback instead of the geophones. I have found the right point before the extension board to input the accelerometer signal which is NOT the same as the Signal IN/OUT cables- those are at the end of the board, after amplifying and filtering. I want the accelerometer signal to go through the same circuitry as the geophone signal so that the noise of the sensors themselves can be compared.

Problem: Coherence isn't great between the accelerometer sets at low frequencies, which leads to a not very smooth transfer function. I might try using the shaker, because the larger motion may lead to better coherence between the accelerometers on top of the STACIS and at its base.



Attachment 1: geo_open_z.png
  6969   Thu Jul 12 15:43:07 2012 YaakovUpdateSTACISNew input point, using accelerometers for feedback

 Here's a picture of where I am now inputting signals into the STACIS with the accelerometers (the orange and blue wires): 


I know this is the right point because I could see the geophone signal from these points . By inputting a swept sine signal into this point, I was able to take a transfer function of this first amplifier/filtering circuit board, which will be useful if I need to make my own filter for the STACIS:


I have unplugged the geophones and am inputting a signal from an accelerometer into this point. The accelerometers output a different signal than the geophones, so I am trying to modify the accelerometer signal to be closer to the geophone one. I've lowered the gain on all the pots for the z axis and put in several BNC attenuators to lower the accelerometer signal amplitude.

At the moment, using the accelerometers as feedback makes the platform vibration worse, which will hopefully be solved by some more attenuation or filtering of the accelerometer signal.

  6988   Wed Jul 18 13:53:34 2012 YaakovUpdateSTACISWeekly update

I have been working on substituting the internal geophones in the STACIS with accelerometers, and this week specifically I have been trying to modify the accelerometer signal so the STACIS PZTs respond properly.

The major problem was that the high signal amplitude caused the STACIS to oscillate uncontrollably, so I lowered all of the pots (for the z direction) and placed several BNC attenuators before the accelerometer signal enters the first amplifier board. The accelerometers now successfully provide feedback without making the STACIS unstable, as shown by this transfer function (the higher and flatter line is open loop, the lower is closed loop with accelerometers providing feedback):


The next step is to optimize the accelerometer feedback so it provides good isolation from 0.1 to 3 Hz, a span that the geophones introduced a lot of noise into. The accelerometers definitely don't introduce as much noise in that region, but don't seem to be doing much isolation either. I will also make some more quantitative plots of the platform motion (using the calibration value for the Wilcoxon accelerometers in the velocity setting with a gain of 1).

Some random discoveries I made this week which are relevant for STACIS testing:

1) Placing weight on the STACIS platform improves stability, but NOT if several blocks are placed on top of each other (they rub against each other, causing lots of vibrations).

2) The accelerometer that is providing feedback must be VERY securely fastened to the STACIS platform; even with three clamps there was extra motion that caused instability. Luckily, there's a convenient steel flange Steve showed me which has a hole that perfectly accommodates the accelerometer and doubles as a weight for the platform. Here is said flange, clamped to the STACIS platform with the accelerometer sitting in the center:


 3) Using the shaker next to the STACIS (all on one platform) improves coherence between the base and platform accelerometers above around 10 Hz, but does nothing lower than that, which unfortunately is the region I'm most concerned with.

  7027   Wed Jul 25 12:00:21 2012 YaakovUpdateSTACISWeekly update

The past few days I've been working on making a noise budget for the STACIS that incorporates all the different noises that might be contributing.

The noises I am concentrating on are accelerometer noise, geophone noise, electrical noise, and ground noise. Noise from the PZT stacks themselves should be tiny according to various PZT spec sheets, but I haven't actually found a value for it (they all just say it's negligible), so I'll keep it in mind as a potential contributor.

Here's how I am determining accelerometer noise: I take two vertical accelerometers side by side, sitting on a granite block and covered in a foam box, and take the time series of both. Then I take the difference of the time series and calculate the PSD of that, which with the calibration factor of the accelerometers (the V/m/s sensitivity) I am able to find the noise in m/s/rtHz. The noise agreed with the accelerometer specs I found at low frequencies but was higher than expected at high frequencies, so I'm still investigating. If I can't find an obvious problem with my measurements I'll try the three-corner hat method (as per Jenne's recommendation), which would allow me to determine the noises of the independent accelereometers.

I tried a similar method for the geophone noise, but the value I came up with was actually higher than the accelerometer noise, which seems very fishy. I realized that the geophones were still connected to the STACIS circuitry when I took the measurements ,which was probably part of the problem. So this morning I disconnected the STACIS entirely and am looking at just the geophone signals which should give a more accurate noise estimate.

Once I have all the noises characterized, the next step is seeing how those noises affect the closed loop performance of the STACIS. I've been working on a block model that incorporates the different noises and transfer functions involved, and when I have the noises characterized I can test a prediction about how a certain noise affects the platform motion.


  7040   Thu Jul 26 16:08:59 2012 YaakovUpdateSTACISNoise plot update

I have a tentative noise plot for the STACIS that includes accelerometer noise, geophone noise, and platform motion with the STACIS off. (Accelerometer noise was measured for the VEL and NONE setting, which are settings on the accelerometer box which make the accelerometer signal correspond to velocity and acceleration, respectively. ) I'm focusing on sensor noise because this is the variable I am looking at changing, and knowing how the sensor noise translates into STACIS platform motion is therefore important.



The accelerometer and geophone noise I determined as described in my last eLog (http://nodus.ligo.caltech.edu:8080/40m/7027) Along the way I found out several things of importance:

1) Horizontal geophones are ONLY horizontal geophones. This is obvious in retrospect, because the springs supporting the magnet inside must be oriented based on vertical/horizontal operation.

2) The geophones in the STACIS are GS-11D (geospace), with a sensitivity of 32 V/m/s (compared to about 3.9 V/m/s for the accelerometers in VEL setting).

3) The accelerometers have different V/m/s sensitivities. I noticed the voltage output of one was consistently higher than the other, leading to very high noise estimates, but then Jenne showed me the actual calibration factors of the individual accelerometers which differed by as much as 0.4 V/m/s (a few percent difference). Taking this into account made the noise plots much more reasonable, but variations in calibration could still create some error.

The accelerometer noise agrees fairly well with the specs on the Wilcoxon page (http://www.wilcoxon.com/prodpdf/731A-P31%2098079a1.pdf). The geophone noise seems surprisingly low; it is even better than the geophone below about 4 Hz. 

To see how this noise translates into actual platform motion, I took PSDs of the STACIS while it was off, on with accelerometer feedback, and on with geophone feedback (the "off" PSD is in the above noise plot). Using this data I'm working on estimating a transfer function that shows how the sensor noise translates to motion so I can come up with a sensor noise budget.



This shows that the geophones are actually doing a better job of isolating than the accelerometers, which is not surprising if the noise plot is accurate and the geophones are actually lower noise. It must be noted, though, that the noise plot was for the horizontal geophones whereas the plot above is for the vertical axis which may have a different noise level. Also, the vertical have some extra isolation by being enclosed in a metal stack with rubber padding at its base.

The problem with the STACIS in the past was the differential motion it introduced. I think this might be because the horizontal isolation was not uniform for each chamber. This means that even what would be symmetric motion (no differential length change) would be translated to differential motion because one end is more fixed than the other. Having accelerometers or better-padded geophones (maybe like the vertical geophones) in the STACIS ought to help with this by making the horizontal isolation more consistent and thus reducing differential motion. So the key may not be the geophone noise as much as varying geophone sensitivities or variation in how well they're mounted in the STACIS. I can test this by swapping out the horizontal geophones with other spares, changing the tightness of the mount, and seeing if either of these changes the horizontal isolation significantly, since these are factors that may differ from unit to unit.

I will also compare horizontal closed loop response with geophone vs. accelerometer feedback to see if the geophones are only doing a good job in the above plot because of their extra padding (the vertical stack).

  7053   Mon Jul 30 17:24:45 2012 YaakovUpdateSTACISRevised sensor noise plot; dead PZT

The geophone noise in my last eLog was taken before any amplification of the signal, but what really matters is the noise after amplification, since it is this signal that the PZTs are driven by. The noise goes on to be amplified about 1000x before the geophone signal gets to the PZTs.

To obtain a more relevant noise plot, I multiplied the geophone noise by 1,000, the approximate gain of the amplification stage for the geophones (called the "compensator board", the semicircular board that sits toward the top of the STACIS). Below is a plot (sensor_noise.fig) that shows the noise for the geophones after amplification and the accelerometer noise (with accelerometers set with a gain of 100x, their highest).


The actual signal from both these sensors has the right magnitude to drive the PZTs (whereas it was much too small in my last plot, where I looked at the sensors before any gain)- this means that for these sensors, both of which are outputting signals that are ready to provide feedback to the STACIS, the accelerometer noise is significantly lower than the geophone noise. This is good news, because it means that there could be a real advantage to using the accelerometers instead of the geophones.

In the process of investigating further advantages of the accelerometers, I believe I killed one of the horizontal PZTs in the spare STACIS (the eBay one). The story: I had that axis in closed loop, and I saw the STACIS shudder, heard a noise, and there was a faint acrid smell. I shut the STACIS off and took out the high voltage card at the base but couldn't find any visible signs of damage (like the current-limiting resistors which burn when a PZT shorts, acc. to old STACIS records). I then tried driving the PZTs with a sine wave, and there was no response in that axis (the other axes looked fine), which leads me to believe I either did unseen damage to the high voltage amplifier (for the y-axis) or killed the PZT itself.

Attachment 1: sensor_noise.bmp
  7054   Mon Jul 30 22:52:51 2012 YaakovUpdateSTACISGeophone calibration

Tonight I looked at the signal from a geophone and accelerometer side by side, in order to see if they show the same ground motion and if the sensitivity factor I am using to convert from V to m/s is right. This is plotted below, along with the current estimates for accelerometer and geophone noise:



From this it is pretty clear that at least one of the sensitivity factors (V/m/s) I am using is wrong (the noise levels are much lower than the ground motion, so they can't account for the difference). I suspect it is the geophone one, because Wilcoxon provided these sensitivities for each individual accelerometer, but I was just using the number I found in online specs for the geophones.

The reason the online value is wrong is probably because of the value of the shunt resistor, a resistor that just goes across the top of the geophone (its purpose is to provide damping, by Lenz's Law). The specs assume a value of 380 Ohm, but I measured the one in the STACIS to be about 1.85 kOhm.

Assuming the accelerometer signal is correct, I multiplied the geophone signal by different factors to try to get an idea of what the true calibration factor is, and found that a value of 0.25 (m/s)/V gives decent agreement at higher frequencies (below 10 Hz the sensitivity drops off, according to the online specs). This is shown below:



Above, the geophone noise was recalculated with the new sensitivity and assuming that both geophones in the noise measurement had the same sensitivity. I took the transfer function of two geophones side by side to see if their gains were dramatically different; this plot is shown below. The coherence is only good for a small band, but looking at that band the gain is approximately unity, implying very roughly that the sensitivity of each is approximately the same. The lack of coherence is strange, and I'm not sure what the cause is. Even using the shaker near the geophones only improved the coherence slightly.


Attachment 2: sensor_comp2.bmp
  7058   Tue Jul 31 15:24:53 2012 YaakovUpdateSTACISOpen loop gains and block diagram

First, a quick note on the PZT I thought I killed- it was most likely something in the high voltage amplifier that broke, since I put the amplifier in another STACIS with a working y-axis PZT and it still didn't work properly. Conclusion: something in the y-axis amplifier circuitry is broken, not the PZT itself.

Today I retook the open loop gains in the X and Z axes (Y axis out of commission for now, see above). With the loop open, I input a swept sine signal from 0.1 to 100 Hz, and measure the output of the geophones. This way all the transfer function that are present in the closed loop are present here as well: the transfer functions of the physical STACIS, the geophone pre-amplifier circuit, the high-voltage amplifier, and the PZT actuators.

Here is a block diagram showing what I am measuring, with the various transfer functions in blue boxes (the measurement is their product):





These open loop gains show there is gain of at least 10x from 2 to 80 Hz in the z-axis and 2 to 60 Hz in the x-axis. This is the region I was seeing isolation in when I switched to closed loop, which is consistent. These measurements were with all the pots in the geophone preamplifier set very low, so more gain (and thus isolation) is hypothetically possible if I find a way to stop the horizontal axes from becoming unstable at higher gains. There is unity gain at around 0.5 Hz and 100 Hz for the z-axis, but the phase is nowhere near 180 deg. at these points so there shouldn't be instability due to this. The peak at around 15 Hz is consistent with old records of the STACIS open loop gain.

  7061   Tue Jul 31 19:34:55 2012 KojiUpdateSTACISOpen loop gains and block diagram

With your definition of the open loop gain, G=+1 is the condition to have singularity in a closed loop transfer function 1/(1-G).

But this is not the sole criteria of the loop stability.
Basically, the closed loop transfer function should not have "unphysical" pole.
For more about loop instability, you should refer stability criteria in literature such as Nyquist's stability criterion.

Both of the X and Z loops look unstable with the current gain.

  7068   Wed Aug 1 11:54:59 2012 YaakovSummarySTACISGeophone calibration and open loop gains

This week I've looked into finding an accurate sensitivity for the geophones in the STACIS. I found that when placing a geophone and accelerometer side by side, and using the sensitivity values I had from spec sheets, the readings were very different (see eLog 7054: http://nodus.ligo.caltech.edu:8080/40m/7054).

I cut the shunt resistor off one of the STACIS geos and found it to be 4000 Ohm, which is one of the standard values for this geophone model. When it is connected to the geophone the net resistance is 2000 Ohm (I took a more careful measurement, I took the geophone out). Then the internal coil resistance should be 4000 Ohm, if they are connected in parallel. However, the geophone spec sheet does not have a sensitivity value for this exact scenario, so I'll have to find a different way to determine the calibration (maybe by putting it next to a seismometer with a known sensitivity). So I know for sure that the sensitivity value I was originally using is wrong, because it assumed an internal coil resistance of 380 Ohm, but I have to check if the value I found by forcing the geophones to agree with the accelerometers (eLog 7054 --> 0.25 (m/s)/V) is correct.

I've also been looking again at the open loop gains of the STACIS (see eLog 7058: http://nodus.ligo.caltech.edu:8080/40m/7058). Attached is what TMC, which makes the STACIS, says it should look like (with a 4000 lb load on the STACIS). Today I am taking the open loop gains into higher frequencies to get a better comparison, but the plots look quite similar to what I have so far. So if it is an unstable open loop gain, then it's at least not new.

Attachment 1: 08011201.pdf
08011201.pdf 08011201.pdf
  7109   Tue Aug 7 21:34:50 2012 YaakovUpdateSTACISMore noise data

Yesterday I plugged the geophone and accelerometer output into the ADC, rather than the SR785, so I could collect for longer and take more data at once.

As per Rana's suggestion, I am also now taking the geophone output after the first op-amp in the circuitry following the geophone (a low-noise op-amp, OPA227). It acts as a buffer so I'm not just measuring other local noise sources (which explains why the geophone noise curve sort of matched the SR785 noise curve in my old plots).

With these changes, I remeasured the accelerometer and geophone noises as well as collected an ASD of a geophone sitting on the STACIS in open loop operation. I also looked up the noise specs for the various op-amps in the geophone pre-amp and high voltage board; everything I found, I added in quadrature to come up with an approximate op-amp noise value for the STACIS. All of this is plotted below:


I left the y-axis in V/rtHz instead of converting it to m/s/rtHz so that the op-amp noise could be compared to the other noises. All sensor data was taken with the sensors horizontal (noise data taken in granite and foam).

The accelerometer and geophone noise still appear to be similar, and the op-amp noise, at least according to specs, is low compared to the other noises. This implies there's not much to gain from switching the geophones with accelerometers nor with swapping out the op-amps for lower-noise components (unless the ones I couldn't find specs for were high-noise, though it seems like mainly low-noise components were used). 

  7112   Tue Aug 7 23:33:44 2012 ranaUpdateSTACISMore noise data

Looks like you're just measuring the ADC noise. You should add ADC noise to your plot. To compare the geophones with the accelerometers, you have to correct for the preamp gain and plot them both in the same units.

To get above the ADC noise you can use an SR560 preamp. (AC Coupled, G = 100)

  7118   Wed Aug 8 11:47:52 2012 YaakovSummarySTACISWeekly summary

As Rana pointed out (http://nodus.ligo.caltech.edu:8080/40m/7112), the geophone/accelerometer noise lines from my last eLog (http://nodus.ligo.caltech.edu:8080/40m/7109) were dominated by ADC noise. I checked this today by terminating the ADC channels with 50 Ohm terminators and measuring the noise. The ADC noise line is included on the plot below, and it is clearly dominating the sensor noise data.


I set the accelerometer gain to 100, and will hook up the geophones to the SR560 pre-amp today- this should put both signals above the ADC noise, and I can calculate the sensor noises without the ADC noise being significant.

I have also begun to make some progress in understanding the pre-amp circuitry, and I will post a schematic when I've sketched it all.

Another issue that seems increasingly relevant to me is the power supply to the high voltage amplifier. It appears to go into the high voltage board from the power supply, then into the geophone pre-amp, then back into the high voltage board (see block diagram below). I tested this by inputting a signal after the pre-amp, with the geophones disconnected- the signal only drives the PZT if the pre-amp is plugged in, so the power that returns from the pre-amp must be powering some chips on the high voltage amplifier.


Power flow through the STACIS :


This is somewhat inconvenient, because it means if I want to provide external feedback (with accelerometers, for example) or actuation (such as feedforward), which I want to input after the geophone pre-amp, the pre-amp still needs to be plugged in for the high voltage amplifier to work and drive the PZTs.  I am cataloging all of the pins on the high voltage amplifier and pre-amp so I can figure out how to reroute the power and cut out the geophone pre-amp entirely if necessary. I'll include a pin diagram with the pre-amp circuit sketch.

  7148   Fri Aug 10 18:11:55 2012 YaakovUpdateSTACISCorrected noise budget, plan for external actuation

I hope you're not all tired of the STACIs noise budgets, because I have another one! Here, the main difference is my modeling of the geophone sensitivity according to a predicted physical model for the system (just a damped oscillator) instead of trying to fit it to the accelerometer motion signal with more arbitrary functions.

The result of this calibration is shown below (accel and geo signals taken for 5 minutes at the same time, in granite and foam):


The m/s/V sensitivity function I am using is g*[(w^2-2idww(0)-w(0)^2)/w^2], where g (the high freq. m/s/V sensitivity) was 2.5*10^-5 and d (damping) was set to 2.

Now, the recalculated noise plot looks like this:


The accel. specs I took from the Wilcoxon spec sheet, and the geo specs I found in https://dcc.ligo.org/public/0028/T950046/000/T950046-00.pdf, a LIGO document about the STACIS. The geo noise was measured for the STACIS geo and their pre-amp, while I was using the SR560 as the pre-amp. If anything, my noise should be lower, since the SR560 noise spec is lower than what I estimated for the STACIS geophone pre-amp, so I'm not sure about that order of magnitude difference between the experimental and expected geo noise. A sign that my noise values are at least reasonable is that the geophone noise flattens out above the geophone's resonant frequency (4.5 Hz), as Jan pointed out it should.

The sensor noise (either accel. or geo.) is the dominating signal below 1 Hz in the STACIS platform measurement, which then limits the closed loop performance at those frequencies. Since the noises I am finding are looking reasonable, I think it's fair to definitively state that accelerometers will not significantly help at low frequencies (there may be at most a factor of 2 lower noise below 1 Hz for the accel., but I need more data to say for sure).

The plan right now is to concentrate on using the STACIS as actuators, perhaps with seismometers on the ground and a feedforward signal sent into the high voltage amplifier.

I took the transfer function of the high voltage board itself (no pre-amp included) by driving the PZTs with a swept sine and measuring the accelerometer response (which I am now fairly confident is calibrated correctly). The input point was the signal IN on the extender board, but with the geophones disconnected from the pre-amp.


I took the coherence at just a few single frequencies (you can't do coherence measurements in swept sine mode on the SR785) to make sure I was really driving the PZTs, and it was near 1 (998, 999.9, etc) at the frequencies at which I drove. Without the extra notches at 1 Hz (which may be real, it's coherent there too), it looks like a 2-pole high pass filter (goes from -180 to 180 deg, approx. an f^2 dependence). This transfer function should be taken into account by the feedforward algorithm.

The current plan is to make a box with a switch that allows geophone feedback and/or external signals into the high voltage amplifier. It would act sort of like the extender card, except more compact so it could fit into the STACIS. It also would have the advantage of not having to reroute the power, since those lines from the pre-amp could all still be connected (see eLog 7118: http://nodus.ligo.caltech.edu:8080/40m/7118).

  7166   Mon Aug 13 21:47:30 2012 YaakovUpdateSTACISTwo changes to STACIS noise budget

In eLog 7148 (http://nodus.ligo.caltech.edu:8080/40m/7148), Koji pointed out that the op-amp and SR560 noise values (which I took from specs and then multiplied by the geophone calibration factor to get m/s/rtHz) were waaay too low. My error was an extra multiplication factor in the plotting script.

The other change was recalculating the ADC noise by splitting a signal into two ADC channels and subtracting the time series (then taking the PSD and converting to m/s/rtHz). It compares well to the value I got by terminating the ADC channels, which was the ADC noise line in my last eLog.

Both these changes are included in the below plot:


Attachment 1: noise_budget_8-13.bmp
  7190   Wed Aug 15 11:40:15 2012 YaakovSummarySTACISWeekly Summary

This week I've been focusing mainly on two things: 1) Designing a port for the STACIS that will allow external actuation and/or local feedback and 2) Investigating the seismic differential motion along the interferometer arms.

The circuit for the port is just a signal summing junction (in case we want to do feedforward and feedback at the same time) with BNC inputs for the external signal and switches that allow you to turn the external signal or feedback signal on/off. I'll test this on a breadboard and post the schematic if it works. I looked at the noise of the geophone pre-amp and DAC, which would be the feedback and external signal sources, respectively. According to Rolf Bork, the DAC noise is 700 nV/rtHz, and I measured the pre-amp board's minimum noise level at 20*10^-6 V/rtHz (which seems quite high). Both these noises are higher than the op-amp noise for my circuit (I'm considering the op-amp LT1012), which according to the specs is 30 nV/rtHz. This confirms that my circuit will not be the limiting noise source

Along with Den, I calibrated the seismometers in the lab and measured the displacement differential arm motion (see eLog 7186: http://nodus.ligo.caltech.edu:8080/40m/7186). I'm trying to find a transfer function for the seismic stacks (and pendulum, but that's simpler) so I can calculate the differential motion in the chamber. After doing this offline, I'll make new channels in the PEM to look at the ground and chamber differential motion along the arms online.

I also am looking at the noise of the geophones with their shunt resistor (4k resistor across the coil) removed, to see if it improves the noise at low frequencies. My motivation for this was that the geophone specs show a better V/m/s sensitivity at low frequencies when the shunt resistor is removed, so the actual signal may become larger than the internal noise at these frequencies.

  7210   Thu Aug 16 20:18:39 2012 YaakovUpdateSTACISInput for feedforward/feedback in the STACIS

Below is the bottom view of the geophone preamplifier and controller for the STACIS. It slides into the upper part of the STACIS, under the blue platform. The geophone signal goes in the bottom left, gets amplified, filtered, and otherwise pampered, and goes out from the bottom right. From there it goes on to the high voltage amplifier, and finally to the PZT stacks. Below right is a closer view of the output port for the preamplifier, top and bottom.


I suggest de-soldering and bending up the pins that carry the geophone signal (so the signals don't go directly to the high voltage amplifier), and adding the circuit below between the preamp and amplifier. The preamp connector is still attached to the high voltage amplifier connector in this setup, only the geophone signal pins are disconnected.


More on the circuit and its placement:

The first op-amp is a summing junction, and the second is just a unity gain inverter so that signal doesn't go into the high voltage amplifier inverted. I tested this with the breadboard, and it seems to work fine (amplitudes of two signals add, no obvious distortion). The switches allow you to choose local feedback, external feedforward, or both.

The geo input will be wires from the preamp (soldered to where the pins used to go), and the external input will be BNC cables, with the source probably a DAC. The output will go to the bent up pins that used to be connected to the preamp (they go into the high voltage amplifier). This circuit can sit outside of the STACIS- there is a place to feed wires in and out right near where the preamplifier sits. For power, it can use the STACIS preamp supply, which is +/- 15V. The resistors I used in the breadboard test were 10 kOhm, and the op-amp I used was LT1012 (whose noise should be less than either input, see eLog 7190).

This is visually represented below, with the preamp pin diagram corresponding to the soldering points with the preamp upside down (top right picture):



  7231   Sun Aug 19 19:56:20 2012 YaakovUpdateSTACISSTACIS signal box made

I made the signal box as described in eLog 7210. It adds the geophone signal and an external signal.

It has six switches, for x, y, and z signals from both an external and local (geophone) source. The x signals add if both x switches are flipped down (and the same for the other directions). For example, if you want to feed in only an external signal in the x direction, flip down the external x direction switch (it's labeled on the box), leaving all others flipped up.

The x, y, and z outputs are wired to the pins from the preamplifier that go to the high voltage board. These I disconnected from the preamplifier by cutting at their base (there are spare connectors if this wants to be undone, or, a wire can just be soldered from the pin to its old spot on the board). The power (plus/minus) and ground are wired to the respective pins from the geophone preamplifier (naturally, the STACIS must be turned on for the box to work since the box shares its power source). Below, the front (switches and geophone/external inputs) and back (power, ground, outputs) of the box are shown:


The preamplifier can plug into its regular connectors- the x,y,and z signals will all be redirected to the signal box with these modifications. The box sits outside the STACIS, there is room to feed the wires out from underneath the STACIS platform.


NOTE: The geophone z switch is a little different than the others, just make sure it's flipped all the way down if you want that signal to be seen in the z output.


  7258   Thu Aug 23 15:42:48 2012 ranaUpdateSTACISSTACIS signal box made


 I found this entry in the old 40m ilog which describes the STACIS performance. It shows that even though the STACIS is bad for the differential arm motion below 3 Hz. It has quite a big and positive effect at 10-30 Hz. The OSEMs show a bigger effect than what the single arm does. I think this is because the single arm is limited by the MC frequency noise above 10 Hz.

We should figure out how to turn on the STACIS but set the lower UGF to be ~5 Hz.

Attachment 1: vsanni-1107222997.pdf
  34   Wed Oct 31 08:33:54 2007 ranaProblem FixedSUSVent measurements
There was a power outage during the day yesterday; whoever was around should post something here about the
exact times. Andrey and David and Tobin got the computers back up - there were some hiccups which you can
read about in David's forthcoming elog entry.

We restarted a few of the locking scripts on op340m: FSSSlowServo, MCautolocker. Along with the updates
to the cold restart procedures we have to put an entry in there for op340m and a list of what scripts
to restart.

David tuned up the FSS Slow PID parameters a little; he and Andrey will log some entry about the proper
PID recipe very soon. We tested the new settings and the step response looks good.

We got the MC locking with no fuss. The 5.6 EQ in San Francisco tripped all of the watchdogs and I upped
the trip levels to keep them OK. We should hound Rob relentlessly to put the watchdog rampdown.pl into
the crontab for op340m.
  66   Tue Nov 6 09:45:22 2007 steveSummarySUSvent sus trend
The mc optics dragwippings were done by locking optics by eq stops and rotating-moving
cages so access were good. This technic worked well with mc1 & mc2
MC3 osems were reoriented only.
Attachment 1: ventsustrend.jpg
  70   Tue Nov 6 15:37:34 2007 robConfigurationSUSrampdown script
/cvs/cds/caltech/scripts/SUS/rampdown.pl is now in the crontab for op340m, running every half-hour at 15&45. It checks the suspension watchdog trip levels, and reduces them by 20 if they are above 150.
  91   Sun Nov 11 21:05:55 2007 ranaHowToSUSMC Touching or not
I wrote a script: SUS/freeswing-mc.csh, which gives the MC mirrors the appropriate kicks
needed to make a measurement of the free swinging peaks in the way that Sonia did.

set ifo = C1
set sus = ${ifo}:SUS-

foreach opt (MC1 MC2 MC3)

  set c = `ezcaread -n ${sus}${opt}_PD_MAX_VAR`
  ezcastep ${sus}${opt}_PD_MAX_VAR +300

  ezcaswitch ${sus}${opt}_ULCOIL OFFSET ON
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
  sleep 1
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
  sleep 1
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
  sleep 1
  ezcawrite ${sus}${opt}_LATCH_OFF 0

  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
  ezcaswitch ${sus}${opt}_ULCOIL OFFSET OFF

  ezcawrite ${sus}${opt}_PD_MAX_VAR $c



It basically ups the watchdog threshold, wacks it around at the pendulum frequency, and then disables the
optic so that there are no electronic forces applied to it besides the bias. The date command at the end
is so that you know when to start your DTT or mDV or lalapps code or whatever.
  122   Mon Nov 26 10:17:31 2007 steveOmnistructureSUSetmy sus damping restored
20 days plot is showing etmy loosing damping 4 times.
I zoomed in with each event. Three of them could of been triggered
by garbage loading just outside. However attachment 2 plot demonstrating that small earthquake or seismic event
did not tripped etmy damping.
The fourth event was preceded by a 4-5 hrs of continous rise of the rms motion at C1:SUS-ETMY_LLPD_VAR
Attachment 1: etmyrms20d.jpg
Attachment 2: etmyrmseq.jpg
  133   Wed Nov 28 17:15:26 2007 ranaConfigurationSUSETMY damping / watchdogs
Steve has noted that ETMY was often tripping its watchdog. I saw this again today.

So I checked the damping settings. Someone had set the SIDE gain to +1. The gain which gives
it a Q of ~10 is +10. I set the SIDE gain to +20. I checked and the ETMX gain is -16 so now
they're at least similar. I have updated the snapshot to reflect the new value.

Hopefully now it will be more well behaved.
  148   Fri Nov 30 19:29:14 2007 ranaConfigurationSUSnew screen
Andrey is working on a new screen to show us the drift of the optics by alarming on
their osem values. You can find it under SUS as 'Drift Mon' from the site map.

To aid in this I ran the following csh commands which effect all optics:
  foreach dof (POS PIT YAW)
     ezcawrite C1:SUS-${opt}_SUS${dof}_INMON.PREC 0

This should make the DOF readouts more readable.
  176   Thu Dec 6 19:19:47 2007 AndreyConfigurationSUSSuspension damping Gain was restored

Suspension damping gain was disabled for some reason (all the indicators in the most right part of the screen C1SUS_ETMX.adl were red), it is now restored.
  213   Wed Dec 26 15:00:06 2007 ranaUpdateSUSETMY tripping
Steve mentioned to me that ETMY is still tripping more than ETMX. The attached DV plot
shows the trend of the watchdog sensors; essentially the RMS fluctuations of the shadow
sensors. (note** DV can make PNG format plots directly which are much better than JPG
when making plots and much smaller than PS or PDF when plotting lots of points).
Attachment 1: etm.png
  214   Wed Dec 26 15:12:48 2007 ranaUpdateSUSETMY tripping
It turned out that the ETMY POS damping gain was set to 1.0 while the ETMX had 3.8.

I put both ETMs to a POS gain of 4 and then also set the PIT, YAW and SIDE gains for
ETMY. Let's see if its more stable now.

In the next week or so Andrey should have perfected his damping gain setting technique
and the numbers should be set more scientifically.
  216   Thu Dec 27 13:08:04 2007 ranaUpdateSUSETMY tripping
Here's a trend from the last 2 days of ETMX and ETMY. You can see that the damping gain increase
has made them now act much more alike. Problem fixed.
Attachment 1: Untitled.png
  220   Thu Jan 3 08:53:55 2008 steveUpdateSUSetmy vs etmx
Rana have corrected sus gain damping setting of ETMY 8 days ago

gain settings: pos, pit, yaw & sd
etmx: 4,2,2,& -16
etmy: 4,2,2,& 50
Attachment 1: sus.jpg
  222   Thu Jan 3 09:55:11 2008 steveUpdateSUSetmy sus damping restored
ETMY watch dog was lost at midnight
Attachment 1: etmy12h.jpg
  225   Fri Jan 4 08:42:03 2008 steveUpdateSUSetmy trips again
ETMY sus damping tripped at 6am this morning
It was reset. We should put an accelerometer to the south end to see
the garbage dumping effect.
Attachment 1: etmy20m.jpg
Attachment 2: etmy120s.jpg
Attachment 3: etmysenV.jpg
  226   Mon Jan 7 09:01:39 2008 steveUpdateSUSBS sus damping restored
The BS sus damping was lost at 8am Sunday morning.
Attachment 1: bssdl.jpg
  232   Thu Jan 10 10:38:02 2008 steveUpdateSUSetmy damping restored
The IST building onstruction has really started yesterday and continuing today with big heavy ground breaking
machinary. The MC is holding lock and the suspentions are hanging on.

ETMY does not like this.

SUS-MC2_LLPD_VAR monitor is a good indicator of seismic activity on this 12 days plot
Attachment 1: etmysus.jpg
Attachment 2: sustrend16d.jpg
  233   Thu Jan 10 12:08:23 2008 steveUpdateSUSwhy did the BS move?
Attachment 1: bshopped.jpg
  235   Thu Jan 10 15:04:04 2008 steveUpdateSUSilluminator light effect on BS position
The bs chamber illuminator light was turned on this morning and left on.
Earlier on Rana noticed that the bs moved.
I follwed up to see what happened. I turned off oplev servo and tried to recenter on oplev pd
by adjusting pitch and yaw biases. It did not move. I looked at suspention and realized that the
illuminator was still on. I turned it off and to my amazement the the AP spot started flashing
Attachment 1: bssusilum.jpg
  237   Mon Jan 14 14:41:09 2008 steveUpdateSUSetmy sus damping restored & mz relocked
Tree days trend of MZ HV drift is typical these days.
So as the etmy sus inability to hold damping for longer then 2-3 days.
Attachment 1: etmysus&mzhvtrend.jpg
  242   Wed Jan 16 18:24:41 2008 ranaUpdateSUSETMY Watchdog
Because Steve keeps complaining about ETMY, I looked at some minute trend to see if there was something exotic happening at that time. It looks like there is some tremendous seismic activity to make it happen.

The trend shows that there is nothing special happening on the ETMX accelerometer or the ETMX suspension. At the same time, however, there is a huge jump in the ETMY sensors and therefore the watchdog signal. Whenever the watchdog value goes above 140, it trips.

After Andrey moves some accelerometers over to the Y end we can see the effect more directly.
Attachment 1: A.pdf
  256   Wed Jan 23 12:31:36 2008 AndreySummarySUSDissapointing Results of XARM optimization (PDF-file)

I attach a PDF-file which summarizes briefly the results of measurements/calculations of Q-factors for ITMX mass as a function of suspension damping gain,

and this file contains the results of measurements of RMS peaks on the values of suspension gains of ITMX and ETMX (see ELOG entries from December 2007, specifically #202, #199, #194)),
but now those dependences are plotted in Q-ITMX and Q_ETMX axes.

Unfortunately, there are no clear narrow areas of minimum in those dependences (that explains the sad title of this ELOG entry).

The attached pdf-file can be shown as a short presentation for a wall during our Wednesday meeting.
Attachment 1: Sad_Results_XARM.pdf
Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf
  260   Thu Jan 24 20:03:40 2008 AndreyConfigurationSUSChanges to Dataviewer channels (XARM)

1) Good news. I added a chanel "C1:SUS-ETMX_POS" to Dataviewer.

I followed the instructions from WIKI-40:

modify the file "C1SUS_EX.ini" in /cvs/cds/caltech/chans/daq,
then telnet to fb40m,
then "click the appropriate blue button on the DAQ MEDM screen".

So, I can now read a signal from the channel "C1:SUS-ETMX_POS" in Dataviewer,

and this allows me to measure Q-factors of ETMX this evening (make similar work for what I did on Tuesday for ITMX).

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).

Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.

Again, I apologize and hope that the problem is not very serious.
  265   Fri Jan 25 10:14:35 2008 robConfigurationSUSChanges to Dataviewer channels (XARM)


2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).

Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.

I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.
  286   Wed Jan 30 13:09:55 2008 AndreyUpdateSUSNew results for XARM (pdf)

See attachments: pdf-presentation with plots in "true" axes Q_ETMX and Q_ITMX, and seismic backgound measurement.

Results that were shown a week ago turned out to be not sad at all!
Attachment 1: New_Results_XARM.pdf
New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf
Attachment 2: Accel-Seismic_10AM.pdf
  305   Sat Feb 9 13:32:07 2008 JohnSummarySUSAll watchdogs tripped
When I arrived this afternoon the watchdogs had tripped on all optics. I reset them and enabled the coil currents.

I had to adjust the alignment of the mode cleaner to get it to lock.
  306   Sun Feb 10 20:47:01 2008 AlanSummarySUSAll watchdogs tripped
A moderate earthquake occurred at 11:12:06 PM (PST) on Friday, February 8, 2008.
The magnitude 5.1 event occurred 21 km (13 miles) NW of Guadalupe Victoria, Baja California, Mexico.
  323   Tue Feb 19 15:21:47 2008 AndreyUpdateSUSEarthquake tripped watchdogs in ETMY, ITMY

According to the web-page http://earthquake.usgs.gov/eqcenter/recenteqsus/Quakes/ci14351140.php ,

there was a 5.0 earthquake in northern Baja California in Mexico at 02.41PM earlier today.

This earthquake made an effect on our watchdogs for ETMY and ITMY (their currents exceeded maximal values).
Watchdogs for ITMY are now restored back,
and it is taking more time for a "side degree" for ETMY to calm down,
it is still (40 minutes after the kick) swinging a lot with amplitude ~ 200mV.
ELOG V3.1.3-